The last 72 hours has been rough for almost every security team, as two newly disclosed PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, have impacted most of the internet. These vulnerability disclosures occurred alongside other high priority vulnerabilities in Gitlab, Node, and React, as well as major incidents for OpenCode, LiteLLM, and Railway.
PHP runs almost 70% of all websites (largely due to Wordpress’ prevalence), and these vulnerabilities affect almost all of them, as they’re present in the runtime engines. If you haven’t patched yet, Wiz’s writeups and response resources are very helpful, as is Calif’s breakdown of the vulnerability. PHP 5.4 through PHP 8 are affected (good news, if you haven’t patched in 20 years, you’re in the clear). Critically, these means a forced migration to PHP 8 as the only major version supported.
Aside from the patching fire drill, the PHP vulnerability disclosures sparked debate and some disappointment within the community. The conversation largely centered on two issues: who deserves credit for discovering the vulnerabilities, and why some information was published before the embargo lifted. Regardless of how you feel about the issues, both of them reflect the new reality of vulnerability discovery and remediation.
The New Normal for Vulnerability Discovery
The first debate centered on who discovered the PHP vulnerabilities first: Wiz or X user LCFR at Calif. While the PHP blog unambiguously confirms LCFR first identified the vulnerabilities, that doesn’t mean Wiz’s research team didn’t independently also find them. The broader issue is adjusting to the reality that first emerged in open-source malware research: multiple researchers will independently discover the same issue at similar times. In other words, “who was first” is more challenging to distinguish, and not as meaningful as it once was. It’s also becoming murkier to determine in light of the numerous private vulnerability research initiatives, especially targeting popular open source libraries.
Two points are clear:
Proper attribution and timelines always matter for recognizing the hard work of the many people involved in discovering and fixing a vulnerability
Now that several teams are using the same AI tools at the same time, not “being first” doesn’t mean you copied
With the growing number of closed or partially closed initiatives from frontier AI labs, we should expect discovery overlaps to happen more frequently. As more teams build and deploy their own AI-powered security tools, independent vulnerability discovery will become an increasingly common outcome. It’s one of the downsides of the privatization of vulnerability research and management, a trend we’ve written about here.
As the market navigates this new normal, there needs to be less emphasis on who found a vulnerability first and a focus instead on providing clear and actionable guidance. Discovery credit still matters and I’m always a fan of calling out the individuals who drive security research, but it’s increasingly difficult to establish definitively who was first, and the conversation can quickly devolve into a race over who publishes the first blog. That’s not a particularly useful way to measure the value of security research - credit should go where credit is due, and it needs to be clear that OpenAI, Calif, and Wiz all seem to have been key in disclosure and patching.
It’s important to give research teams the benefit of the doubt, whether from large companies like Wiz or smaller ones like Calif. It’s worth remembering that even within large companies, this is very a small community of people doing difficult work, often with the shared goal of making software more secure. We should be careful not to lose sight of the substance of the research amid debates over attribution and impressions. I’d prefer we’re thankful to everyone involved for their work in making the internet safer.
The Limits of Coordinated Disclosure
The second controversy was the PHP Foundation criticizing Chainguard for publishing a patched PHP image before the embargo was lifted. Embargo breaches are unfortunate, particularly when coordinated disclosure is essential to giving defenders time to patch. However, incidents like this highlight the growing difficulty of coordinating disclosure across an increasingly decentralized security ecosystem, where multiple vendors and umbrella organizations are all working towards protecting their customers as quickly as possible.
Chainguard may be the most visible example in this case, but it won’t be the last organization to find itself navigating these competing pressures; again, this is a reflection of where the industry is going and the new normal. It’s still unclear whether or not exploits have been spotted in the wild, and when mitigations and embargoes may have been deployed too early by various teams.
For example, we work with several vendors who conduct extensive AI Pentesting, static analysis, and vulnerability research. These teams are all investing in the discovery of open-source vulnerabilities, for both competitive recognition and customer protection. Parallel discoveries, overlapping disclosure timelines, and the race to ship mitigations are getting more challenging to navigate, as popular open source repos are scanned by new models and harnesses on an ongoing basis.
The challenge extends beyond detection to remediation. Without an upstream patch, vendors may develop independent fixes that diverge from one another, complicating downstream patching and potentially introducing new vulnerabilities. This is the new normal: a decentralized vulnerability ecosystem in which discovery, disclosure, and remediation don’t always follow a coordinated path. Embargoes and coordinated disclosure remain important, but they cannot reliably synchronize every researcher, vendor, and release in a world where numerous teams are continuously scanning the same libraries, submitting issues to their under-funded maintainers.
The underlying challenge is that the security ecosystem is becoming more private and distributed into vendor collectives, while many of its established disclosure practices were designed around a smaller number of closely coordinated participants, with an assumption of limited discovery capabilities. Long story short, we’re going to have to expect more mitigations to ship earlier, as it becomes less clear when an exploit is available, and who discovered what vulnerability. Embargos are not the defense they once were.
More RCEs are Under Active Exploitation
While PHP dominated the headlines, it wasn’t the only major vulnerability discovery this month. Critical remote code execution (RCE) vulnerabilities in GitLab, Node, Next, and Plex also deserve attention, underscoring just how much security teams have had to contend with in a short period. It seems we’re on the verge of an everything2shell.
While each of these vulnerabilities has interesting timelines in their own right: from Gitlab needing multiple patches to properly remediate, to Node and Gitlab both taking a private fix and disclose later approach, one key takeaway is that organizations need to start their vulnerability management program with a patching and mitigation strategy first, and a detection response strategy second. In other words, a monthly “patch the criticals” strategy is not an effective solution.
Typically the right answer to “how can we reduce our vulnerabilities” is threefold:
What assets are you able to patch within a one hour time frame? Modern and easily deployable microservices that are not stateful applications should have clear paths for rapid patching.
For assets you can’t patch, what is the mitigation strategy? Typically a combination of WAF and CADR tooling, sometimes backported patching providers.
If an exploit happened, how would you detect it? Requiring a mix of endpoint, cloud and network logs.
These three questions should be answered before focusing on patching high and critical assets only as needed. Once again, AI is introducing a new normal of high impact vulnerabilities for widely distributed open source projects, teams need to proactively prepare their patching and mitigation strategies - that means having a strategy for updating even when vulnerabilities aren’t present.
AI Driven Incidents
Alongside major vulnerability disclosures, this week saw several high profile compromises of open and closed source projects: Railway, OpenCode, and LiteLLM. It’s clear that the real impact of AI from a risk perspective is how it increases the likelihood of attacks - complex attacks are much more achievable for the average threat actor.
Across all three incidents, attackers targeted sensitive credentials. There are two layers to these incidents that are worth considering: first, the likelihood of supply chain breach as AI attacks increase sophistication, second, the importance of being able to properly rotate and manage your API tokens, traditionally categorized as non-human identity (NHI) security. Railway stated in their disclosure that “We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.” Sophisticated attacks are targeting supply chain platforms to gain access to companies. It’s also worth briefly noting in the face of the criticism levied at Railway the challenges of running security at such a high
Second, being able to quickly rotate credentials is a challenging but increasingly necessary process. Teams should have a strategy in place to rotate all credentials. Even when using credential management tools like Hashicorp Vault, challenges remain because your running application ultimately needs access to an unencrypted secret stored in memory - meaning there is never a situation where rotation is an impossible outcome. Optimally, your keys are rotating automatically anyways, but this is a more mature capability many teams don’t have. NHI solutions can also help tackle this problem, but have various tradeoffs depending on their approach and architecture.
Conclusion
AI doesn’t radically transform the fundamentals of security: teams should have always been prepared for supply chain breaches, rapid patching, and credential rotation. AI does however change the speed and sophistication of what teams need to prepare for. Major vulnerability disclosures are clearly on the rise, and sophisticated attacks are growing more commonplace, so teams need to prioritize the fundamentals. Namely having strong posture, patching, mitigation, and incident response capabilities.
Additionally, the nature of vulnerability discovery and disclosure is rapidly growing more complex, as privatized communities work alongside independent researchers, making it unclear who is disclosing what, when, and what mitigation capabilities are available. In my opinion, simplicity is always better: making patching easy while having necessary mitigation tooling is the only real solution.
On "Without an upstream patch, vendors may develop independent fixes that diverge": Alpine Linux published a dated example yesterday. GitLab's 12 October fix for the CVSS 10 regex flaw (CVE-2026-97229) was a set of patches to the Ruby that GitLab bundles in its own packages and images. Upstream Ruby only shipped the fix on 23 October. Alpine runs GitLab in its own image on standard Ruby, so upgrading to GitLab 19.3.6 on 22 October left it vulnerable, and it found that out on 26 October. An attacker had already crashed its workers 8 times on 20 and 21 October, while it was still on an older version. The new rule in their write-up is to check each GitLab release for Ruby or other component patches their own build has to apply. The version string alone did not tell them.
James, your three-question order is the right one, and #3 is where most teams overestimate themselves. "How would you detect it?" usually gets answered tool by tool, and PHP2Shell showed why that breaks: the WAF logs an odd request, EDR sees Apache spawn a shell, the network sees an outbound callback, and each looks dismissible alone. The detection *is* the correlation. Curious whether your SecOps report data shows teams testing that end to end. (Disclosure: I'm at Stellar Cyber.)