PHP2Shell (CVE-2026-109618, CVE-2026-109619): CISO Assistant is not affected

Several customers have asked us about PHP2Shell, the pair of critical PHP vulnerabilities disclosed on October 21, 2026. The short answer: CISO Assistant is not affected, because it contains no PHP. This post explains the vulnerabilities briefly, why we are not exposed, and what we recommend if you run PHP elsewhere in your environment.

What PHP2Shell is

PHP2Shell is the name given to two flaws in the PHP interpreter itself, not in a framework or a CMS. Both are rated 9.2 (CVSS v4.0) by the PHP project and can lead to unauthenticated remote code execution:

• CVE-2026-109618: when memory runs out while PHP is still setting up a request, the cleanup that follows treats half-initialised data as valid. A crafted POST request can turn that into code execution.
• CVE-2026-109619: a use-after-free. State left over from one request can be reused by a later request on the same worker. Memory disclosure is a confirmed impact, and the upload-processing path is exploitable on mod_php and PHP-FPM.

Three points make this one serious:

• Every web-facing PHP setup is in scope: Apache mod_php (the highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.
• Application authentication does not help. PHP parses the request before your application code runs, so a login page in front of the app does not stop the exploit.
• It is already exploited. The identifiers leaked on October 20, and PHP moved its release forward by a day. Amazon saw exploitation attempts from October 17, before disclosure, and several vendors now report active, untargeted scanning.

Why CISO Assistant is not affected

CISO Assistant does not contain or run PHP, in any edition or deployment mode:

• The backend is Python (Django), built on a Python base image.
• The frontend is SvelteKit, running on Node.js.
• The other services in the standard deployment are Caddy (reverse proxy, written in Go), PostgreSQL, and optionally Qdrant for the AI features and our MCP server.

The public repository contains no PHP source files and no Composer manifest, and none of our container images installs a PHP interpreter. This applies to Community, Pro on-premises and our SaaS, which run the same images. Our website, intuitem.com, is built with Astro and served by Cloudflare, also without PHP.

No action is needed on your CISO Assistant instances.

If you run PHP elsewhere

PHP is everywhere: WordPress, Drupal, Nextcloud, GLPI, Moodle, Matomo, phpMyAdmin, and many internal tools. If any of them are reachable over HTTP, treat this as urgent.

1. Find your PHP runtimes

Inventory every place PHP serves web requests: hosts, containers, and appliances or applications that bundle their own interpreter. The command-line php -v can report a different version from the one your web server uses, so check the web runtime itself.

2. Patch

Patching is the only complete fix. The first fixed releases, published on October 21, are:

For 7.4 to 8.1, PHP published source backports but no official releases; check your distribution or LTS vendor. Linux distributions sometimes backport fixes without changing the version number, so read their advisories rather than relying on version numbers alone. Versions 7.3 and older are end-of-life and will not be fixed: plan an upgrade. Restart every PHP worker after updating.

3. Mitigate until you can patch

These settings block the known exploitation paths. They reduce the risk but do not remove it:

• CVE-2026-109618: set memory_limit=-1 at the administrator level, so applications cannot override it, and cap memory at the container or cgroup level so a single request cannot exhaust the host. Do not use RLIMIT_AS or RLIMIT_DATA for this: they can cause the very allocation failures the exploit relies on.
• CVE-2026-109619: set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0.
• Put these in configuration that loads before PHP parses the request (php.ini or the FPM pool, not .htaccess or ini_set()), then restart all workers.
• Limit request bodies at the reverse proxy or load balancer, including requests without a usable Content-Length header.
• Take internet-facing PHP applications off the public network where you can, as CERT-EU recommends, or put them behind a VPN or an access proxy until they are patched.

4. WAF rules

A WAF buys time but is not a fix. Cloudflare has deployed managed rules for the known exploit vectors for all its customers, including the free plan, and other WAF vendors are following. These rules only protect traffic that goes through the WAF, so check that nothing reaches the origin directly. If you write your own rules, flag application/x-www-form-urlencoded POST requests with unusually long field names (the public exploit uses a single field name of about 3.5 MB) or null bytes in field names, and make sure your inspection engine does not skip large bodies.

5. Look for signs of compromise

Start from October 17, not the disclosure date. Useful signals:

• Allowed memory size of ... bytes exhausted errors pointing to Unknown on line 0, which means the failure happened while PHP was still reading the request.
• Segmentation faults in web workers (for example AH00052 ... exit signal Segmentation fault).
• A web server or PHP worker starting a shell (apache2 or php-fpm spawning sh). This is the strongest sign.

A successful exploit can return HTTP 200 and leave the worker running, so a clean access log does not prove that nothing happened.

References

• PHP2Shell FAQ (Tenable)
• Detection, analysis and remediation (Datadog Security Labs)
• Exploitation observed in the wild (watchTowr)
• Technical analysis (JFrog Security Research)

If you have questions about your CISO Assistant deployment, contact us.