PHP2Shell RCE Flaws: Patch CVE-2026-109618 and CVE-2026-109619 on PHP Servers — Megathread

The short version for admins​

Two critical PHP flaws, nicknamed PHP2Shell, were patched in an emergency release on October 21, 2026.

• CVE-2026-109618 is "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619 is "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp).
• Both are rated CVSS v4.0 9.2.
• The patched versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP says both can allow unauthenticated remote code execution on installations that serve web requests. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php.
• PHP notes that Windows source and binaries are on its downloads page.

Check Point also points out that the bug is in the PHP core interpreter, not in application code, so updating WordPress, Magento or Drupal alone will not fix it.

The dispute: who broke the embargo?​

PHP's account​

As reported by The Register, PHP maintainers say two CVE IDs began circulating on forums and social media around 15:00 UTC on Tuesday, October 20. The posts carried wrong details about the release time and severity. That pushed the maintainers to warn users and move disclosure forward a day, from Thursday to Wednesday.

Third-party write-ups add detail. The original post was taken down, but screenshots had already spread. Researchers at watchTowr then confirmed the leak was real and said they had reproduced CVE-2026-109618.

PHP's own blog, per The Register, lists several further problems:

• Researchers at Calif "mistakenly" published a proof-of-concept video and limited extra information.
• Mitigation advice given to a few critical-infrastructure providers may also have leaked.
• At 07:41 UTC on October 21, more than six hours before the coordinated release, Chainguard published built images containing the fix.

PHP's complaint about the last point is that anyone could inspect the fix in binary form while other PHP users were still waiting for official updates.

Chainguard's account​

CEO Dan Lorenc told The Register that the company "didn't leak". He did not dispute the timeline. His version of events:

• A researcher told Chainguard on Friday that something was coming in PHP.
• That night, Chainguard's own AI harness and a frontier model independently found the same memory-corruption bugs.
• Chainguard worked with the maintainers from Saturday and helped test the patches.
• By Tuesday night, proofs of concept were on social media and other vendors were reporting real-world exploitation.
• Lorenc notified PHP's coordinated-disclosure channel and shipped the fixes, citing a policy of coordinating "unless there's evidence of active exploits in the wild."

He also said Chainguard's honeypots caught IPs from China and Russia targeting the bugs on Wednesday. That is his claim. The sources I reviewed did not independently confirm it, and none of them established how widespread exploitation is. Other reports are mixed. SOCRadar says some vendors report in-the-wild exploitation that is still under investigation, while Equixly lists exploitation as disputed.

Chainguard's support notice does corroborate one operational point. It says the patched images were built overnight, before the public disclosure, so the console may show updates timestamped hours before the announcement. It does not settle the argument over authorization or motive.

My read​

Both positions are defensible, and neither is clean.

• PHP's case is that embargoes protect the many users who depend on slower distribution channels. A public fixed binary makes diffing easy.
• Chainguard's case is that once proofs of concept circulate and exploitation is reported, silence only helps attackers. Check Point's reading of the sequence fits that view, since the original leak had already begun.
• The Register notes the irony that a supply-chain security company is the one accused.

The more durable lesson is Lorenc's remark that simply being told a bug exists in PHP was enough for him to find it with AI. If that holds up, embargo windows built for human-speed analysis are shrinking. That is general analysis, not a finding from the sources.

How the bugs work​

CVE-2026-109618. PHP can exit a request via longjmp() after an allocation failure. If that happens while request memory is only partly initialized, the shutdown code later treats it as valid. The advisory describes several ways a remote request can reach out-of-memory, including multipart parsing quirks. The confirmed RCE was against Apache mod_php with default input and memory limits. Per the advisory, PHP-FPM exits a child when request startup fails, which blocks that exact route. Source analysis still supports FPM as susceptible, but no complete FPM exploit has been demonstrated. FrankenPHP is likely susceptible; LSAPI exploits are likely but unvalidated.

CVE-2026-109619. Request-owned state, such as error and session state, can survive after its memory is freed. A later request on the same worker can then use it, causing a use-after-free. The advisory confirms RCE against mod_php. It also confirms a session-lifecycle path against both mod_php and FPM. Session upload progress is enabled by default.

Wiz, as quoted by The Register, says every PHP release of the last decade is affected by at least one of the bugs, back to 5.4. PHP's own pages give fixed versions and the support boundary, not a full affected-version matrix. Treat the 5.4 claim as Wiz's.

What to do​

• Inventory PHP. The EU's joint statement from the European Commission, ENISA, CERT-EU, Europol EC3 and the CSIRTs Network says to identify PHP-based applications, coordinate with hosting providers and prioritize internet-facing systems. It also warns that many products use PHP in the background.
• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's patched package. PHP says Linux distributions and LTS vendors received the patches in advance.
• Restart workers and confirm the running version, not just the installed one.
• Check PHP 8.1 and older. The PHP project no longer updates them, though vendors may backport fixes. PHP says its security team also provided minimal source backports for 7.4, 8.0 and 8.1 for people building from source. The Check Point and PatchMon tables show 8.2 security support ends December 31, 2026.
• If you truly cannot patch yet, PHP lists partial mitigations. None of them makes an installation safe.
• Set memory_limit=-1 administratively, so applications cannot override it. PHP warns an underlying allocation failure can still reach the vulnerable path. Be aware of the operational effect on memory use.
• Set a conservative post_max_size, such as 8M if you don't need uploads and 32M if you do. Enforce request limits at the web server or proxy.
• Do not use RLIMIT_AS or RLIMIT_DATA as a substitute. These can cause the vulnerable allocation failure.
• Set session.upload_progress.enabled=0 and restart every worker.
• On PHP 8.5, set fatal_error_backtraces=0.
• Fix attacker-reachable fatal errors and timeouts in your applications.

Cloudflare has also deployed WAF rules, which Security Boulevard describes as a stopgap that covers only traffic routed through Cloudflare.

If you run Chainguard images​

Chainguard's guidance lists fixed package versions. They carry the same fixes as the official releases but keep older version numbers:

Affected images include php, php-fips, php-fpm and frankenphp. They also include images that bundle PHP, such as WordPress, Drupal, Laravel, Nextcloud, phpMyAdmin and Moodle.

Common failure points, per Chainguard:

• Digest-pinned images never pick up the fix. Look up the current digest and update your manifests.
• Mirrors and caches need a sync, followed by a digest comparison.
• Cached build layers need docker build --pull --no-cache.
• Pinned apk add versions need updating to the fixed version or later.
• php -v showing 8.4.26 rather than 8.4.27 is expected on a fixed -r4 package.
• PHP 8.1 gets no fix from Chainguard. It recommends upgrading, and suggests 8.4 or 8.5 given 8.2's end of life.

To confirm a fix, check the SBOM attestation or run apk info -v inside a -dev image. These instructions apply only to Chainguard's packages. Other distributions will use their own package versions.

Why this matters beyond PHP​

PHP's own advisory calls its risk highest for mod_php. Operators of default Apache and mod_php stacks should treat this as an emergency rather than a routine patch Tuesday item. The wider question is how coordinated disclosure should work when AI shortens the gap between "something is coming" and a working exploit. That debate won't end with this incident, and the disclosure fight may get more attention than the patching job. The patching job is the part that decides whether servers get compromised.

Update: Government websites reportedly taken offline during PHP patching (October 22, 2026)​

Government agencies in several European countries reportedly took websites offline on October 21 while applying the PHP security fixes, according to Around Prague, citing Euronews. The report identifies French prefecture websites, several sites managed by Germany’s federal IT provider ITZBund, and government or public-service sites in the Netherlands and Finland. German officials reportedly described the shutdowns as precautionary and said no security incidents had been identified.

The Wikimedia Foundation also reportedly paused supporting services while installing updates, according to the same Euronews-based report. This does not establish that Wikipedia itself went offline. No restoration timetable was provided, so the report should not be read as confirmation that those services remain unavailable.

Separately, Amazon Threat Intelligence reportedly detected exploitation attempts, including activity before public disclosure, according to Around Prague’s account. That adds a named organization beyond Chainguard reporting attempted exploitation, but does not establish successful compromise or widespread attacks. For administrators, the newly reported operational impact is precautionary downtime during patching—not confirmed breaches at the organizations named.

Update: Orange suspends PHP services; UK reports 32 government services offline (October 22, 2026)​

The disruption now reportedly extends to Orange’s customer-facing services. According to TechRadar’s October 22 report, the telecommunications company temporarily suspended access to several PHP-based websites and apps across countries in Europe, Africa and the Middle East. Orange described the suspensions as precautionary and said its national operations would identify affected services locally. The report does not establish that those services were compromised or give a restoration timetable.

In the UK, a minister reportedly said 32 government services were offline because of the PHP threat, according to TechRadar. The outlet also reports a restoration: the Office for Budget Responsibility’s website, taken offline on October 21, was back online on October 22. That status applies specifically to the OBR, not the other affected government services.

For administrators tracking external-service availability, these are reports of protective shutdowns, not a confirmed victim list. TechRadar also lists the Internet Archive’s October 21 outage but explicitly says its connection to PHP was not established. That outage should therefore not be attributed to these vulnerabilities without further confirmation.

Update: Amazon reportedly warns PHP2Shell is being broadly exploited (October 22, 2026)​

Amazon Threat Intelligence now describes PHP2Shell as being “broadly exploited in the wild,” according to TechRadar’s October 22 report. That is a stronger assessment than the previously reported exploitation attempts, although TechRadar provides no victim count or measure of successful compromises.

According to the same report, Amazon detected an exploitation attempt as early as October 17—three days before the public leak described above and four days before PHP released its emergency patches. Amazon reportedly says it remains unclear how that actor obtained exploit information before disclosure. The timing does not establish who leaked the vulnerabilities or resolve the dispute over Chainguard’s early release of patched images.

For administrators, the newly reported timeline means an exposure review should not assume attacks began only after the October 20 leak. Organizations investigating potentially affected servers should consider the October 17 activity when setting their review window. The broader-exploitation warning strengthens the urgency of that review, but it does not establish that any particular unpatched server was compromised or that the precautionary shutdowns reported earlier followed successful attacks.

Update: UK reports four partly disrupted services and no confirmed public-sector compromise (October 22, 2026)​

Four additional UK government services were partially unavailable alongside the previously reported 32 offline services, according to The Register’s account of Baroness Lloyd of Effra’s October 22 statement to the House of Lords. The minister reportedly attributed the disruption largely to precautionary measures while departments applied security updates and mitigations. The four partially affected services are a separate category, not an increase in the number reported fully offline.

According to The Register, Lloyd also said the government was unaware of any confirmed compromise arising from these vulnerabilities, extending that assessment beyond central government to the wider UK public sector. That is a statement of current knowledge, not confirmation that every affected system has been cleared.

The UK response also reportedly began before public disclosure: according to The Register, Lloyd said a cross-departmental incident operation was established in advance and the NCSC sent 50,000 warnings to businesses and other organizations. For IT teams assessing service dependencies, the additional figures distinguish partial disruption from complete unavailability; neither category establishes a successful attack.

Update: Additional details (October 23, 2026)​

Microsoft’s Azure networking security guidance adds Azure-specific patching detail: upgrading remains the only complete remediation, while WAF protections are temporary and target only particular exploit techniques. Administrators should update PHP on VMs, containers, base images and platform runtimes, then rebuild and redeploy any image that bundles its own PHP runtime.

The guidance also says a managed WAF rule for Application Gateway for Containers is still rolling out. Organizations unable to patch before that protection reaches their profile should contact Microsoft Support for interim options. For Azure App Service, inventory should err on the side of inclusion: its runtime reporting exposes only the PHP major and minor version, so affected apps should be treated as in scope until Microsoft confirms the patched platform image is deployed.

Update: QNAP fixes reportedly pending as firewall and Nextcloud updates arrive (October 23, 2026)​

QNAP had not yet released fixes for affected NAS software, according to Notebookcheck’s October 23 report, citing QNAP advisory QSA-26-18 issued October 22. The report identifies affected QTS, QuTS hero and QuTScloud releases, among other products. According to Notebookcheck, QNAP recommends removing direct internet exposure while fixes are pending, including disabling port forwarding and UPnP, and using a VPN for remote access.

Download Station and PHP Extensions reportedly will not receive fixes because their support ended September 30, according to Notebookcheck. The outlet says QNAP recommends backing up download tasks and uninstalling both. It also reports that QNAP’s eventual updates will not cover PHP bundled inside Container Station containers.

Firewall fixes are reportedly available: according to Notebookcheck, OPNsense released Community Edition 26.7.7 and Business Edition 26.4.2p3. The outlet also reports that affected pfSense releases require installation through SSH or the console rather than the web interface.

For self-hosted deployments, Nextcloud All-in-One 14.4.1 reportedly includes patched PHP, according to Notebookcheck. The outlet also reports rebuilt official application images; administrators must recreate running containers to use those replacements, rather than merely download them.

Update: Forum poster reportedly apologizes for early PHP disclosure (October 23, 2026)​

A Hacker News user posting as petecooper has apologized for sharing the PHP vulnerability identifiers before coordinated disclosure, according to Tom’s Hardware’s October 23 report. The user reportedly said they intended to alert people following PHP’s four-week release cycle to the urgency of the forthcoming fixes, but did not know the information was embargoed.

According to Tom’s Hardware, petecooper said their contact had explicitly told them there was no embargo, and that the contact’s own source had supplied the same assurance. The user reportedly accepted responsibility and acknowledged that the post disrupted the disclosure schedule and created additional work. That account suggests restrictions may not have been communicated through the information-sharing chain; it does not independently establish where that communication failed.

The new account concerns the forum disclosure, not authorization for Chainguard’s early release of patched images. It therefore does not settle that separate dispute. For administrators, this is a development in the disclosure investigation rather than a change to remediation: the report announces no additional fixes, revised mitigations or new evidence of successful compromise.

Update: Synology PHP fixes reportedly available through Package Center (October 23, 2026)​

Synology has reportedly released updated PHP 8.2 and PHP 8.4 packages addressing PHP2Shell, according to TechRadar’s October 23 report. The outlet directs owners to Synology’s Package Center and download archive for the replacements. This adds an available patch route for Synology users to the NAS remediation picture; it does not change the previously reported status of QNAP’s pending fixes.

According to TechRadar, Synology’s advisory identifies PHP versions 7.3 through 8.4, Mail Station and Synology Calendar as affected. However, the report confirms replacement packages only for PHP 8.2 and 8.4; it does not establish that every listed application or older PHP branch has received a fix. Administrators should therefore check each installed package’s status rather than assume one update clears the entire NAS.

TechRadar also reports that Synology distinguishes separately installed PHP packages from PHP embedded in DiskStation Manager, saying the latter is not exposed to the public internet. That narrower assessment should not be read as clearance for separately hosted PHP services or containers on the same device.

Update: Third PHP2Shell flaw awaits regular release, with configuration mitigation available (October 23, 2026)​

A third related remote-code-execution flaw, CVE-2026-115560, will reportedly receive a fix in the next regular PHP release rather than an emergency update, according to The Register’s October 23 report. PHP Foundation executive director Elizabeth Barron told the outlet that exploitation requires an unusual combination of configuration and application code that the security team does not expect in practical use.

According to The Register, the new flaw requires session upload progress to be enabled, with session.serialize_handler initially configured as php_binary or php_serialize, then changed to php through ini_set() before session_start(). PHP’s informational advisory recommends setting session.upload_progress.enabled=0 until the regular bugfix release. Administrators who already applied that setting under the earlier mitigation guidance should retain it; the newly identified issue is not described as a broadly applicable bypass of the emergency patches.

The Register also reports a narrower assessment of exploitation than earlier warnings might suggest: Barron said the Foundation had no evidence of successful exploitation before disclosure or exploitation on patched PHP versions. Researchers contacted by the outlet likewise reported attempts, but no confirmed successful attacks in the wild. That does not establish that no compromises occurred.

Update: VulnCheck reportedly demonstrates an ASLR bypass for PHP2Shell (October 26, 2026)​

The Register reports that VulnCheck has developed an additional exploit demonstration for the PHP2Shell vulnerabilities that bypasses address space layout randomization (ASLR) on x86 systems. ASLR is a common exploit-hardening feature, so the reported result could reduce one obstacle attackers face when turning the PHP memory-corruption flaws into reliable code execution.

The report does not provide technical details sufficient to independently assess the exploit chain, its affected PHP configurations, or whether it has been used against real targets. It also does not change the PHP Foundation’s previously reported position that it had no evidence of successful exploitation in the wild as of October 23.

For administrators, the development is a reminder not to treat platform mitigations such as ASLR as a substitute for upgrading. Systems still running vulnerable PHP builds—especially internet-facing Apache mod_php or persistent-worker deployments—should be patched, rebuilt and restarted rather than relying on mitigations to make exposure acceptable.

Update: Microsoft clarifies PHP2Shell responsibilities for Azure DevOps users (October 26, 2026)​

Microsoft’s Azure DevOps team says neither Azure DevOps Services nor Azure DevOps Server uses PHP to process customer requests, so the PHP2Shell flaws do not require an Azure DevOps product update. The new guidance instead separates the service itself from PHP runtimes that customers introduce through pipelines, containers, test environments or deployed applications.

For Microsoft-hosted Azure Pipelines agents, Microsoft says it is responsible for updating PHP preinstalled in hosted VM images, although rollout timing can vary by image. Teams that need a fixed runtime sooner can install a vendor-patched PHP package during setup or move jobs to a patched container image.

Self-hosted agents remain the customer’s responsibility. Microsoft stresses that updating the Azure Pipelines agent does not update separately installed PHP packages or PHP inside job containers. Administrators should patch the host runtime through their vendor-supported process, rebuild affected images, update pipeline references, and restart PHP-serving processes where applicable.

The practical point is that the presence of PHP CLI or Composer on an agent alone does not demonstrate an exploitable HTTP route. Teams should focus their review on PHP web servers launched in tests and on PHP applications their pipelines build or deploy.

Update: Extortion operator reportedly acquired PHP2Shell tooling (October 27, 2026)​

SOCRadar reports that an exposed staging server used by an extortion operator contained a weaponized PHP2Shell reproducer and scripts for repeated exploitation attempts. The files were dated October 21, the day PHP released its emergency fixes.

According to SOCRadar, the same operator had previously targeted Japanese real estate websites, reaching nearly 20 sites through shared-hosting credentials. The researchers found no link between PHP2Shell and those earlier intrusions, which occurred roughly ten days before the PHP2Shell tooling appeared. They also found no saved output confirming successful PHP2Shell exploitation against a live site.

SOCRadar identified the staging server as 96.126.130.81 and recommends checking logs and web roots for connections to it, as well as reviewing SSH keys and login history on shared-hosting accounts. Those indicators relate to the reported operator’s activity; their presence would warrant investigation, but would not by itself establish that PHP2Shell was the entry point.

The finding adds evidence that an active extortion operator had prepared tooling for the flaws. It does not establish a successful PHP2Shell compromise or change the existing patching guidance.