If you run or host PHP for clients, update it today. PHP released fixes today for two flaws that let an attacker run code on a web server without logging in. Exploit attempts started before the release. A second incident is also circulating today: weak keys at the certificate authority eMudhra. It is real, but much narrower, and the major browsers had already blocked the affected certificates before it went public.

PHP2Shell: what to patch

php.net lists the fixed releases as 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and says the flaws "can allow unauthenticated remote code execution." The two bugs are CVE-2026-109618 and CVE-2026-109619. NVD scores both 9.8. PHP's own score is 9.2 on CVSS v4.0.

Scope is broad. PHP says the risk covers "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." It rates mod_php highest, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." The flaws sit in the engine, so a site with clean application code is still exposed. The Hacker News adds that an attacker can also read memory from the PHP worker process, which "may hold passwords, authentication tokens, API keys, and certificates belonging to other requests."

PHP 8.1 and older get no updates from the PHP project. PHP has published minimal source backports for 7.4, 8.0 and 8.1. Distributions and LTS vendors received the patch in advance, so a fixed distro package may keep an old-looking version number. Check the package changelog for the CVE IDs rather than trusting php -v.

Websites are not the only exposure. The Dutch NCSC's operational repository warns that "PHP is also embedded in appliances, network devices, management interfaces and other vendor products," and keeps an inventory of affected software.

Is it being exploited?

Exploit attempts have been reported, but no confirmed break-ins yet. At release, the PHP Foundation said its team "did not identify any functional exploits at the time of release/public disclosure." At 14:19 UTC, watchTowr reported it "is observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619." Cloudflare's CTO said, "We are seeing early attacks emerging and are updating mitigations as new vectors show up." The Hacker News' latest update says "No source has reported a confirmed break-in of a specific server as of this update." Neither CVE is on CISA's KEV catalog as of today's version.

If you cannot update yet

PHP is blunt about this: "There are no complete mitigations, updating is the only safe choice." Its stopgaps reduce exposure to specific paths. For CVE-2026-109618, set memory_limit=-1 where applications cannot override it, and keep post_max_size low. For CVE-2026-109619, set session.upload_progress.enabled=0 and restart every worker. PHP says that setting "blocks the confirmed session paths but not other variants." watchTowr notes that Session Upload Progress is on by default.

The UK NCSC says to take a system offline only when you can neither update nor apply the mitigations quickly: "you should consider taking the system offline until it can be fully mitigated."

Action today:

1. List every client system that serves PHP: web servers, hosting accounts, self-hosted apps, and appliances with web consoles. Start with internet-facing ones running Apache with mod_php.
2. Update the PHP runtime from the distro, host, or container image. Updating WordPress or Laravel does not update the PHP runtime underneath.
3. Restart Apache, PHP-FPM, and any long-running PHP workers.
4. Check memory_limit and post_max_size after updating. The fix adds a new hard memory limit, and reaching it ends the process.
5. For shared-hosting clients, get a written confirmation and patch time from the host.
6. On servers that were exposed before you patched, look for the signals the researchers describe: "unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID response cookies, and unexplained restarts of PHP workers."

eMudhra: a real CA failure with a narrow blast radius

eMudhra's statement says eight of its Global TLS intermediate CAs had weak keys. A Key Generation Ceremony on April 30, 2025 created them. A researcher reported the problem on October 18, and eMudhra revoked all eight on October 19. The keys were trivially weak. Mozilla's Dennis Jackson, quoted by SecurityWeek, wrote that "The private keys are effectively all-zeroes apart from the last byte."

That matters because anyone holding those keys could issue certificates the client trusts. Google's description, quoted by SecurityWeek: the weak keys enabled "anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs." The last clause is the important one. Mozilla and Google blocked the intermediates on October 17, Apple on October 19, and Microsoft on October 20. eMudhra says none of the eight "have issued any end-entity certificates," and that "Seven of the eight intermediates were never used in production." SecurityWeek notes that "not all clients enforce CT," so Certificate Transparency logs cannot rule out a forged certificate shown to one of those clients.

The remaining exposure is in software that trusts the old root but receives no browser updates. Mozilla is removing the root from NSS 3.131.1 "to protect other applications that use Mozilla's trust store but do not receive OneCRL updates."

Action: confirm browsers and operating systems are current. SecurityWeek notes that "some clients may require software updates to ensure that the compromised intermediates are no longer trusted." Apply the NSS and CA-bundle updates to servers and container images when your distribution ships them. If a client runs a TLS service on an eMudhra certificate, ask their contact whether it chains to the distrusted ECC root. eMudhra says only one US customer ecosystem is affected.

Checking the circulating claims

A widely shared S2 Underground report this morning described both incidents. Several of its specifics differ from the primary sources:

• "The details were leaked before patches were written." The PHP Foundation says only the CVE IDs, with "a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2)," circulated on October 20, and that "No technical details leaked." The fix already existed, and distributors were packaging it.
• NCSC "suggest organizations bring their systems offline until a patch is released." The NCSC alert says "This security issue has now been fixed." Its offline advice covers only systems that can neither be updated nor mitigated.
• "Many government websites were taken offline globally." Sourced precautionary outages so far are narrower: BambooHR's service, and Dutch government services including MijnOverheid and DigiD, per The Hacker News citing NOS. The Dutch NCSC said it had not seen the flaw abused.
• eMudhra fakes "would be accepted by most devices." Major browsers blocked the intermediates between October 17 and October 20. The risk that remains is in clients that never received those updates.

The S2 report's practical advice holds up: update today, and watch for phishing that uses both stories as a lure.