During the week of October 19 to 25, 2026, two critical PHP vulnerabilities became a sharp reminder of how little time organizations now have between disclosure and attack activity.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were nicknamed PHP2Shell. In plain language, they could allow an attacker to send a specially crafted request to a vulnerable web server and run unauthorized code without first signing in. PHP’s security team classified both as critical and urged users to update immediately. The flaws affected PHP installations serving web requests, with some common configurations facing greater risk than others. 1
Then the race began.
Matthew Prince, Cloudflare co-founder and CEO, described the change in activity during a public interview with TBPN. In the hours before the patch was released, Cloudflare was seeing thousands of attack attempts across its network. After disclosure, Prince said that number had risen to “millions of attacks per minute.” His warning was direct: organizations running PHP needed to update immediately. Watch Prince’s comments at 4:59. 2
Cloudflare separately confirmed that it observed attack traffic targeting customers, including attackers modifying their requests in an effort to get around protections. Cloudflare had deployed web application firewall rules before public disclosure, but still told customers to patch PHP rather than treat the protective rules as a permanent fix. 3
That sequence captures the issue facing every business: once useful details become public, attackers do not wait for your next maintenance window.
PHP2Shell was serious, but it was not a reason to panic
A remote code execution vulnerability is dangerous because it may give an attacker the ability to take control of the affected server, access data, disrupt services, or use that system as a path into other parts of the environment.
Prince explained the business impact plainly in the same interview: a compromised server could expose files, intercept information passing through a website, or be used for other malicious activity. Watch at 1:54. 2
The confirmed facts still matter more than the headlines.
PHP published corrected releases on October 21 and stated that updating was the only complete solution. Temporary mitigations could reduce exposure, but they did not make a vulnerable installation fully safe. 1 In its October 23 update, the Canadian Centre for Cyber Security said that proof-of-concept code was publicly available, but it had not identified active exploitation at that time. It also warned that the situation could change quickly and told organizations to prioritize internet-facing systems. 4
Those statements are not contradictory. Cloudflare was seeing large volumes of exploit attempts. The Cyber Centre had not yet confirmed successful active exploitation. An attempt is not proof that an attacker succeeded, but it is proof that vulnerable systems were being searched for at scale.
The software you need to patch may not look like software
Many business leaders hear “PHP vulnerability” and assume the issue applies only to public websites.
That is a dangerous assumption.
PHP can be part of commercial applications, containers, portals, management consoles, and network appliances. The Cyber Centre specifically advised organizations to identify third-party products, appliances, and containers that include vulnerable PHP components. 4
Check Point provides a clear example. It confirmed that, under certain circumstances, the two PHP2Shell vulnerabilities could permit remote code execution through web interfaces on affected firewalls. Exposure depended on the product, version, and enabled functions, including certain mobile access, remote-access VPN, SAML authentication, and captive portal features. Check Point issued a hotfix on October 23. 5
The business lesson is simple: you cannot patch what you do not know you have.
An inventory limited to employee laptops and servers will miss equipment and applications that contain vulnerable software behind the scenes. Firewalls, printers, cameras, network equipment, websites, vendor-managed systems, and older appliances may all have components that are not obvious from the product name.
Technical debt turns a patch into an outage
Nikesh Arora, Palo Alto Networks CEO, made this point during an October 23 All-In Podcast interview.
The host asked whether AI-assisted cyber events like PHP2Shell might start occurring every ten days. At 16:30, Arora replied that “10 days is too long,” meaning he expects serious discoveries to arrive even more frequently. He then connected that speed to technology debt: organizations have delayed upgrading older systems, and some can no longer apply a straightforward patch. They must take services offline, upgrade or rebuild them, and bring them back into production. 6
That is commentary, not a technical forecast. But the operational problem he described is familiar and verifiable: unsupported software receives no normal vendor updates, and even supported fixes can require configuration review, testing, and coordinated deployment. PHP itself noted that older releases were no longer supported by the project, although some third-party vendors may provide backported fixes. 1
Patching remains essential. The larger goal is to avoid discovering your outdated systems during an emergency.
A vulnerability score is not the same as business risk
PHP2Shell received a critical rating. That tells an organization the potential technical impact is high. It does not answer several questions specific to the business:
- Do we use the affected component?
- Is it exposed to the internet?
- Is the vulnerable function enabled?
- Can an attacker reach it through our current controls?
- Can the weakness actually be exploited in our environment?
- What systems or data would be accessible afterward?
- Which issue should we fix first?
Consider CVE-2026-0257, an authentication bypass vulnerability affecting certain Palo Alto Networks GlobalProtect configurations. The vulnerability could allow an unauthorized VPN connection, but exposure required specific authentication-cookie and certificate settings. Palo Alto Networks later reported limited exploit attempts against unpatched devices without mitigations. 7
Now compare that with CVE-2026-114625, disclosed by Arista on October 22. The vulnerability affected certain on-premises VeloCloud Orchestrator deployments and could allow a low-privileged authenticated user to gain powerful operator access. Arista said it was being actively exploited. 8 CISA added it to the Known Exploited Vulnerabilities Catalog the next day and encouraged organizations to prioritize its remediation. 9
A high score matters, but context decides urgency. An internet-facing system under active attack may need immediate action. Another high-scoring issue may not be reachable because the affected function is disabled. A lower-scoring weakness may still matter if it exposes a critical business system.
Effective vulnerability management is not about fixing CVEs in numerical order. It is about finding the shortest credible path from an attacker to business impact.
AI is accelerating both vulnerability discovery and attacker learning
AI did not create years of accumulated software weaknesses. It is making them easier to find.
At 18:30, Arora said powerful models can use sustained computing effort to search for vulnerabilities and combine several weaknesses into an attack path. He also noted that once a patch becomes available, attackers can study what changed and work backward to understand the original weakness. 6
Prince made the same practical point at 4:59: releasing the patch gives defenders the fix, but it can also give attackers enough information to determine how the vulnerability works. 2
Cloudflare’s technical reporting supports the broader direction. It described AI agents as persistent, able to adapt requests based on feedback and combine vulnerabilities, credentials, and permissions while searching for a workable path. 10
This changes the economics of cyber risk. Attackers can examine more systems, try more variations, and move more quickly. Defenders need to use the same persistence against their own environments.
Take an offensive footing for defense
An offensive footing for defense does not mean attacking anyone. It means testing your own environment, within an approved scope, before an attacker does.
At 26:14, Arora described large organizations using penetration-testing tools against their own defenses to find weaknesses and patch them. His warning was that the process does not end. More capable models will find additional paths, creating a continuous cycle of discovery and remediation. 6
That cycle should include six practical steps:
1. Discover what is present and exposed
Map public IP addresses, websites, DNS records, internal devices, and equipment that is not covered by normal management tools. This answers the first question raised by PHP2Shell: Do we have this anywhere?
2. Scan for known weaknesses
Check approved internal and external assets for published vulnerabilities, outdated firmware, and missing updates.
3. Validate exploitability safely
A scanner may say that a weakness is possible. Controlled exploit validation determines whether it can actually be used against the environment. Testing must be authorized, limited to an agreed scope, and scheduled to reduce operational risk.
4. Audit configurations
Not every security gap has a CVE number. Exposed management interfaces, unsafe VPN settings, weak segmentation, and unnecessary services can create risk even when every available patch has been installed.
5. Prioritize remediation
Combine technical severity with exposure, exploitability, active threat information, affected business systems, and the likely impact of compromise. Fix what creates the greatest credible risk first.
6. Review the results and assign accountability
A report only helps if someone understands it, decides what must be fixed, and verifies that the work is completed.
Data Integrity’s Vulnerability Assessment and Exploit Validation service operationalizes this approach. It combines attack-surface discovery, internal and external vulnerability scanning, configuration audits, and weekly automated penetration testing within an approved scope. When a weakness can be validated, the report includes evidence of exploitability, severity, prioritized findings, and remediation guidance. 11
Each month, a Data Integrity security specialist reviews the findings, prepares a plain-language analysis, identifies the issues that matter most, and recommends corrective actions. That creates a recurring process instead of a one-time scanner export that is forgotten after the audit or insurance renewal. 11
Find the weakness before an attacker does
PHP2Shell will not be the last critical vulnerability to place pressure on businesses, vendors, hosting providers, and IT teams.
The right response is not to chase every headline. It is to build visibility and testing into normal operations.
Data Integrity can assess your internal and external exposure, identify known weaknesses, safely validate which ones are usable, and help you prioritize remediation based on real business risk.
Lets find and fix the openings before attackers find them first.