Last month, several websites paused operations after two critical vulnerabilities turned up in PHP, the open-source language behind nearly 70% of the world’s websites. The flaws, collectively called PHP2Shell, had sat dormant for over a decade and were uncovered Opens a new window by a coalition of researchers — with help from frontier AI models.
Palo Alto Networks soon warned Opens a new window that more than 22.6 million exposed instances — systems, servers, applications, websites — were potentially at risk. For enterprises, the real threat goes far beyond a rogue AI model in a test lab. It underscores the immense risk tied to ubiquitous open-source tools and builds a compelling case to re-examine supply chains now that AI can uncover hidden vulnerabilities at unprecedented speed and scale — with researchers demonstrating Opens a new window AI-assisted attacks with data exfiltration in as little as 25 minutes.
Open-source software allows enterprises to build applications faster and avoid reliance on a single vendor. However, it also creates complex dependency chains, meaning a single flaw in a widely used tool like PHP can expose thousands of applications to risk. According to a 2026 report by Omdia (commissioned by Docker), 31% of organizations report that open source makes up more than half of their codebase — a figure projected to grow to 51% within a year.
As the velocity of automated threat discovery accelerates, evaluating the hidden vulnerabilities within these foundational software layers is quickly shifting from a technical precaution to a critical strategic priority.
When a dependency becomes a liability
PHP isn’t the only widely used open-source tool to carry a high-severity flaw. Less than a year ago, a bug in a common component became a major security problem for enterprises: React2Shell, which hit parts of the React and .js ecosystems Opens a new window embedded in countless enterprise apps.
Palo Alto Networks found Opens a new window that China-backed attackers exploited it to steal cloud credentials, run remote-access trojans, and install backdoors, more than 50 firms Opens a new window were targeted.
PHP, meanwhile, is one of the internet’s workhorses — , WordPress, and Wikipedia were all built on it. But it’s also under-resourced. The Electronic Frontier Foundation noted Opens a new window that many such projects are kept alive by a small group of volunteers who are occasionally paid a small stipend, and that those overworked maintainers are now drowning in vulnerability reports, leading to burnout.
Some enterprises do try to vet what they pull in. Docker’s survey Opens a new window found 47% check the reliability of the vendor or source, and 42% accept pre-vetted “secure” open source. But only 24% care whether a project has an active community, and only 27% look at its disclosure policy or repository ratings.
Kawin Boonyapredee, CISO advisor at KnowBe4, told Spiceworks the question isn’t whether to use open source — it’s whether you have the visibility and discipline to know what you’ve pulled in and who’s maintaining it.
“Attackers know this, so they don’t need to break through an organization’s perimeter when a single compromised dependency gets them in the door,” he says.
The numbers back him up. Black Duck’s 2026 report found that 93% of audited codebases contain components with no development activity in the past two years, and that 65% of organizations suffered a supply chain attack in the past year. Of the malicious packages it identified, 34% were legitimate packages that had been hijacked.
Why disclosure is too late
For many enterprises, a vulnerability only becomes a risk once it’s found and disclosed. That mindset needs to change — it’s pushed teams toward detection and patching instead of questioning the risk in the dependencies themselves.
In a world where AI has compressed the exploit window, enterprises have to decide what risk from open source they can actually tolerate. In Boonyapredee’s view: “Is it being exploited right now, is the vulnerable code path actually reachable in an organization’s build, is the maintainer still alive, and can an organization patch it before the SLA expires? If the answer to any of those is no, it’s not a risk organizations are accepting, but a risk organizations are ignoring.”
The Open Source Initiative calls Opens a new window vulnerability response a business-critical liability that needs tools, ownership, and accountability — and points to a real gap: 20% of organizations haven’t defined a process for responding to CVEs, 39% of large organizations struggle to hit their internal remediation SLAs, and 55% of firms that failed a compliance audit last year were running end-of-life open source.
This isn’t only an enterprise problem. A small IT team running a WordPress site and a handful of internal apps faces the same blind spot — dependencies it never inventoried, maintained by people it’s never met.
Why SBOMs still aren’t doing their job
As open-source stacks fragment, the real challenge is identifying which components are affected and need patching. Security firm TuxCare found Opens a new window that many organizations still lack a centralized, real-time inventory — a software bill of materials, or SBOM — of what they’re actually running, and that less than 40% maintain a formal, continuous inventory of indirect dependencies. Most rely on manual audits at major releases or procurement.
The trust model, TuxCare found, is mostly “source and scan”: organizations favor curated repositories (58%) and software composition analysis (51%) over compliance controls (20.3%) and SBOMs (8.4%). That plugs risk at deployment, but it says little visibility and governance across the dependency chain — and it suggests security teams still don’t see SBOMs as operational controls.
That’s a problem when AI-driven threats move fast. IT teams need immediate answers to questions like which applications, systems, or services use a given open-source component. Without an accurate SBOM tied to live threat feeds, that can take days.
Boonyapredee agrees an SBOM can cut triage from weeks to hours — but only a fraction of organizations have closed the gap between generating one and acting on it.
“The challenge with continuous risk management is that these SBOMs are usually static, preventing updated lists from happening in real time. In addition, larger complex ecosystems often have fragmented tooling to maintain a consistent and interoperable list of SBOMs, on top of the challenges of integrating these into automated workflows, vulnerability management platforms, and incident response processes,” he says.
So what does acceptable risk look like now?
Enterprises — and smaller IT teams alike — can no longer trust open source blindly. The fix isn’t a one-off audit; it’s continuous: monitor dependencies, validate software integrity, and add runtime verification.
That means redefining acceptable risk: prioritize supply-chain monitoring, fund SBOM work beyond compliance, and treat dependency visibility as a business requirement rather than a paperwork exercise. An SBOM generated once for a procurement review tells you what you had; one wired into live threat feeds tells you what you’re exposed to now.
Categories: Articles , Security
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
