CVE-2026-48356 is the Magento file-upload flaw that Sansec calls PolyShell, and it is now on CISA’s Known Exploited Vulnerabilities catalog (added October 27, 2026; federal due date November 10). Adobe shipped the fix in APSB26-73 on July 14, 2026. If your store is not on a 2026-jul build, update now. If it was exposed for any time since March, hunt as well. Attackers have used the flaw to plant webshells and to inject JavaScript loaders into CMS blocks, and an update removes neither.

What is affected and what fixes it

The table comes from Adobe’s CVE record and the APSB26-73 solution table, which agree on the fixed builds.

Two details matter here.

2.4.9 is listed as affected. Sansec’s PolyShell write-up says Adobe released the fix in 2.4.9 on May 12, 2026, and backported it to the supported release lines through APSB26-73 on July 14. Adobe’s CVE record, however, lists 2.4.9 among the affected versions and 2.4.9-2026-jul as unaffected. We have not diffed the two releases, so we can’t say which is right. The safe reading is Adobe’s: move to 2.4.9-2026-jul.

Older Open Source lines are not listed at all. Adobe lists 2.4.4 and 2.4.5 2026-jul builds only for Adobe Commerce. For Magento Open Source 2.4.5 and older, the record names neither an affected nor a fixed version. Don’t read that as safe: Sansec says every version up to 2.4.9-alpha2 is affected. If you run one of those lines, plan an upgrade and treat the server-side mitigations below as essential in the meantime.

Check what you run with bin/magento --version or composer show magento/product-community-edition (magento/product-enterprise-edition for Commerce), and compare the result with the table.

How PolyShell works

Sansec describes the flaw in the REST API’s handling of file uploads for cart item custom options, where a product option has type “file”. The most exposed routes are the unauthenticated guest-cart ones:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Uploaded files are written to pub/media/custom_options/quote/. Sansec says the GraphQL mutations use a different code path and are not vulnerable.

What an upload leads to depends on the server. Sansec lists code execution through an uploaded PHP file for Apache before 2.3.5 without php_flag engine 0, for stock nginx configs on 2.0.0 to 2.2.x, and for any nginx config that passes every .php request to PHP-FPM. Stored XSS is possible on versions before 2.3.5 and on custom web server configurations.

Adobe describes the same CVE differently. The CVE record says exploitation “requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page” and scores it CVSS 3.1 9.3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N). The regional copy of the bulletin we read shows 9.6 with A:L and labels the impact “Privilege escalation”. We report both; neither changes the action. A KEV listing outranks the UI:R in the vector. Our CVSS vs EPSS vs KEV guide explains why.

What attackers have done with it

Sansec reported a mass wave on March 30, 2026: 471 stores compromised in one hour, with a backdoor named accesson.php dropped across multiple directories and loaders injected into CMS pages and static blocks. That was months before Adobe’s July backport.

On October 26, The Hacker News reported Sansec’s findings on a longer campaign: 953 stores infected since July 2025 with a JavaScript loader stored in Magento’s cms_block table. Per that report, Sansec attributes 471 of those infections to CVE-2026-48356, and about 102 more to file uploads through PolyShell or CVE-2025-54236 (SessionReaper). One store on 2.4.7-p10 with no missing core patches was compromised through a rogue administrator account. The report also describes webshells disguised as PNG files in pub/media/custom_options/quote/. The loader’s final payload is not known.

These figures are Sansec’s, as reported by The Hacker News. CISA’s catalog entry does not say who is exploiting the flaw, and lists known ransomware use as “Unknown”.

Step 1: Install the fixed build

Update to the 2026-jul build for your release line, then redeploy static content and clear caches as your normal release process requires. If you can’t update this week, do steps 2 and 3 now anyway: they limit what a successful upload can do and tell you whether one has already happened.

Sansec suggests a WAF rule that blocks the vulnerable API calls. That buys time, but it is a mitigation, not a fix.

Step 2: Make sure uploads can’t be served or executed

Magento ships deny rules for this directory. Check that your live config still has them.

nginx. The stock nginx.conf.sample in the 2.4-develop branch denies the directory and only hands named entry points to PHP. These are excerpts from that file, not a complete config:

location /media/custom_options/ {
    deny all;
}

location ~ ^/(index|get|static|errors/report|errors/404|errors/503|health_check)\.php$ {
    # ... fastcgi_pass to PHP-FPM ...
}

# Banned locations (only reached if the earlier PHP entry point regexes don't match)
location ~* (\.php$|\.phtml$|\.htaccess$|\.htpasswd$|\.git) {
    deny all;
}

The risky pattern is a hand-written or hosting-panel config with a generic location ~ \.php$ { fastcgi_pass ...; } and no deny for /media/custom_options/. With that, a PHP file uploaded to the directory is executed. Sansec recommends a deny all location for custom_options placed before any \.php$ block.

Apache. The repository ships pub/media/custom_options/.htaccess containing Require all denied (Apache 2.4) or deny from all (older). Confirm it exists on disk and that AllowOverride lets Apache read it. Sansec also recommends php_flag engine 0 there.

Neither rule stops the upload. Both stop the uploaded file from being fetched or run through the web server.

Step 3: Hunt for an existing compromise

Run these from the Magento root, or adjust the paths. Sansec published the first checks; we added the database queries.

Files in the upload directory. Customer uploads can be legitimate, but any script file there is a strong sign of compromise:

# Everything uploaded through custom options, newest first
find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n' | sort -r | head -50

# Script extensions there are a red flag
find pub/media/custom_options/ -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \)

# The backdoor name from the March wave, anywhere in the docroot tree
find /var/www -name 'accesson.php' -type f

The October report describes webshells disguised as .png. A PNG that starts with <?php is not an image. Check with file or head -c 64 on anything recent in that directory.

Injected scripts in CMS content. The loader lives in the database, so file scans miss it. Run this against a replica or read-only connection (add your table prefix if you use one):

SELECT 'block' AS kind, block_id AS id, identifier, update_time
FROM cms_block
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
UNION ALL
SELECT 'page', page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
ORDER BY update_time DESC;

Column names come from Magento’s Cms module schema; we checked the query’s syntax against a small SQLite copy of those tables, not against a live MySQL store. Many stores have legitimate scripts in CMS blocks, so review hits by update_time and by where the script loads from. The October report lists these loader domains: manulfie[.]click, neswnsssn[.]click, lanhd6549tdhse[.]top, additionalver[.]com and deepveindrilling[.]com. Sansec’s March write-up adds jslibrary[.]net and canevaslab[.]com. Add any you want to the LIKE list.

Admin accounts you didn’t create. One store in the October report was compromised through a rogue admin:

SELECT user_id, username, email, created, logdate, is_active
FROM admin_user
WHERE created >= '2026-03-01'
ORDER BY created DESC;

Web logs. Look for requests to the guest-cart item routes, which usually sit under /rest/V1/ or /rest/<store_code>/V1/:

grep -E '"(POST|PUT) /rest/([a-z0-9_]+/)?V1/guest-carts/[^/ ]+/items' /var/log/nginx/access.log* | head

Headless storefronts call these routes legitimately, so a hit is not proof. Line up timestamps with new files in pub/media/custom_options/quote/ and with cms_block updates.

If you find a webshell or an injected loader, treat the store as compromised. Remove the artifacts, rotate admin, database and integration credentials, check for other persistence (cron, other PHP files, modified app/etc/env.php), and consider your payment-card obligations, since these loaders run in shoppers’ browsers. Our PHP2Shell response guide covers the server-side hunt for PHP webshells in more detail.

Hardening after the patch

• Keep pub/ as the document root and let PHP run only for Magento’s named entry points. Sansec’s RCE conditions are old releases or web server configs that execute PHP files in upload directories.
• Turn off PHP execution in every writable media directory, not just this one. Our php.ini hardening guide covers related settings.
• If you don’t use file-type custom options, Sansec’s WAF suggestion is cheap: block file uploads to the guest-cart item routes.
• Monitor cms_block and cms_page for changes. A loader injected through the database survives code deploys.

Limits of this article

We did not reproduce the exploit or diff the patched releases. Affected and fixed versions come from Adobe’s CVE record and bulletin. The upload mechanics, server conditions and campaign figures come from Sansec, the latter through The Hacker News. The adobe.com/trust copy of APSB26-73 could not be retrieved during research; we used Adobe’s regional helpx copy, which shows “Last updated on 14 July 2026” and may not reflect later revisions. We ran the find and grep commands against a mock directory tree and sample log lines, and the SQL against SQLite, not against a production store.

Sources and verification

CVE-2026-111497 is a memory-corruption bug in Google’s Brotli decompressor. Upstream versions 1.0.3 through 1.2.0 are affected, and 1.0.10, 1.1.1 and 1.2.1 fix it. CISA added it to the Known Exploited Vulnerabilities catalog on October 27, 2026, with a federal remediation date of November 10. The hard part is not the patch. Brotli is compiled into Node.js, Python wheels, Go modules, proxies and service meshes, and several patched builds still report the old version number. Here is where it hides, what “fixed” looks like for each, and a tested way to check code you vendor yourself.

Are you affected?

You are exposed if a vulnerable Brotli decoder processes data an attacker can supply. The CVE record says an attacker with “a crafted Brotli-compressed stream” can “corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code”. Google’s CNA scored it CVSS 4.0 9.2 (Critical). The Node.js project rates its copy High.

The Envoy, Istio and Bun ranges come from Wiz’s write-up, not from those projects’ advisories. We did not read those advisories directly. For Envoy we checked the source instead: bazel/repository_locations.bzl pins Brotli 1.2.0 at tag v1.39.2, while v1.39.3 pins a Brotli commit whose decode.c contains the fix.

Linux distributions usually backport fixes and keep the upstream version. Our Ubuntu 24.04 sandbox, for example, has libbrotli1 1.1.0-2ubuntu0.1. That string alone does not tell you whether the fix is in. Use your distribution’s security tracker for the CVE.

Why the version string can mislead you

Node.js patched its bundled Brotli in place. On the fixed Node.js 22.23.4 the reported library version is still the old one:

$ node -v
v22.23.4
$ node -p process.versions.brotli
1.1.0

We ran that in our sandbox. The source tree agrees: deps/brotli/c/common/version.h declares 1.1.0 at both v22.23.3 and v22.23.4, and 1.2.0 at v24.22.1 and v26.12.1, but only the fixed tags contain the patched decoder (v22.23.3 and v24.22.0 do not). A scanner that flags process.versions.brotli < 1.2.1 will raise false positives on fixed Node.js. A scanner that trusts a vendored version.h can miss real exposure the other way round. For Node.js, use the Node.js version. For anything else you vendor, check the code.

What the bug is

The Node.js advisory gives the clearest description: “An invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer.”

The upstream diff between v1.2.0 and v1.2.1 of c/dec/decode.c shows exactly that. DecodeBlockTypeAndLength() used to return a plain boolean, so “invalid stream” and “need more input” looked the same, and the non-safe callers ignored the result altogether (static void DecodeLiteralBlockSwitch(...)). After the fix the function returns a BrotliDecoderErrorCode, emits BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH for the invalid case, and every caller checks it through a new BROTLI_SAFE_WITH_STATUS macro. That matches the two weaknesses in the CVE record: CWE-252 (unchecked return value) and CWE-787 (out-of-bounds write).

The flaw was found by Khai Tran and Sylvie Mayer of OpenAI Codex Security, who are credited in both the CVE record and the Node.js advisory.

Where untrusted Brotli reaches your code

The flaw is in decompression, so look for places that decode data you did not produce:

• Request bodies. Any endpoint or middleware that inflates Content-Encoding: br uploads.
• Outbound HTTP. HTTP clients decode Brotli responses for you. If an attacker controls or can redirect the URL (webhooks, link previews, feed fetchers, scrapers), they control the compressed bytes.
• Files and archives that contain Brotli streams.
• Proxies and meshes that decompress traffic to inspect or transform it.

Two behaviours we checked, because they mean code that never mentions Brotli can still run it:

• Node.js fetch() decodes Brotli it never asked for. On Node.js 22.23.4, fetch() sent accept-encoding: gzip, deflate. When our local test server replied with content-encoding: br, fetch() decompressed the body anyway. A hostile server can choose Brotli whatever the client advertises.
• Python’s requests turns Brotli on when it is installed. urllib3’s util/request.py appends br to its default Accept-Encoding when brotlicffi or brotli can be imported. With Brotli 1.2.1 installed, requests.utils.default_headers() returned gzip, deflate, br in our test. The decoding then runs in whichever Brotli package is installed.

What to do now

1. Update the runtimes. Node.js to 22.23.4, 24.22.1 or 26.12.1 or later. Move off end-of-life Node.js lines: the advisory notes that “End-of-Life versions are always affected when a security release occurs.”
2. Update language packages in every lockfile and image: Brotli>=1.2.1, brotlicffi>=1.2.1.0, github.com/andybalholm/brotli v1.2.7. Both Python fixes were published to PyPI on October 22, 2026.
3. Update proxies and meshes (Envoy, Istio) and Bun to the fixed releases above. Confirm the ranges against each project’s own advisory.
4. Apply distro updates for libbrotli/brotli, then restart the long-running processes that loaded the old library.
5. Rebuild container images. A fixed base image does not help a running container that was built from the old one.
6. Hunt for vendored copies with the check below.

If you cannot patch a service today, reduce what it decodes. As a stopgap, reject Content-Encoding: br request bodies at the edge for services that do not need them, and stop server-side fetchers from decoding responses from untrusted URLs. This is our editorial suggestion, not vendor guidance, and it does not replace the update.

Inventory commands

# Node.js: the version that matters
node -v

# Python: every environment and image
pip show Brotli brotlicffi 2>/dev/null | grep -E '^(Name|Version)'
pipdeptree -r -p Brotli          # who pulls it in

# Go modules
go list -m all | grep andybalholm/brotli

# Debian/Ubuntu and RHEL-family system libraries
dpkg -l 'libbrotli*' 2>/dev/null | awk '/^ii/{print $2, $3}'
rpm -q brotli libbrotli 2>/dev/null

The pip, node and dpkg lines were run in our sandbox. The go, pipdeptree and rpm lines are standard tool usage that we did not run here.

Checking vendored source for the fix

C and C++ projects often copy c/dec/decode.c into their tree, and Go programs carry decode.go in the module cache or a vendor/ directory. This script looks for the patched function signature instead of trusting any version string:

#!/bin/sh
# brotli-fixcheck.sh DIR...: find vendored Brotli decoder sources and report
# whether they carry the CVE-2026-111497 fix. Looks at the code, not the
# version string, because patched Node.js still reports the old version.
for root in "$@"; do
  find "$root" \( -name decode.c -path '*dec*' \) -o \( -name decode.go -path '*brotli*' \) 2>/dev/null |
  while read -r f; do
    if grep -q 'BrotliDecoderErrorCode DecodeBlockTypeAndLength' "$f" ||
       grep -q 'func decodeBlockTypeAndLength(.*) int {' "$f"; then
      echo "PATCHED    $f"
    elif grep -q 'DecodeBlockTypeAndLength\|decodeBlockTypeAndLength' "$f"; then
      echo "VULNERABLE $f"
    fi
  done
done

We tested it against 12 sources pulled from GitHub: upstream Brotli v1.0.9, v1.0.10, v1.1.0, v1.1.1, v1.2.0 and v1.2.1; Node.js deps/brotli at v22.23.3, v22.23.4, v24.22.0 and v24.22.1; and andybalholm/brotli v1.2.6 and v1.2.7. It reported every fixed release as PATCHED and every earlier one as VULNERABLE. Run it over source trees, vendor/ directories and $(go env GOMODCACHE).

It cannot inspect compiled binaries, and a heavily modified fork may not match either pattern. Treat “no output” as “no recognisable copy found”, not as “safe”.

What to hunt for

No vendor or agency has published indicators of compromise for this CVE, and CISA’s KEV entry does not require forensic triage (forensicTriage: No). Practical checks:

• Crashes. Segfaults or aborts in Node.js, Python or proxy processes since late October, especially in services that fetch remote content or accept compressed uploads.
• Unexpected Brotli. Requests with Content-Encoding: br to endpoints that never receive compressed bodies. Wiz recommends reviewing WAF, application and network logs for suspicious Brotli-compressed traffic.
• Outbound fetches from services that took user-supplied URLs, close in time to a crash.

Limits of this article

We did not reproduce the memory corruption or test any exploit. Our checks cover version strings, source code and HTTP client behaviour in a sandbox: Node.js 22.23.4, Python with Brotli 1.2.1, Ubuntu 24.04. The Envoy, Istio and Bun ranges come from a security vendor’s summary. The list of affected software is not complete. Wiz notes that other products that bundle or link vulnerable versions of the Brotli C decoder may also be affected.

For the wider process of keeping dependency updates moving, see dependency audits without slowing down releases. For publishing or reading “not affected” statements about a library like this, see VEX explained. Last week’s PHP2Shell patch-and-hunt guide covers the two PHP runtime flaws CISA added to KEV the day before.

Sources and verification

CVE-2026-109618 and CVE-2026-109619, which the security community has nicknamed “PHP2Shell”, are two memory-safety flaws in PHP’s core that can give an unauthenticated attacker remote code execution on a server running PHP for the web. The fixes are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 26, 2026, and gave federal agencies until October 29 to act.

These are bugs in the PHP interpreter, so they apply regardless of your framework or CMS. If you run PHP behind a web server, update the PHP package today, restart every PHP worker, then look for signs that someone got in first. Everything below comes from the PHP project’s advisory and CVE records and CISA’s KEV entry unless we say otherwise.

Are you affected?

The CVE records list PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12 as affected. PHP’s advisory adds who is at risk: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” It rates mod_php highest, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

The CVE records only list 8.2 to 8.5. Do not read that as “8.1 is safe”: PHP says 8.1 and older “no longer receive updates” and published source backports for 7.4, 8.0 and 8.1 because of the severity.

Why php -v can mislead you

Most production PHP comes from a distribution or a container base image, and those vendors backport fixes without changing the upstream version number. PHP says Linux distributions and LTS vendors “received the patches in advance”.

We checked an Ubuntu 24.04 host. php -v reports 8.3.6, which is far below 8.3.36, yet the package changelog shows the fix:

$ dpkg -l php8.3-cli | tail -1 | awk '{print $2, $3}'
php8.3-cli 8.3.6-0ubuntu0.24.04.13
$ zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | head -4
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via

So for a distribution build, search the package changelog for the CVE IDs. On Debian or Ubuntu, zcat /usr/share/doc/php*-common/changelog.Debian.gz | grep -m1 CVE-2026-109618 works; on RPM-based systems the equivalent is rpm -q --changelog <php package> | grep CVE-2026-109618 (illustrative; we did not run the RPM form). For official php Docker images and source builds, the upstream version is the one that counts.

Also check the binary that actually serves traffic. The CLI, php-fpm and libapache2-mod-php can come from different packages and be updated at different times.

A version check for upstream builds

This script compares upstream version strings against the fixed releases. We ran it with PHP 8.3 CLI (php php2shell-check.php 8.2.34 8.4.27 8.1.31). It cannot see distribution backports, so a “VULNERABLE” result on a distro build means “check the changelog”, not “definitely exposed”.

<?php
// Compares upstream PHP versions with the fixed releases for
// CVE-2026-109618 / CVE-2026-109619. Does not detect vendor backports.
$fixed = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];

function status(string $v, array $fixed): string {
    $branch = implode('.', array_slice(explode('.', $v), 0, 2));
    if (!isset($fixed[$branch])) {
        return version_compare($v, '8.2', '<')
            ? 'END OF LIFE: no upstream fix; needs vendor backport or upgrade'
            : 'UNKNOWN branch: check php.net';
    }
    return version_compare($v, $fixed[$branch], '>=')
        ? "fixed upstream (>= {$fixed[$branch]})"
        : "VULNERABLE upstream (< {$fixed[$branch]}) unless your vendor backported the fix";
}

foreach (array_slice($argv, 1) ?: [PHP_VERSION] as $v) {
    printf("%-10s %s\n", $v, status($v, $fixed));
}

$ php php2shell-check.php 8.2.34 8.4.27 8.1.31
8.2.34     VULNERABLE upstream (< 8.2.35) unless your vendor backported the fix
8.4.27     fixed upstream (>= 8.4.27)
8.1.31     END OF LIFE: no upstream fix; needs vendor backport or upgrade

What the two flaws do

Both bugs leave PHP’s internal request state inconsistent and let later code trust it.

• CVE-2026-109618, “RCE via OOM corruption”. The CVE record says PHP “uses longjmp() for out-of-memory (OOM) errors to exit the current context”. Some code paths “leave request memory in an uninitialized state before performing an allocation”, and “the subsequent request cleanup procedure may read or branch on this memory.” An attacker who can push a request into an out-of-memory failure at the right moment can trigger it.
• CVE-2026-109619, “RCE via stale global state”. Global state that “temporarily points into request memory” may not be reset, so it “may refer to request memory even after it has been freed.” PHP’s advisory explains the consequence: “A later request handled by the same worker may use that stale state before normal initialization resets it.”

Both carry a CVSS v4.0 base score of 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H): network-reachable, no privileges, no user interaction, but high attack complexity with attack requirements present. If you want to decode the vector, see our guide to reading a CVSS v4.0 vector string. The fix shipped in all four branches as one change, described in PHP’s NEWS file as “Avoid state corruption via bailout”.

Credits in the CVE records name Wiz, Ryan at Calif.io and OpenAI as reporters or finders.

Exploitation status

The public picture is mixed, so here is what each source says:

CISA’s Vulnrichment SSVC entry in the CVE records, dated October 21, still says Exploitation: none. That predates the KEV listing. For how these signals usually relate, see CVSS vs EPSS vs KEV.

Our reading: mass scanning started within hours, working exploits exist, and CISA has listed both as exploited. Whether specific attacks succeeded against production servers is not yet established in public sources. That uncertainty is a reason to hunt after patching, not a reason to wait.

What to do now

1. Inventory. Find every PHP runtime that serves HTTP: VMs, containers, base images, appliances with embedded PHP, and managed hosting. Container images need a rebuild and redeploy; patching the host does nothing for them.
2. Update. Move to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or your vendor’s patched package. For 8.1 and older, use a vendor backport or upgrade. PHP 8.2 itself reaches end of life on December 31, 2026, according to PHP’s release notes, so plan that upgrade too.
3. Restart every worker. CVE-2026-109619 is about state that persists across requests in the same worker. Restart PHP-FPM pools, Apache (for mod_php) and any long-running PHP servers after the package update.
4. Prioritise internet-facing mod_php, then FPM behind public web servers, then internal applications.

If you cannot update today

PHP lists stopgaps and is explicit that “only an update is a complete solution” and these “do not make an installation safe”:

; php.ini or FPM pool config, applied before request parsing, then restart workers.
; Illustrative: check each value against your application's needs.

; CVE-2026-109618 (OOM corruption)
; In an FPM pool use php_admin_value[memory_limit] = -1 so applications can't override it.
memory_limit = -1
; 8M if the app takes no uploads, 32M if it needs them; keep upload_max_filesize below it
post_max_size = 8M
upload_max_filesize = 2M

; CVE-2026-109619 (stale global state)
session.upload_progress.enabled = 0
; PHP 8.5 only:
; fatal_error_backtraces = 0

The reasoning behind each, from the advisory:

• memory_limit=-1 “removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.” With no PHP memory limit, a container or cgroup memory limit becomes your availability boundary. PHP warns: “Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.”
• Low post_max_size, plus limits at the web server or proxy on decoded request size, field count, multipart part count, header count and nesting depth. These “must also cover requests without a usable Content-Length.”
• session.upload_progress.enabled=0 “blocks the confirmed session paths but not other variants”. Set it in php.ini, the FPM pool or server config; PHP says “Do not rely on ini_set() or FPM .user.ini.”
• Hiding errors does not help: “Hiding diagnostics with error_reporting, display_errors or @ does not help.”

php_admin_value matters here because, per the PHP-FPM documentation, “Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set.”

What to hunt for after patching

Patching removes the bug, not an attacker who already used it. Preserve web server and PHP logs before you rotate or rebuild anything. The indicators below come from VulnCheck’s published honeypot observations. They describe scanners and one attempt; real attackers can change every one of them.

• User agents: php2shell-scan/109618, php2shell-verify/1.0, Mozilla/5.0 (php2shell-poc).
• Requests: multipart POSTs to /index.php that upload two files named a and b through the upload-progress path; follow-up GET requests using php://filter to read a session file.
• Session files containing PHP code. The attempt VulnCheck saw tried to plant a webshell through a session file, with a payload that prints PWNED::. A legitimate PHP session file contains serialized data, never <?php.

Two checks you can run on a Linux host. We tested both against sample files; adjust paths to your log format and to the session.save_path of the pool that serves traffic (php -i shows the CLI’s value, not necessarily FPM’s):

# Web logs: known scanner user agents and php://filter reads
grep -hE 'php2shell|php://filter' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

# Session files that contain PHP code or the test marker
grep -lE '<\?php|PWNED::' /var/lib/php/sessions/sess_* 2>/dev/null

Then do the usual post-compromise checks for a web server: new or changed .php files under the document root since October 17, unexpected child processes of the PHP worker or web server user (shells, curl, wget), and outbound connections from web hosts. Our guide to logging for incidents covers which of these you will wish you had recorded.

Federal agencies have to follow CISA’s forensic triage requirements for this KEV entry. If you want to borrow that process, our explainer on CISA BOD 26-04 covers it.

Limits of this article

We have not read the full GitHub security advisories, which PHP says contain the technical details; they were not reachable from our research environment. Exploitation reporting comes from vendors and press summaries we cite, not from our own telemetry. The hunting indicators come from one vendor’s honeypots and will not catch a modified attack. Exposure counts published by vendors differ widely, so we have not repeated them.

Sources and verification