October 23, 2026
Sometimes a cybersecurity story develops so quickly that it’s difficult to understand just how serious the situation has become.
This week, we learned about two critical vulnerabilities affecting PHP, one of the programming languages used extensively throughout the internet. Security researchers discovered vulnerabilities that could allow attackers to execute code remotely on vulnerable servers.
Emergency patches were released on October 21, 2026.
But that wasn’t the only cybersecurity news that day.
Other developments involved Node.js, an open-source tool called LiteLLM, and a certificate authority. The incidents were separate, but together they raised an uncomfortable question: How much of the internet depends on software and infrastructure that can suddenly become a security liability?
The PHP2Shell vulnerabilities
The two vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell.
Both involve memory-management problems that can potentially allow an unauthenticated attacker to execute code on a vulnerable web server.
That last part matters.
An attacker who can execute code remotely may be able to interfere with a server, access information, or establish additional malicious activity, depending on the privileges available and the configuration of the affected system.
According to BleepingComputer, researchers from Calif, OpenAI, and Wiz discovered the vulnerabilities.
The PHP security team released emergency updates on October 21. The fixed versions included PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Administrators running older versions need to investigate whether their operating system or long-term-support provider supplies appropriate backported security fixes. Otherwise, they need to migrate to a supported, fixed version.
The PHP security team also provided temporary mitigations. However, those measures are not substitutes for installing the security updates.
Does this mean 70 percent of the internet is vulnerable?
This is where we need to be careful.
CBS News reported that PHP powers up to 70 percent of the world’s websites and web applications.
That is an enormous number, and it helps explain why the discovery attracted so much attention.
However, there are three different questions we must consider.
First, how many websites use PHP?
Second, how many of those websites are running vulnerable versions or configurations?
Third, how many vulnerable websites have actually been compromised?
Those questions do not have the same answer.
A website using PHP is not automatically evidence of a successful attack. Nor does widespread use of PHP establish that every installation is vulnerable in exactly the same way.
The important issue is whether administrators have identified their exposure and installed the appropriate security updates.
For ordinary internet users, the primary concern is that a vulnerable website might contain personal information that attackers could access if they successfully compromise the server.
That doesn’t mean people should stop using the internet. It means website operators have an urgent responsibility to protect the systems holding customer information.
Attackers were already looking for opportunities
The timing of this discovery is particularly concerning.
On October 22, BleepingComputer reported that Amazon Threat Intelligence had observed activity targeting PHP2Shell beginning October 17.
That was four days before the emergency patches became available.
Other security organizations also reported attempted exploitation before the public disclosure.
But there’s an important distinction between detecting malicious activity and confirming that attackers successfully compromised systems.
Amazon reported that exploitation attempts were widespread, while acknowledging uncertainty about how many attacks had succeeded.
Dataminr’s researchers separately reported that the activity they had examined consisted of scanning, fingerprinting, and unsuccessful exploits, with no known compromises at that time.
Those findings are not necessarily contradictory. They describe different observations and different levels of certainty.
The larger lesson is that administrators cannot assume attackers will wait until a vulnerability is publicly announced before attempting to exploit it.
Another PHP vulnerability emerges
On October 23, BleepingComputer reported another PHP remote code execution vulnerability, CVE-2026-115560.
This issue is separate from the two PHP2Shell vulnerabilities.
According to the PHP security team, exploitation requires an unusual combination of application behavior and configuration settings.
The affected application must change its session serialization configuration at runtime under specific conditions, while session upload progress remains enabled.
Because the required conditions are uncommon, the PHP team plans to address the issue through its regular release process.
In the meantime, administrators of potentially affected systems can disable session upload progress as described in the official advisory.
This development reinforces the importance of checking the actual technical requirements of a vulnerability rather than assuming every PHP installation faces the same risk.
The internet’s terrible, horrible, no good, very bad day
Cybersecurity commentator Nick Espinosa discussed the October 21 developments in a video titled The Internet and the Terrible, Horrible, No Good, Very Bad Day.
When I first saw that title, I didn’t immediately understand what Nick was talking about.
It turns out that he wasn’t discussing PHP alone.
He also covered security patches involving Node.js, a reported compromise affecting LiteLLM, and a certificate authority incident involving eMudhra.
These were separate developments, not evidence of one coordinated attack.
Nevertheless, they illustrate how many different components must work securely for the internet to function as people expect.
Programming languages, web frameworks, AI tools, certificate authorities, and other infrastructure all play important roles.
When one of those components develops a serious security problem, the consequences can extend well beyond the organization responsible for maintaining it.
Nick also discussed vulnerabilities affecting Plex Media Server and BeyondTrust remote support tools, emphasizing the need for administrators to keep affected products updated.
His broader message was straightforward: organizations cannot afford to ignore security updates simply because their systems appear to be operating normally.
Artificial intelligence changes the timeline
Another important part of this story concerns artificial intelligence.
CBS News reported that researchers used an OpenAI model while investigating the PHP vulnerabilities.
AI-assisted tools can help security researchers examine complex software, identify unusual behavior, and discover problems that might otherwise remain undetected.
That’s potentially very good news for defenders.
Unfortunately, attackers can also use increasingly capable tools to accelerate their work.
The concern isn’t simply that AI can discover vulnerabilities. It’s that the time between discovery, disclosure, and attempted exploitation may continue shrinking.
Organizations need time to understand a vulnerability, determine whether their systems are affected, test available fixes, and deploy those fixes without disrupting essential services.
Attackers don’t necessarily have to follow the same procedures.
That difference creates an operational challenge that security teams cannot solve simply by telling everyone to work faster.
Organizations need established emergency patching procedures, accurate inventories of their systems, and the ability to respond when ordinary maintenance schedules are no longer sufficient.
My thoughts are:
When I first heard about this PHP issue, I wasn’t convinced that it was quite as serious as some of the discussion suggested.
I heard the figure about PHP being used by approximately 70 percent of websites, but that number alone didn’t tell me how many websites were actually vulnerable.
Then Terry mentioned a severity score of 9.5.
That certainly got my attention.
Now, I want to be clear that I haven’t independently verified that particular score against the official vulnerability records. But hearing a number that high made me realize that I needed to investigate the situation more carefully.
SANS NewsBites, Volume 28, Number 79 (October 23, 2026), reports CVSS scores of 9.2 for both PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619. It also confirms that Amazon Threat Intelligence observed exploitation attempts as early as October 17. These are attempted attacks, not proof that websites were successfully compromised.
And when I started looking at the reporting, I understood why everyone was concerned.
We’re talking about vulnerabilities in software used throughout the internet, with the potential for remote code execution and attackers already attempting to exploit the weaknesses.
That is not something administrators should casually dismiss.
But I also don’t want to exaggerate the situation.
If 70 percent of websites use PHP, that doesn’t mean 70 percent of websites have been compromised.
It doesn’t even establish that 70 percent are vulnerable.
We need to understand what the vulnerabilities affect, what the available patches address, and what the evidence tells us about actual attacks.
The other thing that concerns me is how quickly this situation developed.
We have researchers discovering serious vulnerabilities, emergency patches being prepared, information leaking before coordinated disclosure, and attackers attempting to take advantage of the situation.
Meanwhile, administrators are expected to keep everything running.
I’ve discussed this problem before on The Security Box.
Attackers don’t have to attend budget meetings. They don’t necessarily need management approval before trying something new. They don’t have to wait for a maintenance window.
Organizations, on the other hand, have responsibilities to their customers, employees, and users. They cannot always shut everything down whenever a security advisory appears.
But that doesn’t excuse ignoring critical vulnerabilities.
If you’re responsible for maintaining a website or another internet-facing system, you need to know what software you’re running and whether it requires attention.
You also need a plan for handling emergency security updates.
And if your organization cannot immediately apply a patch, you need to understand the available mitigations and whether temporarily restricting access is necessary.
I also find the artificial intelligence aspect interesting.
We’ve discussed the risks associated with AI tools, but here’s an example of researchers using AI to identify serious security problems.
That’s a legitimate benefit.
The problem is that the same technological advances may also make it easier for attackers to move quickly.
So we’re back to a familiar question: Are organizations prepared to respond at the speed these threats are developing?
I don’t think every organization is.
And I suspect we’re going to continue seeing incidents that force us to ask that question.
What administrators and ordinary users should do
For website administrators, the immediate priority is to determine whether affected PHP versions are in use and apply the appropriate security updates.
Administrators should also review the official advisories, examine available security logs, and investigate suspicious activity rather than assuming that installing a patch proves a system was never attacked.
Organizations using other affected products mentioned in Nick’s presentation should consult the relevant vendors’ advisories. Those are separate incidents with their own affected versions and remediation requirements.
For ordinary users, keeping devices, browsers, and applications updated remains important.
However, updating a personal phone or computer does not fix a vulnerable PHP server operated by somebody else.
That responsibility belongs to the organization maintaining the server.
Consumers should remain alert to suspicious communications and possible account-security problems, particularly if a service they use subsequently reports a compromise.
Final thoughts
October 21, 2026, was certainly an eventful day in cybersecurity.
The PHP2Shell vulnerabilities demonstrated how serious security problems can affect widely deployed software.
The additional developments Nick Espinosa discussed illustrated the dependence of modern internet services on numerous interconnected technologies.
And the October 22 and 23 follow-up reports showed how quickly the situation continued to evolve.
The lesson isn’t that the entire internet has suddenly become unsafe.
It’s that security maintenance, responsible disclosure, vulnerability research, and timely remediation remain essential.
We cannot prevent every vulnerability from being discovered.
But we can improve how quickly and effectively organizations respond when those discoveries occur.
Otherwise, as Nick put it in his video’s title, we may find ourselves having another terrible, horrible, no good, very bad day.
Sources and additional reading
- CBS News, October 22, 2026: What to know about the PHP bug affecting 70% of the world’s websites.
- BleepingComputer, October 21, 2026: PHP ships emergency patches for critical PHP2Shell flaws.
- BleepingComputer, October 22, 2026: Amazon says PHP2Shell exploitation began 4 days before patches.
- BleepingComputer, October 23, 2026: PHP shares mitigation for new RCE vulnerability with no patch.
- Nick Espinosa, October 21, 2026: The Internet and the Terrible, Horrible, No Good, Very Bad Day.
- SANS NewsBites, October 23, 2026, Volume 28, Number 79: Update PHP Immediately to Fix Critical Flaws.
Related
Discover more from Jared's Technology podcast network
Subscribe to get the latest posts sent to your email.
PHP2Shell and the Internet’s Very Bad Day: What Happened, What’s Vulnerable, and What We Can Learn
October 23, 2026
Sometimes a cybersecurity story develops so quickly that it’s difficult to understand just how serious the situation has become.
This week, we learned about two critical vulnerabilities affecting PHP, one of the programming languages used extensively throughout the internet. Security researchers discovered vulnerabilities that could allow attackers to execute code remotely on vulnerable servers.
Emergency patches were released on October 21, 2026.
But that wasn’t the only cybersecurity news that day.
Other developments involved Node.js, an open-source tool called LiteLLM, and a certificate authority. The incidents were separate, but together they raised an uncomfortable question: How much of the internet depends on software and infrastructure that can suddenly become a security liability?
The PHP2Shell vulnerabilities
The two vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell.
Both involve memory-management problems that can potentially allow an unauthenticated attacker to execute code on a vulnerable web server.
That last part matters.
An attacker who can execute code remotely may be able to interfere with a server, access information, or establish additional malicious activity, depending on the privileges available and the configuration of the affected system.
According to BleepingComputer, researchers from Calif, OpenAI, and Wiz discovered the vulnerabilities.
The PHP security team released emergency updates on October 21. The fixed versions included PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Administrators running older versions need to investigate whether their operating system or long-term-support provider supplies appropriate backported security fixes. Otherwise, they need to migrate to a supported, fixed version.
The PHP security team also provided temporary mitigations. However, those measures are not substitutes for installing the security updates.
Does this mean 70 percent of the internet is vulnerable?
This is where we need to be careful.
CBS News reported that PHP powers up to 70 percent of the world’s websites and web applications.
That is an enormous number, and it helps explain why the discovery attracted so much attention.
However, there are three different questions we must consider.
First, how many websites use PHP?
Second, how many of those websites are running vulnerable versions or configurations?
Third, how many vulnerable websites have actually been compromised?
Those questions do not have the same answer.
A website using PHP is not automatically evidence of a successful attack. Nor does widespread use of PHP establish that every installation is vulnerable in exactly the same way.
The important issue is whether administrators have identified their exposure and installed the appropriate security updates.
For ordinary internet users, the primary concern is that a vulnerable website might contain personal information that attackers could access if they successfully compromise the server.
That doesn’t mean people should stop using the internet. It means website operators have an urgent responsibility to protect the systems holding customer information.
Attackers were already looking for opportunities
The timing of this discovery is particularly concerning.
On October 22, BleepingComputer reported that Amazon Threat Intelligence had observed activity targeting PHP2Shell beginning October 17.
That was four days before the emergency patches became available.
Other security organizations also reported attempted exploitation before the public disclosure.
But there’s an important distinction between detecting malicious activity and confirming that attackers successfully compromised systems.
Amazon reported that exploitation attempts were widespread, while acknowledging uncertainty about how many attacks had succeeded.
Dataminr’s researchers separately reported that the activity they had examined consisted of scanning, fingerprinting, and unsuccessful exploits, with no known compromises at that time.
Those findings are not necessarily contradictory. They describe different observations and different levels of certainty.
The larger lesson is that administrators cannot assume attackers will wait until a vulnerability is publicly announced before attempting to exploit it.
Another PHP vulnerability emerges
On October 23, BleepingComputer reported another PHP remote code execution vulnerability, CVE-2026-115560.
This issue is separate from the two PHP2Shell vulnerabilities.
According to the PHP security team, exploitation requires an unusual combination of application behavior and configuration settings.
The affected application must change its session serialization configuration at runtime under specific conditions, while session upload progress remains enabled.
Because the required conditions are uncommon, the PHP team plans to address the issue through its regular release process.
In the meantime, administrators of potentially affected systems can disable session upload progress as described in the official advisory.
This development reinforces the importance of checking the actual technical requirements of a vulnerability rather than assuming every PHP installation faces the same risk.
The internet’s terrible, horrible, no good, very bad day
Cybersecurity commentator Nick Espinosa discussed the October 21 developments in a video titled The Internet and the Terrible, Horrible, No Good, Very Bad Day.
When I first saw that title, I didn’t immediately understand what Nick was talking about.
It turns out that he wasn’t discussing PHP alone.
He also covered security patches involving Node.js, a reported compromise affecting LiteLLM, and a certificate authority incident involving eMudhra.
These were separate developments, not evidence of one coordinated attack.
Nevertheless, they illustrate how many different components must work securely for the internet to function as people expect.
Programming languages, web frameworks, AI tools, certificate authorities, and other infrastructure all play important roles.
When one of those components develops a serious security problem, the consequences can extend well beyond the organization responsible for maintaining it.
Nick also discussed vulnerabilities affecting Plex Media Server and BeyondTrust remote support tools, emphasizing the need for administrators to keep affected products updated.
His broader message was straightforward: organizations cannot afford to ignore security updates simply because their systems appear to be operating normally.
Artificial intelligence changes the timeline
Another important part of this story concerns artificial intelligence.
CBS News reported that researchers used an OpenAI model while investigating the PHP vulnerabilities.
AI-assisted tools can help security researchers examine complex software, identify unusual behavior, and discover problems that might otherwise remain undetected.
That’s potentially very good news for defenders.
Unfortunately, attackers can also use increasingly capable tools to accelerate their work.
The concern isn’t simply that AI can discover vulnerabilities. It’s that the time between discovery, disclosure, and attempted exploitation may continue shrinking.
Organizations need time to understand a vulnerability, determine whether their systems are affected, test available fixes, and deploy those fixes without disrupting essential services.
Attackers don’t necessarily have to follow the same procedures.
That difference creates an operational challenge that security teams cannot solve simply by telling everyone to work faster.
Organizations need established emergency patching procedures, accurate inventories of their systems, and the ability to respond when ordinary maintenance schedules are no longer sufficient.
My thoughts are:
When I first heard about this PHP issue, I wasn’t convinced that it was quite as serious as some of the discussion suggested.
I heard the figure about PHP being used by approximately 70 percent of websites, but that number alone didn’t tell me how many websites were actually vulnerable.
Then Terry mentioned a severity score of 9.5.
That certainly got my attention.
Now, I want to be clear that I haven’t independently verified that particular score against the official vulnerability records. But hearing a number that high made me realize that I needed to investigate the situation more carefully.
SANS NewsBites, Volume 28, Number 79 (October 23, 2026), reports CVSS scores of 9.2 for both PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619. It also confirms that Amazon Threat Intelligence observed exploitation attempts as early as October 17. These are attempted attacks, not proof that websites were successfully compromised.
And when I started looking at the reporting, I understood why everyone was concerned.
We’re talking about vulnerabilities in software used throughout the internet, with the potential for remote code execution and attackers already attempting to exploit the weaknesses.
That is not something administrators should casually dismiss.
But I also don’t want to exaggerate the situation.
If 70 percent of websites use PHP, that doesn’t mean 70 percent of websites have been compromised.
It doesn’t even establish that 70 percent are vulnerable.
We need to understand what the vulnerabilities affect, what the available patches address, and what the evidence tells us about actual attacks.
The other thing that concerns me is how quickly this situation developed.
We have researchers discovering serious vulnerabilities, emergency patches being prepared, information leaking before coordinated disclosure, and attackers attempting to take advantage of the situation.
Meanwhile, administrators are expected to keep everything running.
I’ve discussed this problem before on The Security Box.
Attackers don’t have to attend budget meetings. They don’t necessarily need management approval before trying something new. They don’t have to wait for a maintenance window.
Organizations, on the other hand, have responsibilities to their customers, employees, and users. They cannot always shut everything down whenever a security advisory appears.
But that doesn’t excuse ignoring critical vulnerabilities.
If you’re responsible for maintaining a website or another internet-facing system, you need to know what software you’re running and whether it requires attention.
You also need a plan for handling emergency security updates.
And if your organization cannot immediately apply a patch, you need to understand the available mitigations and whether temporarily restricting access is necessary.
I also find the artificial intelligence aspect interesting.
We’ve discussed the risks associated with AI tools, but here’s an example of researchers using AI to identify serious security problems.
That’s a legitimate benefit.
The problem is that the same technological advances may also make it easier for attackers to move quickly.
So we’re back to a familiar question: Are organizations prepared to respond at the speed these threats are developing?
I don’t think every organization is.
And I suspect we’re going to continue seeing incidents that force us to ask that question.
What administrators and ordinary users should do
For website administrators, the immediate priority is to determine whether affected PHP versions are in use and apply the appropriate security updates.
Administrators should also review the official advisories, examine available security logs, and investigate suspicious activity rather than assuming that installing a patch proves a system was never attacked.
Organizations using other affected products mentioned in Nick’s presentation should consult the relevant vendors’ advisories. Those are separate incidents with their own affected versions and remediation requirements.
For ordinary users, keeping devices, browsers, and applications updated remains important.
However, updating a personal phone or computer does not fix a vulnerable PHP server operated by somebody else.
That responsibility belongs to the organization maintaining the server.
Consumers should remain alert to suspicious communications and possible account-security problems, particularly if a service they use subsequently reports a compromise.
Final thoughts
October 21, 2026, was certainly an eventful day in cybersecurity.
The PHP2Shell vulnerabilities demonstrated how serious security problems can affect widely deployed software.
The additional developments Nick Espinosa discussed illustrated the dependence of modern internet services on numerous interconnected technologies.
And the October 22 and 23 follow-up reports showed how quickly the situation continued to evolve.
The lesson isn’t that the entire internet has suddenly become unsafe.
It’s that security maintenance, responsible disclosure, vulnerability research, and timely remediation remain essential.
We cannot prevent every vulnerability from being discovered.
But we can improve how quickly and effectively organizations respond when those discoveries occur.
Otherwise, as Nick put it in his video’s title, we may find ourselves having another terrible, horrible, no good, very bad day.
Sources and additional reading
Share this:
Like this:
Related
Discover more from Jared's Technology podcast network
Subscribe to get the latest posts sent to your email.
Published in article commentary