Policy

PHP2Shell was probed before the patch. Start the log review at October 17.

PHP fixed two unauthenticated remote code execution bugs on October 21. Amazon saw an exploit attempt on October 17. Most companies run PHP inside software they buy, so the work is a vendor inventory, not only a patch.

Edited by Emilio Santos 6 min read
Server racks in a colocation hall
Much of the exposed PHP sits inside products you bought, not code you wrote. Photo: Circuit & Capital

On Wednesday, October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The releases fix CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities, both rated 9.2 on CVSS version 4, that the project says “can allow unauthenticated remote code execution.” The pair is now widely called PHP2Shell. The project’s advisory says the people at risk are “all PHP installations serving web requests,” including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Amazon’s threat intelligence team says it saw a PHP2Shell exploit attempt against its honeypots on October 17, four days before the fix was public. Sophos and Amazon have both reported exploitation attempts. Neither has confirmed a successful compromise: Sophos says the attempts it saw failed, and Amazon says PHP2Shell is “now seeing broad exploitation attempts in the wild” but that it is unclear whether any would have succeeded on real-world systems. For most companies, PHP is not something they bought on purpose. It runs under the marketing site, the help desk, the vendor portal and the appliance in the rack. That changes what this week’s work looks like.

What happened

  • October 20: the PHP security team gave advance notice of a critical release for October 21 at 14:00 UTC, addressing two vulnerabilities rated CVSS v4.0 9.2. It said it might release earlier if exploitation appeared.
  • October 17: Amazon Threat Intelligence later reported a PHP2Shell exploit attempt in its MadPot honeypot telemetry dated October 17, from an IP address tied to a commercial anonymization network. Amazon says it is unclear how the actor got exploit information before disclosure.
  • October 21, about 02:00 UTC: Amazon says it found multiple proof-of-concept exploits, the earliest around this time, and further attempts against its sensors through 08:00 UTC from varied infrastructure, which it reads as multiple actors.
  • October 21: PHP published the fixed releases and its advisory. CVE-2026-109618 is code execution through memory corruption when PHP handles an out-of-memory error partway through a request. CVE-2026-109619 is code execution through internal state that survives after its memory is freed and is reused by a later request on the same worker. PHP rates mod_php the highest-risk setup, with “a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”
  • October 21: CISA urged organizations to patch immediately. At publication it said it had not observed exploitation. CERT-EU issued advisory 2026-018 the same day.
  • October 22, 16:18 UTC: Sophos updated its advisory to report multiple exploit attempts and, at the time, one successful exploitation.
  • October 22, 21:21 UTC: Sophos corrected that update. Its customer telemetry shows scanning and a small number of failed exploitation attempts, and there is no evidence of a successful compromise. The payload, likely a Mirai variant Sophos calls Potassium, was not delivered because the attempt was blocked. Sophos adds that building a working exploit is “not straightforward,” and that the vulnerabilities remain serious and patching remains the main recommendation.
  • October 23: PHP published an informational advisory about a further, unlikely remote code execution path (CVE-2026-115560) that needs an unusual combination of configuration and application code. It suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, a mitigation already listed for CVE-2026-109619.

PHP 8.1 and older get no updates from the PHP project. Because of the severity, the security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors ship their own fixes. PHP 8.2 reaches end of life on December 31, 2026.

As of this writing on October 22, neither CVE is in CISA’s Known Exploited Vulnerabilities catalog. We checked the catalog JSON feed, version 2026.10.21 with 1,754 entries, this afternoon. NVD lists both records as “Undergoing Analysis.”

What it means for CISOs

Two working assumptions break here. The first is that the disclosure date is the start of the risk window. Amazon’s advice is direct: “Start investigations from the earliest known exploitation, not from the disclosure date. For PHP2Shell, investigate from at least starting on October 17.” No successful compromise has been confirmed, but a system patched this week was exposed from at least the 17th, and the log review is how you show it was not entered.

The second is the patch service level. Amazon’s CISO writes that for critical bugs in internet-facing systems, teams should “measure patch and mitigation timelines in hours,” because “a 7-day or 30-day SLA assumes a delay that no longer exists.” Whether you adopt that is a policy choice with a staffing cost, and it should be made on purpose rather than discovered during the next incident.

The harder problem is visibility. CISA notes that PHP “is often a component of other software and prevalence may not be directly observable.” CERT-EU makes the same point and points to a list maintained by the Dutch NCSC of third-party products that embed PHP. Your scanner may find the servers you run. It will not tell you which SaaS vendor’s customer portal runs mod_php on 8.1.

What it means for CFOs

This is a supplier question with a paper trail. The useful output this week is a dated list: which vendors run PHP in the service you use, what version, and when they patched. That list is what your auditor, insurer and board will ask for if anything turns up later, and “the vendor said we are fine” is not an answer you can defend without a date and a name.

Budget for the tail. Systems on PHP 8.1 or older either get upgraded, get a paid backport from an LTS vendor, or come offline; CISA and Sophos both recommend taking unpatchable internet-facing systems offline or behind network-layer authentication. If the business refuses, record a dated, owned exception rather than an informal one. The 8.2 end-of-life date on December 31 means a second round of the same decision is ten weeks away. If a compromise is confirmed at a public company, the Form 8-K question follows; the SEC clock starts at the materiality determination, not at the advisory.

What to do this week

  1. Inventory where PHP runs. Start with internet-facing systems you host, then list vendors and products that embed PHP: content sites, help desks, portals, appliances, hosted plugins. Use the NCSC-NL list linked from CERT-EU as a starting point.
  2. Ask suppliers for patch status in writing. One question: do you run PHP in the service we use, on what version, and on what date did you apply the October 21 fixes? Record each answer with the date and the person who gave it. The SBOM request pack and vendor claim checker help with the follow-ups.
  3. Patch. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s fixed package, internet-facing systems first, and restart every worker. PHP lists configuration mitigations for systems that cannot update at once, but says they “do not make an installation safe.”
  4. Review logs back to October 17. Amazon suggests looking for POST requests carrying the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, and reviewing web server logs. Check vendor-hosted systems by asking the vendor for the same review.
  5. Check for webshells and unexpected processes. CISA says to watch for PHP worker processes launching shells or downloading tools. Amazon adds unexpected process execution or file modification on web servers. Sophos’s post lists indicators from the attempts it saw.
  6. Deal with end-of-life versions. Anything on 8.1 or older goes offline, behind network-layer authentication, or into the risk exception register with an owner and an expiry date.

What to watch next

Watch the KEV catalog. If CISA adds either CVE, the row will carry a federal due date and may mark forensic triage, which would make the October 17 lookback a formal expectation for agencies. Watch Sophos and Amazon for any confirmed successful exploitation; so far both report attempts, and the payload Sophos analyzed, a likely Mirai variant, was blocked before delivery. Watch vendor advisories, which tend to arrive later than the upstream fix. And watch NVD, where analysis of both records is still under way.

Sources

Related: The BeyondTrust bug was used before the patch. Check the logs., the same lookback logic for a remote-support appliance, and CISA listed three bugs attackers are already using.

ES
Emilio Santos edits Circuit & Capital. How we source and correct pieces: editorial standards.
circuits50capital@circuits.fit