The most dangerous assumption an organisation can make this week is "our code is secure, so we are not affected." PHP2Shell does not live in application code. CVE-2026-109618 and CVE-2026-109619 are two critical flaws in the PHP interpreter itself, and they let an attacker run code on a web server without logging in. A WordPress site, a Laravel customer portal and a single "Hello World" page are equally exposed if the PHP runtime underneath has not been updated.
PHP released emergency fixes on 21 October 2026, a day earlier than planned after details leaked online. Exploitation attempts were observed within hours. For ANZ organisations, PHP2Shell is both an operational problem and an evidence problem: the patch needs to land, and APRA CPS 234 supervisors, SOC 2 auditors and ISO 27001 certification bodies will expect a record showing when it landed, which assets it covered, and how the fix was verified.
Part One: What PHP2Shell Actually Is
PHP2Shell is the name given to two memory-handling flaws in the PHP engine, each rated 9.2 on the CVSS v4.0 scale. Both allow unauthenticated remote code execution and sit below the application layer.
CVE-2026-109618: Out-of-Memory Corruption
When PHP runs out of memory part-way through setting up a request, some of its internal data is left half-built. The cleanup code that runs afterwards treats that data as valid. An attacker who can push a request into that state can corrupt memory and turn the corruption into code execution.
Read PHP advisory (GHSA-w8hw-w9fx-j79w) →CVE-2026-109619: Stale Global State
Some internal state belonging to a request survives after the memory behind it has been freed. The next request handled by the same PHP worker can then act on that leftover, attacker-influenced data before normal initialisation resets it.
Read PHP advisory (GHSA-6wmf-4rv5-p3rp) →Why Secrets Are at Risk Before Code Execution
Researchers also showed that an attacker can read memory from a PHP worker process without first achieving code execution. That memory can hold database passwords, session tokens, API keys and certificates belonging to other users' requests. An organisation that patches without checking for earlier access may still have exposed credentials in circulation.
The flaws were found by Wiz Research, Calif and OpenAI's Codex Security team. The vulnerable code had been in PHP for more than a decade. The researchers say AI tooling helped them turn it into a working exploit in about a week, work they estimate would otherwise have taken a team months.
Part Two: Who Is Affected
Every PHP installation that serves web requests is in scope, from PHP 5.4 up to, but not including, the fixed releases below. The question is not which application you run. It is which PHP runtime sits underneath it.
| PHP Branch | Vulnerable Status | Fixed In |
|---|---|---|
| 8.5 | Below 8.5.12 | 8.5.12 |
| 8.4 | Below 8.4.27 | 8.4.27 |
| 8.3 | Below 8.3.36 | 8.3.36 |
| 8.2 | Below 8.2.35 | 8.2.35 (end of life 31 December 2026) |
| 7.4, 8.0, 8.1 | All versions | No official release. Use distribution or LTS vendor package, or PHP's source backports. |
| 5.4 to 7.3 | All versions | No fix. Upgrade to a supported branch immediately. |
Risk Depends on How PHP Is Served
Apache mod_php carries the highest risk. Researchers demonstrated an exploit where a single unauthenticated request triggers the attack before any application code runs.
PHP-FPM is not a safe harbour. FPM shuts a worker down when a request fails early in setup, which blunts one path. CVE-2026-109619, however, has been shown to reach code execution on FPM when a particular operation runs inside the application. php-cgi, LiteSpeed and FrankenPHP are all in scope and should be treated as vulnerable until patched.
The Version String Trap
Linux distributions received the patches before public release. A patched Debian or Ubuntu package can therefore carry an old-looking version number. A scanner or asset register that checks only the version string will report patched servers as vulnerable. Confirm the fix against the package changelog, which should name the CVE identifiers.
Part Three: From Leak to Exploitation Attempts by the Next Day
The disclosure did not go to plan. Coordinated disclosure normally gives defenders a short head start. With PHP2Shell, attackers had details at roughly the same moment defenders did.
| Date (UTC) | Event |
|---|---|
| 2024 | A PHP core developer finds early signs of the out-of-memory flaw during PHP's external audit. No concrete path to code execution is found, and a fix stalls. |
| August 2026 | Wiz, Calif and OpenAI report working exploits to the PHP security team. |
| 17 October 2026 | Amazon Threat Intelligence later traces an exploitation attempt to this date, four days before disclosure. |
| 20 October 2026 | Details leak online ahead of planned 22 October disclosure. At 19:33 UTC, PHP posts advance notice and brings release forward to 21 October. |
| 21 October, 03:02 | Cloudflare enables emergency WAF rules by default after seeing early attack traffic. |
| 21 October, ~14:00 | PHP publishes 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with official security advisories. |
| 21 October, 14:19 | watchTowr reports active exploitation attempts against both CVEs through its honeypot network. |
| 22 October 2026 | Neither CVE is yet in CISA's Known Exploited Vulnerabilities catalog. |
Some organisations took services offline rather than wait and some suspended service across the United States, Canada and Ireland as a precaution. Several different government and education sites went offline while they patched. Cloudflare also reported attackers adjusting payloads to get around its WAF rules, so a WAF is a stopgap, not a place to wait.
One Forgotten PHP Server Is All It Takes
Staging sites, old microsites and vendor-hosted portals rarely make the patch list. See every internet-facing PHP asset in your organisation before an attacker does.
Part Four: The Response Plan
Patching is the only complete fix. The PHP project states this directly, and it is the position the major advisories have taken. Every other measure buys time against specific attack paths and nothing more.
Step One: Build a Complete PHP Inventory
The servers that get breached are rarely the ones on the patch list. Start from the internet-facing estate and work inwards:
- Production web servers, load-balanced pools and container images
- Staging, UAT and preview environments with public DNS records
- Old marketing microsites, campaign landing pages and acquired-company domains
- Internal admin tools and intranet portals reachable over VPN
- Third-party and managed hosting accounts where you do not control the runtime
For each asset, record the PHP version, the patched package changelog and the SAPI in use. Apache mod_php assets go to the top of the queue.
Step Two: Patch, Rebuild and Restart
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. Rebuild and redeploy container images, because a patched base image changes nothing until the containers running in production are replaced. Then restart Apache, PHP-FPM and every long-running PHP worker. The vulnerable code stays in memory until the process restarts.
On managed or shared hosting, ask the provider to confirm in writing that the runtime has been updated and restarted. That confirmation is part of your evidence trail.
After patching, review memory_limit and post_max_size. The fix introduces a hard memory ceiling. Reaching it now ends the process without running shutdown handlers, which can surface as new errors in memory-heavy applications.
Step Three: Interim Mitigations Where Patching Must Wait
Updating is the only complete mitigation. For servers that cannot update yet, the PHP security advisories list configuration changes that reduce exposure to specific attack paths. None of them makes a server safe, and every change below needs a restart of every PHP worker to take effect.
For CVE-2026-109618 (out-of-memory corruption):
- Set and enforce
memory_limit = -1administratively, and confirm that no pool, directory or application setting restores a finite memory limit. This removes the predictable per-request limit that the confirmed exploit relies on. It is not a complete mitigation: if an underlying allocation fails, PHP can still reach the vulnerable path. - Keep
post_max_sizeconservative and enforce the decoded request size at the web server or proxy. Reducemax_input_nesting_level, and limit the number of input variables, multipart parts, headers per part and uploads. If the application does not use multipart form data, block those requests before they reach PHP. - A container or cgroup memory limit can partly stand in for PHP's own limit, but it does not guarantee that allocations won't fail. Unless each worker has its own group, hitting that limit can kill the master process and every worker. Do not use
RLIMIT_ASorRLIMIT_DATA: they make allocations fail at the limit, which triggers the vulnerable path.
For CVE-2026-109619 (stale global state):
- On PHP 8.5, set
fatal_error_backtraces = 0administratively. This removes the producer used in the confirmed remote code execution case, but not other request-owned state. - Set
session.upload_progress.enabled = 0administratively. This blocks the demonstrated session-based attack, but not the other paths. PHP suggests leaving it off even after patching if you don't use the feature. - Reduce remaining risk: eliminate fatal errors and warnings on paths an attacker can reach, and avoid INI settings applied per request, such as
php_valuein .htaccess under mod_php. Prefer php.ini or FPM pool configuration applied at startup. Where performance allows,pm.max_requests = 1limits each worker to one request.
Step Four: Check for Compromise Before the Patch
An exploitation attempt was traced to 17 October, four days before disclosure. Patching closes the door; it does not tell you whether someone already walked through it. The researchers suggest reviewing logs for:
- Unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses
- Unusually large PHPSESSID cookies in responses
- Unexplained restarts of PHP workers
Where any of these appear, assume secrets held in worker memory were exposed. Rotate database credentials, API keys and session secrets, and invalidate active sessions.
Part Five: What PHP2Shell Means for ANZ Compliance Evidence
A patched server is not the same as a demonstrably patched server. Auditors and regulators do not ask whether PHP2Shell was fixed. They ask when it was identified, which assets were assessed, when each was remediated, and how remediation was verified.
APRA CPS 234
APRA-regulated entities must maintain information security capability commensurate with the threats they face and test the effectiveness of their controls systematically. A critical, actively exploited runtime vulnerability is exactly the event that tests whether that capability works. If PHP2Shell leads to a material information security incident, the 72-hour notification obligation to APRA applies. The record of identification, remediation and verification is what demonstrates the capability was in place.
SOC 2 and ISO 27001
SOC 2 auditors assess vulnerability management under the Common Criteria for system operations. ISO 27001:2022 control A.8.8 requires timely management of technical vulnerabilities. In both cases, the evidence that matters is the same: an asset inventory showing every PHP runtime was in scope, patch records with dates, and an independent verification that the fix holds. A scan report produced only from version strings is weak evidence when patched distribution packages can show old version numbers.
Privacy Breach Notification
Because PHP2Shell can expose session tokens and credentials from worker memory, a compromise may involve personal information. Australian organisations covered by the Notifiable Data Breaches scheme and New Zealand organisations under the Privacy Act 2020 should assess whether any confirmed access meets the threshold for notification.
The Lesson Beyond This CVE
PHP2Shell shows how quickly the window between disclosure and exploitation now closes. An exploitation attempt preceded the patch by four days, and live attacks followed within hours of release. AI tooling compressed a decade-old bug into a working exploit in a week. An annual penetration test, scoped once and delivered months later, cannot describe exposure that changes this quickly.
Capture The Bug's continuous penetration testing combines expert-led testing with a PTaaS platform that reports validated findings in real time. When a critical CVE lands, our team checks which of your assets are exposed, validates whether mitigations hold, and retests after remediation, producing the evidence trail APRA CPS 234, SOC 2 and ISO 27001 assessors look for.
Book a rapid PHP2Shell exposure assessment with Capture The Bug to confirm which of your PHP assets are vulnerable, verify that patches have taken effect, and document the result for your next audit.
Critical CVEs Don't Wait for Your Annual Pentest
Learn how ANZ organisations move from point-in-time testing to continuous coverage that keeps pace with disclosures like PHP2Shell.
Frequently Asked Questions
What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on the CVSS v4.0 scale. CVE-2026-109618 arises when PHP runs out of memory while setting up a request and its cleanup code trusts half-built internal data. CVE-2026-109619 arises when request state outlives the memory it points to, so a later request on the same worker acts on stale data. Both allow an unauthenticated attacker to execute code on the server. PHP released fixes on 21 October 2026, and exploitation attempts were observed the same day.
Does updating WordPress, Laravel or Drupal fix PHP2Shell?
No. The vulnerabilities are in the PHP runtime, not in any framework, CMS, plugin or theme. Updating the application leaves the vulnerable runtime in place. The fix comes from the server's PHP package, the hosting provider, or the container base image, followed by a restart of every PHP worker. A fully patched WordPress install running on PHP 8.3.35 remains vulnerable.
Which PHP versions are affected, and which are fixed?
Every PHP version from 5.4 up to, but not including, the fixed releases is affected. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 receive no official release; organisations on those branches need a distribution or LTS vendor package, PHP's published source backports, or an upgrade. PHP 5.4 to 7.3 have no fix and must be upgraded. Because distributions received patches early, check the package changelog for the CVE identifiers rather than relying on the version string.
Is turning off session upload progress enough to protect a server?
No. Setting session.upload_progress.enabled = 0 blocks the confirmed session-based attack paths for CVE-2026-109619 but not other variants, and does not address CVE-2026-109618. The memory-limit mitigations for CVE-2026-109618 narrow exposure but do not close it. PHP states that no configuration change fully mitigates these vulnerabilities. Mitigations are a stopgap for systems that cannot be patched immediately, not a substitute for patching.
How should ANZ organisations document their PHP2Shell response for compliance?
Record four things: the asset inventory showing every PHP runtime assessed, the date each was patched or mitigated, the evidence used to confirm the fix (package changelog or independent testing, not version strings alone), and the outcome of any log review for compromise before patching. APRA CPS 234 entities should keep this as evidence of information security capability and control testing, and assess whether any confirmed access is a material incident requiring notification within 72 hours. SOC 2 and ISO 27001 assessors will look for the same record under vulnerability management controls.
