PHP2Shell: The Race Against Time - What the PHP Flaws Mean for Websites, Devices, and Your Data

Two critical PHP flaws, a prematurely broken embargo, and attack attempts even before the official disclosure: PHP2Shell affects more than traditional websites. The vulnerable runtime may also be embedded in firewalls, hosting control panels, and other devices. We explain in plain language what happened, who needs to act, and what you actually need to do as an individual user.

On October 20, two initially unremarkable numbers appeared online: CVE-2026-109618 and CVE-2026-109619. Behind them were two PHP vulnerabilities that had not yet been fully disclosed. PHP is the technology that processes forms, queries databases, and generates pages on countless web servers.

The disclosure was supposed to follow an orderly sequence: first updates and prepared protection rules, then technical details. But the identifiers became public early, an incorrect maximum score of 10.0 began circulating, and a video showing a working attack was accidentally published that evening. PHP moved the release up by one day.

Too late for a quiet start: Amazon later found an exploitation attempt dated October 17 - four days before the patch. After the disclosure, providers recorded a rapidly growing wave of attacks; Reuters, citing Cloudflare, reported millions of attempts within a matter of hours. Those were not millions of successful breaches, but they show how quickly critical vulnerabilities are now tested by automated systems.

The vulnerability itself is not on your smartphone. Yet it can still affect you through data stored by a provider, manipulated websites, more convincing phishing, or services that are taken offline as a precaution. Your device can be clean while your data is at risk on someone else's server.

What You Need to Know First

PHP2Shell is the name given to two memory-safety flaws in the PHP core. Under the right conditions, attackers can execute code on a server without logging in; one of the vulnerabilities can also expose memory contents containing session tokens, passwords, API keys, or database credentials. Both CVEs are rated 9.2 under CVSS 4.0.

The upstream branches are fixed starting with PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Older branches may receive backported fixes from distributions, hosting providers, or LTS vendors. Updating a CMS or plugin alone is not enough: what matters is the PHP runtime that actually handles web requests.

Individual users do not need to install anything on their phones. Operators must inventory and patch websites, containers, management interfaces, and devices running PHP, and investigate them for possible earlier attacks.

1. How an Old Memory Problem Turned into a Global Race Against Time

2024: A Warning Sign with No Demonstrated Attack

The story began in 2024. During an external PHP security audit, researchers noticed the first signs of what would later become the out-of-memory problem. However, there was no reliable path from a web request to code execution, and potential fixes risked breaking compatibility or stability. The small security team did not reach a quick consensus. The PHP Foundation later openly described the delay as a structural failure: decision-making was too cumbersome and resources were too scarce.

Summer 2026: AI-Assisted Research Turns Theory into Practice

In July and August 2026, Calif, OpenAI, and Wiz examined the PHP core using conventional methods and powerful AI models. On August 11, researchers reported a concrete path to remote code execution; Wiz independently found additional variants and demonstrated attack chains against real-world PHP applications. Humans still had to reproduce the results, eliminate false positives, and review the patches. AI nonetheless shortened the search - and with it, the time defenders have once a vulnerability is disclosed.

October 17: The Earliest Known Attempt

Amazon Threat Intelligence later identified an exploit attempt dated October 17 in its MadPot telemetry. A honeypot hit does not prove that real systems were successfully compromised, but it moves the forensic lookback window. How the actor obtained enough information so early remains unknown; there is no reliable attribution.

October 20 and 21: The Embargo Breaks and the Patch Arrives

On October 20, the CVE identifiers began circulating publicly, together with the incorrect CVSS score of 10.0 and an attack video that had been published by mistake. PHP moved the release up to October 21 at 2:00 p.m. UTC. Hosting providers, distributions, and security vendors prepared packages and filters in parallel. Cloudflare enabled protective rules before the release and combined signals from both requests and responses. Even so, a WAF remains only an additional barrier: it does not fix the vulnerable PHP code.

The fixed versions were released on October 21; public exploit tools and mass scanning followed soon afterward. Government agencies, hospitals, universities, and companies proactively took services offline, including police services in Berlin and Brandenburg for a time. This is not evidence of a breach; it may instead demonstrate a functioning emergency process: better to go offline in a controlled manner than remain online while compromised. PHP2Shell also makes clear that internet-facing systems must respond to critical RCE vulnerabilities in hours, not days.

Two critical PHP vulnerabilities, active exploitation attempts, and a vast potential attack surface are confirmed. What remains unknown is how many systems were actually compromised or how much data was lost.

2. What Goes Wrong Technically - Without Unnecessary Jargon

PHP works in a website's engine room: it runs the code behind WordPress, online stores, or portals, processes input, and communicates with databases. The flaws sit below the CMS layer. A fully up-to-date application can therefore still be running on a vulnerable PHP runtime.

CVE-2026-109618: Cleaning Up Incomplete Data

If PHP reaches its memory_limit at the wrong moment, processing can stop while internal data structures are only partially initialized. During cleanup, PHP may then treat those areas as valid data. An attacker tries to deliberately trigger this state and shape the memory layout so that it leads to code execution.

An unauthenticated attack has been demonstrated on Apache with mod_php, and it can take effect before the application's own code runs. A login, two-factor authentication, or a WordPress security plugin will not protect against it in that case. Other PHP deployment modes may also be affected; prerequisites and reliability vary by SAPI, application, and configuration.

CVE-2026-109619: A Stale Reference Survives the Next Request

In the second vulnerability, a reference to memory that has already been freed remains after a serious error. When the same PHP worker processes a later request, it reuses that stale state - a use-after-free or stale global state.

Possible consequences include code execution, crashes, or memory disclosure. The last is particularly insidious: an attacker does not need to leave behind a visible web shell to obtain session tokens, database passwords, API keys, or certificates. Simply looking for changed files after patching is therefore not enough.

Remote code execution initially means that code runs with the privileges of the PHP or web server account, not automatically with root access. That account may nevertheless be able to read configuration files, reach databases, or access internal services. File permissions, network segmentation, and least privilege therefore determine how far a compromise can spread.

3. Is Nearly 70 Percent of the Internet Really Affected?

As of October 23, 2026, W3Techs reports that PHP is used by 69.3 percent of websites whose server-side programming language it can identify. Among those PHP websites, 65.3 percent use PHP 8, 26.9 percent use PHP 7, and 7.7 percent use PHP 5.

Those figures describe adoption, not patch status or successful attacks. Many systems were updated within hours, distributions ship backports under older version numbers, and on appliances the vulnerable path may not be publicly reachable. The fair conclusion is therefore this: about seven in ten websites with an identifiable server-side language use PHP and had to review their defenses. There is no reliable way to quantify how many remain vulnerable or compromised today.

4. What PHP2Shell Means for Individual Users

PHP Does Not Directly Infect Your Device

PHP2Shell runs on servers. You do not need to reset your smartphone or install a special app. Your device is at risk only if a manipulated website tricks you into downloading something malicious. Keep your operating system, browser, and apps up to date, and use only trusted sources. A supposed "PHP2Shell update" for your device is very likely a lure.

Your Data May Still Be Affected

When you order from an online store, your name, address, and order history may remain stored there for a long time. If the server is compromised, that data may be affected even if you have not visited the site in months. Memory disclosure can also reveal tokens and access keys that do not exist as files on the server.

Even a familiar website can be manipulated: the domain and padlock icon stay the same while an injected script steals login or payment data. HTTPS protects the connection to the server, not the integrity of the server itself. Stop if you encounter unfamiliar payment windows, redirects, or downloads, and contact the provider through a known channel.

Fraud Often Follows the Technical Attack

Stolen details make phishing more convincing. Even a message containing your real name and correct order number can be fake. Open important services through the official app, a bookmark, or an address you type yourself. Warning signs of an account takeover include unexpected login or password-reset notices, unfamiliar sessions, changed recovery information, and push approval, TAN, or two-factor authentication requests that you did not initiate. Do not approve anything "just to be safe"; instead, inspect the account directly and remove unknown devices.

For online banking, a password or PIN alone is usually not enough because of strong customer authentication. Phishing can still trick you into approving a legitimate authorization for someone else's login or payment. Verify the recipient, IBAN, and amount; for unfamiliar activity, contact the bank through its official app or a known phone number.

Practical Steps to Take Now

If a service reports only maintenance or a precautionary shutdown, you do not need to change passwords indiscriminately or freeze your cards. Use an official alternative channel and monitor the provider's updates.

If a provider reports a possible exposure of login credentials, change the password there and anywhere else you reused it. End active sessions, enable two-factor authentication or passkeys, and give special priority to securing your email account.

If you entered information on a suspicious site or installed a supposed security app, secure your accounts from another device, contact your bank if payment data was involved, and have the affected device checked.

No security app or VPN can repair the PHP runtime of someone else's online store. Security software can help with the second wave of attacks involving malicious downloads, fake apps, and known malicious sites - but it does not mean data on another party's server is safe.

5. PHP Also Runs in Firewalls, NAS Systems, and Other Devices

PHP is not limited to websites. It also appears in management interfaces and add-on services for firewalls, routers, NAS systems, hosting control panels, VoIP systems, camera recorders, and industrial appliances. A product is affected only if it uses a vulnerable PHP version to handle reachable web requests. Exposure and the availability of a vendor patch also matter.

pfSense: Netgate confirmed that the PHP-based GUI and captive portal are affected. The default GUI is usually reachable only from the LAN; a captive portal is intentionally exposed to untrusted clients. The same bug therefore carries different risk depending on exposure.

Palo Alto Networks: Certain PAN-OS and Panorama versions are affected. According to the vendor, the issue affects the management web interface, including the XML API, not the data plane or GlobalProtect in general. Until a fix is installed, management access should be available only from trusted networks or through a controlled jump host.

Plesk: Customer websites use their own PHP handlers, while the Plesk interface uses a separate engine. Updating only one layer can leave the other overlooked. Plesk therefore released updates for both components.

Cisco and Sophos show why products, cloud services, and customer installations must be assessed separately. Cisco confirmed that individual product families were affected, classified others as unaffected, and was still investigating additional products. Sophos stated that its products were not affected, but temporarily took the separately hosted legacy MyUTM portal offline because it used a vulnerable PHP version.

The Dutch NCSC maintains a continuously updated status list. It is a valuable inventory, but it does not replace the latest vendor advisory: a PHP dependency alone does not prove exploitability, and the absence of a notice is not an all-clear.

What to Check on a Device at Home or in Your Organization

Record the manufacturer, model, firmware, and add-on packages. Search the official support site for both CVEs and for "PHP2Shell," and install updates only through the intended firmware or package mechanism. Never replace embedded PHP on your own; appliances often contain vendor modifications and signed components.

Disable remote management from the WAN, unnecessary port forwards and UPnP mappings, and review cloud-based remote access. If you need external access, use a VPN where possible and open the local interface only after connecting.

Separate guest, IoT, and management networks so that compromised devices cannot reach local management services. If a firewall, NAS, or camera recorder no longer receives security updates, replacement is often the only sustainable solution.

6. What Operators Need to Do Now

Step 1: Establish Responsibility and Inventory

With managed hosting, the provider usually performs the update; with VPS instances, dedicated servers, containers, and appliances, you or your service provider are responsible. Require a verifiable answer covering both CVEs, the package or firmware version, and the restart of all PHP processes. At the same time, inventory domains, subdomains, staging environments, legacy projects, webmail, containers, and devices with embedded PHP.

Step 2: Verify the Correct Patch Level

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Source-code backports are available for PHP 7.4, 8.0, and 8.1; the distributor's or LTS provider's advisory is authoritative.

Distributions may backport fixes into older package releases. Ubuntu 24.04 LTS, for example, lists 8.3.6-0ubuntu0.24.04.13 as fixed; cPanel also shipped backports. Compare the full package version against the distributor's or platform provider's advisory, not just the bare upstream version number.

Step 3: Verify the Runtime Actually Handling Requests

php -v usually shows only the command-line version. The web server may use a different installation through PHP-FPM, mod_php, or a container. Therefore, check FPM pools, web server modules, virtual hosts, and images:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

After the update, old workers must be replaced: with mod_php, typically by restarting the web server; with PHP-FPM, by restarting the pools. Restarting a container with the same image does not help; the image must be updated and redeployed.

Step 4: Keep Requests from Reaching PHP on Systems You Cannot Patch

If you cannot patch immediately, restrict access to trusted networks or a VPN - or take the service offline. A WordPress maintenance plugin does not protect you if the attack takes effect before application code runs. Use a static maintenance page or block access at the reverse proxy, load balancer, or web server.

WAF and CDN rules can buy time, but they are not a patch. Cloudflare observed changing attack patterns and had to evaluate requests and responses together. Also make sure the origin server cannot be reached directly through a second IP address or alternate hostname.

PHP configuration measures such as disabling session upload progress or enforcing stricter memory and upload limits reduce only certain attack paths and may have side effects.

Step 5: Look Back to at Least October 17

Preserve web server, PHP, proxy, WAF, system, and container logs before they rotate. Look for unusual form requests, PHP_SESSION_UPLOAD_PROGRESS, memory errors, unexpected shell processes, new files, accounts, cron jobs, and outbound connections. A successful attack does not have to crash the worker; conversely, a single error does not prove a breach. The overall picture is what matters.

Step 6: Rotate Secrets Accessible to PHP

Because memory contents may be exposed, you should rotate every secret the PHP process could read on internet-facing systems that were unpatched - such as database passwords, API, cloud, and deployment tokens, SMTP or OAuth credentials, and session keys. First patch or isolate the affected system; then generate new credentials from a trusted environment.

Step 7: Do More Than "Clean Up" When There Are Signs of Compromise

If there are signs of compromise, isolate the system in a controlled manner, preserve logs and, where appropriate, volatile data, and rebuild critical hosts from trusted artifacts instead of merely deleting visible files. Also review administrator and database accounts, deployment pipelines, and connected systems. If personal data may be affected, involve privacy or data protection personnel early; under the GDPR, a breach subject to notification generally must be reported within 72 hours.

7. The Broader Lesson: Discovery Is Accelerating, and Remediation Must Keep Pace

PHP2Shell shows how AI is shifting the boundary between "theoretically possible" and "practically exploitable." Models can analyze source code, crash traces, and patch differences at scale; as a result, the interval between disclosure and working exploit code is also shrinking.

The answer is not simply more AI. Maintainers need resources and clear decision-making processes; operators need complete inventories, fast patch deployment, isolation, and practiced recovery. At Protectstar, we use AI alongside code reviews and human validation. It accelerates discovery, but it does not replace accountability.

Conclusion

PHP2Shell affects servers, but it may reach you as a data risk, a fraud attempt, or a service outage. Stay alert, not alarmed: use official contact channels, do not approve unexpected prompts, and take targeted action in response to notices from affected providers.

For operators, what matters is the active PHP runtime, every forgotten instance, embedded components, restarting old processes, and looking back to at least October 17. If no patch is available, isolation is more responsible than continued operation. A reachable website is not proof that it is secure.