Private Key Was 4: eMudhra Blunder and the PHP Vulnerability

A private key that guards trust on the internet is meant to be a random number about 116 digits long. One of eMudhra's was the number 4. Not a number starting with 4. Just 4.

That came out the same week as PHP2Shell, a PHP vulnerability that can let a stranger run code on a server with one request. The two stories are separate, but both hit Indian websites, and both have a checklist.

Quick answer

• eMudhra: the Bengaluru certificate authority created eight intermediate certificates with tiny private keys: 4, 56, 66, 115, 155, 156, 230 and 237. Anyone could recover them in under a second.
• PHP2Shell: two critical PHP bugs, CVE-2026-109618 and CVE-2026-109619, both rated 9.2. They allow remote code execution without logging in.
• Fix PHP now: move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP workers.
• Fix trust stores: update ca-certificates, Python's certifi and Go, and rebuild container images.

What happened at eMudhra

eMudhra is a Bengaluru company founded in 2008, listed on the NSE and BSE, and licensed in India to issue digital signature certificates. It says it has issued more than 60 million certificates.

On 17 October, a researcher who calls himself "Wayne" told the browser makers that the private keys of eight eMudhra intermediate certificate authorities could be worked out from the certificates themselves. To prove it, he signed a message with each of the eight keys.

Six of the keys could issue certificates for websites. Two were for code signing, which vouches for software. Security researcher Scott Helme then recovered all eight in under a second by simply trying values one at a time.

eMudhra says the keys came from a key ceremony on April 30, 2025. A flaw in the ceremony script created a second set of weak keys next to the strong ones. Because the labels looked alike, staff used the weak ones by mistake. The chairman called it "a script error and human error".

Why a key of 4 is a disaster

Think of a certificate authority as a notary for the internet. When your browser shows a padlock for your bank, a trusted authority has signed a certificate saying that server really belongs to the bank.

That signature needs the authority's private key. Whoever holds the key can sign a certificate for any website, and software that trusts the authority will believe it.

These certificates use NIST P-384 keys, which should carry about 384 bits of randomness. The number of possible keys is a figure with 116 digits, far too many for anyone to search.

Every one of eMudhra's eight keys was smaller than 256. So an attacker needs at most 256 guesses, and a laptop does that in milliseconds. A key of 4 is like a bank locker whose combination is a single digit.

With a key, an attacker on the same network, such as public Wi-Fi, could fake a site's certificate and read or change the traffic.

eMudhra share fell from Rs 539 to Rs 345 in two sessions, a 36% crash

Source: The Times of India

The damage so far

Chrome and Firefox blocked the affected certificates on 17 October, and eMudhra revoked them on 18 October. The company says it revoked them within 14 hours of finding the issue.

eMudhra says only one of the eight was put into production and none issued customer certificates, which matches public Certificate Transparency logs. Cloudflare said it found no active exploitation on its services.

The bigger problem is software outside the browser. Helme forged a test certificate for a payment processor's API, and curl, Python and Node.js accepted it with default settings on every Linux and macOS machine he tested.

About 30,000 certificates under eMudhra's G3 root need to move to a new chain. The company is exiting the global SSL/TLS business, which it says is about 1% of revenue. Its shares crashed 36% in two sessions, and CERT-In issued an advisory.

eMudhra says its Indian digital signature and eSign businesses are not affected.

PHP2Shell: the PHP vulnerability hitting the web

PHP runs WordPress, Drupal, Joomla, Laravel and Magento. Wiz says it powers 70% of all websites, and Tenable cites W3Techs at 69.3% of sites whose server language is known.

PHP2Shell is two bugs in the PHP engine itself, not in a plugin. One is in how PHP handles running out of memory: half-built request data is later treated as valid. The other leaves stale state from one request that the next request on the same worker can reuse.

The result is remote code execution without a password. Wiz says affected code goes back to PHP 5.4, and memory leaks can expose passwords, tokens and API keys from other requests.

Timing matters. Amazon Threat Intelligence saw an exploit attempt on 17 October, four days before the patch. It now says PHP2Shell is being broadly exploited, and advises starting any investigation from 17 October.

CrowdStrike warns the attack leaves almost no trace. The only server sign may be a single memory-limit fatal error in the web server's log, which is easy to dismiss as noise.

BleepingComputer reports VirusTotal tracks more than 5.1 million PHP hosts exposed online.

What Indian developers and site owners should check

If you run PHP (WordPress, Laravel, custom sites):

1. Check your PHP version in your hosting panel or server.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux vendor's patched package.
3. Restart PHP-FPM, Apache and any long-running PHP workers. A patch without a restart does not protect you.
4. On PHP 8.1 or older, there is no official release. Upgrade, or confirm a vendor backport covers both CVEs.
5. Using Laravel Forge? Its automatic security updates do not patch PHP, so update each server yourself.
6. Look back at error logs from 17 October for unusual memory-limit fatal errors.
7. Rotate passwords, API keys and tokens that lived on an unpatched server.

Config tweaks such as memory_limit changes reduce some attack paths, but PHP says they do not make a server safe. Cloudflare's WAF rules, free plans included, are a stopgap, not a fix.

For the eMudhra issue:

1. Update your OS trust store (ca-certificates on Linux).
2. Update Python's certifi to 2026.10.19 or later.
3. Rebuild Go apps with Go 1.27.3 or 1.26.10 or later.
4. Rebuild and redeploy container images.
5. If you bought an eMudhra TLS certificate, check whether it chains to the G3 root and ask for a replacement.

Never fix a certificate error by turning verification off. Cloudflare warns that this removes the very protection the updates restore.

The lesson

Both stories say the same thing. Breaking weak systems is getting cheaper, and Wiz says AI models helped turn a long-hidden PHP flaw into a working exploit.

Strong keys, quick patches and knowing what you run now matter more than ever.

FAQs

What was eMudhra's private key? One of the eight weak keys was the number 4. The others were 56, 66, 115, 155, 156, 230 and 237.

Is my eSign or digital signature affected? eMudhra says its Indian digital signature and eSign businesses are unaffected. The problem was in its global TLS certificates.

Which PHP versions fix PHP2Shell? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches need a vendor backport or an upgrade.

Is my WordPress site at risk? Yes, if its PHP is unpatched. The bug is in PHP itself, so an up-to-date WordPress does not help. Ask your host to confirm the patch and a restart.

This article is for general information only and is not professional security advice.

Sources

• The Times of India: eMudhra to exit global SSL/TLS biz; 30,000 certificates affected
• Internet Freedom Foundation: A private key with the value 4
• Ars Technica: eMudhra drops out of TLS business after using cert private key of 4
• Kudelski Security: eMudhra intermediate CA private key compromise
• Implicator.ai: eMudhra estimates 30,000 certificates need migration
• Tenable: php2shell FAQ
• BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches
• Wiz: PHP2Shell, AI uncovers critical RCE vulnerabilities
• Laravel Forge: PHP security advisory, October 2026
• The Hacker News: Someone tried to exploit PHP2Shell 4 days before disclosure