Is my Magento or Adobe Commerce store exposed to PolyShell (CVE-2026-48356), and what should I do?
CVE-2026-48356 is an unauthenticated unrestricted file upload flaw in Adobe Commerce, Magento Open Source, Adobe Commerce B2B and Adobe Commerce Events, nicknamed PolyShell in public research. Adobe fixed it in security bulletin APSB26-73 on 14 July 2026, and CISA added it to its Known Exploited Vulnerabilities catalogue on 27 October 2026. There is no new Composer release: apply Adobe's July 2026 isolated patch for your release line, stop PHP running in pub/media, and hunt for web shells and card skimmers.
Added to CISA KEV on 27 Oct 2026
CISA lists CVE-2026-48356 in its Known Exploited Vulnerabilities catalogue, which means it has evidence of exploitation. Its 10 November 2026 due date applies only to US federal agencies under BOD 26-04. It is not a UK deadline, but treat it as a strong signal to act now. Known ransomware use is listed as Unknown and CISA does not require forensic triage for this entry.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 27 October 2026, 22:45 GMT.
At a Glance
Based on Adobe, CISA and NVD as of 27 October 2026. Last updated 27 October 2026, 22:45 GMT.
CVSS 9.3 Critical
Scored by NVD and in Adobe's CVE record. The APSB26-73 bulletin lists 9.6. No authentication needed, but the scoring says user interaction is required.
Exploited, in CISA KEV
Added on 27 October 2026. Adobe's bulletin still says it is not aware of exploits in the wild.
Every unpatched store
Adobe Commerce, Magento Open Source, Commerce B2B and Commerce Events on the release lines below.
Adobe isolated patch
The July 2026 patch for your line (KA-37421), or magento-cloud-patches on Commerce Cloud. Commerce Events 1.21.0.
Adobe publishes APSB26-73 with isolated patches for each release line. NVD publishes CVE-2026-48356 the same day.
Adobe last updates the bulletin. It still says Adobe is not aware of exploits in the wild.
Adobe updates KA-37421, which explains the July 2026 isolated patches.
CISA adds CVE-2026-48356 to its Known Exploited Vulnerabilities catalogue.
Affected and fixed versions
| Product | Affected | Fix |
|---|---|---|
| Adobe Commerce | 2.4.9; 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18 and earlier | July 2026 isolated patch for each line (2.4.9-2026-jul to 2.4.4-2026-jul) |
| Magento Open Source | 2.4.9; 2.4.8-p5, 2.4.7-p10 and 2.4.6-p15 and earlier | July 2026 isolated patch for each line (2.4.9-2026-jul to 2.4.6-2026-jul) |
| Adobe Commerce B2B | 1.5.3; 1.5.2-p5, 1.4.2-p10, 1.3.4-p17 and 1.3.3-p18 and earlier | July 2026 isolated patch for each line (1.5.3-2026-jul to 1.3.3-2026-jul) |
| Adobe Commerce Events | 1.6.0 to 1.20.0 | 1.21.0 |
| Adobe Commerce on cloud infrastructure | As above | Latest magento/magento-cloud-patches |
| Older lines (Commerce below 2.4.4, Open Source below 2.4.6) | Out of support, treat as vulnerable | Upgrade to a supported line |
The "2026-jul" fixes are isolated patches applied on top of the latest security release for each line, not new Composer versions, so the version number in composer.lock does not change. Confirm with Adobe's vendor/bin/patch-status.
What is confirmed, and what comes from public research
- Confirmed by Adobe, NVD and CISA: an unrestricted upload of a file with a dangerous type (CWE-434), exploitable over the network without authentication. Adobe calls the impact privilege escalation. CISA says it could result in arbitrary code execution.
- From public research only: security researchers report that files are uploaded through a product's file custom option using the guest-cart REST API, land in
pub/media/custom_options/quote/, and can be polyglots: valid images that also contain PHP. Adobe, NVD and CISA have not confirmed this. - From the patch itself: Adobe's July patch adds ownership checks to guest-cart requests. Adobe does not say which part of the patch fixes this CVE.
The detection pack covers the public research path and also looks for PHP anywhere under pub/media, so it does not depend on the exact technique.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Patch and harden
- Apply the July 2026 isolated patch for each store's release line, or update magento-cloud-patches.
- Confirm it with Adobe's
vendor/bin/patch-status. - Stop PHP running anywhere in pub/media on nginx or Apache.
- Block or rate-limit file uploads on guest-cart item requests at the WAF.
Hunt and contain
- Look for unexpected files in pub/media/custom_options/quote/.
- Search for images that contain PHP, and PHP files anywhere in pub/media.
- Check for new admin users, changed CMS blocks and checkout JavaScript.
- If you find a shell or skimmer, keep the evidence, then contain and rotate secrets.
Proactive: Check Exposure and Fix
Apply Adobe's patch first, then make sure an uploaded file can never run as PHP.
Find every store and its release line
Run the free checkers below against each Magento root. They read the version from composer.lock, look for the code the July patch adds and report PATCHED, LIKELY VULNERABLE or UNKNOWN.
Apply the July 2026 isolated patch
Install the patch for your release line from Adobe's KA-37421, or update magento/magento-cloud-patches on Commerce Cloud, and update Commerce Events to 1.21.0. Stores below 2.4.4 (Open Source below 2.4.6) get no patch and need a supported line. Confirm with vendor/bin/patch-status.
Stop PHP running in pub/media on nginx
Keep the rules from Adobe's own sample config. A plain prefix location loses to a generic location ~ \.php$ block, so use ^~ and put the media deny before any PHP location.
# Keep these from Adobe's nginx.conf.sample
location ^~ /media/custom_options/ { deny all; }
location ~* ^/(pub/)?media/.*\.(php|phtml|phar) { deny all; }
# Only pass Magento's own entry points to PHP
location ~ ^/(index|get|static|errors/report|errors/404|errors/503|health_check)\.php$ {
# fastcgi_pass ...
}Stop PHP running in pub/media on Apache
Keep Adobe's .htaccess files. php_flag engine 0 only works with mod_php, so with PHP-FPM the handler block and the deny are what protect you. Check AllowOverride lets them apply, or copy the rules into the vhost.
# pub/media/.htaccess (from Adobe's sample)
php_flag engine 0
<FilesMatch ".*\.(ph(p[3457]?|t|tml)|[aj]sp|p[ly]|sh|cgi|shtml?|html?)$">
SetHandler default-handler
</FilesMatch>
# pub/media/custom_options/.htaccess
Require all deniedAdd a WAF rule for guest-cart uploads
Most stores never take customer file uploads through the guest-cart API. Block, or rate-limit and log if you sell products with file options, POST and PUT requests to /rest/*/V1/guest-carts/*/items that carry a file custom option. Block all requests to /media/custom_options/ and to PHP files under /media/.
Do not hand every .php to PHP-FPM
Replace generic PHP locations with Adobe's list of entry points, keep security.limit_extensions = .php in the FPM pool, and make sure image or other extensions are never mapped to the PHP handler.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams, MSPs and agencies. Check each store's patch status and hunt for uploaded web shells. Everything is read-only.
check-polyshell.sh
Reads the Magento version, looks for the code Adobe's July 2026 patch adds, scans pub/media for suspicious uploads, and optionally reviews your nginx or Apache config and access logs.
bash check-polyshell.sh --magento-root /var/www/magento
bash check-polyshell.sh --magento-root /var/www/magento \
--web-config /etc/nginx/sites-enabled/magento.conf \
--access-log /var/log/nginx/access.logCheck-PolyShell.ps1
The same checks in PowerShell 5.1 or 7, with the same output. It also runs under PowerShell on Linux, so you can use it on the web server itself.
.\Check-PolyShell.ps1 -MagentoRoot 'D:\www\magento'
.\Check-PolyShell.ps1 -MagentoRoot /var/www/magento -WebConfig /etc/nginx/sites-enabled/magento.conf -AccessLog /var/log/nginx/access.logKQL hunts and Sigma rules
10 KQL queries for Microsoft Sentinel and Defender XDR covering IIS, WAF, Application Gateway and nginx or Apache logs, files written into pub/media, web workers spawning shells and checkout files being changed. 11 Sigma rules cover the same ground for other SIEM platforms.
Verdicts
- PATCHEDAll the July 2026 patch markers are present, or a fixed release, and no indicators were found.
- LIKELY VULNERABLEA version in Adobe's affected range with no patch markers, or an unsupported line.
- UNKNOWNThe version could not be read, the markers are partial or the patch layout for that line could not be verified. Confirm with patch-status.
- INDICATORS FOUNDA suspicious upload, a PHP file in pub/media or a served request for one. This overrides PATCHED.
Exit codes
| Code | Meaning |
|---|---|
| 0 | PATCHED |
| 1 | LIKELY VULNERABLE, or INDICATORS FOUND |
| 2 | UNKNOWN, or no Magento found |
| 3 | Error, such as a missing Magento root or an unreadable log |
MSPs and agencies can use the exit code in RMM or scheduled jobs to flag stores at scale. Web config findings and guest-cart counts are informational and do not change it.
Know the limits
- Both checkers are read-only. They never write, move, delete or run any file, never call the Magento API and send no network traffic.
- A version number cannot prove the July patch is applied, so the checkers look for code the patch adds. Customised or relocated code can give false results.
- They do not check the database, cron jobs or other persistence. Do those by hand, as in the hunts below.
- The KQL has not been run against a live tenant. Fields marked UNVERIFIED FIELD depend on your connectors. No indicators of compromise are included, because Adobe and CISA have published none.
Reactive: How to Hunt
A store that ran an affected build may already hold a web shell or card skimmer, and the patch removes neither. Hunt over the whole period each store was unpatched. CybaOps can run these hunts across your estate or your clients'.
Files in the custom options upload folder
Look in pub/media/custom_options/quote/ for script or server config files (.php, .phtml, .phar, .htaccess, .user.ini), double extensions such as x.php.jpg, SVG or HTML files, and files whose content does not match their extension. The checkers do this.
Images that contain PHP
Search for files whose bytes include <?php or <?=, even with valid image headers. Read them as bytes only. Never open or include them in PHP.
PHP anywhere in pub/media
Magento ships no PHP files under pub/media, so any .php, .phtml or .phar there needs explaining. Check for recently changed PHP files elsewhere in the web root too (KQL Q6 and Q7).
Access logs
Look for a guest-cart item POST or PUT followed by a request into /media/custom_options/quote/ from the same IP, any successful request into that folder, and any request for a PHP file under /media/ (KQL Q1 to Q5 and the Sigma webserver rules).
New admin users and tokens
Review Admin, System, Permissions, All Users for accounts you do not recognise, and check for new integrations and API tokens.
Skimmers and web workers running shells
Check for changed CMS blocks and pages, head and footer scripts in the design config, and changed JavaScript or templates in themes, pub/static and checkout modules (KQL Q10). Look for web workers spawning shells or tools (KQL Q8 and Q9).
If you find something
- Keep the evidence first: copy the web server and application logs and the suspicious files, with hashes and timestamps, before changing anything.
- Put the store into maintenance mode if a skimmer or shell is confirmed, remove the web shells and injected code, and apply the patch.
- Rotate secrets: admin passwords and 2FA, the database password, the crypt key in app/etc/env.php (using Adobe's key rotation process), integration and API tokens and payment gateway keys.
- Tell your payment provider if card data may have been exposed.
- Scan the code base and database for malware, and rebuild from a known good release if you cannot be sure the clean-up is complete.
Patched does not mean clean
Adobe's patch stops new uploads, but it does not remove a web shell, a skimmer or an admin account that is already there. Every store that ran an affected build should be hunted, not just patched.
Magento PolyShell FAQ
Short answers based on Adobe, CISA and NVD as of 27 October 2026.
Is CVE-2026-48356 being exploited?
Yes, according to CISA, which added it to its Known Exploited Vulnerabilities catalogue on 27 October 2026. Adobe's bulletin, last updated 11 August 2026, still says Adobe is not aware of any exploits in the wild, and public research reports widespread attempts against Magento stores. Neither Adobe nor CISA has published indicators of compromise.
What is PolyShell?
PolyShell is a name used in public research for CVE-2026-48356. Adobe, CISA and NVD only use the CVE number. The name refers to polyglot files, valid images that also contain PHP, which public research says attackers upload.
How severe is it?
NVD and Adobe's own CVE record score it CVSS 3.1 9.3 Critical. The APSB26-73 bulletin lists 9.6. It needs no authentication, although the scoring says user interaction is required. Adobe describes the impact as privilege escalation and CISA says it could result in arbitrary code execution.
Is there a new Magento version that fixes it?
No. The fix is Adobe's July 2026 isolated patch for each release line, applied on top of the latest security release (for example 2.4.8-p5 plus the July patch), as described in Adobe's KA-37421. Commerce Cloud uses the latest magento-cloud-patches package, and Commerce Events is fixed in 1.21.0. A version number alone cannot show the patch is applied, so confirm with Adobe's patch-status tool.
Does applying the patch remove a web shell or skimmer?
No. The patch stops new uploads but leaves anything already planted. Hunt over the whole period the store was unpatched for files in pub/media, new admin users, changed CMS blocks and checkout JavaScript, and web workers running shells.
My store runs Magento 2.4.3 or older. Am I affected?
Adobe's bulletin only lists supported lines, and older lines get no patch. Treat them as vulnerable, harden pub/media and the web server now, and plan an upgrade to a supported line.
Does the 10 November due date apply to UK organisations?
No. CISA's due date applies to US federal agencies under BOD 26-04. Treat the KEV listing as a strong signal to act now rather than as your deadline.
We are an MSP or agency running many stores. Where do we start?
Run the free checkers against each store's Magento root, web server config and access logs. Apply the July patch on every store reported as LIKELY VULNERABLE or UNKNOWN, roll out the pub/media hardening and WAF rule across all of them, and treat any INDICATORS FOUND result as an incident.
Protect Your Stores, and Your Clients'
CybaOps monitors your web servers, endpoints and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- CISA: Known Exploited Vulnerabilities catalogue (CVE-2026-48356 added 27 October 2026)
- Adobe: Security bulletin APSB26-73 for Adobe Commerce and Magento Open Source
- Adobe: KA-37421, July 2026 isolated patches for Adobe Commerce and Magento Open Source
- NVD: CVE-2026-48356
Related threat guides: PHP2Shell and GLPI unauthenticated SQL injection. All threat guides.