PHP2Shell Is a Visibility Problem: Managing Human and AI Risk

Every time a critical vulnerability lands, the first question is the same: where are we exposed? Most teams can't answer it quickly, and that's the gap attackers count on. PHP2Shell is the latest example. When the PHP2Shell vulnerabilities emerged last week, security teams faced the familiar challenge of responding before the full extent of the threat was clear.

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute malicious code on servers running PHP, a widely used web programming language. Emergency patches were released on October 21, but researchers have confirmed successful exploitation of a vulnerable PHP installation. Researchers used AI tools to help discover and verify the vulnerabilities. AI is now speeding up the work on both sides.

PHP2Shell is the latest reminder that security teams rarely know how easily attackers can exploit a newly discovered vulnerability or how widespread the exposure might be.  That means assessing risk, prioritizing remediation, and making calls that touch business continuity while new information continues to surface. Attackers are now using AI to gain an advantage, and that changes the math.

The window to respond keeps shrinking 

While attackers' early efforts to probe for PHP2Shell vulnerabilities before the emergency patches became available appeared unsuccessful, researchers have since confirmed remote code execution against an Apache server running PHP.  That attack required a specific configuration, and we don't yet know how reliably it works elsewhere. Waiting for certainty isn't a strategy.

The common thread across PHP2Shell, and the painful Log4Shell a few years back is that security teams must respond when they don't yet know the full extent of the threat.  First, identify which systems need immediate attention. Second, decide whether to apply temporary safeguards while you test updates. Third, revisit your assumptions as new details emerge. Every hour spent guessing is an hour attackers can use. According to Google Threat Intelligence Group, cybercriminals are using AI to research vulnerabilities and develop exploit code.  That shrinks the time that defenders have to take action. Security teams should use AI to close that gap by analyzing large volumes of security alerts, identifying suspicious activity and prioritizing vulnerable systems based on their exposure. That lets analysts focus where it's needed most while they test and deploy emergency patches. As researchers learn more about a threat, teams should revisit their initial risk assessments. AI doesn't replace judgment. It buys your people time to use it.

AI introduces risks inside organizations. Employees adopt tools without security approval, leaving IT teams unaware that those applications are accessing company systems and data. That's a visibility problem, and it's the same one PHP2Shell exposes. 

You can't defend what you can't see

We saw how hard that gets in 2021, when the Log4Shell vulnerability exposed a problem many organizations didn't realize they had. Log4j, a widely used Java logging library, was embedded in applications and software supplied by third-party vendors. Security teams had to figure out where the vulnerable code was running before they could begin fixing it. For some organizations, that meant tracking down software components buried several layers deep within their applications. You can't patch what you can't find. I remember Log4Shell. It happened while I was a security leader at a different company, and my team actually called it Log4Christmas because that was how we spent our end of year. The patching wasn't even the hardest part. The hardest part was finding everywhere Log4j was running, including in vendor software we didn't even know to ask about. 

PHP2Shell is the same test. Security teams need to identify which servers run affected PHP versions, whether those servers are accessible from the internet, and which third-party applications may also be vulnerable.  Sometimes that means asking software vendors when an organization's own inventory doesn't provide the answers. Finding vulnerable systems is only part of the job. The other part is limiting what attackers can do if they successfully compromise any of those systems.

Small security gaps can create major business disruptions

In 2021, one compromised password on a legacy VPN account without multifactor authentication let attackers into Colonial Pipeline. They launched a  ransomware attack. The company shut down its pipeline operations to contain the damage. One small gap became a business continuity event.

An attacker who successfully exploits PHP2Shell could gain a foothold inside an organization's environment and move into other systems. How far they get depends on the server's access privileges and the safeguards separating it from other systems. Limiting that server's privileges and separating it from critical systems limits the damage.

Not every gap is a software flaw. Some start with everyday decisions people make to get their work done. That’s why human behavior belongs in the same risk conversation.

Employees need guidance that won't disrupt their work

Employees are already using AI for a wide range of work activities. According to the U.S. Census Bureau, 56% of American workers reported using AI for at least one job-related task. Those activities range from writing and analyzing information to software development. Some employees use tools without IT approval, often because they help them get work done faster. They aren't being careless. They're trying to move faster. But an employee who connects an unauthorized AI agent to a company database has created another service account, one that may have access to far more than it needs.

This growing use of shadow AI creates another visibility problem for security teams. They often have incomplete records of which tools employees use, what information they share or whether AI-generated applications include unreviewed software dependencies.  Shadow AI didn't cause PHP2Shell. But it makes the same basic question harder to answer: where are we exposed? 

Employees need to know which AI tools they can use and what company information they can share. Banning AI doesn't work. Employees route around controls that get in the way, and you lose visibility entirely. The better approach is see, allow, stop: see which tools are in use, allow the safe ones, and add friction only where the risk is real. 

Zero risk isn't the goal. Knowing where you're exposed and acting on it fast is.