CVE-2026-48356

Work through these in order. A verified no at any step lowers your exposure. Patching is still the fix.

1. Inventory every instance. Production, staging, UAT, dev, old migration copies and agency-hosted stores. Staging is often internet facing and patched last.
2. Check the version. From the Magento root, run bin/magento --version, and composer show magento/product-community-edition (Open Source) or composer show magento/product-enterprise-edition (Commerce). Compare against the affected list. Adobe lists 2.4.9 as affected; Sansec says 2.4.9 shipped with the fix, so a 2.4.9 store should confirm rather than assume.
3. Confirm APSB26-73 is applied. Fixed builds carry the -2026-jul suffix. Confirm that build, or the matching isolated security patch, is deployed on every node, and check Adobe's Quality Patches Tool for the fix's status.
4. Check whether the REST API is reachable from the internet. Storefronts are public by design. Sansec names two routes that need no credentials, POST /V1/guest-carts/:cartId/items and PUT /V1/guest-carts/:cartId/items/:itemId, served under /rest/ and /rest/<store code>/. Sansec says other REST routes are also affected and that the GraphQL mutations use a different code path and are not. Check whether your CDN, WAF or load balancer passes these paths through.
5. Check the upload directory. Confirm pub/media/custom_options/ exists and what it holds: find pub/media/custom_options/ -type f ! -name '.htaccess'. Per Sansec, the upload works even if no product has a file-type custom option.
6. Check whether the web server serves or runs files there. This decides how bad an upload is. Nginx: Adobe's nginx.conf.sample denies /media/custom_options/; Sansec warns the deny block must come before any \.php$ location block or PHP may still run. Apache: confirm pub/media/custom_options/.htaccess exists and denies all access, and add php_flag engine 0 for mod_php. A non-default AccessFileName means the .htaccess is never read. Safe test: place a harmless text file there and request it under /media/custom_options/ and /pub/media/custom_options/; you want 403, not the file.
7. Check what an attacker inherits. The starting identity is an anonymous internet user. Uploaded files run as the web server or PHP-FPM user, so check what that account can read (database credentials in app/etc/env.php), write, and reach on the network. The vector's user-interaction flag fits the stored cross-site scripting path, where a customer or admin who opens an uploaded file could lose their session, so review admin access and whether admin sessions require 2FA.

These reduce risk while you schedule the patch. Test each one after you put it in place.

• WAF or virtual patch on the upload path. Block or inspect requests to the guest-cart item routes that carry a file_info object, especially with filenames ending in .php, .phtml, .phar or .html. Sansec notes that only blocking the API call stops the upload; blocking web access to the directory stops files from being served, not written. Check whether your WAF vendor has published a rule.
• Block execution and access in upload directories. Apply the nginx deny rule or Apache .htaccess above to pub/media/custom_options/, and make sure PHP runs only from the intended entry points, never from pub/media.
• File integrity monitoring. Alert on any new file in pub/media/custom_options/ and on new .php, .phtml or .phar files anywhere under pub/media.
• EDR on web hosts. Watch for the PHP or web server process spawning shells or system commands.
• Segmentation. The storefront should reach its database, cache and search services, not internal admin networks.
• Admin access. Restrict the admin URL by IP or VPN, require 2FA, remove stale admin accounts.

From Sansec's write-up.

• Any .php, .phtml or .phar file in pub/media/custom_options/. Sansec calls this a strong indicator of compromise.
• Files in that directory that begin with an image header such as GIF89a but contain PHP code.
• REST requests to /V1/guest-carts/.../items carrying file_info, especially from sources that never complete a checkout.
• Unexpected PHP files outside normal code paths, including a file named accesson.php, which Sansec lists as a follow-on backdoor: find /var/www -name 'accesson.php' -type f.
• Unexpected script tags added to CMS pages or static blocks.

Am I exposed to CVE-2026-48356?

You may be if you run Adobe Commerce, Commerce B2B or Magento Open Source on a version listed in APSB26-73 without the July 2026 fix, and your REST API is reachable. The impact is higher if your web server serves or runs files from pub/media/custom_options/.

Is there a patch for CVE-2026-48356?

Yes. Adobe released fixed builds on July 14, 2026 in bulletin APSB26-73, such as 2.4.8-2026-jul and 2.4.7-2026-jul, with matching builds for Commerce B2B. Applying the update is the complete fix.

How do I mitigate CVE-2026-48356 without patching?

Block the guest-cart upload requests at your WAF, deny web access and PHP execution in pub/media/custom_options/, and monitor that directory for new files. Test each control. Blocking the directory alone doesn't stop files from being uploaded.

Is CVE-2026-48356 being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on October 27, 2026, which means CISA has evidence of exploitation, with a federal due date of November 10. Sansec, which discovered the flaw, reports exploitation attempts since March 2026, before Adobe's July fix.

Oct 27, 2026. First published, the day CISA added the CVE to KEV.

• CISA Known Exploited Vulnerabilities catalog
• NIST NVD: CVE-2026-48356
• Adobe security bulletin APSB26-73
• Sansec: PolyShell, unrestricted file upload in Magento and Adobe Commerce
• Magento nginx.conf.sample (GitHub)