PHP2Shell Exploited Since Oct. 17: Check Your Site

Amazon said on October 21, 2026 that it saw an attempt to exploit PHP's PHP2Shell flaws on October 17, four days before public disclosure, and that they are now being broadly exploited. If your site runs PHP, updating is not enough: check what happened from October 17 on.

What we know

  • The first attempt: according to Amazon Threat Intelligence, writing on the AWS Security Blog on October 21, its MadPot honeypots (decoy servers built to attract attacks) logged an exploitation attempt on October 17. It came from an address on a commercial anonymization network. Amazon says it is unclear how the attacker got the details early.
  • Patch day: Amazon says several proof-of-concept exploits were circulating by about 02:00 UTC on October 21, and that more attempts came from other anonymized networks between 02:00 and 08:00 UTC. Because they differed, it believes several actors were involved. It adds that its analysis is ongoing and it does not know whether those attempts would have worked on real systems.
  • After disclosure: PHP released the fixed versions at 14:00 UTC. Amazon says more proofs of concept appeared within hours and were used against its sensors almost immediately. Its conclusion: "PHP2Shell is now being broadly exploited in the wild."
  • What it recommends: upgrade now to the fixed versions, which AWS calls the only complete fix for both flaws (CVE-2026-109618 and CVE-2026-109619). There is, it says, no configuration-only workaround that fully covers them.
  • If you can't upgrade today: Amazon suggests considering blocking multipart file uploads, after checking how that affects your application.
  • What to check: look for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads, review web server logs, and look for unexpected processes or file changes. AWS says investigations should start "at least" on October 17, not on the disclosure date.
  • The IP addresses: the report lists six IPs seen on October 17 and 21. Amazon notes they belong to shared anonymization infrastructure, are not exclusive to these attacks, and should be investigated rather than blocked.

What changes and what doesn't

The fix is the same as yesterday: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package.

What changes is the start date for your review. When the fixes shipped, the PHP Foundation said it had not identified working exploits. Amazon's report doesn't fully contradict that, since it doesn't know whether the early attempts succeeded, but it does show someone was trying from October 17 and that attacks are now widespread. A site updated on October 21 may have been exposed for four days before that.

The report also gives no count of compromised sites. It describes attempts against honeypots, not victims.

How to tell if you're affected

  1. Confirm your PHP version. In WordPress: Tools → Site Health → Info → Server. In Drupal: Reports → Status report. If you don't see 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later (or a patched package from your host), updating still comes first.
  2. Ask your host about dates. "When did you apply the fixed PHP version on my plan? Have you reviewed logs from October 17 for CVE-2026-109618 and CVE-2026-109619?" On shared hosting, the server logs usually sit with the provider.
  3. Look for files added or changed since October 17. In your hosting file manager or over SFTP, sort your site folders by modified date, especially uploads, themes and plugins or modules. A .php file you don't recognize in an images folder is a bad sign.
  4. Review admin accounts. In WordPress or Drupal, check for new users or permissions you didn't grant.
  5. On a VPS or your own server, whoever runs it should review access logs from October 17 against the indicators in the AWS report and look for odd processes started by the web server user.
  6. Don't block those IPs blindly. They belong to anonymization networks many people use. If they show up in your logs, treat it as a lead to investigate, not proof.
  7. If you find something, deleting the file is not enough: change the passwords and keys your site stores (database, email, payments), restore from a backup taken before October 17 if you have one, and watch Search Console for security warnings or pages you didn't publish.

Related: PHP2Shell: Attacks Seen After PHP Patch, What to Do

Sources

Updates: if PHP, AWS or a national CERT publishes numbers of compromised sites, they will be added here with a link.