PHP Just Patched Two Critical RCE Flaws. Find Every Server Before Attackers Do.

Introduction

On 20 October 2026 the PHP security team gave advance notice of a security release, warning that two critical vulnerabilities, both rated CVSS v4.0 9.2, would be fixed the following day at 14:00 UTC. It also reserved the right to release early if details leaked or exploitation appeared in the wild.

The fixes are now out. On 21 October 2026 PHP published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and told every user to update immediately. The two flaws, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote code execution on web servers running PHP. The UK National Cyber Security Centre has encouraged UK organisations to take immediate action.

PHP is not an edge appliance sitting in one rack. It sits underneath customer portals, content management systems, internal tools, supplier products and appliances that bundle it without saying so on the box. That is what makes this release different from a typical patch day. The hard part is not applying the update. It is finding every place PHP runs.

This article explains what the two flaws are, who is affected, why it matters to the business, how penetration testers find exposed and vulnerable PHP, and what to do this week.

What the Two Flaws Are

Both vulnerabilities live in the core of PHP itself, in the php-src project, not in a particular framework or plugin. Both are about the way PHP handles memory and internal state around the start and end of a web request. Both carry the same CVSS v4.0 vector in the official GitHub advisories: network attack vector, no privileges and no user interaction required, with high attack complexity and specific attack requirements.

CVE-2026-109618: remote code execution via out-of-memory corruption

The GitHub advisory GHSA-w8hw-w9fx-j79w explains that PHP jumps out of the current context when it runs out of memory. In some places, request memory is briefly reachable before it is fully initialised. If any allocation fails at that moment, the request is left in an invalid state, and the shutdown procedure may then read or act on that invalid data.

The advisory describes several ways an attacker can push a request into an out-of-memory condition while it still appears to sit within PHP's limits. These centre on multipart form parsing: requests without a usable declared content length, parts with an unrestricted number of headers, and empty file controls combined with nested field names. The key point for defenders is simple. This is triggered by how PHP parses an incoming request, so with Apache mod_php it can happen before any of your application code runs.

CVE-2026-109619: remote code execution via stale global state

The GitHub advisory GHSA-6wmf-4rv5-p3rp covers a different weakness. PHP workers hold global state, such as error, session, object and extension state, that can point into memory owned by a single request. If that state is not reset properly, a later request handled by the same worker can use it after the memory has been freed. That is a use-after-free, and PHP says a carefully shaped heap layout can turn it into full remote code execution.

Exploitation needs two halves. One request has to leave the stale state behind, for example through a fatal error, a timeout or memory exhaustion. A later request on the same worker then has to touch that state before normal initialisation clears it. The advisory names two confirmed ways that later step happens: warnings raised while applying invalid or deprecated INI settings early in a request, and PHP's session upload progress feature, which is enabled by default and does not need the application to call session_start().

The advisory is also clear that hiding errors does not help. Changing error_reporting, using @, or turning off display_errors does not protect against this vulnerability.

Who Is Affected

According to PHP's security advisory, the risk applies to all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The official version information is:

• PHP 8.5 before 8.5.12 is affected. Fixed in 8.5.12.
• PHP 8.4 before 8.4.27 is affected. Fixed in 8.4.27.
• PHP 8.3 before 8.3.36 is affected. Fixed in 8.3.36.
• PHP 8.2 before 8.2.35 is affected. Fixed in 8.2.35. PHP notes that 8.2 reaches end of life on 31 December 2026.
• PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, the PHP security team published minimal source backports for PHP 7.4, PHP 8.0 and PHP 8.1, and recommends contacting your LTS vendor or upgrading.

The NCSC's position is broader still. Its guidance says organisations using any version of PHP are affected, and that discovery should not be limited to outdated versions.

Exposure is not equal across deployments. PHP considers the risk highest for Apache mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. For CVE-2026-109618, the advisory says source analysis supports PHP-FPM as susceptible, although no complete FPM exploit had been demonstrated. For CVE-2026-109619, session lifecycle remote code execution was validated against both mod_php and FPM, with the FPM path depending on a suitable application operation.

Is it being exploited?

At the time of writing, neither the PHP advisory nor the NCSC reports confirmed exploitation in the wild, and neither CVE appears in CISA's Known Exploited Vulnerabilities catalogue. The NVD records were still at the "Received" stage, not yet analysed, on publication day. That is not a reason to wait. Full technical write-ups are now public, and the NCSC tells organisations that cannot update to assess their systems for evidence of compromise and look for backdoors.

Why This Matters to the Business

The confirmed impact, in PHP's words, is unauthenticated remote code execution as the web worker account. In business terms, that means an attacker who never logs in could run commands on the server that hosts your website, portal or internal tool.

What happens next depends on what that server can reach. In our work we regularly find that web servers hold database credentials, API keys for payment and CRM platforms, and network routes into internal systems. A foothold on one PHP host is rarely the end of the story. It is the start of an attack path.

That has direct consequences for leadership:

• Customer data. Web applications usually sit next to the personal data that UK GDPR obliges you to protect.
• Service availability. Both flaws are rooted in memory handling. PHP itself warns that request size controls reduce denial of service risk even after patching.
• Supply chain. The NCSC specifically warns that appliances and third-party products may bundle PHP. You may be exposed through a product you never think of as "a PHP application".
• Evidence. Boards, insurers and customers will ask whether you were affected and how you know. "We patched the servers we knew about" is a weak answer.

None of that requires catastrophising. It requires an accurate inventory and a verified fix.

How Penetration Testers Find Exposed and Vulnerable PHP

Vulnerability scanners are useful here, but they mostly report what a server says about itself. A penetration test answers a harder question: where does PHP actually run, can an attacker reach it, and does the configuration make these flaws exploitable? This is how our team approaches it, without running exploit code against production systems.

External discovery

• Attack surface mapping. We enumerate domains, subdomains, IP ranges and cloud-hosted services to find web applications the organisation owns, including forgotten marketing sites, staging environments and legacy portals.
• Technology fingerprinting. Response headers such as X-Powered-By, session cookie names, URL patterns, error pages and framework artefacts often reveal PHP even when nobody has documented it.
• Version leakage. Exposed diagnostic pages, verbose errors and headers can disclose exact PHP versions. Version strings need care, because Linux distributions received the patches in advance and their packages may carry fixes under their own versioning. We confirm with the vendor's advisory rather than guessing from a banner.
• Request handling. Both advisories centre on how PHP parses incoming requests, particularly multipart form data. We check whether reverse proxies, load balancers and web application firewalls enforce limits on request size, multipart parts and headers before traffic reaches PHP.

Internal and configuration review

• Server API identification. We establish whether each host uses Apache mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed, because PHP's advisory treats them differently.
• Configuration audit. We review the settings the advisories call out: session.upload_progress.enabled, fatal_error_backtraces on PHP 8.5, memory_limit, post_max_size, and per-directory overrides in .htaccess or PHP_VALUE parameters passed from nginx or other frontends.
• Bundled and hidden PHP. We look inside appliances, vendor products and containers. NCSC-NL has published an inventory of software with a PHP dependency, which the NCSC references in its guidance, and it is a useful starting point.
• Blast radius. We test what the web worker account could reach if compromised: secrets on disk, database privileges, outbound network access and routes to internal systems. That turns a patching task into a prioritised risk picture.

The output is not a list of version numbers. It is a map of where PHP runs, which instances are reachable, which configurations matter, and which ones lead somewhere valuable.

Practical Remediation: What to Do This Week

1. Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from the official downloads page, or apply your Linux distribution's updated packages. PHP is explicit that updating is the only complete mitigation.
2. Restart every worker. PHP-FPM pools, Apache processes and long-running workers keep the old code in memory until they restart.
3. Find the rest. Follow the NCSC's advice to identify systems running PHP across your estate, starting with internet-facing systems, and do not limit discovery to outdated versions.
4. Chase your vendors. Ask suppliers of appliances, hosted platforms and packaged software whether their products include PHP and when fixed builds will ship.
5. Apply interim measures where you cannot update yet. PHP's advisory lists them: enforce memory_limit=-1 administratively, keep post_max_size low, set session.upload_progress.enabled=0, set fatal_error_backtraces=0 on PHP 8.5, and remove invalid or deprecated per-request INI settings. Apply these in php.ini, the FPM pool or server configuration, not with ini_set() or .user.ini. PHP warns these reduce exposure but do not make an installation safe.
6. Avoid the trap. PHP advises against using RLIMIT_AS or RLIMIT_DATA as a memory control, because they can trigger the vulnerable path.
7. Consider isolation. Both the NCSC and CERT-EU suggest taking or isolating internet-facing systems offline where you cannot patch or mitigate quickly.
8. Look for compromise. If a system was exposed and unpatched, review it for signs of compromise and backdoors before declaring it fixed. The NCSC points organisations that need help to NCSC-assured Cyber Incident Response providers.

Key Takeaways

1. This is core PHP, not a plugin. Every framework, CMS and custom application built on an affected PHP version inherits the risk.
2. Unauthenticated means internet-facing first. Prioritise anything the public can reach.
3. mod_php carries the highest risk. PHP has demonstrated an exploit that runs before application code.
4. FPM is not immune. One flaw was validated against FPM, and the other is assessed as susceptible.
5. Hiding errors does not protect you. Suppressing diagnostics does not block CVE-2026-109619.
6. Mitigations are partial. Only an update fully fixes these flaws.
7. Your inventory is the real test. Bundled and forgotten PHP is where exposure tends to survive patch day.
8. Verify, then retest. Confirm fixes on every host, and check again after configuration changes.

Conclusion

PHP's warning was unusually direct: update now, there are no complete mitigations. The patch itself is straightforward. The difficulty is that PHP is so widely embedded that many organisations cannot say with confidence where it runs.

Scanners will tell you about the servers they already know about. A penetration test tells you about the ones you forgot, whether they can be reached, and what an attacker could do from there. That is the evidence boards, auditors and insurers need after a release like this.

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation. Mongoose Cyber Security is CREST-accredited, and we can help you confirm where PHP runs across your estate and what it exposes.

Card image: PHP logo by Colin Viebrock, licensed under CC BY-SA 4.0, placed on a plain background.