Reputation Radar #17: Four Days Early

Big vulnerabilities usually arrive with a clean timeline. Someone finds the bug, the vendor fixes it quietly, everyone publishes on the same day, and defenders race attackers from that moment on. PHP2Shell broke that timeline. The race started before the starting gun.

The bug, briefly

Wiz published the details on October 21st, alongside the PHP project's emergency fixes: two use-after-free flaws, CVE-2026-109618 and CVE-2026-109619, in how PHP handles sessions and fatal errors during a request. Every PHP version since 5.4 is affected, and PHP runs something like 70% of all websites, WordPress, Drupal, Joomla and MediaWiki among them. Wiz didn't undersell it: "These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history."

The detail that made us sit up was in their write-up of how the bugs were found and weaponised. Frontier AI models did a lot of the heavy lifting, and the old barrier of adapting an exploit to each PHP build is gone: "With AI this is no longer a barrier."

Someone was early

Amazon runs a large honeypot network it calls MadPot. On October 17th it caught an exploitation attempt against PHP2Shell, four days before the embargo lifted at 14:00 UTC on October 21st (Amazon Threat Intelligence). Then, between 02:00 and 08:00 UTC on the 21st, more attempts arrived, still hours ahead of the public release, from different anonymised infrastructure, which suggests more than one actor had the bug.

Amazon is careful about what it doesn't know. It can't say how the information leaked or whether real systems were hit in that window. But its one-line takeaway is the right one for anyone running a disclosure process: "An embargo protects defenders only until someone else finds the same bug." Their practical advice follows from it: start your investigation window on October 17th, not on the day you read the advisory.

Confirmed compromises followed quickly. Adel Karimi, who leads detection and response at Perplexity, published honeypot evidence of successful remote code execution against Apache with PHP 8.4 on October 24th (honeypot data), and Expel's Marcus Hutchins called it the best confirmation of in-the-wild exploitation he'd seen. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on the 26th with a federal deadline of three days.

What the reputation column shows

Amazon published the six source IPs behind those early attempts, so we ran them through our own API.

All six come back investigate. None is benign, and none is flagged malicious either. The October 17th address resolves to a commercial VPN exit with three sources behind it, tagged as an anonymity network and residential proxy. The rest are a mix of the usual rented infrastructure: a second VPN provider, a DigitalOcean droplet, a Hetzner server, a small VPS host, and one address on a cloud network with no feed history at all.

That matches Amazon's own guidance almost word for word. They describe these as shared anonymisation infrastructure and recommend investigating rather than blocking, because the same VPN exit carries traffic for plenty of ordinary people. Blocking every VPN and cloud address that ever touched a PHP2Shell payload would cost you real customers and stop very little, since the next attempt comes from the next exit.

What a reputation check does buy you here is triage. A request to your PHP app that combines a multipart upload with a session upload-progress field, from an address that resolves to a VPN exit or a freshly rented droplet, is worth a much closer look than the same request from your payment provider. Amazon even names the string to hunt for: PHP_SESSION_UPLOAD_PROGRESS in POST requests.

The patch gap

If the exploit window opened early, the patching window is closing slowly. Qualys reported that only 199,000 of roughly 156 million PHP installations, about 0.13%, were patched within 12 hours of disclosure (Qualys). Their stopgap for systems that can't be updated yet is to disable session upload progress in php.ini, with the honest caveat that "compensating controls buy valuable time, but they do not remove the flaw." Amazon is blunter: there's no configuration-only fix, so patch.

So for most of the internet, the realistic position this week is unpatched PHP, exploit code that AI can adapt to any build, and attackers who had a head start. Treat anything PHP-shaped in your logs since October 17th as worth a second look.

Also on the radar

• Brotli2Shell, the other "2Shell". CVE-2026-111497 is an out-of-bounds write in Google's Brotli decoder. It doesn't hit browsers, but it does hit runtimes and libraries that decompress Brotli data: Node.js, .NET, Envoy, Python HTTP clients and more (Tenable). It was exploited against Node.js on October 26th and went into CISA's catalog the next day. "Any application that decompresses attacker-controlled data with a vulnerable Brotli decoder is potentially at risk."
• Gheist and the stolen GitHub tokens. Wiz tracked an automated campaign that, since September 15th, has used stolen GitHub tokens to plant a workflow called sync-check in every repository it can reach, printing secrets in a form that slips past GitHub's masking (Wiz). More than 13,500 branches across 850+ accounts. GitHub's approval hold stops it in public repos, but not in private repositories or Enterprise, where it keeps working. The commits come from real accounts, which is the whole trick.
• Two more for the KEV list. CISA added an SQL injection in Arista VeloCloud Orchestrator (CVE-2026-114625) and a command injection in Collabora Online's built-in CODE server (CVE-2026-110447) on October 23rd, both with three-day deadlines (CISA KEV). VeloCloud's orchestrator is another of those boxes that manages every branch at once.

If you want the longer read on why a cloud or VPN result in the reputation column is a starting question rather than a verdict, we walked through it in Borrowed reputation: when attackers hide behind trusted infrastructure.

See you next week.

Sources are linked inline, with credit to Wiz, Amazon Threat Intelligence, Adel Karimi, Qualys and the other original researchers. If we got a detail wrong, tell us and we'll fix it.

About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.