CVE-2026-48356 PolyShell: Magento Flaw Scored 9.3 Under Active Attack, How to Check and Patch Today

Direct answer: CVE-2026-48356, which Sansec named PolyShell, is a file upload flaw in the REST APIAPIThe official door 2 systems use to exchange data, without anybody copying it by hand.Open the glossary of Magento Open Source and Adobe Commerce. It has a CVSS score of 9.3, and CISA added it to the KEV catalog on 27 October 2026. Magento 2.4.x stores without the July 2026 isolated patch are still vulnerable. Today, check the version, check the upload folder, apply the patch, then look for signs of attack.

Attackers have used this flaw since 19 March 2026. According to the Sansec report, on 30 March 79.5% of the stores that Sansec protects became targets. Attackers installed backdoors and card data stealing scripts on the stores that they got into.

Main condition: Adobe did not publish a new Composer version for this fix. The fix comes as a monthly isolated patch file on top of the last -p version. So version 2.4.8-p5 alone is not safe. Limit: This article has no request content, no payload, and no attack sequence.

We read the Adobe CVE record, NVD, the bulletin APSB26-73, APSB26-153, the October 2026 isolated patch KB, the APSB26-146 hotfix KB, the Sansec report, and CISA KEV on 31 October 2026, from 06.30 to 07.40 WIB. We ran the scripts of steps 1, 2, 4, and 5 in podman containers with the official php, nginx, debian, and mariadb images on the same date. The version test used real composer.lock files of 4 Magento Open Source versions. The test server holds no customer data.

The problem: attackers used this flaw 7 months before KEV

The first attack occurred on 19 March 2026, but the fix for the 2.4.8 and older lines came only on 14 July 2026.

According to the Sansec report, Adobe fixed this code in the 2.4.9 pre-release branch in October 2025. Sansec gave a public warning on 17 March 2026. 2 days later, the first attack occurred, and mass scanning started on 23 March.

Adobe published the bulletin APSB26-73 on 14 July 2026 with priority 2. At that time, Adobe wrote that it knew of no exploit in the wild. CISA added this CVE to CISA KEV only on 27 October 2026, with a deadline of 10 November 2026 for US federal agencies.

Magento runs on PHP, so a Magento store also needs the latest PHP fixes. Also read about the PHP2Shell flaws in PHP. The difference: PolyShell is in the Magento code, not in PHP.

How it works: the guest cart REST API stores files with no file type check

This flaw makes a store accept a file from a visitor with no login and keep it in the media folder.

This section uses the official summary. It helps you choose the correct steps. It does not explain how to attack.

Summary from Adobe and Sansec

According to the Adobe CVE record, Adobe Commerce has an unrestricted upload of a file with a dangerous type (CWE-434). This flaw can lead to code execution. NVD gives the same score, 9.3, with the status Analyzed.

According to the Sansec report, the guest shopping cart REST API accepts a file as part of a product option. Magento stores that file in pub/media/custom_options/quote/. Magento does not check the file extension, so a PHP file that looks like an image can be stored. GraphQL mutations use a different path and are not affected.

A stored file becomes dangerous when the web server runs or serves the files in that folder. Sansec writes that many stores use a web server configuration from their hosting provider, not the official Magento sample.

Scores from each source

The score is different per source, so always write the score with its source.

Source	Score	Note
Adobe CVE record (CNA)	CVSS 3.1 9.3	User interaction required, scope changed, no availability impact
NVD	CVSS 3.1 9.3	Status Analyzed, KEV data recorded
Bulletin APSB26-73	CVSS 3.1 9.6	Critical, no authentication, privilege escalation impact
Adobe priority	2	Written on 14 July 2026, before KEV
CISA KEV	Added 27 October 2026	Used in attacks

Exploitation status on 31 October 2026

CISA KEV lists this CVE as a flaw that attackers use. Sansec reported harmful PHP files on 82% of the stores that Sansec monitors on 14 April 2026. After they got in, attackers installed the accesson.php backdoor and JavaScript loaders in CMS blocks.

Rama Digital analysis: attackers have had this flaw for 7 months. So treat every store that was not patched before April 2026 as already scanned. A patch alone is not enough for that store, so step 5 is mandatory.

Who has the highest risk

Magento 2.4.x stores without the July 2026 patch, with a web server that runs PHP files in the media folder, have the highest risk.

This table sums up the Sansec report, the bulletin APSB26-73, and the official Magento nginx sample.

Store condition	Risk	Reason
Magento 2.4.x without the July 2026 isolated patch	High	The REST API is on by default, so files can be uploaded
Custom nginx that sends every .php file to PHP-FPM	Highest	Sansec: uploaded files can run as code
Apache or LiteSpeed without .htaccess in custom_options	High	Files in the folder can be read or can run
Stores that moved servers or changed configuration	Additional	Old files stay on the disk and can open later
Magento Open Source 2.4.6 and older	High	The latest Open Source patches cover 2.4.7 and newer only
nginx with the official Magento 2.3+ sample and the latest patch	Low	The official sample denies this folder and runs only entry point files

A headless store that uses GraphQL for the cart still has the REST API on. So a headless store still needs the patch.

Vulnerable and safe versions

Use the release line table, because Adobe safe labels such as 2.4.8-2026-jul are not Composer version numbers.

Product or line	Vulnerable	Safe on 31 October 2026
Adobe Commerce dan Magento Open Source 2.4.9	2.4.9	2.4.9 + 2026-jul isolated patch or newer
2.4.8	2.4.8-p5 and older	2.4.8-p5 + 2026-jul isolated patch or newer
2.4.7	2.4.7-p10 and older	2.4.7-p10 + 2026-jul isolated patch or newer
2.4.6	2.4.6-p15 and older	Commerce: 2.4.6-p15 + patch. Open Source: upgrade to 2.4.7 or newer
Adobe Commerce 2.4.5 and 2.4.4	2.4.5-p17, 2.4.4-p18 and older	last -p + 2026-jul isolated patch or newer
Adobe Commerce B2B	1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18	Same version + 2026-jul patch
Adobe Commerce Events	1.6.0 to 1.20.0	1.21.0
Magento Open Source 2.4.5 and older	No fix	Upgrade to 2.4.7 or newer

The table data comes from the bulletin APSB26-73 and APSB26-153. According to the October 2026 isolated patch KB, the monthly fixes come as isolated patch files with no Composer package. A store must be on the last -p version, then apply the monthly patches in order. The newest build on 31 October 2026 is 2026-oct from 13 October 2026.

Adobe also published hotfix APSB26-146 on 7 September 2026 for CVE-2026-75650, another Magento flaw used in attacks. That hotfix is not in the October isolated patch, so apply it on its own. Sansec writes that 2.4.9 from 12 May already has the PolyShell fix. Adobe still lists 2.4.9 as vulnerable, so this article follows Adobe.

Before you start

• SSH access to the store server, with sudo rights or the user that owns the Magento folder.
• The Magento folder path, for example /var/www/store, and the store URL.
• Access to the store database. The database name is in app/etc/env.php.
• A recent backup of the code and the database, and a staging server when you have one.
• For Adobe Commerce 2.4.6 and older: the Composer keys from your Adobe account, because the patch download asks for them.

Step 1: Check the Magento version and the monthly patch

Save this script as check-version.sh. The script reads the edition and the version from composer.lock, then looks for the Commerce Version Tool from the July 2026 patch.

#!/usr/bin/env bash
# Check the Magento version and the July 2026 patch for CVE-2026-48356 (APSB26-73).
# Usage: bash check-version.sh /var/www/store
root="${1:-.}"
lock="$root/composer.lock"
if [ ! -f "$lock" ]; then echo "No composer.lock in $root"; exit 1; fi

# Read the version of 1 package from composer.lock.
pkg() {
  php -r '$l = json_decode(file_get_contents($argv[1]), true);
    foreach (array_merge($l["packages"] ?? [], $l["packages-dev"] ?? []) as $p)
      if ($p["name"] === $argv[2]) { echo ltrim($p["version"], "v"); exit; }' "$lock" "$1"
}

ee=$(pkg magento/product-enterprise-edition)
ce=$(pkg magento/product-community-edition)
if [ -n "$ee" ]; then edition="Adobe Commerce"; version=$ee; else edition="Magento Open Source"; version=$ce; fi
echo "Edition: $edition"
echo "Version: ${version:-not found}"

# Last -p version per release line on 31 October 2026 (APSB26-73 and APSB26-153).
case "$version" in
  2.4.9) line=2.4.9; last=2.4.9 ;;
  2.4.9-*) line=pre; last=2.4.9 ;;
  2.4.8*) line=2.4.8; last=2.4.8-p5 ;;
  2.4.7*) line=2.4.7; last=2.4.7-p10 ;;
  2.4.6*) line=2.4.6; last=2.4.6-p15 ;;
  2.4.5*) line=2.4.5; last=2.4.5-p17 ;;
  2.4.4*) line=2.4.4; last=2.4.4-p18 ;;
  *) line=old ;;
esac

if [ "$line" = old ]; then
  echo "RESULT: VULNERABLE. This release line gets no more fixes. Upgrade to 2.4.7 or newer."
elif [ "$line" = pre ]; then
  echo "RESULT: pre-release version. Move to 2.4.9, then apply the July to October 2026 isolated patches."
elif [ "$edition" = "Magento Open Source" ] && [[ "$line" =~ ^2\.4\.[4-6]$ ]]; then
  echo "RESULT: VULNERABLE. The latest Open Source patches cover 2.4.7 and newer only. Upgrade to 2.4.7-p10 or newer."
elif [ "$version" != "$last" ]; then
  echo "RESULT: VULNERABLE. First move to $last, then apply the July to October 2026 isolated patches."
elif [ -f "$root/vendor/bin/patch-status" ]; then
  echo "Commerce Version Tool found. Lines for CVE-2026-48356:"
  (cd "$root" && php vendor/bin/patch-status | grep -i 'CVE-2026-48356') || echo "No CVE line. Read the full output of php vendor/bin/patch-status."
else
  echo "RESULT: VULNERABLE. $version does not have the July 2026 patch, because vendor/bin/patch-status is missing."
fi

# Additional Adobe Commerce modules, when installed.
b2b=$(pkg magento/extension-b2b)
events=$(pkg magento/commerce-eventing)
[ -n "$b2b" ] && echo "B2B $b2b: also apply the B2B isolated patch for this version."
if [ -n "$events" ]; then
  if [ "$(printf '%s\n' "$events" 1.21.0 | sort -V | head -1)" = 1.21.0 ]; then
    echo "Commerce Events $events: has the fix."
  else
    echo "Commerce Events $events: VULNERABLE. Update to 1.21.0."
  fi
fi

Run the script in the store folder. You can also read the version with a Magento or Composer command.

cd /var/www/store
bash check-version.sh /var/www/store
# Other ways to read the version
php bin/magento --version
composer show magento/product-community-edition    # Open Source
composer show magento/product-enterprise-edition   # Adobe Commerce

The Commerce Version Tool exists only after the July 2026 isolated patch is in. When the tool exists, the script runs php vendor/bin/patch-status and shows the CVE-2026-48356 line. The correct status is PROTECTED.

Check the result: "First move to" means the store is not on the last -p version. "patch-status is missing" means the July patch is not in. "Upgrade to 2.4.7-p10" means your Open Source line gets no more fixes. Each of those results means: go to steps 2, 3, and 4.

Step 2: Check the upload folder and the web server rules

This step answers 1 question: does your web server serve or run the files in pub/media/custom_options/?

Save this script as check-folder.sh. The script counts the files in the folder, reads .htaccess, then writes 2 test files with no code and requests them from the web. The script deletes the test files after the test.

#!/usr/bin/env bash
# Check the custom_options upload folder and the web server rules (CVE-2026-48356).
# Usage: sudo -u www-data bash check-folder.sh /var/www/store https://your-store.com
root="${1:-.}"
url="${2%/}"
dir="$root/pub/media/custom_options"

echo "Files in custom_options other than .htaccess: $(find "$dir" -type f ! -name .htaccess 2>/dev/null | wc -l)"
if [ ! -f "$dir/.htaccess" ]; then
  echo ".htaccess: missing. Apache can serve the files in this folder."
elif grep -qiE 'deny from all|require all denied' "$dir/.htaccess"; then
  echo ".htaccess: present and denies access. This file applies to Apache only."
else
  echo ".htaccess: present, but it does not deny access."
fi
if [ -z "$url" ]; then echo "Give the store URL as argument 2 for the web test."; exit 0; fi

# Web test with 2 files that hold no code, then delete the files.
mkdir -p "$dir/quote"
name="rd-check-$$"
printf 'access test\n' > "$dir/quote/$name.txt"
printf 'access test\n' > "$dir/quote/$name.php"
open=0
for f in "$name.txt" "$name.php"; do
  for p in media pub/media; do
    code=$(curl -s -o /dev/null -w '%{http_code}' "$url/$p/custom_options/quote/$f")
    echo "/$p/custom_options/quote/$f -> HTTP $code"
    case "$code" in 403|404) ;; *) open=1 ;; esac
  done
done
rm -f "$dir/quote/$name.txt" "$dir/quote/$name.php"
if [ "$open" = 1 ]; then
  echo "RESULT: OPEN. The web server serves or runs files in this folder. Do step 4."
else
  echo "RESULT: closed. All requests get 403 or 404."
fi

# Run as the web server user, so the test files can be written
sudo -u www-data bash check-folder.sh /var/www/store https://your-store.com
# nginx: find the rules for this folder
sudo nginx -T 2>/dev/null | grep -n custom_options

In our test, the text file got HTTP 200 and the .php file got 418 from the stand-in PHP block. On a real server, a .php file that gets 200 means that PHP runs the files in that folder. The .htaccess file applies only to Apache and LiteSpeed, not to nginx.

Check the result: "closed" means every request gets 403 or 404. "OPEN" means: do step 4 today. A file count above 0 means: do step 5.

Step 3: Install the last -p version, the isolated patches, and hotfix APSB26-146

Only the Adobe fix closes this flaw, and the fix must sit on the last -p version of your release line.

This order follows the October 2026 isolated patch KB and the Adobe guide to apply an isolated patch. The example uses the 2.4.8 line and Magento Open Source.

# 0. Back up the code and the database. Test on staging first.
php bin/magento maintenance:enable
# 1. Move to the last -p version of your release line. Example: the 2.4.8 line.
composer require magento/product-community-edition=2.4.8-p5 --no-update
composer update
php bin/magento setup:upgrade
# 2. Apply the July, August, September, and October 2026 isolated patches, in order.
#    Adobe file name pattern: <version>-<year>-<month>-<sequence>-<component>.patch
patch -p1 --dry-run < 248p5-2026-07-001-CE.patch
patch -p1 < 248p5-2026-07-001-CE.patch
#    Do the same for the next months. Adobe Commerce: the CE file, then the EE file.
# 3. Apply the CVE-2026-75650 hotfix from APSB26-146 in the same way.
# 4. Check the result, then open the store again.
php vendor/bin/patch-status
php bin/magento cache:flush
php bin/magento maintenance:disable

Download the patch files from the October 2026 isolated patch KB and the July, August, and September KBs. Each ZIP file can hold several files per component. Apply only the files that match the installed component versions. When -p1 fails, the Adobe guide to apply an isolated patch tells you to try -p2.

For Adobe Commerce, use the package magento/product-enterprise-edition. For Adobe Commerce on Cloud, put the patch files in the m2-hotfixes folder and deploy, or use the latest cloud-patches package. For Commerce Events, update the module to 1.21.0.

Check the result: php vendor/bin/patch-status prints PROTECTED for CVE-2026-48356 and lists no July to October patch as missing. Then run check-version.sh again.

Step 4: Apply a temporary mitigation until the patch is in

This step keeps files in the upload folder from being read or run, but it does not stop the upload.

Rama Digital analysis: We built 3 steps from the Sansec report and the official Magento nginx sample. Condition: you cannot patch the store today. Limit: files can still land on the disk, so this step does not close the flaw.

4a. nginx: deny the custom_options folder above the PHP block

The official Magento sample already uses location /media/custom_options/ { deny all; } and sends only entry point files to PHP-FPM. Many hosts send every .php file to PHP-FPM. For that configuration, add this block from Sansec.

# Put this inside the server block, ABOVE every location block for PHP.
location ~* ^/(pub/)?media/custom_options/ {
    deny all;
    return 403;
}

sudo nginx -t && sudo systemctl reload nginx
sudo -u www-data bash check-folder.sh /var/www/store https://your-store.com

Our test proves that the order sets the result. A rule below the PHP block gives 403 for the text file, but the .php file still goes to the PHP block. A rule above the PHP block gives 403 for every file.

4b. Apache and LiteSpeed: check .htaccess

Make sure that pub/media/custom_options/.htaccess exists. The official Magento content is the first 6 lines below. Sansec adds the php_flag engine 0 block.

<IfVersion < 2.4>
    order deny,allow
    deny from all
</IfVersion>
<IfVersion >= 2.4>
    Require all denied
</IfVersion>
<IfModule mod_php.c>
    php_flag engine 0
</IfModule>

This file applies only when AllowOverride permits it. Run check-folder.sh after the change to prove the result. We did not test Apache or LiteSpeed for this article.

4c. WAF: block file uploads through the guest cart REST route

According to the Sansec report, only a WAF that blocks that API call stops the upload. Ask your WAF provider for a rule for PolyShell or CVE-2026-48356. At the last Sansec update, Cloudflare had not published a matching rule. Test the buy button and checkout after the rule is on, because headless stores use the cart REST route.

Check the result: check-folder.sh prints "closed". Limit: files that are already stored stay on the disk. A new configuration or a server move can open them again.

Step 5: Look for signs that the store was touched

A patch does not remove files that an attacker planted, so check the disk, the logs, and the database.

Save this script as check-signs.sh. The script looks for files in the upload folder, PHP files and images with PHP code, the accesson.php backdoor, and suspicious log lines.

#!/usr/bin/env bash
# Check for signs of CVE-2026-48356 (PolyShell) attacks on disk and in the web server log.
# Usage: sudo bash check-signs.sh /var/www/store /var/log/nginx/access.log
root="${1:-.}"
log="${2:-}"
dir="$root/pub/media/custom_options"
show() { if [ -n "$1" ]; then printf '%s\n' "$1" | sed 's/^/   /'; else echo "   none"; fi; }

echo "1. Files in custom_options other than .htaccess:"
show "$(find "$dir" -type f ! -name .htaccess 2>/dev/null | head -20)"
echo "2. Files with a PHP extension in custom_options:"
show "$(find "$dir" -type f -iregex '.*\.\(php[0-9]?\|phtml\|phar\|pht\|phps\)' 2>/dev/null)"
echo "3. Files with PHP code in custom_options, images included:"
show "$(grep -rlE '<\?(php|=)' "$dir" 2>/dev/null)"
echo "4. accesson.php and PHP files in assets/images folders:"
show "$(find "$root" -type f \( -name accesson.php -o -path '*/assets/images/*.php' \) 2>/dev/null)"
echo "5. Other PHP files in pub/media:"
show "$(find "$root/pub/media" -type f -iname '*.ph*' ! -path "$dir/*" 2>/dev/null)"
if [ -n "$log" ]; then
  echo "6. 200 responses from the custom_options folder in the log:"
  show "$(grep -E '/(pub/)?media/custom_options/' "$log" | awk '$9 == 200' | tail -5)"
  echo "7. POST or PUT to guest cart items: $(grep -cE '"(POST|PUT) [^"]*guest-carts/[^/ ]+/items' "$log")"
fi

sudo bash check-signs.sh /var/www/store /var/log/nginx/access.log
# Apache: /var/log/apache2/access.log or the domain log in your hosting panel

Then save these queries as check-cms.sql. The queries look for script tags in CMS blocks and pages, loader domain names from the Sansec report, and the 5 newest admin accounts.

-- Check CMS blocks, CMS pages, and admin accounts (CVE-2026-48356).
-- Add the table prefix when your store uses one.
SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%<script%';
SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%<script%';
-- Loader domain names from the Sansec report.
SELECT 'cms_block' AS source_table, block_id AS id, identifier FROM cms_block
  WHERE content REGEXP 'lanhd6549tdhse|jslibrary|canevaslab|deepveindrilling'
UNION ALL
SELECT 'cms_page', page_id, identifier FROM cms_page
  WHERE content REGEXP 'lanhd6549tdhse|jslibrary|canevaslab|deepveindrilling';
SELECT user_id, username, email, created, logdate, is_active FROM admin_user
  ORDER BY created DESC LIMIT 5;

# Read the database name from app/etc/env.php, then run:
mysql -t -u DB_USER -p DB_NAME < check-cms.sql    # or mariadb -t

A script tag in a CMS block can be valid, for example a chat or analytics script. Compare each result with the changes that your team made. A POST to guest cart items is also normal on a headless store, so compare the count with a normal day.

Check the result: 0 files in custom_options other than .htaccess, 0 accesson.php files, 0 unknown scripts in CMS, and no admin that you do not know. When you find even 1 sign, turn on maintenance mode and keep the logs and a copy of the disk. Then replace the credentials from the list in the APSB26-146 hotfix KB: the encryption key, admin passwords, integration tokens, payment API keys at the provider, database passwords, and SSH keys. Install the code again from a clean source, then apply the patch.

Example: 1 morning of response for 3 stores

This simulation uses dummy data. The store names, times, and results are not customer data.

Time (WIB)	Dummy store	What we checked	Result	Action
07.00	store-fashion (Open Source 2.4.8-p3, hosting nginx)	Steps 1 and 2	VULNERABLE, folder OPEN	Step 4a this morning, patch tonight
07.40	store-wholesale (Adobe Commerce 2.4.7-p10, B2B)	Step 1	patch-status missing	CE, EE, and B2B patches July to October, then the hotfix
08.30	store-legacy (Open Source 2.4.6-p15, Apache)	Steps 2 and 5	Folder closed, 1 .php file in custom_options, 1 new admin	Incident response, replace credentials, upgrade to 2.4.7-p10
10.00	All stores	Step 5	Results kept with the logs	Do step 5 again each week

Lesson from the simulation: a closed folder does not prove that a store is clean. store-legacy was closed in step 2, but step 5 still found a file and a new admin.

Who applies the patch

Patch duty is different per hosting type, so this table helps you know who must act today.

Hosting type	Patch owner	What you do
VPS or own server	Your IT team or developer	Steps 1 to 5
Adobe Commerce on Cloud	Your team, through cloud-patches or m2-hotfixes	Deploy the patch, then steps 1 and 5
Managed Magento hosting	The provider for the server, your team for the Magento code	Ask for the patch-status output in writing, then step 5
Third-party agency or developer	The agency, per the contract	Ask for the step 1, 2, and 5 output in writing

Rama Digital recommendation: a store that holds payment gateway API keys must treat each sign in step 5 as an incident. For another recent flaw in a web runtime, also read about the Node2Shell flaw in the Brotli decoder.

Checklist for today

1. List all Magento and Adobe Commerce stores, staging included. Owner: IT team. Evidence: a list of URLs and paths.
2. Check the version with step 1. Owner: developer. Evidence: script output per store.
3. Check the folder with step 2. Owner: server admin. Evidence: script output per store.
4. Apply step 4 on each OPEN store. Owner: server admin. Evidence: step 2 output after the rule is on.
5. Install the last -p version, the July to October 2026 patches, and hotfix APSB26-146. Owner: developer. Evidence: patch-status output.
6. Look for signs with step 5. Owner: server admin. Evidence: script and query output, kept with the logs.
7. Check the Adobe bulletins each month, because the next fix comes as a new isolated patch.

Frequently asked questions

My store is on 2.4.8-p5. Is my store safe?

Not yet. Version 2.4.8-p5 is the last vulnerable version in the Adobe bulletin. The store is safe after the July 2026 isolated patch or a newer one is applied on top of 2.4.8-p5.

Why does Composer not offer version 2.4.8-2026-jul?

Adobe ships monthly fixes as isolated patch files, not as Composer packages. The Composer version stays 2.4.8-p5. Check the patch with php vendor/bin/patch-status.

My store runs Magento Open Source 2.4.6. What do I do?

Apply step 4 today, then do step 5. Plan an upgrade to 2.4.7-p10 or newer, because the latest Open Source patches cover 2.4.7 and newer only.

The folder is denied in nginx. Is my store safe?

Not yet. The rule only stops web access to the files. Uploads can still land on the disk, and a new configuration can open those files again. Apply the patch.

Are headless stores with GraphQL affected?

Sansec writes that GraphQL mutations are not affected. But the REST API stays on by default in a headless store. So the patch is still necessary.

Does the patch remove a planted backdoor?

No. The patch only closes the flaw. Do step 5 to find the files, CMS scripts, and admin accounts that an attacker added.

Why are there 2 scores, 9.3 and 9.6?

The CVE record and NVD give 9.3 with no availability impact. Bulletin APSB26-73 gives 9.6 with a low availability impact. Both are Critical.

Is a Magento security extension enough without the patch?

No. Scanners and WAFs help to find and stop attacks, but the vulnerable code stays until the Adobe patch is in.

Next step

The limits that still apply: the step 4 mitigation does not close the flaw, and a patch does not remove files that are already planted. When your store shows a sign in step 5, or you need help to apply the patch and check the store, use Vibe Code Rescue for an audit and stabilisation. For 1 urgent issue today, book a 30-minute session.

Sources

• Adobe CVE record: flaw summary, CWE-434, the 9.3 score, and affected versions.
• NVD: the 9.3 score, Analyzed status, and KEV data.
• bulletin APSB26-73: the 9.6 score, priority 2, affected versions, and safe version labels.
• APSB26-153: the 2026-oct build and the APSB26-146 hotfix note.
• October 2026 isolated patch KB: isolated patches, the install order, and the Commerce Version Tool.
• APSB26-146 hotfix KB: CVE-2026-75650 and the list of credentials to replace.
• Adobe guide to apply an isolated patch: the patch -p1 command.
• Sansec report: the PolyShell name, attack timeline, signs of attack, and web server rules.
• CISA KEV: CVE-2026-48356 added to the catalog on 27 October 2026.
• official Magento nginx sample: the official rule for the custom_options folder.