· Magento · 3 min read
PolyShell (CVE-2026-48356): is your Magento store patched?
PolyShell lets anyone upload PHP files to a Magento store through the REST API. Who is affected, the July 2026 patch, how to look for a backdoor, and what to do in order.

By Kompilo
In March 2026 the security firm Sansec disclosed PolyShell: a flaw that lets anyone upload files to a Magento or Adobe Commerce store through the REST API, without logging in. Within days it was used in mass attacks. If your store is not on a patched release yet, here is what to check and what to do.
What PolyShell is
Magento lets a shopper attach a file to a product option in the cart. PolyShell abuses that route: with two guest-cart API calls, an attacker uploads a file that looks like an image but contains PHP code, a so-called polyglot. Magento only checks that the file looks like an image, so it is saved under pub/media/custom_options/. On a server that runs PHP files from that folder, the upload becomes a web shell: full control of the store.
It is tracked as CVE-2026-48356, and Sansec found that the vulnerable code has been in Magento since the first 2.0 release. GraphQL uses a different code path and is not affected.
How widely it was exploited
Sansec’s own figures from the stores it monitors:
- First attacks in the wild on 19 March 2026, two days after the disclosure.
- By 24 March, 56.7% of the stores had a malicious PHP file uploaded.
- By 14 April, 82% of the stores had been hit with malicious uploads.
Many of those uploads never ran, because a correctly set up server does not execute PHP from the media folder. But the file stays on disk, and one wrong server rule later is enough to turn it into a backdoor.
Is your store patched?
- Magento 2.4.9 includes the fix, according to Sansec.
- For older release lines, Sansec reports that Adobe backported the fix in its July 2026 security update, APSB26-73 (14 July).
- Adobe ships that update as isolated patches for 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18. You have to be on that latest -p release of your line before you apply it.
- Magento Open Source can download these patches only for 2.4.6 and later. On older Open Source versions, the way out is an upgrade.
- On Adobe Commerce Cloud, the latest cloud-patches update contains the fix. Adobe warns not to apply the isolated patch on top of it.
Look for a backdoor today
A patch stops new uploads; it does not remove files that arrived before it. On the server, check:
- The folder pub/media/custom_options/. Anything other than its .htaccess, and above all .php, .phtml or .phar files, is a strong sign of an attack.
- Files named accesson.php anywhere in the Magento folder. Sansec found this backdoor in assets/images folders placed under var, lib, app, vendor, pub and other top-level folders.
- CMS pages and static blocks for script tags you did not add. Sansec lists the domains it saw in these injections.
If you find something, treat the store as compromised: keep a copy as evidence, remove the files, change the admin, database and API passwords, and look for other changes before you call it clean.
What to do, in order
- 01Block the API call itself with a web application firewall rule. Sansec’s point: only a rule that blocks the upload request stops the attack.
- 02Make sure the upload folder can never run code. On nginx, deny pub/media/custom_options/ in a location block placed before any .php block. On Apache, keep the .htaccess in that folder that turns the PHP engine off and denies access.
- 03Patch: upgrade to 2.4.9, or apply the July 2026 isolated patch for your release line after updating to its latest -p release.
- 04Watch for new files: file-integrity monitoring on the Magento folder flags a new PHP file on the day it appears.
A blocked upload is still a file on your server. Check first, then patch.
Where to start
If you are not sure which patch level you are on, or whether the files in your media folders belong there, our free audit checks your version, missing security patches and the upload folders, and tells you what to fix first.
Sources: Sansec’s PolyShell research (17 March 2026, updated in May and July), Adobe’s knowledge-base article on APSB26-73, and Akamai’s analysis (27 March 2026). Advisories change; check them before you act.