PHP 两个严重 RCE 漏洞与 eMudhra 证书私钥事件同日爆发

For thirty years, someone has declared PHP dead every time a new framework shipped. Today the timeline thinks it finally has proof: two critical remote code execution bugs, an embargo that leaked a day early, and an exploit posted on X with “get it while its hot 😈” about twelve hours before the patch, since retracted by its own author. The PHP security team did this properly. They pre-announced a release for 21 October at 14:00 UTC, two flaws at CVSS 9.2, with no CVE numbers and no affected versions. That gives operators a maintenance window without handing attackers a map. The map leaked anyway. A small group fed the hints and the leaked CVE numbers into a handful of LLMs, claimed to have rediscovered the bug, and published an exploit that its author has since retracted. One of them put it plainly: PHP “told us where to look.” Whether someone could have waited thirteen hours is the wrong fight, though. What decides how bad today gets is who receives a patch at all. Only PHP 8.2 through PHP 8.5 are supported, and PHP 8.1 and older are end of life. By WordPress.org’s own numbers, 35.1% of WordPress sites run a PHP version with no security support, and 16.46% of all WordPress sites are still on PHP 7.4. WordPress is about 40% of the web. Microsoft faced this choice twice. The day after WannaCry hit in May 2017, it shipped a patch for Windows XP, three years after XP’s end of life. Two years later it didn’t wait for the fire: the BlueKeep fix for XP and Server 2003 shipped the same day as the supported ones. So PHP gets to pick. Patch the EOL branches and it saves everyone, and nobody learns anything, because the servers on PHP 8.1 and older stay where they are until the next one. Don’t, and it breaks a third of WordPress as the price of being right. Node.js made that decision in advance. Its own security releases, shipping today as well, put it in writing: “End-of-Life versions are always affected when a security release occurs.” The only fix Node offers is a supported version. To be answered at 14:00 UTC: which versions are affected and which get fixed. Updates, 21 October 01:19 UTC: PHP 8.6 release manager Joe Ferguson says “ini settings won’t save you”, so disabling session.upload_progress, which most WordPress hosts did overnight, is not a fix. 07:43 UTC: Cloudflare says it is already seeing early attacks and has deployed WAF rules against the known exploit vectors for every customer, free plan included. Its CTO calls them “a STOPGAP only.” They help only if your origin server refuses traffic that doesn’t come through Cloudflare, because an attacker who finds the origin’s IP address goes straight around them. 11:09 UTC: Rather than wait, governments are pulling sites offline. The Dutch parliament, the Dutch national cyber security agency and Finland’s central government web services went dark as a precaution, along with universities in Vienna and Freiburg and sites like Tweakers, Pinboard, 4chan and every wiki on Miraheze. Patch expected at 14:00 UTC. If you’re on PHP 8.1 or older this morning, you’re doing triage this afternoon, not an upgrade. That’s your server, though, and you get a choice. On 17 October, Mozilla’s Dennis Jackson reported that eight intermediate CA keys belonging to eMudhra, which sells certificates as emSign, were trivially recoverable. A P-384 private key should be a random 384-bit number. Engineers write keys in hexadecimal, a base-16 notation that uses the digits 0 to 9 and the letters a to f, and in hex that key is 96 characters long, the same size as a 116-digit ordinary number. All eight were values under 256: two hex characters or fewer, eight bits at most. One of them was the number 4. xkcd called it in 2007. The top key was generated at random for illustration. The bottom value comes from the eight keys Mozilla recovered. Anyone holding those keys could issue a certificate for any domain (your bank, your company, your mail server) and every client trusting that chain would accept it. Six were TLS intermediates, two were for code signing. There is nothing a site owner can patch here. The only cure is distrust. Firefox blocked the eight intermediates three hours after the report, then Mozilla emergency-removed trust in the entire emSign ECC Root CA - G3, and Chrome says it is taking a similar path. Apple and Microsoft followed, though Ars Technica found Edge on Windows 10 still connecting to vulnerable hosts on Tuesday night. eMudhra estimates about 30,000 certificates now have to migrate to another chain, and those customers did nothing wrong. The three hours is the good part. The keys came out of a key ceremony on 30 April 2025. For roughly eighteen months, eight keys anyone could brute-force on a laptop in milliseconds sat in the web’s trust stores, and nobody noticed. CAs are audited every year for exactly this. eMudhra says the keys were generated in certified HSMs (tamper-proof hardware built to generate and guard keys), that a flaw in a key-generation script created a second, weaker key pair, and that staff used it by mistake “because the key labels were similar.” That is eMudhra’s first-day account and nothing more yet; Mozilla is still asking questions. Whatever the cause turns out to be, a certificate authority has exactly one job. The replies under every viral post about this are full of racism. That is not okay, it explains nothing, and it moves the ecosystem nowhere good. Go shipped 1.27.3 and 1.26.10 with the eight keys hard-blocked and no setting to turn that off, even for programs that bring their own trusted roots. That’s the right call, and the bill still goes to whoever rebuilds next, with no say in it. Browsers fixed this in three hours because browsers update themselves. Everything else is on you: - Go 1.25 and older are out of support and get no fix. - curl on macOS still accepts the chain, because it reads a local certificate file and skips revocation. - Container images ship whatever trust store they were built with. - Phones, appliances and IoT that never get updates keep trusting the root forever. Cloudflare’s advice to anyone hitting the resulting errors: “It’s important to not resolve these errors by disabling verification.” Plenty of people will. For eMudhra, browsers and Go have a fix. curl on macOS and every hand-rolled trust store are still waiting for one, or don’t know they need it. For PHP the fix is due at 14:00 UTC, still a few hours away, and until it ships nobody knows what it covers or whether the overnight workaround holds. Either way, what decides your exposure is how long the fix takes to reach your servers. Firefox took three hours because browsers update themselves. A Go binary built last spring gets the TLS fix only when someone rebuilds it, and plenty never will be. A server on PHP 7.4 may not get a PHP fix at all. That part is yours, and it is dull: a PHP version that still gets patches, and base images you rebuild on a schedule of your own. The teams that already do it will patch as soon as the release lands and go back to work. First published 21 October 2026, 10:33 UTC. Last updated 21 October 2026, 11:55 UTC. - Update, 11:55 UTC: governments, universities and large sites are taking PHP services offline as a precaution. Added to the updates in the PHP section. - Update, 11:25 UTC: PHP 8.6 release manager Joe Ferguson says ini settings will not mitigate the flaws, and security researcher Charlie Eriksen, who has seen the patches, confirms it. Added to the updates in the PHP section, and the open question about session.upload_progress is removed from the 14:00 UTC callout. - Update, 11:15 UTC: Cloudflare CTO Dane Knecht reports early attacks on the PHP flaws, and Cloudflare has deployed stopgap WAF rules for all customers, including the free plan. Added as an update in the PHP section. - Correction, 11:15 UTC: the researcher who posted the viral PHP exploit has retracted it. The bug they “recreated & lab/field tested” is, in their own words, “DEAD at the addref”, and what remains is a medium-severity memory bug without code execution. The first version of this post called it a working exploit and cited the same researcher on whether disabling session.upload_progress covers both bugs. Both are corrected, and the citation is removed because their page now says both things. - Correction, 11:15 UTC: the first version said Apple and Microsoft followed Mozilla with blocks. Ars Technica found Edge on Windows 10 still connecting to vulnerable hosts on Tuesday night, so the sentence now says so. - Update, 11:10 UTC: added the obligatory xkcd 221. PHP - PHP security release pre-announcement, php.net - PHP supported versions, php.net - watchTowr confirms the leak, X - Exploit writeup and its retraction, J4ck3LSyN - Exploit claims and WordPress hosts disabling upload progress, The Repository - Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619, Sansec - Early mitigation steps, ma.ttias.be - Cloudflare WAF rules and early attacks, Dane Knecht, X - “ini settings won’t save you”, Joe Ferguson, PHP 8.6 release manager, Mastodon - Configuration changes confirmed not to mitigate, Charlie Eriksen, X - Cloudflare WAF changelog, Cloudflare - Node.js October 2026 security releases, Node.js - WordPress usage statistics, WordPress.org - Microsoft’s WannaCry patch for Windows XP, MCPmag - BlueKeep, CVE-2019-0708, Tenable eMudhra and TLS - Bug 2083449: private key compromise of eMudhra intermediate certificates, Mozilla - eMudhra intermediate CA compromise tracker - The Internet goes on high alert after discovery of 8 compromised TLS certs, Ars Technica - eMudhra’s private keys compromised, one of them was the number 4, The Register - Eight eMudhra CA keys compromised, The Hacker News - Go issues emergency update blocking eight CA keys, The Hacker News - crypto/x509: mitigation for a specific Certificate Authority, Go issue tracker - Cloudflare warns fixing botched eMudhra certs goes beyond browsers, iTnews