PHP2Shell: The security flaws behind millions of cyberattack attempts

Two critical vulnerabilities in PHP, the technology behind a substantial share of the web, have triggered an urgent global response. Website operators are racing to apply security updates while attackers attempt to exploit systems that remain exposed.

Known collectively as PHP2Shell, the vulnerabilities could allow attackers to run malicious code on affected servers without logging in. Emergency fixes were released on 21 October 2026, but exploitation attempts have already been reported at scale.

For businesses, the implications extend beyond an unavailable website. A successful attack could expose sensitive information, disrupt customer services or give criminals a foothold within an organisation’s infrastructure.

However, one distinction matters: millions of attack attempts does not mean millions of confirmed breaches. Some services have also been taken offline deliberately while their operators apply updates.

What is PHP, and why is this such a significant issue?

PHP is a programming language used on web servers to process requests and generate content. It operates behind the scenes, supporting everything from contact forms and customer accounts to online shops and business applications.

Cloudflare estimates that PHP is used by almost 70% of websites. Widely used platforms, including WordPress and Magento, depend on it.

That reach explains the concern. A vulnerability in a single plugin might affect websites using that particular extension. A vulnerability in PHP itself can reach across different platforms, hosting providers and organisations.

The percentage describes PHP’s adoption, however, rather than the proportion of websites successfully attacked. The risk to any individual service depends on its software, configuration and whether the necessary fixes have been applied.

What do the vulnerabilities allow attackers to do?

PHP2Shell comprises two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both carry a critical severity rating of 9.2 out of 10 under CVSS v4.0.

They involve the way PHP manages memory when processing requests encounters problems.

The first concerns memory exhaustion. If PHP runs out of memory at a particular point, internal data can remain only partially prepared. During cleanup, PHP may then treat that incomplete data as valid, creating memory corruption that can lead to remote code execution.

The second concerns stale internal state. After a request fails, PHP can retain references to memory that has already been released. A subsequent request handled by the same worker may use those invalid references, potentially enabling an attacker to execute code.

In practical terms, an attacker may be able to send a specially crafted request that makes a vulnerable server run instructions of their choosing.

The PHP project identifies installations serving web requests as at risk, with the highest risk associated with Apache’s mod_php configuration. In a demonstrated attack against that configuration, exploitation could occur before the website’s own application code ran.

What has happened so far?

The PHP Foundation says early indications of the memory-exhaustion problem emerged following a security audit in 2024. Fixing it proved difficult because proposed approaches involved compatibility, performance and other engineering trade-offs.

Reports from researchers in August 2026 clarified the potential for remote code execution, making remediation a priority.

On 20 October, vulnerability identifiers began circulating publicly. A demonstration video and early patched software images subsequently added to the disclosure disruption. The PHP project brought its planned release forward by one day, publishing emergency updates on 21 October.

Attack activity escalated quickly. According to Associated Press, Cloudflare’s chief executive reported millions of exploitation attempts within hours of the announcement.

AWS also identified an attempted exploit in its monitoring infrastructure dating back to 17 October, before public disclosure. It reported further attempts and subsequently described broad exploitation activity.

Crucially, AWS said it remained unclear whether the early attempts would have succeeded against real-world systems. The evidence shows attackers were already targeting the flaws, but does not establish a global total of successful breaches.

Why have websites been taken offline?

An unavailable website is not automatically a hacked website.

Where operators cannot immediately secure an exposed service, temporarily withdrawing it can reduce the opportunity for exploitation while updates are applied.

Associated Press reported temporary disruption to limited UK government services and precautionary measures in Japan. At that stage, Japan’s government said it had received no reports of related cyberattack damage.

Businesses should therefore distinguish between a preventative shutdown, an attempted attack and a confirmed compromise. Those situations have different implications, even when the visible outcome is the same unavailable webpage.

Is updating WordPress enough?

No. Updating WordPress, a theme or a plugin alone does not fix these vulnerabilities.

The affected component is the PHP software running underneath the website. That component needs to be patched by whoever manages the hosting environment.

The fixed upstream releases announced on 21 October are:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Some operating-system and hosting vendors may provide packages containing backported fixes. Businesses should request explicit confirmation that both vulnerabilities have been addressed, rather than relying solely on the version number displayed in a dashboard.

Older PHP branches require particular attention because normal upstream support has ended. Their operators should confirm an appropriate vendor fix or arrange an upgrade.

What should businesses do now?

Identify every exposed service

Check more than the main company website. Customer portals, staging sites, subdomains and older applications may also run PHP.

Give someone clear responsibility for coordinating the response across IT, developers and hosting providers.

Verify that the update is live

Ask the technical owner to confirm that the actual web-serving environment is running a patched build, with affected services restarted or redeployed where required.

Afterwards, test important functions such as logins, enquiry forms and checkout journeys.

Keep additional protections in place

Web application firewall protections can help reduce exposure, but they do not replace the PHP update. Where patching cannot happen promptly, assess whether access should be restricted or the affected service temporarily withdrawn.

Investigate earlier activity

AWS recommends checking for exploitation from at least 17 October. Relevant evidence includes suspicious web requests, unexpected processes and unexplained file changes.

Patching prevents further exploitation of the vulnerability. It does not establish whether someone gained access beforehand.

What does this mean for the wider business community?

PHP2Shell illustrates how quickly a weakness in widely used software can become an operational problem for organisations of every size.

It also highlights a common gap in website management: keeping visible content and plugins updated while responsibility for the underlying server software remains unclear.

Businesses need to know who maintains that software, how emergency updates are deployed and how completion is verified.

The most useful question to ask your provider today is straightforward:

“Have you patched both PHP2Shell vulnerabilities across all our environments, verified the live services and checked for earlier exploitation?”

Information checked on 22 October 2026. This is a developing incident, and findings may change as investigations continue.