PHP2Shell: what to do after a security flaw

On October 21, 2026, the PHP project fixed two critical flaws in its engine, known as PHP2Shell. The same week, OpenJDK published its quarterly security advisory and then a critical one. No technology is immune to flaws. Here is where they occur and the six steps to follow after they are announced, whatever your runtime.

PHP2Shell: what happened

On October 21, 2026, the PHP project released fixes for two vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619. A CVE is the public identifier of a flaw. Both are rated 9.2 out of 10 on CVSS v4.0.

Both are memory flaws. In the first, an out-of-memory condition leaves request data partly initialized. In the second, part of a request outlives the memory that held it (GHSA advisory). The advisory covers every PHP installation that handles web requests. The risk is highest with Apache and mod_php. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

On the Java side, OpenJDK published its quarterly advisory on October 20. It lists 47 CVEs and the highest is rated 7.0. On October 21, OpenJDK published a further advisory for CVE-2026-91403, rated 9.1. This flaw concerns eight compromised intermediate CA certificates in the TLS library.

If you run PHP, follow the official advisory and your national agency's alert: CISA in the United States and CERT-FR in France.

Why no platform is immune

A CMS is made of several layers of software. A flaw can affect any of them and each layer is fixed in its own way.

• The engine, or runtime. This software runs the CMS code. It is PHP or the Java Virtual Machine (JVM). PHP2Shell and CVE-2026-91403 affect this layer. You fix this type of flaw by updating the engine, whatever the CMS version.
• Libraries and frameworks. The CMS reuses these components. In December 2021, Log4Shell affected the Java library Log4j. In March 2022, CVE-2022-22965 allowed remote code execution in the Spring framework. You fix this type of flaw by updating the dependency.
• The application. This is the code of the CMS and its extensions. Their vendor publishes the fix.

Artificial intelligence speeds up the discovery of flaws. Wiz Research reports that a single researcher did in one week what would have taken a top team several months. The PHP Foundation reports the same trend. Its security team has published 15 CVEs since July 1 and handled more than 100 reports that were invalid, duplicates or not reproducible.

What to do after a flaw: six steps

These six steps apply to PHP2Shell and to the next flaws, whatever the runtime.

1. Read the official sources. The advisory from the project or vendor and your national agency's alert are the reference. They list the affected versions, the fixed versions and the most exposed configurations.
2. Take stock of what you run. In its alert, CISA asks organizations to inventory every PHP instance, including those embedded in other software. Do the same for a JVM shipped with a product.
3. Patch the layer where the vulnerability lives: the engine, a library, or the application. An up-to-date application on a vulnerable engine is still exposed, and a patched engine can’t protect a vulnerable application.
4. Fix the critical systems first. Apply the fixed versions listed in the advisory, starting with systems reachable from the internet. If you cannot patch right away, follow your national agency's guidance.
5. Know who patches and how fast. The vendor, the hosting provider and your team each have a role. Write this split down before the next flaw, with a target time between the announcement and the fix.
6. Prepare for the next flaw. Follow the support calendar of your versions. A branch at the end of its life receives no more fixes. Each PHP branch gets two years of active support and then two years of security fixes. PHP 8.2 will receive no more fixes after December 31, 2026. OpenJDK publishes its fixes in January, April, July and October. After the crisis, write down what slowed the fix.

Questions to ask your CMS vendor and hosting provider

Ask these questions before the next flaw. Ask every vendor the same ones to compare the answers.

• Which runtime and CMS versions do you support, and until when?
• Who applies the patches, and how soon after a flaw is announced?
• Where do you publish your security advisories?
• How do we report a vulnerability to you?
• How quickly can you tell whether a new flaw affects us?

Our article on software security for your CMS covers the best practices in detail.

The PHP Foundation's response

On October 21, the PHP Foundation published a post on the cause of the delay. An external security audit found the first signs of the problem in 2024. No concrete attack vector was known at the time. Several fixes were developed and the work stalled and restarted for months.

The Foundation calls this delay "a structural failure". It attributes it to its security team's decision process and its lack of resources. The team is "a small group of foundation-funded developers and a little volunteer help". The Foundation has started changing its processes.

What about Jahia?

Jahia is a Java CMS. It runs on the JVM in a servlet container, Apache Tomcat by default (Jahia Academy). We maintain a Java CMS, and we publish security fixes too. Our Trust Center states that Jahia scans its code continuously and releases security fixes on a regular basis. You can report a vulnerability to security@jahia.com.

A word for the teams who patch

Patching a critical flaw in the middle of the week is demanding work, and it is rarely seen. The teams who do it, whatever their runtime, have our full support.

FAQ