PHP2Shell shows how AI is shrinking the window for Indian enterprises to respond to cyber threats

The PHP2Shell vulnerabilities are highlighting a new problem for Indian enterprises—it is no longer enough to know that a critical vulnerability has been disclosed. Companies also need to know how quickly attackers can turn that disclosure into a working attack, and artificial intelligence is helping compress that timeline. Wiz, which discovered the vulnerabilities, said PHP powers about 70% of websites globally.

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were publicly disclosed on October 21. Both carry a CVSS v4.0 score of 9.2. 

The more consequential development, however, is the speed at which the vulnerabilities moved from disclosure to active exploitation attempts. Zscaler’s ThreatLabz said its global decoy network observed 1,156 exploitation attempts from 156 unique attacker IP addresses targeting 70 organisations in the first 48 hours after disclosure. The activity included scanning and possible exploitation using multiple tools and methods, including remote-code-execution payloads.

Amazon Threat Intelligence found that the clock may have started even earlier. AWS said it identified a PHP2Shell exploitation attempt in its MadPot telemetry dating to October 17—four days before public disclosure. After the patches were released, Amazon said proof-of-concept exploits appeared within hours and were used against its sensors almost immediately.

The episode is significant not only because PHP is widely deployed across internet-facing applications, websites and business infrastructure, but because security researchers are increasingly seeing AI being used to accelerate vulnerability discovery and exploitation. Deepen Desai, Chief Security Officer, Zscaler, said, “We are seeing several real-world examples of AI accelerating vulnerability discovery and exploitation and helping orchestrate end-to-end attacks using autonomous agents.”

On PHP2Shell, Desai said researchers used frontier AI models “to uncover critical flaws in PHP, and develop and adapt working exploits across multiple applications in hours.” He added that “Usage of the powerful AI models makes it easier for discovering and chaining such issues at scale. These capabilities make it trivial to develop working exploits for threat actors of all skill levels.”

For Indian companies, that creates a problem that goes beyond the PHP vulnerabilities themselves. The window between a vulnerability becoming public and attackers actively looking for exposed systems is getting shorter, while enterprises still have to contend with sprawling technology estates, third-party applications and systems that may not appear in their formal asset inventories.

 “AI compresses the time between vulnerability disclosure and widespread attack, says Sanjeev Singh, Partner at Deloitte India. “It can help attackers identify exposed systems, analyse patches, generate exploit variations, automate reconnaissance,” Singh said. “Consequently, defenders may have hours rather than days to respond.”

The blind spot inside the enterprise

Singh said the risk is particularly significant for organisations running internet-facing PHP services, but warned that companies should look beyond systems that are immediately visible to their security teams. “The risk is significant for Indian organisations operating internet-facing PHP services, particularly those running on Apache mod_php, unsupported PHP versions, shared hosting environments or poorly maintained applications,” he said. “Banks, e-commerce platforms, government portals, IT service providers should also examine commercial appliances and management interfaces containing embedded PHP. These components may be vulnerable even when PHP is not visible within the organisation’s formal software inventory.”

That is where the PHP2Shell episode becomes a broader enterprise security story. PHP may sit underneath an application, a vendor-managed platform, a customer portal or an appliance without being treated as a separately managed asset. Fortinet has similarly advised organisations to identify affected PHP deployments across third-party and hosted environments, rather than limiting the exercise to software that is directly managed by internal IT teams. It has also recommended interim protections such as virtual patching, IPS and web application firewall controls while security updates are being deployed.

Zscaler’s ThreatLabz has urged organisations to inventory PHP installations across their environments, including standalone servers, vendor appliances and applications that rely on PHP.

The reason for the urgency is the potential blast radius once an exposed server is compromised. “Successful exploitation allows an unauthenticated attacker to execute code with the privileges of the PHP worker, which in some cases may be running as the root user,” Singh said.

That could allow attackers to steal application data, credentials and encryption keys, install malware or manipulate transactions, he said. “Attackers may also be able to move into databases, cloud environments or corporate networks if the compromised server contains reusable credentials or has excessive network permissions.”

For Singh, that is why PHP2Shell should not be reduced to a conventional patching exercise. “Companies should treat PHP2Shell as a potential security incident, not simply a patching task,” he said. “Installing the update closes the vulnerability but does not remove an attacker who may already have gained access.”

The implication is particularly important in an environment where AI is reducing the time available for defenders to react. If attackers can automate reconnaissance and adapt exploits rapidly, organisations need to establish exposure and investigate potential compromise at the same time as they patch. “The central lesson is that patching, asset visibility and lifecycle management are inseparable,” Singh said. “Organisations cannot protect software they do not know they operate.”