PHP2Shell: Critical PHP Vulnerability (CVE-2026-109618 & CVE-2026-109619)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Summary

On October 21, 2026, the PHP project released security updates for two critical vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both were rated critical, each scoring 9.2 out of 10 under CVSS v4.0, and can allow an attacker to execute code on your server without any credentials – an unauthenticated PHP remote code execution, or RCE for short. The 2026 PHP vulnerability ranks among the most severe flaws in the language’s history.

Affected are all PHP versions from PHP 5.4 through 8.5.11 – effectively every PHP installation that serves web requests, whether WordPress, Joomla, Drupal, TYPO3 or a small custom application. The flaw sits in the PHP core itself, not in a CMS or plugin.

Patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches (8.1 and below, including PHP 7.x) no longer receive official releases. Germany’s Federal Office for Information Security (BSI) issued a cybersecurity warning about the PHP vulnerability demanding immediate action; the UK NCSC, CERT-EU and Canada’s Cyber Centre published equivalent alerts.

Affected and patched PHP versions

What is PHP2Shell?

The PHP2Shell vulnerability comes in two parts: PHP2Shell is the collective name for two flaws in the PHP core. Both are memory-safety bugs of the use-after-free type (CWE-416): PHP keeps using internal state after the underlying memory has already been freed. The name deliberately echoes Log4Shell, the critical Java flaw of 2021 – and just like there, the problem is not in a single application but in a component almost everything builds on.

The key terms first:

• Remote Code Execution (RCE): PHP ends up running attacker-controlled code on your server – no login, no user interaction required.
• Out-of-Memory (OOM): PHP aborts a request once it hits the configured memory_limit.
• Memory corruption: a bug class where memory contents become invalid and the program later misinterprets them – the technical foundation of many RCE exploits.

CVE-2026-109618: RCE via out-of-memory corruption

PHP aborts a request via longjmp() when the memory limit is reached. This can interrupt PHP mid-processing – for example while parsing a multipart/form-data request (the format browsers use for forms with file uploads). The still-partially-initialized request data is then mistakenly treated as valid during cleanup. The memory behind it may still contain data from earlier, attacker-controlled allocations.

The result: a single, specially crafted HTTP request can compromise the PHP worker during request processing – before a single line of your application code runs. On Apache with mod_php, full remote code execution was demonstrated with default settings; on PHP-FPM, RCE was confirmed through application-level code paths.

CVE-2026-109619: RCE via stale global state

PHP workers (mod_php processes, FPM workers) handle many requests in sequence. Between two requests, internal state must be cleanly reset. With this flaw, a fatal error – for example caused by memory exhaustion – can abort a request in a way that leaves global state pointing at memory from the old request that has long been freed. A subsequent request on the same worker consumes that stale state before normal initialization replaces it.

Confirmed paths include early INI diagnostics (mod_php evaluates .htaccess and php_value configuration before the actual request startup), the session upload progress feature (session.upload_progress.enabled is on by default) and, on PHP 8.5, the fatal_error_backtraces option. A proof of concept was demonstrated against a real-world application running on Apache with mod_php.

Heartbleed-style memory disclosure

Beyond code execution, the researchers showed that the flaws can also be used to read parts of the PHP process memory – comparable to Heartbleed in OpenSSL. That memory can contain session tokens, passwords, API keys or certificates from other requests. This attack form needs no prior code execution and is correspondingly harder to detect.

Who is affected?

Every PHP installation that serves web requests:

• PHP-FPM (typically behind Nginx or Apache)
• Apache with mod_php
• php-cgi (CGI/FastCGI setups)
• FrankenPHP
• LiteSpeed (LSAPI)

Apache mod_php was rated the most critical case, for two reasons: the demonstrated exploit triggers the vulnerability before application code runs, and mod_php shares its process space directly with the web server.

Crucially: this PHP server vulnerability lives in the PHP core. WordPress, Joomla, Drupal, TYPO3, Magento, Shopware or your own script are not the cause – but every application on a vulnerable PHP runtime is in principle attackable, down to a trivial script that only prints output. Wiz Research demonstrated unauthenticated RCE against the official WordPress, Drupal and Joomla container images.

How was PHP2Shell discovered?

The story is remarkable because frontier AI models played a decisive role in the coordinated disclosure of a vulnerability of this magnitude for the first time:

• Back in 2024, a PHP core developer working on findings from the first external security audit (OSTIF/Quarkslab, funded by the Sovereign Tech Agency) found the first signs of the OOM problem – but a concrete exploit path remained theoretical.
• On August 11, 2026, security firm Calif (researcher Ryan A, a.k.a. lcfr_hax, as part of the “Patch the Planet” program) reported an unconditional remote code execution to the PHP project. OpenAI independently reported the same root cause; Wiz Research followed on August 24, and OpenAI supplied additional attack vectors on September 18.
• The underlying bugs had been in the code for more than a decade. The exploit chain was considered so complex that it bordered on what human researchers could practically achieve – frontier models lowered that barrier. OpenAI describes the details in its post on the coordinated release.
• On October 20, the CVE IDs leaked early – with a wrong CVSS score of 10.0 and a wrong release time. An accidentally published PoC video by Calif and an embargo break by Chainguard accelerated the release; PHP moved it forward by one day.

Is PHP2Shell already being exploited?

Sources differ slightly here, so with an explicit as-of date (October 22, 2026):

• AWS observed exploitation attempts as early as October 17 – four days before public disclosure (Datadog Security Labs).
• Cloudflare saw attack traffic against customers during the leak window, including mutated payloads trying to bypass its WAF rules.
• Bitdefender and the Canadian Cyber Centre reported no confirmed widespread exploitation at the time of writing, but stress this can change quickly – a working PoC is circulating.

Am I affected by PHP2Shell? – the PHP2Shell check

Before changing anything, check for PHP2Shell – concretely: find out which PHP version your website really uses. That is not always as trivial as it sounds.

Step 1: Check the PHP version (CLI)

On a server with SSH access:

php -v

or alternatively:

php -r 'echo PHP_VERSION, PHP_EOL;'

The output shows the PHP CLI version, e.g. PHP 8.3.35 (cli). If it is below the fixed versions (8.2.35, 8.3.36, 8.4.27, 8.5.12), action is required.

Step 2: Identify the version actually in use

Important: the CLI version does not have to be the same one Apache or PHP-FPM uses for your site. Multiple PHP versions can coexist on one server.

For PHP-FPM, first check which FPM services are running:

systemctl list-units --type=service | grep -i fpm

Typical services are named php8.3-fpm, php8.4-fpm or php-fpm. Get the matching version via the binary:

php-fpm8.4 -v

Which pool serves which site is defined in the pool configuration (Debian/Ubuntu: /etc/php/*/fpm/pool.d/) and the web server config (for Nginx the fastcgi_pass socket, for Apache the proxy:fcgi: or SetHandler lines of the vhost).

For Apache with mod_php:

apache2ctl -M | grep php    # Debian/Ubuntu
apachectl -M | grep php     # Fedora/RHEL

If the output shows php8_module (or php_module), mod_php is in use – the package is typically called libapache2-mod-php8.x:

dpkg -l | grep libapache2-mod-php   # Debian/Ubuntu
rpm -q php                          # Fedora/RHEL-like

Step 3: Further indicators – and their limits

• HTTP headers: some servers send X-Powered-By: PHP/8.3.5. You can see it with curl -I https://your-domain.tld or the browser dev tools. Beware: the header is often disabled or overridden by the web server/proxy – its absence does not mean “safe”, and its content does not have to match the CGI/FPM version. It is a hint, not proof.
• phpinfo(): a file info.php containing <?php phpinfo(); in the webroot shows the exact version and configuration. But: phpinfo() reveals a lot about your system to attackers. Create such a file only briefly for diagnostics and delete it immediately afterwards or block access – a public phpinfo() is no permanent solution.
• Docker: docker exec <container> php -v shows the version inside the running container – the host version says nothing about the image.

Beware the backport trap

Linux distributions often backport security fixes into their existing package versions. php -v can therefore report 8.3.10 even though the package already contains the PHP2Shell patch. Conversely, an unchanged upstream version does not automatically mean “unpatched” – and a new upstream number from a third-party repo does not automatically mean “fully patched”.

So additionally check the package changelog or your distributor’s security advisory:

apt changelog php8.4-fpm        # Debian/Ubuntu
apt policy php8.4-fpm           # installed vs. available package version
rpm -q --changelog php | less   # Fedora/RHEL

Relevant sources include Debian Security Advisories (DSA), Ubuntu Security Notices (USN) or your enterprise distributor’s errata.

Installing the PHP security update: the PHP2Shell fix

There is no complete alternative to the PHP2Shell update – as the PHP project itself puts it (“no complete mitigations, updating is the only safe choice”). Afterwards, read the section for your setup and do not forget: restart PHP-FPM or the web server, otherwise old workers keep running. The PHP vulnerability in short – what to do: check the version, apply the patch, restart services, read the logs for attack traces.

Debian / Ubuntu

sudo apt update
sudo apt upgrade

Then check the installed package version (apt policy php8.4-fpm, adjust the name as needed) and look at the changelog (see the backport note above). PHP packages on Debian/Ubuntu often come from the security repository or – for newer versions – from the well-known Sury repository (packages.sury.org), which ships patched builds promptly.

Fedora / RHEL-like systems

sudo dnf upgrade php\*
sudo dnf list php --showduplicates   # check available versions

The same applies here: verify the package version and changelog (rpm -q --changelog php) against the distributor’s erratum. If you use Remi’s Repo or module streams, keep track of the source.

Restart PHP-FPM

A restart is mandatory after the update, otherwise the old worker processes keep running:

sudo systemctl restart php8.4-fpm   # adjust the name to your version

Then verify the service runs the new version:

systemctl status php8.4-fpm
php-fpm8.4 -v

Apache mod_php

With mod_php, PHP runs inside the Apache process – updating PHP alone does nothing if Apache keeps working with the old library:

sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # Fedora/RHEL

Then test the website and check the logs (journalctl -u apache2, /var/log/apache2/error.log).

Managed hosting (Plesk, cPanel, provider panels)

On shared hosting or managed servers you usually have no root access – and you do not need it:

1. Check which PHP version is set per domain (Plesk: “PHP Settings”, cPanel: “MultiPHP Manager”, many hosts show it in the customer panel).
2. Switch to a patched version if available (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or newer).
3. Contact your host if only vulnerable versions are offered – reputable providers patch their platforms centrally and communicate that; when in doubt, ask about the PHP2Shell status.
4. For WordPress additionally in the backend: Tools → Site Health → Info → Server shows the PHP version WordPress actually sees.

PHP2Shell and Docker: containers, images, platforms

IRC-Security.de

Cybersecurity Artikel und Tutorials

Docker changes nothing about the core question: what matters is the PHP version inside the image, not the one on the host. Containers do add two pitfalls though: your own images contain their own PHP, and running containers never update themselves.

How much at risk am I with Docker?

Short answer: just as much as without Docker, as far as the initial flaw is concerned. If the PHP inside the image is vulnerable, an HTTP request can compromise the PHP worker inside the container – the network is the whole point of that container.

Isolation only helps with the second step: code initially runs “only” inside the container, as the container user, with the mounted volumes and the secrets in the environment variables. That limits the damage – but a container with database access, an upload directory and API keys is still very rewarding for attackers. PHP2Shell inside a container is a critical event, not “half as bad”.

Which images are affected?

Everything that contains PHP. Typical candidates:

• php:* base images (php:8.3-fpm, php:8.4-apache, php:8.5-cli, …) and everything built on them (FROM php:… in your Dockerfile)
• Images bundling PHP: wordpress:*, nextcloud:*, drupal:*, joomla:*, matomo:*, mediawiki:* and many more
• FrankenPHP images (dunglas/frankenphp:*)
• Custom builds, including multi-stage builds with COPY --from=php…

Find PHP bases in your project:

grep -rnE '^\s*FROM\s+\S*(php|frankenphp)' . --include='Dockerfile*'
grep -rnE 'image:\s*\S*(php|wordpress|nextcloud|drupal|joomla|frankenphp)' . --include='*compose*.y*ml'

What do I actually need to do?

1. Switch to patched tags. The official PHP images on Docker Hub have already been updated (tags like php:8.3.36-fpm-bookworm, php:8.4.27-apache, php:8.5.12-fpm-alpine; the floating tags php:8.3, php:8.4 etc. also point to the fixed builds). In the Dockerfile, ideally pin php:8.3.36-fpm-bookworm instead of php:8.3-fpm.
2. Rebuild your own images – with --pull. Without --pull, the build cache may reuse the old, vulnerable base image:

docker compose build --pull
docker compose up -d --force-recreate

3. Hub images without a custom build – simply re-pull and recreate the containers:

docker compose pull
docker compose up -d --force-recreate

4. Do not forget more than the web container: queue workers, cron containers, schedulers – everything using the same PHP image.
5. Verify inside the running container:

docker exec <containername> php -v

6. Mind digest pins: if you pin images via @sha256:…, you must bump the digest to the patched build manually – pins do not fetch security updates automatically.
7. Clean up old, vulnerable images afterwards so nothing accidentally starts from them.

Do the providers handle the update?

Partly – and this is where most wrong assumptions come from:

• Docker Official Images and Docker Hardened Images were already updated by Docker Inc. to the patched PHP versions. That only means the image in the registry is new – your running container stays on the old build until you recreate it.
• App images (wordpress, nextcloud & co.) are being rebuilt by their maintainer teams with the new PHP – the pull and the recreate are on you.
• Managed platforms / PaaS usually patch their own runtime centrally. Whether and when that happened is something only the provider’s advisory or status page tells you – your own container images deployed there remain your responsibility.
• Auto-updaters (e.g. Watchtower) can re-pull hub images and recreate containers – but they cannot repair locally built images. For FROM php:… Dockerfiles you need a rebuild, ideally automated via CI or Dependabot/Renovate.

Coolify specifically

Coolify is a special case because Coolify itself is written in PHP (Laravel) – the platform was vulnerable across all v4 release lines, independent of the apps you deploy with it:

• Update from v4.4: in the dashboard via Settings → Update → Check now → Update.
• Older v4 lines: via SSH with the official patch script (curl -fsSL https://cdn.coollabs.io/coolify/patch.sh | sudo bash), which installs the matching security release of your line and only recreates the Coolify container.
• Coolify Cloud is already patched – nothing to do there.
• Coolify has proactively disabled 58 PHP-based service templates until it is verified which images contain the fix.
• Important: the Coolify update only patches Coolify itself. Your deployed application containers stay vulnerable until you rebuild/redeploy them – so trigger a redeploy with a fresh build per application inside Coolify.

Details are in the official Coolify documentation and the linked GitHub issue.

Dokploy, CapRover, Easypanel, Dokku, Portainer & co.

Same principle as with Coolify, split in two:

1. Check the tool itself: does the platform or one of its core containers run PHP? Then read the project’s advisory and apply the tool update.
2. The apps deployed through it: remain your job – rebuild or re-pull the images and redeploy the applications.

For Kubernetes the same applies: build the image with patched PHP, then restart the rollout (kubectl rollout restart) so all pods pull the new version, and verify the digest of running pods if needed. If you want more background on images, containers and Docker Compose, see the article on Docker fundamentals.

Interim measures if you cannot patch immediately

If an update is temporarily impossible, the official advisories say the following measures reduce the attack surface – but they do not fully protect and do not replace the PHP security update:

• set memory_limit=-1 in a way applications cannot override (e.g. php_admin_value in the FPM pool or Apache configuration) – removes the controllable OOM trigger, but not every path
• low post_max_size (e.g. 8M when uploads are not needed), keep upload_max_filesize below it
• session.upload_progress.enabled=0 – closes the upload-progress path of CVE-2026-109619, not the whole flaw
• request limits at the reverse proxy/web server (body size, header and multipart counts)

PHP 7.x, 8.0 and 8.1: what to do with end-of-life versions?

Old PHP versions are not “safe because old” – quite the opposite: the flaws go back to PHP 5.4, and PHP 8.1 and older receive no official releases from the PHP project anymore.

Your realistic options:

1. Check distribution/vendor backports: the PHP security team provided source backports for 7.4, 8.0 and 8.1, and LTS vendors (Debian LTS, Ubuntu with Extended Security Maintenance, RHEL, specialized PHP-LTS providers) build packages from them. What counts is the package version in the changelog, not the upstream number.
2. Migrate to a supported version (8.2+). That is the permanently right answer: anyone running PHP 7.x in production is already running without security updates – PHP2Shell just makes that especially visible.
3. Apply the mitigations above in the meantime – consciously as a stopgap, not a solution.

Could my server already be compromised?

A successfully installed PHP update does not prove nobody got in beforehand. Exploitation attempts were reportedly observed before the release. This checklist is defensive and meant for your own systems:

In the web server/PHP logs (access.log, error.log, FPM log, syslog/journald):

• unusual or unusually large HTTP POST requests, especially with multipart/form-data
• frequent PHP out-of-memory errors (“Allowed memory size exhausted”) around request initialization
• a conspicuous surge of HTTP 500 errors
• crashing or constantly restarting PHP-FPM or Apache workers (segfaults, “child exited”)

On the system:

• new or unexpectedly changed PHP files in the webroot and in upload directories (wp-content/uploads & co.) – PHP files in upload folders are almost always a red flag
• webshells: files passing request parameters to system, shell_exec, passthru, eval and the like
• unknown cron jobs (crontab -l for all users, /etc/cron.*) and unknown user accounts (/etc/passwd, last, auth.log)
• PHP/web server processes unexpectedly spawning shells, interpreters (bash, python) or download tools (curl, wget) – visible e.g. in the process list, audit logs or EDR
• for WordPress: unusual changes to plugins, themes, wp-config.php, new admin accounts

If you find concrete evidence: isolate the system (disconnect the network, do not just wipe and reinstall), preserve volatile data and images, and run a forensic investigation – yourself or via a service provider. A useful entry into the mindset and methodology is the article on Linux penetration testing and IT forensics at IRC-Security.de (German); for update hygiene in general, the piece on Linux patch management (German).

Is WordPress affected by PHP2Shell? (and Joomla, Drupal, TYPO3)

Yes and no. Whether you search for PHP2Shell WordPress, PHP2Shell Joomla, PHP2Shell Drupal or TYPO3 – the answer is the same and needs a precision:

• The CMS is not the cause. The flaw lives in the PHP core, not in WordPress core, not in plugins, not in the theme.
• But: WordPress runs on PHP. If your WordPress runs on a vulnerable PHP version, the WordPress PHP vulnerability is real – Wiz demonstrated unauthenticated RCE against the official WordPress, Drupal and Joomla images.
• A WordPress update does not help. Core, theme or plugin updates do not patch the PHP runtime. Only the PHP security update (or a distribution backport) closes the hole.

How to check the version as a WordPress operator:

• In the backend: Tools → Site Health → Info → Server → PHP version
• In the provider’s hosting panel (Plesk “PHP Settings”, cPanel “MultiPHP Manager” or similar)
• Ask your host’s support if only old versions are offered
• If you run WordPress via the wordpress:* Docker image: PHP is bundled inside → pull the updated image and recreate the container (see the Docker section)

The more general attack patterns behind this – how web application vulnerabilities get classified, for instance – are covered in the article on the OWASP Top 10; a comparison with classic injections like SQL injection shows why PHP2Shell plays in a different league: the application cannot act as a protective layer here because the attack strikes before it even runs.

Can a firewall or WAF prevent PHP2Shell?

A web application firewall can help, but it is no substitute for the update:

• Cloudflare enabled PHP2Shell rules for all customers (including the free plan) and used its new “Full Transaction Detection” for it – rules evaluating a request and its response together, because the request alone cannot always distinguish an exploit from legitimate traffic. Other vendors (Azure WAF, Google Cloud Armor, AWS WAF, Imunify360, Sucuri and more) followed with their own rules.
• Blocking requests at an upstream boundary (WAF, reverse proxy) stops the attack before it reaches the vulnerable parser – a real protective gain as long as the rules cover the payload variants.
• However: exploits mutate (Cloudflare observed exactly that), internal attack paths and non-HTTP(S) paths remain, and memory disclosure does not even necessarily have a blockable request shape.

Bottom line: WAF yes – as an additional layer (defense in depth), not a fix. If you want to dig into reverse proxies and gateways: API gateway fundamentals with Kong and Nginx.

FAQ: PHP2Shell

Sources and further reading

Official sources and advisories:

• PHP announcement of the security releases (php.net)
• GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619)
• The PHP Foundation: Today’s PHP Security Release
• php2shell.com – the researchers’ overview site

Authorities:

• BSI cybersecurity warning: PHP – critical vulnerabilities threaten web applications worldwide (German)
• CERT-EU Advisory 2026-018: Critical Vulnerabilities in PHP
• NCSC (UK): Critical security issue affecting PHP
• Canadian Centre for Cyber Security: AL26-026
• NCSC-NL: operational information on the PHP2Shell incident (GitHub)

Research and detection:

• Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities
• OpenAI: Patch the Planet – global response coordination
• Datadog Security Labs: PHP2Shell – detection, analysis, and remediation
• Cloudflare: Deploying protections against php2shell

Docker and platforms:

• Docker: Security Update on PHP2Shell – Impact for Docker Customers
• Coolify Docs: PHP Security Advisory 2026 (PHP2Shell)
• Coolify GitHub Issue #12266: Update Coolify now for PHP2Shell

Further reading on IRC-Coding.de and IRC-Security.de:

• OWASP Top 10: Web Application Security Risks
• SQL Injection: Risks, Protection & Best Practices
• Docker Containers: Images, Dockerfile & Compose
• Linux Bash Coding Tutorial for Beginners
• Popular Programming Languages: Developer Guide (incl. PHP)
• IRC-Security.de: Linux patch management and automatic updates (German)
• IRC-Security.de: Kali Linux, penetration testing and IT forensics (German)

Related PHP2Shell article on IRC-Mania.de (German):

• PHP2Shell: WordPress, Docker, Coolify and home servers – check and secure them now

PHP2Shell from an AI perspective on BotServ.de:

• English: PHP2Shell – Critical PHP Vulnerability and AI’s Role
• Deutsch: PHP2Shell – Kritische PHP-Sicherheitslücke und die neue Rolle der KI
• Español: PHP2Shell – Vulnerabilidad crítica y el rol de la IA
• Русский: PHP2Shell – критическая уязвимость PHP и роль ИИ

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert