Some of the most dangerous cybersecurity threats aren't hiding in obscure software. They're buried in the technology millions of websites rely on every day.

That's what makes the recent discovery of two critical vulnerabilities in PHP so concerning.

Known collectively as PHP2Shell, the flaws affect one of the internet's most widely used programming languages. They could allow attackers to take control of vulnerable servers, access sensitive information and compromise websites without needing login credentials.

Emergency patches are now available, but the discovery has raised some uncomfortable questions. How did such serious weaknesses remain hidden for so long? How quickly can attackers exploit them? And what does the growing use of AI in vulnerability research mean for organizations trying to stay protected?

A Vulnerability With Enormous Reach

PHP has been powering websites for more than 30 years. including WordPress, Drupal and Joomla, as well as business applications, online stores and public services.

But its reach goes further. PHP is also used in components of cybersecurity products. Palo Alto Networks, for example, has confirmed that its PAN-OS and Panorama management interfaces are affected by PHP2Shell, while Fortinet is investigating potential exposure across several of its products.

According to W3Techs, PHP is used by roughly 70% of websites where the server-side programming language is known.

That gives PHP2Shell an enormous potential reach.

On October 21, 2026, PHP's developers released emergency updates addressing two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both carry a critical CVSS v4.0 severity score of 9.2.

The weaknesses lie within PHP itself, rather than any particular website or plugin. That distinction matters.

An organization could have a well-maintained website, secure application code and up-to-date plugins, yet still be vulnerable because of the underlying PHP installation.

And unlike attacks that depend on stolen passwords or users clicking malicious links, these vulnerabilities can potentially be exploited remotely without authentication.

What's Actually Going Wrong?

At the heart of PHP2Shell are weaknesses in how PHP manages memory when something goes wrong.

When a web server processes a request, PHP allocates memory to perform the necessary tasks. If an error occurs, that memory should be released safely, leaving the system ready to handle the next request.

PHP2Shell exploits situations where this process breaks down.

Under certain conditions, specially crafted requests can trigger memory corruption or leave behind references to memory that has already been released. An attacker may then be able to manipulate that memory, potentially executing malicious code or exposing sensitive information.

Researchers demonstrated how these weaknesses could be exploited against popular PHP-based platforms, including WordPress and Drupal.

Particularly concerning is the risk associated with Apache servers running mod_php. In some configurations, exploitation can occur before the website's own application code even starts running.

Other deployment methods, including PHP-FPM, are also affected.

For businesses, the potential consequences are serious. A successful attack could expose credentials, compromise customer information, alter website content or provide a foothold for further attacks.

AI Helped Uncover What Had Been Hidden for Years

Perhaps the most interesting part of the PHP2Shell story is how the vulnerabilities were discovered.

Researchers from Wiz, Calif and OpenAI used AI-assisted security research to investigate weaknesses buried deep within PHP's code.

Some of the underlying problems had existed for years. In fact, the PHP Foundation acknowledged that an earlier security investigation had identified signs of one issue in 2024, but had not established a practical route to exploitation.

That changed in 2026.

AI-assisted research helped investigators uncover and demonstrate attack methods that had previously proved extremely difficult to develop.

It's an important development for cybersecurity.

AI can help researchers examine enormous codebases, investigate unusual behavior and connect weaknesses that might otherwise remain undetected. Problems that once required weeks of painstaking manual analysis may become easier to investigate.

But there's another side to this.

The same capabilities could help attackers identify vulnerabilities, analyze patches and develop exploits more quickly.

AI isn't creating every vulnerability. Many already exist. What it's changing is how quickly those weaknesses can be discovered and potentially turned into working attacks.

For security teams, that could mean considerably less time to respond.

Attackers Didn't Wait for the Official Announcement

The urgency surrounding PHP2Shell became even clearer when Amazon Threat Intelligence reported an attempted exploit dating back to October 17, 2026.

That was four days before the vulnerabilities were publicly disclosed.

Amazon subsequently observed further exploitation attempts around the release of the emergency patches.

These findings don't prove that the attempts successfully compromised real-world systems. They do, however, show why organizations cannot assume attackers will wait for an official security advisory before taking action.

The wider response was swift. Security agencies issued warnings, hosting and security providers introduced protections, and some websites were temporarily taken offline while administrators investigated their exposure.

For organizations that depend on their websites and online applications, even precautionary downtime can have a significant business impact.

And once a vulnerability becomes public, the pressure only increases.

What Should Organizations Be Doing?

The immediate priority is patching.

Fixed versions of PHP, including 8.2.35, 8.3.36, 8.4.27 and 8.5.12, are available. Organizations using unsupported releases should move to supported versions or obtain appropriate vendor-backed security fixes.

But an effective response involves more than installing an update.

• Know where PHP is running. That includes public websites, internal applications, cloud workloads and third-party products. Software dependencies aren't always obvious, particularly in large environments.
• Prioritize internet-facing systems. Systems accessible from the public internet deserve immediate attention, especially those handling sensitive information or supporting critical services.
• Verify that updates have worked. Patching shouldn't be considered complete until teams confirm that affected services are running fixed versions.
• Look for signs of compromise. Review web server logs, unusual requests, unexpected processes and suspicious file changes. Given the reports of exploitation attempts before public disclosure, checking historical activity is particularly important.
• Consider temporary protections where necessary. Web application firewalls and vendor-recommended mitigations can help reduce exposure while patches are deployed. However, they shouldn't replace the updates themselves.

In its recent PHP security advisory, Kudelski Security's Threat Alert Center offers more specific guidance for teams unable to patch immediately, including limiting multipart requests and disabling PHP session upload progress tracking. But the warning is clear: “These measures reduce exposure to specific attack paths only and do not make an installation safe.”

Organizations should also follow the latest guidance from the PHP project and relevant cybersecurity authorities.

The aim is straightforward: identify what's exposed, address the most urgent risks and determine whether attackers may already have gained access.

The Bigger Issue Goes Beyond PHP

PHP2Shell highlights a familiar problem that becomes more difficult as technology environments grow.

Organizations depend on an enormous amount of software they didn't develop and may not fully understand. Open-source libraries, third-party components and shared infrastructure are essential to modern operations, but each can introduce security exposure.

When a major vulnerability emerges, security teams need answers quickly.

Which systems are affected? Are they exposed to the internet? Is exploitation being observed? Which services matter most to the business?

Without reliable asset visibility and a clear way to prioritize vulnerabilities, even experienced teams can struggle to decide where to focus.

This is where risk-based vulnerability management becomes particularly valuable. Rather than treating every alert equally, organizations can combine technical severity, exploit intelligence, asset exposure and business context to decide what needs attention first.

At Kudelski Security, helping organizations build that understanding is an important part of our work across vulnerability management, threat detection and incident response. The goal isn't simply to identify more security issues. It's to help teams act on the ones that matter most.

Kudelski Security's Cyber Fusion Center is also monitoring the situation and assessing potential opportunities for threat hunting as developments unfold.

PHP2Shell won't be the last critical vulnerability to affect software used across the internet. And as AI changes the speed of vulnerability discovery, the time available to respond could become even shorter.

The organizations best prepared for that future won't necessarily be those generating the most alerts. They'll be the ones that know where they're exposed, understand the risks and can act quickly when it matters.

‍