Black October: What PHP2Shell and the eMudhra Certificate Breach Mean for Your Website

On Tuesday, October 21, some of the best-known sites on the internet went dark on purpose. The Wikimedia Foundation shut down many of the services that support Wikipedia. The Internet Archive went offline to patch. The Netherlands, Finland, and France pulled government websites down as a precaution. And the US National Security Agency gave website owners advice you almost never hear from a government agency: if you cannot install this update right now, take your site offline until you can.

Four days earlier, in a separate story that got far less attention, a company trusted to vouch for websites' identities admitted that eight of its master keys could be guessed in 256 tries or fewer.

Neither event was aimed at small businesses. Both landed on them anyway. Axios called it "Black October," and I think it is the clearest lesson in years about what it really takes to keep a website safe. Let me walk you through what happened, in plain English, and what it means for the site your business runs on.

What happened with PHP2Shell

PHP is the programming language that runs most of the web. According to W3Techs, which tracks the technology behind millions of sites, 69.2 percent of websites whose server language is known use it. If your site runs on WordPress, Joomla, or Drupal, or lives on a typical cPanel hosting plan, it runs on PHP.

PHP2Shell is the name for a pair of flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. In plain terms, a stranger could send a specially crafted request to any website running PHP and make that server run their code. No password, no login, no clicking a bad link. Security people call this "remote code execution," and it is the worst category there is: whoever pulls it off can read your database, plant malware on your pages, or use your server to attack someone else. The first flaw scored 9.8 out of 10 on the standard severity scale.

Three details made it a true emergency:

• It reached back fourteen years. Every PHP version from 5.4, released in 2012, through the current 8.5 was affected.
• AI found it. A security firm called Calif found one of the flaws using OpenAI's GPT-5.6 Sol model, as part of an OpenAI program called "Patch the Planet." Another firm, Wiz, independently found both. OpenAI called it "one of the most impactful vulnerabilities in recent memory."
• Part of it was already known. One of the underlying bugs was spotted by a PHP developer during a 2024 audit. It was never fixed, because nobody could agree on a fix and nobody had shown it could actually be exploited. AI showed it could.

The researchers found the flaws in August and kept them quiet while PHP's maintainers prepared a fix. That plan held until October 20, when details leaked online the day before the scheduled release, and a proof-of-concept video went out by mistake. Amazon's threat team had already logged an early attack attempt on October 17. The patch shipped on the 21st, and Cloudflare and the security firm watchTowr both reported attacks the same day. Another firm, Sansec, had warned that mass attacks would start within fifteen minutes of the release. Then, on October 23, PHP disclosed a third related flaw that affects even fully patched versions, with its fix still waiting on the next regular release.

About half of PHP websites could not simply update

Here is the part that should worry any business owner running an older site. When the fix shipped, PHP released official, ready-to-install updates only for its currently supported versions: 8.2, 8.3, 8.4, and 8.5. Versions 7.4, 8.0, and 8.1 got source code patches only, which means someone has to build and install them by hand. Anything older got nothing at all.

So I looked up how many sites are actually on those supported versions. As of today, W3Techs puts the answer at about 52 percent. The other 48 percent of PHP sites are running a version that had no ready-made fix the day the attacks started.

Sites end up on old versions for an ordinary reason: they were built once, they worked, and nobody touched them again. Upgrading PHP can break an old plugin or theme, so the upgrade keeps getting put off. Nothing looks wrong from the outside. The site loads, the phone rings, and the risk just sits there underneath, until a week like this one.

The certificate breach that sat open for 17 months

The second story is quieter, but it goes to the heart of how the internet decides who to trust.

When you see the little padlock next to a web address, your browser is checking a certificate: a digital ID card that proves the site really is who it says it is. Those ID cards are issued by a small number of companies called certificate authorities, and browsers trust them through a chain. A root certificate sits at the top, an intermediate certificate signs on its behalf, and the intermediate vouches for individual websites. Whoever holds an intermediate's private key can issue a valid-looking ID card for any website on earth.

On October 17, a security researcher scanning a public database of these certificates noticed something wrong with eight intermediates belonging to eMudhra, an Indian certificate authority. A proper private key is a random number more than 100 digits long. These keys were all smaller than 256. One of them was literally the number 4. Anyone could find them by trying 256 numbers, and the well-known security researcher Scott Helme recovered them from the public certificates in under a second.

eMudhra traced it to a faulty script in an April 2025 key ceremony: it generated a second, weak set of keys with labels similar to the real ones, and staff picked the wrong set. That means the keys were guessable for about 17 months before anyone noticed. With them, an attacker could have created a trusted-looking certificate for your bank, your email, or your website, and quietly intercepted the traffic.

The response, once it was found, was fast:

• Chrome and Firefox blocked the certificates the same day
• eMudhra revoked all eight within 14 hours
• Apple followed on October 19 and Microsoft on October 20
• Mozilla removed trust in the eMudhra root entirely
• On October 22, eMudhra announced it is leaving the website certificate business, with about 30,000 customer certificates to be replaced

There is no evidence the keys were ever abused, which is good news. But two lessons apply to every site owner. First, your certificate is only as good as the company behind it, and when that company fails, someone has to replace yours. Second, browsers updated themselves, but servers and apps that keep their own list of trusted certificates did not. Linux distributions, programming languages, and tools such as curl all had to ship updates, and some of those were still pending days later. Your website's server talks to payment processors, email services, and other APIs, and it trusts them using one of those lists.

The real risk of coding your own website

Here is what I want every business owner to take from this week. When people talk about the risk of building your own website, or having an AI tool build it for you, they usually mean the code might be sloppy. That is sometimes true, but it is not the big risk. The code you write sits on top of a stack of other software: the language that runs it, the server and operating system underneath, the certificates that prove who you are, and the lists of who your server trusts. Every one of this week's emergencies happened in those lower layers, the ones a do-it-yourself build or an AI coding tool never touches again after day one.

There is a real irony in this story. The same kind of AI that will happily write you a website in an afternoon is now finding flaws like PHP2Shell faster than ever, and OpenAI itself says findings like these will "increase sharply in the coming months." The tool that writes your site does not read security bulletins on your behalf, does not get the warning from CISA, the US cybersecurity agency, and does not log into your server on a Tuesday morning to install a patch. We covered the other half of that gap in our piece on whether AI can build your website. The site appears in ninety seconds. Looking after it lasts as long as the site does.

To be fair to the big template platforms, Wix and Squarespace patch their own servers, so their customers mostly did not have to lift a finger this week. Their tradeoffs are different, and we have written about what you actually own on those platforms. The sites most exposed in Black October were the ones in between: a WordPress install on a bargain hosting plan, a server somebody set up a few years ago, a site a relative built as a favor. They all work fine, right up until the week they do not.

What the week looked like from here

I will be straight with you about our own position, because I think you deserve that from anyone selling you security.

None of the websites and platforms we build run on PHP. They are built on Next.js, run in containers on servers we manage, and get their certificates from a free, automated certificate authority that renews them every few months without anyone touching them. So PHP2Shell did not apply to our clients, and neither did eMudhra. If a certificate authority behind our sites ever did fail, replacing every certificate would be a routine renewal, not a scramble.

That is not because our stack is immune. No stack is. Earlier this year, Next.js had its own critical security advisories. We patched them, rebuilt and redeployed, and then went through the server logs to confirm nobody had gotten in. That is the job. It is not glamorous, and it is not something you can buy once. It is somebody keeping watch on every layer, every week, and acting the same day when a bulletin lands.

How we can help

If your site runs on PHP today, the first job is to confirm the runtime is on 8.2 or newer and actually patched, not just the plugins. If you are on an older version, it is time to plan an upgrade or a rebuild, because the next flaw will not wait for you either.

If you would rather not be the person keeping watch, that is exactly what our care plans are for. The Essential plan, at $149 a month, covers managed hosting and certificates, uptime monitoring, and security patches, so that when the next Black October comes, we are the ones reading the bulletin and patching the server, and you hear about it after it is handled. The Standard plan, at $299 a month, adds dependency updates and bug fixes on top. You can see everything on our pricing page.

And if your site is old enough that the upgrade itself is the risky part, that is usually the sign it is time to rebuild on a modern foundation. Our guide to when to rebuild instead of patching will help you decide.

The bottom line

Black October was not about bad code written by careless people. It was about a fourteen-year-old flaw in software that runs most of the web, and a certificate authority that went seventeen months without noticing its keys could be guessed. The sites that came through fine were the ones with someone on watch: someone who knew which version they were running, heard about the flaw that morning, and patched the same day.

Your website deserves that too. Run it through our free Website Grader for a quick read on its health, or call us at 770-769-5239 and we will tell you honestly what it runs on and what needs attention. If it turns out you are already in good hands, we will tell you that too.