Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews1

Critical PHP vulnerabilities patched: what website owners should check

Fixes for two critical PHP vulnerabilities were released on 21 October, and on 23 October the developers clarified an additional rare risk. We explain the fixed versions and what to ask the administrator of a 1C-Bitrix website or another PHP-based system.

АльбинаCommunity author★ 142
Comments 0

A specialist seen from behind beside a server rack in a data centre
In this article

On 21 October 2026, the PHP developers released fixes for two critical vulnerabilities that can, under certain conditions, allow unauthenticated code execution on a server. If your website runs on PHP, now is the time to obtain confirmation of the update from your administrator or hosting provider. This also applies to websites running on 1C-Bitrix: the PHP runtime serving web requests is what needs to be checked.

For a business owner, the priority is to confirm that the PHP runtime actually serving the website has received the fix, then test the store's key operations. An accessible home page alone tells you nothing about whether the fix is installed.

What is known as of 23 October

The official PHP advisory of 21 October lists CVE-2026-109618 and CVE-2026-109619. The developers urge users to update installations that serve web requests. The risk affects different ways of running PHP; a particularly dangerous scenario has been described for Apache with mod_php, where the attack is triggered before application code runs.

The PHP Foundation confirms the severity of both vulnerabilities. They concern memory management and the handling of PHP's internal state. A vulnerable version requires investigation and an update, but does not in itself prove that a particular website has already been compromised. The Foundation also confirms code execution through certain application-level paths on PHP-FPM; this environment must not be assumed safe.

Amazon Threat Intelligence reported PHP2Shell exploitation attempts detected by its monitoring systems from 17 October, before public disclosure. The report specifically notes that it is unclear whether the observed attempts would have succeeded against real-world systems. This is a reason to accelerate protection, rather than declare all PHP websites compromised.

Which versions include the fixes

  • PHP 8.5 — fixes were released in 8.5.12.
  • PHP 8.4 — in 8.4.27.
  • PHP 8.3 — in 8.3.36.
  • PHP 8.2 — in 8.2.35.

These are the PHP project's releases dated 21 October. A Linux distribution or long-term support vendor may backport the fix to a package with a different version number. Decisions should therefore be based on the vendor's advisory and the installed package version, rather than a comparison of short version numbers alone.

For PHP 8.1 and older, check support status and the availability of a fix with the vendor separately. The PHP project itself no longer provides regular updates for these branches; migration to a supported branch should be planned with website compatibility testing.

PHP's clarification of 23 October

On 23 October, PHP published an additional advisory on a rare code execution scenario, assigned CVE-2026-115560. It depends on an unusual combination of configuration and application code: the session serialization format, changing it during a request, and upload progress tracking being enabled. PHP plans to publish a full advisory and a fix in its regular release cycle; the announcement did not specify the date of the next release.

Ask the administrator to assess separately whether this clarification applies after installing the fixes released on 21 October. PHP recommends temporarily disabling session upload progress tracking until the next release to protect against this scenario. If the application never changes the serialization handler at runtime, PHP says the feature can remain enabled. Choose the setting with the application in mind and test file uploads; if the feature was disabled earlier, keep it disabled.

What to ask the person responsible for the website

  1. Identify the PHP runtime and package serving each website. The command-line version and the version serving web requests may differ.

  2. Confirm that both CVEs have been addressed: identify the package, the source of the fix, and when it was installed. Saying that the server has been updated is insufficient without identifying the runtime concerned.

  3. Check that the processes serving the website are using the fixed build. The administrator should determine the necessary restarts and maintenance window based on the architecture.

  4. After the update, test login, forms, the cart, checkout, uploads, and exchanges with external systems — the features that are actually used.

  5. Assess signs of possible compromise separately. Updating closes the vulnerability, but does not remove the consequences of an intrusion that has already occurred.

On shared hosting, start with the provider's support team: the PHP settings in the control panel do not always show full package details. For a VPS or dedicated server, appoint a responsible administrator and request the same confirmations. If a server hosts several websites, checking one domain does not establish the status of the other runtimes.

If an update is not yet possible

PHP states that configuration changes do not fully mitigate both vulnerabilities. Temporary measures must be chosen according to the official advisory and the conditions of the particular system. Do not copy memory or file upload limit settings to a production server without testing: they may change application behaviour and the store's availability.

Keep protective measures separate from the investigation. The administrator should check for unexpected file changes, process execution, and web server logs. Where logs are available, the review period should start no later than 17 October; preserve the logs before they are cleared or overwritten. If there are signs of intrusion, preserve the available evidence and involve an incident response specialist. Having a patch installed does not replace this review.

What constitutes a sufficient response

A useful outcome is confirmation for every runtime in use: both vulnerabilities have been fixed with a package from an identified vendor, the running processes are using the update, the website's key workflows have been tested, and any signs of suspicious activity are being investigated separately.

Information current as of 23 October 2026, 17:58 Moscow time. Sources: the PHP advisories of 21 and 23 October, the PHP Foundation, and Amazon Threat Intelligence. This article explains the published information and the checks to perform; the status of a particular website or infrastructure must be established separately.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.