Magento CVE-2026-48356 (PolyShell): Patch and Hunt

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

Vulnerability ManagementIncident ResponsePhpFile UploadRemote Code Execution