The security update you keep postponing might be more important than you think

On 21 October, PHP’s maintainers released an emergency security update. Within hours, Amazon was seeing attempts to exploit the vulnerabilities against its network of decoy systems.¹

PHP helps run a large part of the web. Under the right conditions, someone on the internet could use the vulnerabilities to run code on a vulnerable server without logging in. They could expose sensitive information or gain a foothold on the machine hosting a website.²

Eight days after the release, Palo Alto Networks reported that attackers were using the PHP vulnerabilities against some of its internet-exposed management interfaces. In the campaign it described, the attackers combined PHP2Shell with another vulnerability to gain the highest level of control over the affected device.³

That same week, researchers recovered private keys belonging to eMudhra, a company whose certificates help browsers and other software decide whether to trust an online service. Those keys could be used to create certificates that appeared legitimate, potentially allowing someone to impersonate a website or service.⁴⁵

Both incidents involve software most of us rarely see: the runtime beneath a website and the certificates behind a secure connection. An available update helps only when it reaches the device that needs it.

What happened with PHP?

PHP is a programming language and runtime used by many websites, including sites built with WordPress, Drupal and Joomla. The application in your browser depends on that runtime.

The vulnerabilities, collectively called PHP2Shell, were in PHP itself, in the way it handled certain fatal errors. A website could have up-to-date application code and still be exposed because its underlying PHP installation was vulnerable.²

Wiz Research demonstrated attacks against test deployments of WordPress, Drupal and Joomla. In those tests, the researchers could execute code without an account. They also showed that the flaws could expose pieces of the PHP process’s memory, potentially including passwords, authentication tokens and API keys.²

These were controlled demonstrations, not evidence that every WordPress site was compromised. The target’s configuration and the permissions available to the compromised process affect what an attacker can do. Someone able to run commands can start looking at what the server can access.

The researchers reported the issues privately in August. Patched releases and public disclosure followed on 21 October.² The record of attempted exploitation, however, began earlier: Amazon later found an attempt against one of its decoy systems on 17 October, four days before disclosure. It couldn’t establish whether the attempt would have succeeded against a real system or how the person behind it obtained the information. Further attempts appeared almost immediately after the patch was released.¹

By 26 October, the US Cybersecurity and Infrastructure Security Agency had added both PHP vulnerabilities to its catalogue of flaws known to be exploited.⁶ Palo Alto Networks then reported the campaign against its exposed management interfaces.³

Why disclose a vulnerability?

Publishing details can help attackers. Keeping a vulnerability secret indefinitely, though, leaves users unable to protect themselves.

With coordinated disclosure, a researcher reports a vulnerability privately to the software maintainer, who investigates and prepares a fix. Once the fix is ready, the vulnerability is disclosed. Users can then find out whether they’re affected and install the update.

A private report gives defenders a head start. It cannot stop someone else from independently finding the flaw or already using it. Amazon’s discovery of an attempt before the PHP2Shell disclosure shows the limit of an embargo: it’s an agreement between the people who know about a vulnerability.¹

A fix gives attackers information too. They can read the advisory or compare the old software with the updated version to work out what changed. Depending on the flaw, that can help them attack systems that haven’t been updated.

Not every disclosure immediately produces a reliable exploit. Mandiant studied 138 vulnerabilities disclosed in 2023 that it knew had been exploited. Of the 41 first observed being exploited after a patch became available, five were exploited within one day and 12 within a week. The sample was selected because the vulnerabilities were known to have been exploited; it doesn’t mean all disclosed vulnerabilities follow that timetable.⁷

An update closes the particular weakness it fixes. It won’t undo damage from an attacker who already got in, or protect against every other way in. For PHP2Shell, Amazon says updating is the only complete remediation for both vulnerabilities. Temporary measures can reduce exposure while an update is prepared, but they don’t fix the underlying problem.¹

eMudhra: who does your software trust?

When you connect to a website over HTTPS, your browser checks a digital certificate to help establish that it has reached the intended service. Certificate authorities are organisations trusted to participate in issuing those certificates.

In October, researchers recovered eight eMudhra intermediate certificate authority private keys. Six were associated with website and service authentication; two were associated with code signing, which helps software identify the publisher of code.⁴

With those keys, someone could produce certificates or signatures that appeared to come through a trusted authority. A forged website certificate could enable impersonation and interception if the attacker could also get into the path of the connection and the affected software still trusted the certificate. Possessing a certificate alone doesn’t put an attacker inside everyone’s connection.⁴⁵

The problem lay in the system used to decide who is at the other end; HTTPS encryption itself hadn’t been broken.⁵

The response involved blocking or removing trust in the affected certificate authorities. Microsoft updated its Windows disallowed-certificate list and later removed associated certificates from Windows and Edge trust lists.⁴ Cloudflare updated its services and released updates for some customer software. It said its review had not identified active exploitation against Cloudflare services; that isn’t proof that exploitation occurred nowhere.⁵

Your browser isn’t the only software making secure connections. An application might use the operating system’s list of trusted certificates, or it might maintain its own. Cloudflare warns that a successful browser test doesn’t prove a background service on the same machine is protected.⁵

Some updates change what software is willing to trust, sometimes quietly and automatically. Most people don’t need to inspect certificate chains by hand. But if you run applications, it’s worth knowing which parts of your stack maintain their own trust settings. Disabling certificate checks to make an error disappear removes the protection those checks provide.⁵

The box between your devices and the internet

A router may sit behind the television for years, largely forgotten once the Wi-Fi works. It may receive less attention than a smart speaker, but it’s a computer too. Your devices use it to reach the internet, and it often controls which incoming connections are allowed and how devices on your home network communicate.

What happens if an attacker gains control of a router depends on the access they obtain. They might change network settings, interfere with connections, observe traffic that isn’t properly encrypted, try to reach other devices, or use the router to attack someone else.

A compromised router doesn’t automatically expose every password or let an attacker read every HTTPS connection. Properly authenticated HTTPS is designed to protect the contents even when the network carrying them cannot be trusted. The eMudhra incident shows why the authentication part matters.

In 2024, the US Department of Justice announced that it had disrupted a network of hundreds of compromised home and small-office routers used by a group known as Volt Typhoon. According to the department, the group used them to conceal the origin of further attacks. Most were old devices whose manufacturers had stopped providing security updates.⁸

The router owners didn’t have to be the intended targets. The devices were connected and vulnerable, and they could make traffic appear to come from somewhere else.

Find out who maintains your router and for how long. If your internet provider supplied it, the provider may manage updates remotely or expect you to take action. If you bought it, the manufacturer’s support page may show the latest firmware and end-of-support date. Check the exact model: similarly named products can have different support timelines.

You can also check whether its administration interface is accessible only from inside your home or from the internet. Remote administration can be useful, but it creates another exposed service to maintain.

An unsupported router doesn’t become compromised the day support ends. But if someone finds a serious vulnerability afterwards, there’s no fix coming. Keep the device, and you accept a risk that can grow while your ability to address it shrinks.

Where AI fits

Wiz says its researchers used AI models during PHP2Shell discovery, exploit development and patch validation. The models helped the researchers work through complex flaws and adapt demonstrations to different applications.²

Similar assistance can help attackers. In a separate report, Google’s threat intelligence team described a case where it had high confidence that a criminal actor used an AI model to help discover and develop an exploit for a previously unknown vulnerability.⁹

Amazon argues that AI-assisted analysis is making it cheaper to turn information about a patch into a working exploit.¹ That’s an assessment of a broader trend, not proof that AI was used in every PHP2Shell attack or a measurement of how much faster this particular campaign moved.

If these tools make exploits easier to understand and adapt, more vulnerabilities may become practical targets for more people. Researchers and maintainers can use the same tools.

Following the updates

Most people can’t follow every security advisory. Start by finding out where updates come from and whether they’re still reaching the software you depend on.

Your phone and computer may install operating system updates automatically, but some applications update separately. Your browser can download an update and then wait for you to restart it. A router may update itself, be managed by your provider, or require a manual firmware update. An old connected camera may still work perfectly even though its manufacturer has stopped maintaining its software.

Businesses face the same problem across servers, appliances, containers and third-party dependencies. An application may be up to date while the PHP runtime beneath it is not. A browser may have received a trust update while a background service uses an older certificate store.

Updates can cause problems too, so testing, backups and a recovery plan belong in a maintenance process. But if that process takes weeks to deploy an urgent fix to an internet-facing system, it also needs to account for the risk during those weeks.

Strong, unique passwords and multi-factor authentication reduce the damage from stolen credentials. Backups help when prevention fails, and restricting remote access can reduce exposure while a fix is being prepared. None makes an unpatched vulnerability disappear, and a patch doesn’t make the other precautions unnecessary.

In both the PHP2Shell and eMudhra cases, researchers identified the problems, maintainers prepared fixes and providers distributed them. The changes still need to reach users’ and organisations’ systems, even when the only visible result is an update followed by a restart.

Sources

Footnotes

1. Amazon Threat Intelligence: PHP2Shell exploitation attempts before public disclosure ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Wiz Research: PHP2Shell technical analysis and disclosure timeline ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Palo Alto Networks Unit 42: PHP2Shell threat brief and updates ↩ ↩²

4. Microsoft: Response to compromised eMudhra certificate authority keys ↩ ↩² ↩³ ↩⁴

5. Cloudflare: Eight eMudhra certificates are compromised ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. CISA: Critical vulnerabilities in PHP require immediate patching ↩

7. Mandiant: Analysis of 2023 time-to-exploit trends ↩

8. US Department of Justice: Disruption of a botnet of home and small-office routers ↩

9. Google Threat Intelligence: Adversaries leverage AI for vulnerability exploitation ↩