Critical PHP Security Vulnerabilities: Is Your Website at Risk? (October 2026)

What has happened

On 21 October 2026, the PHP project released urgent fixes for two critical memory-handling vulnerabilities: CVE-2026-109618 and CVE-2026-109619. In affected configurations, crafted web requests may allow an unauthenticated attacker to execute code in the PHP process.

The risk concerns the PHP runtime behind web applications, not just a particular content management system. Websites using frameworks and applications such as WordPress, Drupal or bespoke PHP code may rely on the same affected runtime. Whether a specific host is vulnerable depends on the PHP build actually serving requests.

The UK National Cyber Security Centre has urged organisations to act promptly. Reports of a possible exploit and evidence of widespread compromise must be treated as different claims; do not assume a host was compromised solely because it ran an affected version.

Which versions need checking

The PHP project's fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Earlier builds within those branches need updating. PHP 8.1 and older no longer receive regular upstream releases, though Linux distributors or extended-support providers may supply backported fixes.

Check the version of PHP that handles actual website requests. A server can contain several PHP runtimes: a command-line interpreter, multiple PHP-FPM pools, Apache modules or application-specific containers. A successful command-line version check alone does not prove the websites are running a fixed build.

• For PHP 8.5, the fixed upstream release is 8.5.12.
• For PHP 8.4, the fixed upstream release is 8.4.27.
• For PHP 8.3, the fixed upstream release is 8.3.36.
• For PHP 8.2, the fixed upstream release is 8.2.35.
• If your distribution packages PHP with security backports, confirm the exact fixed package and advisory with that distributor instead of relying on the displayed major/minor version alone.

Identify where PHP is running

Start with the websites and applications your organisation publishes. Hosting panels, configuration management, server inventories and container definitions can help identify which PHP runtime each site uses. Include forgotten subdomains, staging environments and administrative interfaces exposed through the same infrastructure.

1. List the internet-facing applications that use PHP and identify their hosting providers, servers or containers.
2. On a server you administer, use the following read-only command as one quick check of the command-line interpreter. Record its result, then separately establish which PHP build serves each site.
   bashCopy

   php -v

3. Check the configured PHP-FPM pools, web-server modules, hosting panel versions or container image references appropriate to your environment. Review the vendor's security advisory for each installed package.
4. Compare each actively used runtime against the relevant upstream or distribution-specific fixed release and prioritise public-facing services.

Apply the security update

Apply the fixed runtime using the update mechanism supported by your hosting provider, operating system vendor or application platform. If PHP is inside a container, rebuild or redeploy the application using a fixed image and confirm the running container has actually changed.

Updating PHP can affect extensions or application compatibility. Preserve a usable backup and plan for the appropriate service reload or restart, while keeping the exposure window as short as reasonably possible.

1. Read the PHP project advisory and your distribution or hosting vendor's specific package notice. Identify the appropriate fixed release for every active runtime.
2. Apply that approved package, image or hosted-runtime update, then restart or reload the affected web-serving processes as required by your platform.
3. Check each production site's actual PHP runtime after the change, then exercise the main application functions and inspect runtime and application logs for failures.
4. Record which services were checked and which remain pending. If a site cannot be updated promptly, assess restricting public exposure while an authorised upgrade route is prepared.

What if immediate patching is not possible?

The PHP project states that configuration changes cannot fully eliminate these vulnerabilities. Its advisory discusses mitigations that reduce particular attack paths, but organisations should not treat a web application firewall rule or PHP configuration change as equivalent to a fixed runtime.

For an affected internet-facing service that cannot yet be patched, consider temporarily restricting access or taking it out of public service if operationally feasible. Use the PHP project's own detailed guidance before applying any interim PHP memory or request-size changes: those changes can affect application behaviour or availability.

If there is evidence of suspicious activity, follow your incident-response process. Installing an update prevents the known vulnerable path but does not by itself establish whether earlier compromise occurred.

How to confirm the immediate work is complete

The immediate goal is a verified inventory and a fixed runtime on each in-scope service, with an explicit record of any exceptions. The PHP and UK NCSC advisories are the source of truth for new corrections.

• Every internet-facing PHP application is mapped to its actual executing PHP runtime.
• Each runtime is updated to a fixed upstream release or an explicitly confirmed vendor-backported package.
• The running service version is rechecked after the required restart or container replacement.
• A basic functional test succeeds and outstanding exceptions have an owner and an interim exposure decision.
• Any later change to official affected-version or mitigation guidance is reassessed against the same inventory.