Hackers Exploited the PHP Vulnerabilities Days Before They Were Patched

Wired ·

Amazon Web Services says an actor tried to exploit two critical PHP flaws on 17 October, four days before the vulnerabilities were publicly disclosed and patched. The early attempt highlights the risk that attackers may obtain or develop exploit information before fixes are announced, while defenders are still preparing to update affected systems.

AWS found the activity when it reviewed data from a deliberately vulnerable honeypot; the attempt came from an IP address linked to a commercial anonymisation network. Researchers also saw several attacks around the public disclosure, and AWS says PHP2Shell is now being widely exploited, though it is unclear whether the observed attempts would have worked against real systems. AWS argues that AI tools can help more attackers turn technical details into exploits quickly, putting pressure on vulnerability disclosure and patching timelines.

In short

  • AWS found a PHP2Shell exploit attempt dated 17 October.
  • The attempt preceded public disclosure and patches by four days.
  • AWS says the flaws are now being widely exploited.

Cybersecurity Technology

Read the full article at the source →

Discussion

  • Shane Rounce: Four days is the bit that sticks with me. It means “patch when the advisory drops” was already too late for anyone running these versions. Attackers don’t wait for the press release. I run a lot of PHP sites, so a few habits that have saved me grief: Patch critical fixes the same day. Test on a staging copy, then push live. “Next maintenance window” is a gift to attackers. Know what you’re running. Keep a list of PHP versions, CMS, plugins and themes. Old, unsupported PHP is where most of the trouble starts. Put a WAF in front. Cloudflare or similar can block known exploit patterns while you get the patch out. It buys time, it isn’t a substitute. Limit the blast radius. Disable PHP functions you don’t need, stop PHP executing in upload folders, and run each site under its own user so one compromise doesn’t take the lot. Watch your logs. Odd POST requests, unexpected new files, and traffic from anonymisation networks are early warning signs. Test your backups. Offsite and versioned, and actually restore one now and then. The AI point is the one to take seriously. If tools can turn a technical write-up into a working exploit in hours, the gap between disclosure and mass exploitation is only going to shrink. Response speed is what to invest in. I’ve written more on this sort of thing on the AceHost blog (acemedia.host) if you want the longer versions. 1 day, 2 hours ago

Log in to join the discussion