VamiSec × Wiz
DE EN
Request a check

Briefing by VamiSec GmbH · · certified Wiz partner

PHP2Shell: Are your PHP systems affected?

On October 21, 2026, Wiz Research disclosed critical memory-safety flaws in the core of PHP: CVE-2026-109618 and CVE-2026-109619. On affected versions, attackers can read process memory and execute code without authentication. Whether the application itself is securely written makes no difference. As a certified Wiz partner, VamiSec checks at short notice whether you are affected: from the outside with Wiz ASM, the Wiz Red Agent and VamiRedteam, and from the inside through connectors that prove the actual version level.

Request an exposure check The essentials in 60 seconds

Black-box from the outside Agentless from the inside Only with written authorization

2 CVEscovering four attack paths demonstrated by Wiz
9.2CVSS v4.0 according to PHP, for both CVEs
Since 5.4according to Wiz, every PHP version from the past ten-plus years is affected
Pre-authno login and no flaw in the application code required
2026-10-21Patch and coordinated disclosure

Short answer

PHP2Shell is the name for two critical vulnerabilities in the core of the PHP programming language: CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and published on October 21, 2026. When PHP aborts a request with a fatal error, above all when it runs out of memory, internal state is left behind. A later request in the same worker process, and on the OPcache path even a different worker, keeps using this stale state.

  • Impact: Without authentication, attackers can read parts of the process memory, such as passwords, tokens and API keys, and execute code on the server.
  • Scope: The flaw is in PHP itself. Every installation that handles web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz demonstrated the attacks against the container images of WordPress, Drupal and Joomla that were current at the time of testing.
  • Fix: Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a distribution package that includes the fix, and restart all PHP processes. Workarounds and WAF rules only buy time.
  • Check: As a certified Wiz partner, VamiSec determines at short notice which PHP systems are reachable from the internet and, with the inside view, also which instances are actually vulnerable.

Published: Updated: Author: Valeri Milke, VamiSecPrimary source: Wiz Research

01 · Overview

What Wiz Research found

PHP is the server-side language behind a large part of the web. WordPress, Drupal, Joomla and MediaWiki, the software behind Wikipedia, all run on it. According to W3Techs, 69.3 percent of all websites with a known server-side language use PHP (as of October 22, 2026). This is in line with the roughly 70 percent Wiz cites. The figure describes how widely PHP is used, not how many systems are vulnerable.

Researchers Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz found several memory-safety bugs in the PHP core. They all arise at the same point: when PHP aborts a request because of a fatal error, usually an out-of-memory (OOM) condition. The core then does not clean up completely. A pointer to memory that has already been freed survives, and the next request in the same worker accesses it.

From this pattern, Wiz developed four attack paths. They range from reading other memory regions to executing code on the server, all without authentication. Wiz sees PHP2Shell as a turning point similar to Heartbleed (2014) and Log4Shell (2021). As with Log4Shell, the biggest challenge is how widespread the software is: PHP is embedded in web servers, container images, appliances and hosting platforms, often without showing up in the asset inventory.

Independently of Wiz, Calif and OpenAI had already reported the root cause to the PHP team in August 2026. According to Wiz, there are further variants of the same pattern beyond the four paths it demonstrated. The PHP team's patch addresses the root cause.

Code execution without authentication

Wiz chained the bugs into the exploit script “php2shell” and used it to execute code on wordpress:latest, drupal:latest and joomla:latest. The applications were only examples: according to Wiz, even a simple “Hello World” application on an affected version can be vulnerable.

A Heartbleed-style memory leak

Even without code execution, the memory of the PHP worker can be read. It may contain data from other requests or from the server, such as passwords, session tokens, API keys and certificates.

Below the application

The attacks take place in the PHP core, before or while the application starts. Updating WordPress, plugins or frameworks therefore does not protect you. The only thing that matters is the PHP runtime.

02 · Vulnerabilities

Two CVEs, four demonstrated attack paths

The PHP project is the responsible CVE Numbering Authority (CNA). It describes the two CVEs by bug class. In its blog, Wiz maps its four attack paths somewhat differently. We show both views.

Official title: “RCE via OOM corruption” · GHSA-w8hw-w9fx-j79w

CVE-2026-109618: Code execution via out-of-memory corruption

Until now, on an out-of-memory error PHP has jumped out of the current execution with longjmp(). If this happens at a moment when request memory is reachable but not yet fully initialized, request shutdown later reads invalid state. This can lead to code execution.

  • Validated: full unauthenticated code execution over HTTP against Apache mod_php with default limits, before any application code runs
  • PHP-FPM vulnerable according to source code analysis; FrankenPHP likely vulnerable, LiteSpeed not validated
  • Fix: a deferred “soft OOM” at the next safe point and an immediate process exit on a hard out-of-memory condition

CVSS v4.0 9.2CWE-416 · CWE-755 · CWE-824 and others

Official title: “RCE via stale global state” · GHSA-6wmf-4rv5-p3rp

CVE-2026-109619: Code execution via stale global state

A worker retains global state, for example related to errors, sessions or objects, that still points into the freed memory of an earlier request. If a later request in the same worker uses this state before normal initialization, a use-after-free occurs.

  • Confirmed: the upload progress path of the session module (enabled by default, no session_start() required), validated against mod_php and PHP-FPM
  • Confirmed: the backtrace of the last fatal error in PHP 8.5 (option fatal_error_backtraces)
  • Impact: memory disclosure and code execution without authentication

CVSS v4.0 9.2CWE-416 · CWE-755 · CWE-824 and others

About the CVSS score: PHP rates both CVEs at 9.2 under CVSS v4.0 (vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). The high attack complexity (AC:H) reflects that an attack requires many crafted requests. The NVD additionally assigns 9.8 under CVSS v3.1, and Germany's CERT-Bund also gives 9.8. According to the PHP Foundation, a score of 10.0 that circulated before publication was wrong.

The four attack paths from the Wiz analysis

Attack paths demonstrated by Wiz Research (source: Wiz blog, 2026-10-21)
Attack pathPossible impactDemonstrated by WizCVE per Wiz blog
Use-after-free in the unserializer of upload progress handling Memory corruption, code execution Unauthenticated code execution on WordPress, Drupal and Joomla CVE-2026-109618
Process memory disclosure via the session cookie Memory contents of other requests are disclosed Unauthenticated reading of worker memory, independent of the application CVE-2026-109618
Use-after-free in the backtrace of the last fatal error Memory corruption, code execution Unauthenticated code execution on Drupal CVE-2026-109619
Type confusion in OPcache Corruption of the shared OPcache state, code execution Unauthenticated code execution on WordPress CVE-2026-109619

Different mapping: The PHP advisories and Wiz's site php2shell.com list the upload progress path and the memory leak under CVE-2026-109619. The OPcache path appears only in the Wiz analysis, not in the PHP advisories. For patching and remediation this makes no difference: the patched versions fix both CVEs.

03 · Technical background

How a memory bug becomes an attack

All attack paths follow the same pattern. PHP workers such as PHP-FPM or Apache with mod_php handle many requests one after another. If one of them aborts hard, stale state can carry over into the next request.

Request A

Memory runs low

A crafted request, such as a large multipart upload, drives PHP into an out-of-memory error while the request is still starting up.

Abort

Cleanup remains incomplete

PHP discards the request's memory. Global pointers, for example to the session ID, the unserializer state or the backtrace, still point to the freed region.

Request B

Same worker, new content

The attacker reallocates the freed memory. PHP treats the stale pointer as if it were still valid.

Impact

Leak or code execution

Memory contents end up URL-encoded in the PHPSESSID cookie of the response. Other variants allow targeted memory corruption all the way to code execution.

Simplified illustration based on the technical analysis by Wiz Research. Blue: allocated memory; striped: stale state; orange: leaked memory.
Session module · memory leak

Leak via the session cookie

PHP processes multipart uploads under RFC 1867 very early, before the modules are fully initialized. If upload progress tracking is enabled, which is the default, the session module already creates a session ID at this stage. An out-of-memory error at this point leaves behind a pointer to freed memory. A later upload request in the same worker reads the reallocated region and writes it into the PHPSESSID cookie of the response. This works even if the application never calls session_start().

Session module · unserializer

Use-after-free in the upload progress unserializer

In the same early window, the session module can decode session data and, to do so, stores the unserializer's bookkeeping data globally. If a memory error aborts this path, this data remains globally reachable even though its memory has already been freed. Wiz combined this bug with the memory leak. The leak removes the uncertainty about memory addresses, which made unauthenticated code execution on WordPress, Drupal and Joomla possible.

Engine · PHP 8.5

Use-after-free in the fatal error backtrace

PHP 8.5 can store the backtrace of the last fatal error in a global variable. An out-of-memory error frees the memory without resetting this variable. If the same worker emits a message early in the next request, PHP follows the dangling pointer into memory the attacker has filled. Wiz used this to demonstrate unauthenticated code execution against Drupal.

OPcache · shared memory

Type confusion in the shared OPcache

OPcache stores compiled code in shared memory that all workers use together. If a memory allocation fails while code is being stored, the local and the shared bookkeeping state diverge. Another worker then reallocates the space, and old references point to an object of the wrong type. Wiz built an unauthenticated attack chain against WordPress from this.

04 · Affected systems

Which versions and systems are affected

What matters is the PHP runtime, not the application. Every installation that handles web requests is at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php particularly exposed, because there the attack takes effect before any application code runs.

PHP branches, fix status and support (sources: php.net, PHP advisories, Wiz, Calif; as of 2026-10-22)
PHP branchSupportVulnerableFixed in
8.5Active support until 2027-12-31before 8.5.128.5.12
8.4Active support until 2026-12-31before 8.4.278.4.27
8.3Security fixes only, until 2027-12-31before 8.3.368.3.36
8.2Security fixes only, ends on 2026-12-31before 8.2.358.2.35
8.1 · 8.0 · 7.4Unsupportedall versionsno release The PHP team has published only minimal source backports. Patched packages come from distributions and LTS vendors.
7.3 to 5.4Unsupportedaffected according to Wiz and Califno upstream fix Only individual distribution and hosting builds, such as Debian ELTS or Ubuntu Pro. Replace these versions.

The official CVE records list only the 8.2 to 8.5 branches. That does not mean older versions are safe: PHP has provided backports for 7.4 to 8.1, and Wiz and Calif name PHP 5.4 as the earliest affected version.

Watch out with distribution packages: Ubuntu, Red Hat, AlmaLinux, CloudLinux, Debian ELTS and many hosting providers backport the fix without changing the PHP version number. Debian trixie and bookworm, by contrast, have adopted the new versions 8.4.27 and 8.2.35. Ubuntu 24.04, for example, still reports PHP 8.3.6 but is patched with the package 8.3.6-0ubuntu0.24.04.13. In that case, the package version is what counts. Conversely, a hidden version string proves nothing.

Where PHP often runs unnoticed

  • Container images: official php images, CMS images such as wordpress, drupal and joomla, and your own images built on them
  • Kubernetes workloads with PHP-FPM behind Nginx or Apache, including in sidecars, Jobs and CronJobs
  • Virtual machines with PHP from distribution packages, third-party repositories or custom builds
  • PaaS and serverless: App Engine, Cloud Run, Elastic Beanstalk, Azure App Service and similar services that, depending on their configuration, do not update automatically
  • Managed and shared hosting for websites, shops and landing pages, often managed by agencies or business units
  • Appliances and third-party products with a PHP web interface, such as monitoring, ticketing or admin tools. Only a vendor update helps here. According to the BSI, more and more vendors of network components are now publishing their own advisories because PHP is built into their products. The Dutch NCSC-NL maintains a public list of such products.

Enter a version or paste the output of php -v. Runs entirely in your browser; nothing is transmitted. Does not replace checking every instance.

Take a quick inventory of versions

These commands only read data and change nothing. They help with an initial assessment but do not replace a complete inventory.

# PHP version and settings. Note: php -i shows the CLI configuration.
php -v
php -i | grep -i -E "session.upload_progress.enabled|memory_limit"
# PHP-FPM and mod_php often use their own php.ini (binary name varies by distribution)
php-fpm8.3 -i | grep -i -E "session.upload_progress.enabled|memory_limit"

# Package version: distributions often backport fixes without a new version number
dpkg -l | grep -E "^ii\s+(php|libapache2-mod-php)"              # Debian/Ubuntu
apt-get changelog php8.3 | grep -E "CVE-2026-10961[89]"          # adjust package names
rpm -q --changelog php-common | grep -E "CVE-2026-10961[89]"     # RHEL/Alma/Rocky/SUSE
apk info -vv | grep -i "^php"                                     # Alpine

# Container image: read the bundled PHP version
docker run --rm --entrypoint php <image> -v
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' <image> | grep PHP_VERSION

# Kubernetes: find pods with typical PHP images
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -i -E "php|wordpress|drupal|joomla|nextcloud|magento|matomo"
Detection proof of concept · open source

Active testing with Assetnote's php2shell-scanner

On October 22, 2026, Assetnote's research team released a scanner for CVE-2026-109618 and CVE-2026-109619. It demonstrates the vulnerable behavior over HTTP without executing code on the target system. This makes it well suited for confirming findings from the inventory and the outside view in a targeted way.

  • The scanner sends a small control request and up to three crafted multipart requests with array keys nested 62 levels deep, growing from 1 MiB to 20 MiB.
  • A target counts as vulnerable if PHP responds with a memory error, with an empty HTTP 500 response compared with the control request or with a crash of the FPM worker, or if it reports an unpatched version.
  • By default, it checks /index.php. You can specify your own paths, headers and host lists, as well as separate rules for mod_php and PHP-FPM.
assetnote/php2shell-scanner on GitHub

Before you use it

  • Only test systems you are authorized to test.
  • Each tested path generates around 29 MiB of load, and the scanner deliberately triggers memory errors. Schedule tests of production systems in a maintenance window.
  • With a low memory_limit, the scanner also reports patched versions as vulnerable. Always cross-check hits against the installed version and package level.
VamiSec can help

Analysis, recon and attack surface management

We plan and support the use of the scanner, evaluate the results and separate real hits from false positives. In doing so, we map your external attack surface with VamiRedteam. The agentic platform maps domains, subdomains, hosts and exposed services and works only within the approved scope: with signed authorization, a hard boundary at the scope and a complete audit log.

Request an analysis

Status at distributions and platforms

Selection, as of the morning of 2026-10-22. Check the current status with each vendor.
VendorStatus
DebianFixed for trixie (DSA-6574-1, php8.4) and bookworm (DLA-4848-1, php8.2); ELTS updates for 7.4, 7.3 and 7.0
UbuntuFixed for 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS (USN-8948-1); older releases via Ubuntu Pro (USN-8948-2)
Red Hat Enterprise LinuxUpdates for RHEL 8, 9 and 10 in progress (bulletin RHSB-2026-013, not yet complete)
AlmaLinuxAll PHP streams on 8, 9 and 10 patched, with the suffix .alma.1 appended to the old version number
SUSEFirst updates released (including SUSE-SU-2026:4843-1), overall status still open
Alpine Linuxphp83, php84 and php85 patched on edge, 3.24 and 3.23; 3.22 and php82 still open
Docker Official Imagesphp 8.2 to 8.5 rebuilt; wordpress, drupal and joomla:latest with patched PHP on Oct 22; EOL tags such as 8.1 and 7.4 will not be rebuilt
CloudLinux / cPanelea-php 5.2 to 8.5 released as backports, some with unchanged version numbers
Google CloudApp Engine standard automatically for PHP 8.2 and later; Cloud Run for PHP 8.2 and later only with automatic base image updates; GKE, App Engine flexible and custom images must be rebuilt and redeployed; according to Google, runtimes with PHP 8.1 and older remain vulnerable
AWSAWS services not affected, according to AWS; packages for Amazon Linux; Elastic Beanstalk and Lightsail require a platform update or new instances

05 · Immediate actions

What to do now

Prioritize by risk: first the systems reachable from the internet, then internal applications, build pipelines and base images. The PHP project puts it this way: “There are no complete mitigations, updating is the only safe choice.”

  1. Build an inventory

    Record every PHP instance with its version and package level: hosts, container images in registries, running Kubernetes pods, PaaS services, hosting contracts and appliances. Flag everything that is reachable from the internet.

  2. Patch and restart

    Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package. Then restart Apache, PHP-FPM and all long-running PHP workers; otherwise the old code keeps running.

  3. Rebuild and roll out images

    Rebuild container images that contain PHP, update base images and redeploy the pods. Patching the host does not protect containers that bring their own PHP.

  4. Replace legacy versions

    There is no official release with a fix for PHP 8.1 and older. Use patched packages from an LTS vendor or migrate to 8.4 or 8.5. Anything that cannot be patched should be temporarily disconnected from the internet, as recommended by Germany's Federal Office for Information Security (BSI) and CISA.

  5. Interim protection where patching takes time

    PHP lists interim measures that reduce the risk but do not eliminate it. The BSI advises implementing all of them together. They only take effect if they are set in php.ini, in the FPM pool or in the server configuration, not via ini_set() or .user.ini. Afterwards, all workers must be restarted.

  6. Look for signs of attack

    Check logs from at least October 17, 2026 onward. On that day, Amazon observed the first exploitation attempt against its honeypots. The indicators are listed in the Detection section.

  7. Rotate credentials if there are indications of an attack

    The memory leak can expose passwords, tokens, API keys and certificates. If there are signs of an attack from before the patch, rotate these secrets and invalidate sessions.

  8. Document and check reporting duties

    Record your inventory, patch times and findings. If there are indications of exploitation, check the reporting duties under NIS2, the GDPR, DORA or the Cyber Resilience Act.

Interim measures per PHP · not complete

Configuration

  • session.upload_progress.enabled = 0 blocks the confirmed session paths, but not other variants. PHP advises keeping the option disabled even after patching if you don't need it.
  • fatal_error_backtraces = 0 (PHP 8.5 only) blocks the confirmed backtrace path.
  • memory_limit = -1, enforced with php_admin_value so that applications cannot override the value, combined with a memory limit at the container or cgroup level. Do not use RLIMIT_AS or RLIMIT_DATA.
  • post_max_size = 8M, or 32M if uploads are needed, with upload_max_filesize set below it.
  • A low pm.max_requests in PHP-FPM, in extreme cases 1, if performance allows.
  • Hiding error output does not help: display_errors, error_reporting or @ offer no protection.
Upstream · hardening

Web server, proxy and system

  • Limits at the web server or proxy for request size, number of fields, multipart parts, headers and nesting depth, including for requests without a usable Content-Length
  • Block multipart uploads where they are not needed
  • SELinux or AppArmor to contain the consequences of code execution
  • WAF and CDN rules as an additional layer (see below). Direct traffic to the origin server bypasses them.

According to PHP, memory_limit = -1 does not fully close the flaw, because other memory allocations can fail as well. Without a container limit, the setting also increases the risk that the server uses up all of its memory.

WAF and CDN: who provides what

Vendor protection rules, as of 2026-10-22. All vendors stress that they are no substitute for the patch.
VendorProtectionEnabled automatically?
CloudflareManaged Rules “Generic Rules – Anomalous Execution” and a rule for responsesyes for all WAF plans including Free, since Oct 21, 03:02 UTC
VercelWAF rules against known php2shell patterns, including for proxies to external PHP backendsyes for all projects
AWS WAFPHP rule group version 2.3 with the rule PHP2Shell_BODY, plus SizeRestrictions_BODY from the Core Rule Setpartly only if the rule groups are included in the web ACL
Azure Front DoorManaged rule 99006001, which removes malicious parts from responsesno off by default, rollout through Oct 28
Google Cloud ArmorManaged rules; the File Upload and RFI categories are recommendedpartly only where managed rules are already active
Fastly Next-Gen WAFCVE-specific template rule for both CVEsno must be enabled
AkamaiAdaptive Security Engine rule 3000991not specified
Imperva Cloud WAFProtection without configuration; Elastic WAF and WAF Gateway need updatesyes according to Imperva

06 · Detection

How to spot an attack

The indicators come from Wiz, Fastly, Amazon, Huntress and CrowdStrike. They are starting points for an investigation, not proof. According to Wiz, their absence does not mean you are not affected.

Network and requests

Suspicious requests

  • Multipart uploads with the field PHP_SESSION_UPLOAD_PROGRESS
  • Form POSTs larger than 1 to 2 MB or with deeply nested field names in square brackets
  • Unusually large or malformed PHPSESSID cookies in responses
  • Many similar requests in quick succession
Logs

Error patterns

  • Memory limit errors with the suffix in Unknown on line 0
  • Clusters of HTTP 500 responses after multipart requests
  • Apache segfault messages (AH00052) and unexplained restarts of PHP workers

CrowdStrike points out that a successful attack can also end inconspicuously with HTTP 200.

Host

Signs of code execution

  • PHP processes such as php-fpm, php-cgi, httpd or apache2 that spawn shells, interpreters or curl, wget and nc
  • Commands such as /bin/sh -c, whoami, id, uname
  • New files in the web root, new cron jobs or new accounts

Suspect a compromise? Our CSIRT is available around the clock at csirt@vamisec.com. A Compromise Assessment establishes whether attackers are already inside your systems.

07 · Status and background

Is PHP2Shell already being exploited?

The sources contradict each other, and the situation is changing quickly. As of : exploitation attempts are widely reported, but no authority has confirmed successful attacks on real systems.

Authorities

No confirmed exploitation yet

According to its security advisory (version 1.2, updated October 22), the BSI is not yet aware of any successful exploitation at scale. Proof-of-concept code is public. As of October 21, CISA had not observed any exploitation. The CVEs are not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Security vendors

Exploitation attempts reported

Amazon Threat Intelligence saw a first attempt on its own honeypots on October 17 and has been reporting widespread exploitation since October 21, while saying that success is unclear. Cloudflare is observing attack traffic and attempts to bypass its rules. Huntress and Cisco Talos found no successful exploitation on October 21.

Exploit code

Be careful with public PoCs

Wiz and Calif are not publishing their exploit. Numerous alleged PoCs are circulating on GitHub. Some are based on disproven assumptions, others could contain malware. For detection, Assetnote's scanner offers a transparent open-source tool.

Why an old bug is exploitable now

According to Wiz, the vulnerable code has been in PHP for more than ten years. Until now, exploiting it was extremely laborious: several bugs have to be chained and adapted to the memory layout of each target environment. Even a different PHP version, configuration or application can break an exploit's assumptions.

Today, AI models take over exactly this adaptation work. For its research, Wiz used its own AI agent, Wiz Atlas, as well as the models Gemini 4 Argon and GPT-5.6 Sol. According to Wiz, this allowed a single researcher to achieve in one week what would previously have taken a top team months. According to OpenAI, Calif worked with GPT-5.6 Sol, and the PHP team also used AI tools for validation.

For defenders, this means complexity no longer offers reliable protection. Vulnerabilities once considered theoretical become exploitable in practice. As this case shows, however, the same tools also help find and fix them.

Timeline

  1. Calif and OpenAI independently report the root cause to the PHP team (according to the PHP Foundation).
  2. Wiz Research finds the first vulnerability; code execution against Drupal and WordPress follows on Aug 20 and 21.
  3. Wiz reports its attack paths to the PHP security team.
  4. PHP confirms the Wiz reports and works on a coordinated fix.
  5. Amazon observes a first exploitation attempt on honeypots.
  6. The CVE numbers leak. PHP moves the disclosure forward by one day.
  7. PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Wiz, Calif, OpenAI and the PHP Foundation disclose the details. BSI and CISA issue warnings.
  8. Distributions and platforms follow with updates; exploitation attempts are increasing.

08 · Wiz coverage

What Wiz provides for PHP2Shell

Wiz customers will find a dedicated PHP2Shell advisory in the Threat Intel Center of their Wiz tenant. According to Wiz, it includes detection, response and remediation guidance.

Agentless vulnerability detection

Using read-only cloud APIs and disk snapshots, Wiz identifies which PHP packages are present on VMs, in container images, in registries and in serverless functions, without agents. The Security Graph shows which vulnerable instances are reachable from the internet.

Runtime detection with Wiz Defend

The eBPF-based Wiz Runtime Sensor detects behavior typical of PHP2Shell exploitation. From sensor version 1.0.12768 onward, you can enable a response policy that automatically terminates such processes. We recommend testing it in simulation mode first.

Remediation and threat hunting

The advisory provides guidance on remediation and on hunting for signs of attack. According to Google Cloud, the Wiz Green Agent can derive resource-specific steps from it. Also according to Google Cloud, patched PHP images from WizOS are available to all Wiz customers for 60 days at no extra cost.

For PHP2Shell, Wiz explicitly names agentless and runtime detection. Wiz does not claim PHP2Shell-specific detection for Wiz ASM and the Red Agent. We therefore use them not as a PHP2Shell scanner but for the outside view: Which PHP systems are reachable, and where are secrets exposed? The Wiz Threat Briefing on PHP2Shell is available as a recording.

09 · VamiSec exposure check

We check at short notice whether PHP2Shell affects you

As a certified Wiz partner, we use the Wiz platform specifically for PHP2Shell. You decide how deep we look: from the outside only, without access to your environment, or additionally from the inside through read-only connectors. The result is a prioritized list of the systems you need to patch first.

Option A · from the outside

Black-box check

We look at your environment the way an attacker sees it from the internet. You do not need to give us any access for this.

  • Wiz ASM discovers your reachable domains, subdomains, IP addresses and API endpoints, starting from your root domains
  • We identify PHP stacks and version indicators. Wiz's Attack Surface Rules additionally check reachable services for known vulnerabilities, misconfigurations and exposed secrets
  • The Wiz Red Agent acts as an AI-powered attacker and tests reachable web applications and APIs for logic flaws, authorization gaps and exposed data. Wiz does not name a dedicated PHP2Shell test for it
  • It checks exposed secrets to see whether they are still valid and what they give access to
  • In addition, we map your attack surface with recon and attack surface management from VamiRedteam and, once authorized, confirm suspected cases with Assetnote's scanner

Result: a list of your reachable PHP systems with a risk rating. From the outside, you get indicators, but no certainty about the patch level.

Option B · from the inside

Cloud and Kubernetes check

We connect Wiz to your cloud accounts and clusters with minimal read permissions and without agents on your workloads. For the scan, Wiz briefly creates disk snapshots and deletes them afterward.

  • Read-only cloud connectors for AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud and VMware vSphere
  • Agentless scanning of VMs, container images, registries and serverless functions for installed PHP packages and versions. We match package versions with backported fixes against the distributions' advisories
  • Kubernetes connector via Helm chart with read permissions for EKS, AKS, GKE, OpenShift and self-managed clusters
  • Optionally, and only with separate approval, the Wiz Runtime Sensor, an eBPF sensor on hosts and nodes, to detect attacks at runtime. It requires a matching Wiz license

Result: a reliable inventory for the connected accounts and clusters, showing which workloads use which PHP version and which of them are vulnerable. We check self-compiled PHP and appliances separately.

Recommended · combined

Outside and inside together

The combination answers the crucial question: which vulnerable PHP instances are actually reachable from the internet?

  • The outside view and the inventory are linked in the Wiz Security Graph
  • Attack paths from the internet to vulnerable workloads and sensitive data
  • A prioritized action plan with patch order, interim protection and evidence for audits
  • Verification after patching that all instances have the fix

Result: a solid basis for decisions by IT, the CISO and executive management.

01 · Initial call

Define the scope

In 30 minutes, we clarify domains, cloud providers, clusters and your priorities.

02 · Authorization

Authorize in writing

You approve the scope in writing. Without authorization, we test nothing.

03 · Check

Outside and inside view

We carry out the agreed checks and report critical findings immediately.

04 · Result

Report and action plan

You receive a management summary, the technical list of findings and the patch order.

What we need from you
  • For the outside view: your root domains and known IP ranges, plus written approval of the scope
  • For the inside view: a read-only role per cloud account, which we set up together, and installation of the Kubernetes connector via Helm
  • A contact person from operations or IT security for questions
How we work
  • We work only within the approved scope and agree test windows with you
  • Active verification of individual systems, for example with the Assetnote scanner, only with separate written approval and in an agreed time window, because it deliberately triggers memory errors and can cause PHP workers to crash or restart
  • We settle confidentiality upfront with an NDA and, where needed, the processing of test data with a data processing agreement
  • If there are signs of a compromise, we bring in our CSIRT immediately on request

Request an exposure check

Book a meeting directly or write to wiz@vamisec.com. We reply within 24 hours. Feel free to include your domains, cloud providers and clusters right away, so we can assess the scope immediately.

Wiz Partner Badge Technical Foundations Wiz Partner Badge Demo Accreditation
Book a meeting Send an email

10 · Reporting duties

When you must report PHP2Shell

In Germany and the EU, an unexploited vulnerability alone does not trigger a reporting duty. That changes if it has been exploited in your environment. In addition, manufacturers that ship PHP in their own products must report as soon as there is reliable evidence of active exploitation. Providers of digital infrastructure and services, ICT service providers and financial entities may also be required to inform their customers about possible protective measures as soon as a significant cyber threat arises. The deadlines start when you become aware of the incident, not when the CVE is published. This overview is for orientation only and is not legal advice.

NIS2 · German BSI Act (BSIG) §§ 30, 32, 35

Important and essential entities

Handling and patching vulnerabilities is part of the risk management required by the BSIG. You must report a significant security incident, such as successful unauthorized access that can cause severe operational disruption. In that case: early warning within 24 hours, notification within 72 hours, final report one month after the notification.

GDPR · Art. 33, 34

When personal data is affected

If the memory leak has exposed personal data or credentials, notify the supervisory authority within 72 hours, unless the breach is unlikely to result in a risk. If the risk is high, inform the affected individuals without undue delay. Every personal data breach must be documented.

Cyber Resilience Act · Art. 14

Manufacturers that ship PHP in their products

Since September 11, 2026, manufacturers must report actively exploited vulnerabilities in their products through ENISA's reporting platform, including for products already on the market. This applies, for example, to appliances or software with embedded PHP. Deadlines: 24 hours, 72 hours, and a final report 14 days after a fix becomes available. Website operators are not covered.

DORA · Art. 19

Financial entities

Banks, insurers and other financial entities do not report under the German BSI Act but under DORA, to their supervisory authority. Under DORA, successful malicious access is a key criterion for a major ICT-related incident. The initial notification is due within 4 hours of classification, and no later than 24 hours after becoming aware of the incident.

A blocked attack attempt is usually not a reportable incident, but at most a near miss. Voluntary reports to the BSI, including anonymous ones, are still possible. Further reading: NIS2, Cyber Resilience Act, DORA.

11 · FAQ

Frequently asked questions about PHP2Shell

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619. They arise when PHP aborts a request because it has run out of memory and leaves internal state behind that a later request reuses. This lets attackers read memory and execute code without authentication. The flaws were disclosed on October 21, 2026, by Wiz Research, Calif, OpenAI and the PHP project.

Am I affected by PHP2Shell?

Any PHP installation that handles web requests and is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is affected, unless a patched distribution package is installed. This applies to PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older will not get an official release with a fix.

Which PHP versions are safe?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and later versions are safe. Packages from distributions such as Debian, Ubuntu or Red Hat can contain the fix without a new version number. In that case, check the package changelog for both CVE numbers.

What about PHP 8.1, 8.0, 7.4 and older versions?

The PHP project no longer publishes updates for these branches. For 7.4, 8.0 and 8.1, it has provided only minimal source backports, and for older versions no fix at all. Use patched packages from an LTS vendor or migrate to PHP 8.4 or 8.5. The BSI and CISA advise temporarily disconnecting systems that cannot be patched from the internet.

Is updating WordPress, Drupal or Joomla enough?

No. The vulnerabilities are in the PHP runtime, not in the application. Updating the CMS, themes or plugins does not protect you. You need to update PHP itself and then restart all PHP processes.

Is PHP2Shell already being actively exploited?

As of October 23, 2026, Amazon, Cloudflare and other vendors report widespread exploitation attempts. However, the BSI and CISA have not yet confirmed any successful exploitation, and the CVEs are not in CISA's KEV catalog. Even so, treat PHP systems that are reachable from the internet as if they were under attack.

Does a WAF or CDN protect against PHP2Shell?

Only partially. Cloudflare, Vercel, AWS, Google, Akamai, Imperva, Fastly and Microsoft have published rules, some enabled automatically, some not. All of them stress that the rules do not replace the patch. Attackers vary their requests, and traffic that goes directly to the server bypasses the WAF.

Are there workarounds if I can't patch right away?

Yes, but they are only partially effective. Among other measures, PHP recommends session.upload_progress.enabled = 0, fatal_error_backtraces = 0 on PHP 8.5, a smaller post_max_size, and memory_limit = -1 combined with a container memory limit. These settings belong in php.ini or the FPM pool, and all workers must be restarted afterwards.

Is there a scanner or proof of concept for PHP2Shell?

Yes. Assetnote has released the open-source php2shell-scanner on GitHub (github.com/assetnote/php2shell-scanner). It demonstrates the vulnerable behavior with crafted multipart requests without executing code, but it generates around 29 MiB of load per path and triggers memory errors. Use it only on your own or authorized systems, and cross-check hits against the package level. VamiSec supports you with planning and evaluation, including recon and attack surface management with VamiRedteam.

Do I need to restart PHP-FPM or Apache after the update?

Yes. Running workers keep the old code in memory. Restart Apache, PHP-FPM and all long-running PHP processes, and roll out containers with rebuilt images.

How do I find vulnerable PHP in containers and Kubernetes?

Check the PHP version in every image, for example via the PHP_VERSION environment variable or php -v, and match the running pods against the images. Base images from registries and CI pipelines are part of this. Wiz can do this agentlessly for connected cloud accounts, registries and clusters. You should also check self-compiled PHP and appliances separately.

What data can leak, and do I need to rotate keys?

The memory leak can contain data from other requests and from the server, such as passwords, session tokens, API keys and certificates. If there are indications of an attack from before the patch, you should rotate these secrets and invalidate active sessions.

Do I have to report PHP2Shell?

The vulnerability alone is not reportable. A reporting duty arises in the event of a significant security incident under NIS2, a personal data breach under the GDPR, a major ICT-related incident under DORA or, for manufacturers, an actively exploited vulnerability in their own product under the Cyber Resilience Act.

How does the VamiSec exposure check work?

After a 30-minute initial call and your written authorization, we check from the outside with Wiz ASM, the Wiz Red Agent and VamiRedteam. If you wish, we also check from the inside through read-only Wiz connectors for cloud and Kubernetes. You receive a prioritized list of findings and an action plan. We report critical findings immediately.

What access does VamiSec need for the check?

For the outside view, none: only your domains, IP ranges and written authorization. For the inside view, a read-only role per cloud account and the Wiz Kubernetes connector. Both work with minimal, mostly read-only permissions and do not install agents on your workloads. For the agentless scan, Wiz briefly creates disk snapshots, and by default the Kubernetes connector can read all resources in the cluster, including secrets.

Where is data processed during the check?

Wiz offers tenants in the EU. We agree with you in advance which tenant we use for your check. According to Wiz, scans of connected cloud resources run in the region of the respective resource. According to Wiz's subprocessor list, some processing, for example for support and usage analytics, also takes place outside the EU. For Red Agent analyses, Wiz uses a global endpoint, according to its subprocessor list. If you have strict data residency requirements, we agree on the use of the Red Agent with you in advance.

12 · Sources

Primary sources and vendor guidance

This page summarizes the publications in our own words. The original sources are authoritative. We update the page as soon as the situation changes.

  1. PHP2Shell: AI uncovers critical RCE vulnerabilitiesWiz Research, 2026-10-21
  2. php2shell.comWiz, overview with versions and interim measures
  3. Critical remote code execution vulnerabilities, update nowPHP project, advisory of 2026-10-21
  4. GHSA-w8hw-w9fx-j79w (CVE-2026-109618)PHP project, GitHub Security Advisory
  5. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)PHP project, GitHub Security Advisory
  6. Today's PHP security releaseThe PHP Foundation, 2026-10-21
  7. CVE-2026-109618 and CVE-2026-109619CVE records from the PHP CNA
  8. NVD: CVE-2026-109618National Vulnerability Database
  9. PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweitBSI, IT security advisory BITS-H 2026-297981-1132, version 1.2 of 2026-10-22 (in German)
  10. WID-SEC-2026-4055CERT-Bund, warning and information service (WID)
  11. Security Advisory 2026-018CERT-EU, 2026-10-21
  12. Joint statement on critical PHP vulnerabilitiesEuropean Commission, ENISA, CERT-EU, Europol, CSIRTs Network
  13. Critical Vulnerabilities in PHP Require Immediate PatchingCISA, 2026-10-21
  14. PHP2ShellCalif
  15. Patch the Planet: global response coordinationOpenAI, 2026-10-21
  16. Responding to core PHP vulnerabilitiesGoogle Cloud
  17. PHP vulnerabilities: WAF protectionCloudflare
  18. Proactive protection for critical PHP RCEFastly
  19. PHP2Shell security bulletinVercel
  20. Security Bulletin 2026-143-AWSAWS
  21. PHP2Shell exploitation prior to public disclosureAmazon Threat Intelligence
  22. Addressing PHP2Shell: upgrade guidance and Azure WAFMicrosoft
  23. Critical RCE vulnerabilities in PHP coreAkamai
  24. PHP2Shell vulnerability updatesImperva
  25. PHP2Shell hunting guidanceHuntress
  26. PHP RCE zero-daysCrowdStrike
  27. assetnote/php2shell-scannerAssetnote, open-source detection scanner, 2026-10-22
  28. NCSC-NL/php2shellNCSC-NL, list of affected software
  29. VamiRedteamVamiSec, agentic platform for recon, attack surface management and pentests
  30. Usage statistics of PHPW3Techs, 2026-10-22
  31. Wiz ASM auto recon · Wiz Red Agent · Agentless scanningWiz, product information
Valeri Milke
Valeri MilkeManaging Director, VamiSec GmbH · ISO/IEC 27001 & 42001 Lead Auditor · updated

Clarity about your PHP systems

We show you where PHP runs in your environment, which instances are vulnerable and reachable, and what you should do first.

Request an exposure check