It's Complicated: You, Your SaaS Vendors and PHP2Shell

How a Shelved 2024 Bug Reached the World#

In 2024, a core developer working under contract to the PHP Foundation was fixing an issue from an external audit when they found what the Foundation calls "the first signs of the OOM problem" behind one of this month's flaws: a weakness in how PHP handles running out of memory.

A potential exploit was theorized, but "no concrete vectors were found." The security team "developed several competing approaches, but each came with its own trade-offs." With no demonstrated way in and no easy fix, the PHP maintainers let it wait. The Foundation relies on donations, and security work on PHP itself still depends on "a small group of foundation-funded developers and a little volunteer help." Read without hindsight, the call looks like ordinary triage, the kind every underfunded engineering team makes every week.

The Foundation's own judgment, published the day the fixes shipped, is harsher: it now calls the delay "a structural failure, caused by both the security team's decision process and its lack of resources."

In August 2026, three teams with AI tools found the flaws independently: Ryan Austin of the security firm Calif, during an audit of PHP's source code; a team at OpenAI; and the cloud security company Wiz, using large language models and its own tool, Wiz Atlas. Looking has become cheap. Turning a find into an attack is still hard: Imperva notes that "triggering the bug is much easier than turning it into code execution."

On October 17, Amazon's threat sensors recorded an exploitation attempt, four days before the fixes were released. News of the flaws leaked on October 20, ahead of the planned release, and a video Calif published by mistake the same day revealed a few limited details. The PHP project published its fixes on October 21, and watchTowr observed exploitation of both flaws in the wild the same day: "Reaching the server over the network is enough; no account or prior access is needed."

Fixing, and Waiting on the World to Change#

The US Cybersecurity and Infrastructure Security Agency (CISA) opens its list of actions with the first task: "identify and inventory systems running any version of PHP across your organization." From there the work splits in two, depending on who runs the system.

For the systems a company runs itself, the hard part is finding them. No one has a list with "PHP" written next to every system, so someone has to go and look. That means logging into servers one at a time, reading through hosting dashboards, and tracing the scheduled jobs and small tools that face the public. Each find raises the same two questions: does this run PHP, and what can reach it? Anyone who has done this work knows the dread that comes with it, because there is no way to tell how many more are left. It might be an old marketing site still online, an internal tool someone set up years ago and everyone forgot, or a container image that has not been rebuilt in months.

Once a system is found, the fix is in the company's hands. The team updates it, checks it, and knows it is done.

For the systems SaaS vendors run (the CRM, the help desk, the forms on the website, billing), there's nothing to log into, so the only way to know is to ask. It's easy to assume a vendor handles a flaw like this on its own, and most will. But their servers hold your data and the access tokens you've given them, and from the outside there's no way to tell whether they run PHP at all, let alone whether they've patched. So the questions go out by email and support ticket. Answers come back uneven. One vendor replies with a version number and a patch date. Another replies "we're monitoring the situation." Another says nothing at all. There is no way to speed a vendor up from outside, and no way to verify an answer from outside either. The follow-up emails go out, the ticket sits open, and the timeline belongs to someone else.

By the end of the week, two lists sit side by side. One is things fixed. The other is things the company has been told.

Finding the High Ground#

Nobody in this story made a bad call: not the PHP maintainers, not the SaaS vendors, and not the company that chose to buy rather than build. The risk still ended up with the end customer, on a timeline it didn't choose. That's what makes it complicated, and it's why the high ground has to be chosen before the next week like this one arrives. Three decisions are worth making now.

Know which links your most sensitive data passes through. Customer records, payment details, credentials: each one travels through a chain of systems, some run by you, some by SaaS vendors, some by vendors of vendors. A crisis week is a bad time to draw that map for the first time, because every question you send a vendor starts with knowing whether the answer matters. Which systems does our most sensitive data actually touch, and who runs each one?

Set terms with the SaaS vendors you keep. Contracts and renewals are the moment to agree on what a vendor will disclose about the software it runs, how fast it will disclose, and what a compromise there can reach. The reach matters. The advisory for one of these flaws describes attacker code running "with the web worker's privileges", and a vendor's compromised server can use whatever access tokens you have handed that vendor. Rotation timing matters too: rotate the keys you have given a vendor after they confirm the fix, because rotating earlier puts new keys on an unpatched server. What will our SaaS vendors commit to telling us, and how quickly?

Own the few links where waiting isn't acceptable. Most of the time, the SaaS trade is worth it. The vendor absorbs the maintenance, and your team builds things that matter to the business. The argument here is for knowing the exceptions. For the small number of systems where a four-day gap between attack and patch would do real damage, running the system yourself means you can patch the afternoon a fix ships and know it is done. Which of our systems cannot wait on someone else's schedule?

Somewhere right now, a small team is looking at a flaw nobody can exploit and deciding it can wait, in software your company runs on. You cannot stop the next decision like the one made in 2024. You can decide how much of your week it gets to own. That is the subject of the webinar, "Post-SaaS Application Architecture: Building the Enterprise Stack for 2027," on November 10 with Nick Van Weerdenburg and Ben Hofferber: what to build, what to buy and what to own.

Join the webinar#