CVE-2026-48356

What is Adobe Commerce and Magento?

Magento Open Source and its commercial sibling Adobe Commerce are among the most widely deployed self-hosted e-commerce platforms. A Magento store is a PHP application that owns the full purchase path: catalogue, cart, checkout, payment handoff, and the customer records behind it. Tens of thousands of merchants run one on their own infrastructure rather than on a hosted platform, which means the merchant, not a vendor, is responsible for patching it.

That makes Magento an unusually attractive target. Code execution on a storefront does not merely compromise a server; it puts the attacker in the page where customers type their card numbers. The entire Magecart ecosystem exists because of this: a JavaScript skimmer injected into checkout monetises immediately and quietly, often for months before anyone notices. Magento's REST API compounds the exposure, because several cart endpoints are deliberately unauthenticated so that guests can shop without an account.

Overview

CVE-2026-48356, named PolyShell by its discoverers, is an unrestricted file upload in the guest cart REST API. An unauthenticated attacker can add an item to a guest cart with a custom option of type "file", embed base64 file content in the request, and have the server write that content to disk under pub/media/custom_options/quote/ with an attacker-chosen name and extension. Where the web server is configured to execute PHP in that directory, the result is a web shell and full remote code execution as the web server user.

The attacker's file is a polyglot: it opens with a valid image header such as GIF89a so it satisfies the only check Magento applies, and ends in .php so the server runs it. Hence the name. The add-to-cart JSON response echoes the stored filename back, so the attacker does not even have to guess where the file landed.

The disclosure history is the reason this page is worth reading closely. Sansec published the PolyShell advisory on 2026-03-17, two days before the first in-the-wild attacks. Adobe fixed the flaw only in the 2.4.9 pre-release branch, shipping it on 2026-05-12, and did not backport to supported lines until APSB26-73 on 2026-07-14. For roughly four months, stores on 2.4.8 and earlier had no vendor patch while mass exploitation was underway. The APSB26-73 bulletin still carried Adobe's standard line that it was "not aware of any exploits in the wild", which was not the case for this issue.

Affected Versions

The July patches ship as isolated patch files that apply cleanly only on the exact latest patch level of each line, so merchants several patch levels behind must step forward first.

Technical Details

The CWE is CWE-434, unrestricted upload of file with dangerous type: the application accepts a file from an untrusted source without constraining what kind of file it is or what the server will do with it afterwards.

Two endpoints are reachable without a session: POST /rest/<store>/V1/guest-carts/{cartId}/items and PUT /rest/<store>/V1/guest-carts/{cartId}/items/{itemId}. A cart item may carry custom options, and an option of type "file" accepts a file_info object containing base64 data, a declared MIME type, and a filename. Three separate controls are missing from that path: the supplied option ID is not validated against the product, the option type is not gated, and the filename extension is not restricted. The only surviving control is an image header sniff, which a polyglot file passes trivially.

Whether this becomes code execution or merely a hostile file on disk depends on the web server. Common nginx and Apache configurations that pass .php under pub/media to the PHP handler turn it into unauthenticated RCE in a single request, with no chaining required. The CVSS vectors disagree on detail: NVD scores it 9.3 with UI:R and no availability impact, while Adobe scores it 9.6 with A:L. Both treat it as critical and neither requires privileges.

Discovery

The flaw was found and named by the Sansec Forensics Team, the e-commerce malware research group whose eComscan and Sansec Shield products monitor Magento installations. Sansec detected the probing on 2026-03-16 and published a public advisory on 2026-03-17 without a CVE identifier, before Adobe had a fix for production release lines. The CVE was assigned and published alongside the APSB26-73 backport on 2026-07-14; Adobe's bulletin acknowledgements do not credit a reporter for this entry. A detailed technical write-up with a working proof of concept was later published on GitHub by Abraxas Labs, derived from tracing the image validator and the guest-cart option file processor.

Exploitation Context

Exploitation is confirmed, large-scale, and has been continuous since March 2026. Sansec observed the first attacks on 2026-03-19, and on 2026-03-30 recorded 471 stores compromised within a single hour, which remains the clearest indication of how cheap and reliable the exploit is.

PolyShell is the entry vector for a long-running skimming campaign Sansec has tracked since July 2025, now covering 953 infected stores across five loader domains. The attack chain is consistent: upload a PHP web shell through the guest cart endpoint, drop accesson.php backdoors across multiple directories for persistence, then inject a JavaScript loader into Magento CMS blocks so the skimmer is served from the database rather than from a file, which defeats file-integrity scanners. The most recent loader domain, deepveindrilling.com, was registered on 2026-10-06 and appeared in the CMS blocks of 83 stores within days, 60 of which had already carried an earlier version of the loader.

Two findings deserve emphasis. First, the campaign operators were observed combining PolyShell with SessionReaper (CVE-2025-54236) against the same targets. Second, patched stores were still being infected: Sansec documented a store on 2.4.7-p10 with no missing core patches that was reinfected on 2026-10-23, where earlier forensics had turned up a rogue administrator account and a GSocket backdoor. Patching evicts nothing that is already resident. No nation-state actor has been attributed and no ransomware use has been reported; this is financially motivated card skimming.

Remediation

1. Apply APSB26-73. Move to the -2026-jul build for your release line (2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, 2.4.5-2026-jul, or 2.4.4-2026-jul), or upgrade to Magento 2.4.9. Note that the isolated patch applies only at the exact latest patch level of a line.
2. Until the patch is applied, block or filter POST and PUT requests to /rest/*/V1/guest-carts/*/items* carrying a file_info object at the WAF or reverse proxy.
3. Deny web access to pub/media/custom_options/ and ensure PHP cannot execute there. On nginx, place the deny rule before any PHP location block; on Apache, confirm the directory .htaccess both disables the PHP handler and denies access. This prevents execution but not the upload itself.
4. Hunt for uploaded shells: list every .php, .phtml, and .phar file under pub/media/custom_options/quote/ and the wider media tree, and search the whole document root for accesson.php.
5. Search CMS blocks and CMS pages in the database for script tags and external loader domains. A file-level scan will not find this layer, which is the point of the technique.
6. Audit the admin user table for accounts you cannot account for, check for GSocket or other reverse-shell persistence, and review integration tokens and cron entries.
7. If any indicator is found, treat the store as compromised: rotate the database password, admin credentials, API and integration tokens, and payment gateway keys, and follow your card-brand breach notification obligations.
8. Review web server access logs back to at least 2026-03-16 for guest-cart item requests with unusually large bodies, and for subsequent requests to files under pub/media/custom_options/.
9. Federal civilian agencies must remediate by 2026-11-10 under BOD 22-01.