Adobe Commerce and Magento CVE-2026-48356 Is on KEV: What to Patch and Check

CVE-2026-48356 is an unrestricted upload of file with dangerous type flaw (CWE-434) in Adobe Commerce and Magento Open Source, scored CVSS 3.1 9.3 Critical, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 27 October 2026 with a due date of 10 November 2026. Adobe's fix is in security bulletin APSB26-73. If you run Adobe Commerce, Adobe Commerce B2B, Magento Open Source or the Adobe Commerce Events module, move to the fixed build Adobe lists in APSB26-73 now, then check your store for uploaded files and injected scripts, because public research reports exploitation since March 2026 and patching does not remove anything an attacker already left behind.

Key takeaways

• It is on KEV. CISA added CVE-2026-48356 on 27 October 2026. The KEV due date is 10 November 2026. CISA lists known ransomware campaign use as "Unknown".
• It is critical. Adobe, as the CVE Numbering Authority, and NVD both score it CVSS 3.1 9.3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N).
• The affected range is wide. The CVE record lists Adobe Commerce 2.4.4 through 2.4.9 lines (up to 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18), Adobe Commerce B2B up to 1.5.3, Magento Open Source up to 2.4.9 (2.4.6 to 2.4.9 lines), and Adobe Commerce Events up to 1.20.0.
• The fix is named in Adobe's bulletin. The CVE record lists builds named 2.4.9-2026-jul, 2.4.8-2026-jul and so on as unaffected, and Adobe Commerce Events 1.21.0. Read the exact package names and install steps from APSB26-73 before you change anything.
• Exploitation is not new. Public research, referenced in the CVE record's CISA data, describes mass exploitation under the name "PolyShell" from March 2026, including webshells disguised as images in pub/media/custom_options/quote/.
• Patching is step one, not the end. Search the upload directory, CMS blocks and CMS pages, and admin users. Rotate credentials if you find anything.
• Web server configuration matters. Magento's own nginx.conf.sample denies web access to /media/custom_options/. Stores running a custom configuration should compare theirs against it.

What happened

On 27 October 2026, CISA added CVE-2026-48356 to the KEV catalog under the name "Adobe Commerce and Magento Unrestricted Upload of File with Dangerous Type Vulnerability". KEV is CISA's list of vulnerabilities with reliable evidence of exploitation in the wild. A KEV listing is the clearest public signal a defender gets that a flaw is being used against real systems, not just that it could be.

CISA's short description reads: "Adobe Commerce and Magento contain an unrestricted upload of file with dangerous type vulnerability that could result in arbitrary code execution in the context of the current user, potentially gaining elevated access or control over the victim's account or session."

The CVE itself is older than the KEV entry. NVD shows the record was published on 14 July 2026, with Adobe's product security team (psirt@adobe.com) as the source. The record was last modified on 28 October 2026, after the KEV addition, which is when NVD showed the KEV dates. The CISA ADP data in the CVE record carries the references to the public exploitation research.

So there are three dates that matter, and they mean different things:

1. The flaw was publicly described and exploited before it had a CVE record in NVD. Public research dated 17 March 2026 and linked from the CVE record, describes the flaw, names it PolyShell, and reports live attacks from 16 March 2026.
2. Adobe published the CVE on 14 July 2026, tied to bulletin APSB26-73.
3. CISA added it to KEV on 27 October 2026, which sets a remediation due date for US federal civilian agencies and is a strong prioritisation signal for everyone else.

Timeline from primary sources

Two cautions on this table. First, the March to May rows come from public research, not from Adobe, and should be read as that research's account; we could not load Adobe's bulletin text in this run (adobe.com refuses scripted requests), so we cannot independently confirm Adobe's own fix history, only what the CVE record says about affected and unaffected builds. Second, the October loader research describes one criminal campaign that used several entry points over time. It links earlier waves to this flaw; it does not say every compromised store was entered this way.

What the KEV entry says

Here is the KEV entry for CVE-2026-48356, field by field, as published in CISA's machine readable feed (catalog version 2026.10.27):

Why BOD 26-04 matters here, even if you are not a federal agency

BOD 26-04 was issued on 10 June 2026 and replaced the older BOD 22-01 approach, which used fixed KEV deadlines. The new directive sets remediation urgency from four variables:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE on the KEV catalog?
3. Exploit automation. Can an adversary automate all the steps of exploitation?
4. Technical impact. Does exploitation give partial or total control of the asset?

CISA publishes the last three for each CVE through its Vulnrichment program, as SSVC data in the CVE record. For CVE-2026-48356, the CISA coordinator SSVC entry in the CVE record's CISA ADP data reads exploitation: active, automatable: no, technical impact: total. KEV status is now yes. And for almost every store, the storefront is internet facing by design, because that is how customers buy things.

That combination puts the typical production store in a high urgency position under BOD 26-04's Table 1. Federal agencies should read their exact timeline from Table 1 in the directive. Everyone else can borrow the logic: an internet facing, KEV listed flaw with total technical impact should move to the front of the queue regardless of how your scanner sorts it. We have a separate explainer on BOD 26-04 remediation timelines and forensic triage.

The flaw: CWE-434 and how to read the record

CWE-434 in plain terms

CWE-434, "Unrestricted Upload of File with Dangerous Type", means software lets someone upload a file of a type that the environment will treat as code or as active content. The classic case is a web application that stores uploaded files somewhere inside its web root, accepts any file extension, and sits behind a web server that will run .php files it finds there. Upload a file, request its URL, and the server executes it.

What Adobe's record says

Adobe's CNA description in the CVE record says the flaw "could result in arbitrary code execution in the context of the current user, potentially gaining elevated access or control over the victim's account or session. Exploitation of this issue requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page. Scope is changed."

What the public research says

The research referenced in the NVD record describes the mechanism differently, and in more detail. According to that research, Magento's REST API accepts file uploads as part of cart item custom options. When a product option has the type "file", the platform processes an embedded file object with base64 data, a MIME type and a filename, and writes the file to pub/media/custom_options/quote/. The research says three checks were missing: the submitted option ID was not verified against the product's real options, the upload ran whether or not the product had a file type option, and dangerous extensions such as .php, .phtml and .phar were not blocked. The only check was an image header test, which a file that is both a valid image and valid PHP (a polyglot) passes.

The research says the most dangerous routes are the anonymous guest cart item routes in the REST API (/V1/guest-carts/:cartId/items and the matching update route), because they need no credentials, and that GraphQL mutations use a different code path and are not affected.

The same research separates three outcomes depending on version and web server configuration:

• Unrestricted file upload on all Magento Open Source and Adobe Commerce versions before the fix.
• Stored cross site scripting where uploaded content can be served and rendered, which the research ties to versions before 2.3.5 or custom web server configurations.
• Remote code execution through an uploaded PHP file where the web server will execute PHP in the upload directory, which the research ties to specific older stock nginx setups, non stock nginx configurations that pass every .php request to FastCGI, and older Apache setups without the PHP engine disabled for that directory.

Reading the two together

Adobe's scoring says user interaction is required. The research describes an unauthenticated upload. These are not necessarily in conflict. One plausible reading, and this is our interpretation rather than something either source states, is that Adobe scored the outcome its record describes (code running in a victim's context after they open a crafted URL or page, which matches the stored content path), while the research focuses on server side code execution on stores whose web server configuration allows it. The practical answer is the same either way: the upload itself is the root cause, the fix is Adobe's, and your web server configuration decides how bad things get before you apply it.

The CVSS vector, metric by metric

Base score 9.3, Critical.

Affected and fixed versions

The table below transcribes the affected data in the CVE record that Adobe submitted. It is the best structured source we could load. Adobe's bulletin APSB26-73 is the authority on the exact package names, patch files and install steps, and if it differs from this table, the bulletin wins.

Four things to notice.

The "2026-jul" labels are how the CVE record names the fixed builds. They are not normal Composer version strings. Adobe has used different delivery formats over time for security fixes, including full patch releases and isolated security patches applied on top of a release. Do not guess a Composer constraint from the label. Open APSB26-73 and use the package names and versions it gives.

2.4.9 appears in the affected column. The March research, as updated in May, says 2.4.9 contained the fix. The CVE record lists plain 2.4.9 as affected and a 2.4.9 July build as unaffected. We cannot reconcile that from the record alone. If you run 2.4.9, read APSB26-73 and assume you need whatever it lists for the 2.4.9 line until the bulletin tells you otherwise.

Magento Open Source 2.4.4 and 2.4.5 are not listed. The record lists Open Source only for the 2.4.6 to 2.4.9 lines. That most likely reflects Adobe's support windows, not a judgment that older Open Source releases are safe. The research says the vulnerable code has existed since the first Magento 2 release. If you run an older, unsupported line, treat yourself as affected and plan an upgrade, not a patch.

Adobe Commerce Events is separate. It is listed with its own version range (up to 1.20.0 affected, 1.21.0 unaffected). If you use it, it needs its own upgrade, in addition to the core fix.

Who is exposed

Exposure for this flaw depends on four things you can check:

1. Your version. Any store on a line listed above, below the July build or equivalent fix, is affected.
2. Whether the REST API guest cart routes are reachable.
3. Your web server configuration for pub/media/custom_options/. Whether uploaded files there can be fetched, rendered or executed decides whether an upload becomes stored script content, code execution or just an orphaned file on disk.
4. Whether you were already compromised. The research says many affected stores were hit months ago. If you patch today without looking, you may be closing the door with an attacker already inside.

Am I running an affected version?

Start with an inventory, not a guess. Agencies, hosts and in house teams often have more storefronts than anyone remembers: regional stores, B2B portals, staging copies, old campaign sites, and that one store a subsidiary still runs.

1. Ask the application

On each server or container, from the Magento root:

bin/magento --version

This prints the installed Magento CLI version. It is quick, but it does not tell you whether an isolated security patch was applied on top.

2. Ask Composer

Magento 2 is installed and updated through Composer. The lock file is the truth about what is deployed:

composer show magento/product-community-edition 2>/dev/null
composer show magento/product-enterprise-edition 2>/dev/null
composer show | grep -i "magento/"

The first metapackage is Magento Open Source, the second is Adobe Commerce. If you use Adobe Commerce B2B or Adobe Commerce Events, find their packages in the same composer show output and compare with the ranges above. If you build from a repository, composer.lock in the repository should match what is on the server; if it does not, that is a finding of its own.

3. Check the web server configuration

Magento's own sample nginx configuration, nginx.conf.sample in the Magento 2 source, includes a deny rule for the custom options upload location inside the /media/ handling:

location /media/custom_options/ {
    deny all;
}

The same file also denies /pub/media/ paths for downloadable, customer, import, custom_options and certain theme customization files. Compare your live configuration with the sample for your release. If your host wrote its own configuration, ask them directly whether requests to pub/media/custom_options/ are denied and whether .php files in pub/media can ever reach the PHP handler.

For Apache, Magento ships .htaccess files in media subdirectories. The research recommends confirming that pub/media/custom_options/.htaccess exists, denies access and disables the PHP engine. If your Apache uses a non default AccessFileName, or ignores .htaccess (AllowOverride None), those files do nothing and you need the equivalent rule in the server configuration.

A test you can run safely from outside, without uploading anything, is to request a path under the directory and confirm it is denied:

curl -s -o /dev/null -w "%{http_code}\n" https://shop.example.com/media/custom_options/quote/
curl -s -o /dev/null -w "%{http_code}\n" https://shop.example.com/pub/media/custom_options/quote/

A 403 or 404 is what you want. A 200 with a directory listing is a serious problem. Run this only against stores you own or are authorised to test.

Fix and workarounds

The fix: apply APSB26-73

1. Read APSB26-73 for your exact product and line. Note whether the fix is a release, a patch release or an isolated patch, and note any prerequisites.
2. Apply it in a non production copy first. Run your normal deployment pipeline: composer update or patch application, bin/magento setup:upgrade, dependency injection compile, static content deploy, cache flush, whatever your build already does.
3. Run checkout tests. Guest checkout, logged in checkout, any product with file type custom options, and any headless frontend that uses the REST cart API.
4. Deploy to production and re-run the version or patch check from the previous section on every node.
5. Upgrade Adobe Commerce Events to 1.21.0 or the version APSB26-73 names, if you use it.

If you are on a line that Adobe no longer supports, there may be no fix for your line at all. In that case the fix is an upgrade to a supported line, and until then the mitigations below are all you have.

Mitigations while you schedule the fix

These reduce risk; they do not remove the flaw. The first two come from Magento's own sample configuration and the public research. The rest are our suggestions.

• Deny web access to pub/media/custom_options/ in the web server, as in Magento's nginx.conf.sample. Place the nginx rule so that it is matched before any \.php$ location, or the PHP handler can still win.
• Make sure no .php file under pub/media can reach PHP. Magento's sample configuration only passes specific front controllers to PHP. Configurations that send every .php request to FastCGI are the ones the research ties to code execution.
• Suggestion: rate limit or filter the guest cart item routes at your edge if your web application firewall or reverse proxy can match REST paths and request body content, and if you can do so without breaking checkout. Test carefully; checkout outages cost money too.
• Suggestion: watch the upload directory. Alert on any new file in pub/media/custom_options/ that is not an expected image type, and on any file there whose name ends in .php, .phtml, .phar or .html.

Blocking web access to the upload directory does not stop files being written to disk through the API. The research makes this point clearly, and it is the reason the fix, not the workaround, is the goal.

After the fix: what to check

KEV listing means exploitation happened. The public research describes a consistent post exploitation pattern: a PHP webshell uploaded through the flaw, secondary backdoor files dropped elsewhere, then JavaScript injected into CMS blocks and pages. Patching stops new uploads. It does not remove what is already there.

The steps below come from the public research and from general incident response practice. The commands and queries are read-only starting points to test in a copy or a quiet window, not a complete detection. Treat them as a starting checklist and bring in your incident response process if you find anything.

1. Look in the upload directory

find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

On a store that does not sell products with file upload options, this should return little or nothing. Anything with a script extension is suspicious. So is an "image" whose size or content does not look like an image. The research reports polyglot GIF and PNG files dropped with names such as index.php or an option number followed by index.php, and images under pub/media/custom_options/quote/ that were really webshells.

2. Look for known backdoor file names

The research names a secondary backdoor file, accesson.php, dropped across multiple directories after the initial upload, and recommends checking pub/media/customer_address/ as well:

find . -name 'accesson.php' -type f
find pub/media/customer_address/ -type f ! -name '.htaccess'

3. Search CMS content for injected scripts

The October research found the loader in the cms_block table, which holds the static blocks Magento renders into storefront pages, and recommends searching both blocks and pages for the code patterns it uses rather than for domains, because domains are often encoded:

SELECT block_id, identifier, update_time
FROM cms_block
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

Run the same query against cms_page, and add your table prefix if your install uses one. update_time shows the most recent write, which is useful for your timeline. Be aware that legitimate themes and extensions can also use localStorage, so review each hit by hand.

4. Review admin users and integrations

Check admin_user for accounts you do not recognise, recent creation dates and recent password changes. Review API integrations and their tokens. The research recommends checking for unfamiliar processes on the host too.

5. Rotate credentials

If you find anything, rotate the database password, admin passwords, and API integration credentials once the attacker's access is removed. The research is explicit that deleting an injected script does not remove the attacker's ability to write to your database if they still hold credentials or a backdoor.

6. Check logs for the upload route

Search web server and application logs for requests to the REST guest cart item routes that you cannot tie to real checkout traffic, especially around the dates in the timeline above, and for requests to anything under media/custom_options/ that is not a normal image fetch. Keep the logs: under BOD 26-04 and its implementation guidance, federal agencies may have forensic triage obligations, and outside government your payment card obligations may require evidence too.

Technical details

This section collects the specifics a defender needs in one place. Everything here comes from the KEV feed, the NVD record or the public research referenced by NVD, as noted.

On related entries: the October research says some stores in the same campaign also had files uploaded through CVE-2025-54236, which the research calls SessionReaper and which Adobe fixed in APSB25-88. If you are patching for CVE-2026-48356, check that the earlier Adobe Commerce KEV entries are also closed on every store. Attackers who find one unpatched entry point often find others.

What would have helped

Practices any team can use

Know every store you run, and what version each is on. Most of the risk here sits in the stores nobody is watching. An inventory that lists every Magento and Adobe Commerce installation, its Composer lock file, its hosting, and its owner turns "are we affected?" from a week of emails into a query.

Track KEV, not just CVSS. CVSS told you this was critical in July. KEV told you in October that it was being exploited, and the public research said so in March. A process that only reacts to CVSS treats a 9.3 that nobody is exploiting the same as a 9.3 that is being sprayed across the internet. A process that watches KEV, and ideally public exploitation research for the platforms you run, gives you the signal to move.

Treat the web server configuration as part of the application. The difference between "an orphaned file on disk" and "code execution" here was largely the web server configuration. Keep that configuration in version control, compare it with the vendor's sample on every upgrade, and review it when you change hosts.

Watch CMS content, not just code. The injected scripts lived in database rows. Code review and file integrity monitoring miss that. A periodic diff of CMS blocks and pages, or an alert on writes to those tables outside your content team's normal hours, would have shown the change.

Where Safeguard fits

Adobe Commerce is commercial software and Magento Open Source is maintained by Adobe. The fix for CVE-2026-48356 has to come from Adobe, and Safeguard does not replace Adobe's bulletin, your web server configuration review or your incident response. Safeguard did not find this vulnerability, and nothing in this post should be read that way.

Where Safeguard helps is the work around the fix: knowing which of your projects carry affected Magento and Adobe Commerce packages, putting KEV listed findings at the top of the queue, stopping builds that would ship an affected version, and keeping the evidence of what you fixed and when.

How Safeguard helps, step by step

Step 1: inventory every store from its lock file

Safeguard's software composition analysis reads PHP projects through Composer, including composer.lock, and builds an SBOM for each project. Connect the repositories that hold your storefronts (and the ones your agencies maintain for you, if you have access), or scan a checked out copy with the Safeguard CLI or a local runner. Each project's SBOM then lists the Magento and Adobe Commerce metapackages and modules it actually pins, with versions. That gives you one place to answer "which stores are on which line" instead of asking every team.

Step 2: put KEV listed findings first

Safeguard shows CISA KEV status alongside each vulnerability, together with CVSS and EPSS, so findings for CVE-2026-48356 can be filtered and sorted ahead of findings that are only scored high. Reachability analysis helps rank findings in your own code paths. For a platform like Magento, where the vulnerable code is the platform itself, the KEV signal and the internet facing nature of the storefront matter more than a call graph, so use both views and do not let a "not reachable" label talk you out of patching a KEV listed platform flaw.

Step 3: gate the build on the fixed release

Create a Safeguard policy that fails any build whose SBOM contains an affected Magento or Adobe Commerce version for a KEV listed CVE, and attach it to the gates in your CI pipeline. Once a store moves to the fixed build, the gate keeps it there: a branch that reintroduces an old lock file, or a forgotten staging store being promoted, fails the check instead of shipping.

Step 4: track the work and keep the evidence

Assign each affected store to an owner, and track it to closure. Safeguard can open fix pull requests for dependency upgrades through autonomous remediation, which ships switched off with every category set to Manual. For a Magento platform upgrade, which usually needs database migrations and testing, you will often want a human to drive the change; the pull request is still a useful start because it shows the exact lock file change. When the work is done, the SBOM history and the gate results show when each store moved to the fixed build, which is the evidence an auditor or a payment card assessor will ask for.

Common mistakes

• Patching and stopping there. A KEV flaw that was exploited for months needs a compromise check, not just a patch.
• Trusting bin/magento --version alone. If the fix ships as an isolated patch, the version string will not change. Use the method Adobe's bulletin names to confirm.
• Guessing Composer constraints from the CVE record's "2026-jul" labels. Read the bulletin.
• Assuming 2.4.9 is safe. The CVE record lists plain 2.4.9 as affected. Confirm against APSB26-73.
• Only blocking the upload directory. Files can still be written through the API. It reduces impact; it does not fix the flaw.
• Putting the nginx deny rule after a catch all \.php$ location. Order matters; the PHP handler can still win.
• Ignoring staging and old stores. Attackers do not care which store is "real". A compromised staging store with production credentials is a production incident.
• Deleting an injected script without rotating credentials. The research is explicit that the attacker may keep write access to the database.
• Reading "user interaction required" as "low priority". On a storefront, every visitor supplies the interaction.

FAQ

Is CVE-2026-48356 being exploited?

Yes. CISA's KEV listing means there is reliable evidence of exploitation, and CISA's SSVC data in the CVE record marks exploitation as active. Public research referenced in the NVD record describes mass exploitation from March 2026. CISA lists known ransomware campaign use as "Unknown".

What is the KEV due date for CVE-2026-48356?

10 November 2026. That date binds US federal civilian agencies under BOD 26-04. For everyone else it is a useful outer limit, not a target.

Which version fixes CVE-2026-48356?

The CVE record lists July 2026 builds of each supported line (labelled 2.4.9-2026-jul, 2.4.8-2026-jul and so on) and Adobe Commerce Events 1.21.0 as unaffected. The exact package names and install steps are in Adobe's bulletin APSB26-73. Use the bulletin, not this post, as the source for what to install.

Is Magento 2.4.9 safe from CVE-2026-48356?

Not according to the CVE record, which lists 2.4.9 as affected and a 2.4.9 July build as unaffected. Public research said in May that 2.4.9 contained the fix, which we could not confirm from Adobe's side. Check APSB26-73 for the 2.4.9 line and follow it.

Does blocking pub/media/custom_options fix it?

No. It reduces impact by stopping uploaded files from being fetched or executed through the web server, but files can still be written to disk through the API. Apply the fix from APSB26-73.

How do I know if my store was compromised?

Check pub/media/custom_options/ and pub/media/customer_address/ for unexpected files, search for backdoor file names such as accesson.php, search cms_block and cms_page for injected scripts, review admin users and integrations, and review logs for the REST guest cart routes. If you find anything, treat it as an incident and rotate credentials.

Is the GraphQL API affected by CVE-2026-48356?

The public research says GraphQL mutations use a different code path and are not vulnerable, and names the REST guest cart routes instead. Apply Adobe's fix regardless.

Did Safeguard find this vulnerability?

No. Adobe published the CVE, the public research referenced in the NVD record describes the exploitation, and CISA added it to KEV. Safeguard helps with inventory, prioritisation, gating and evidence around the fix.

Checklist for this week

For the platform and e-commerce team:

1. List every Magento and Adobe Commerce installation, including staging, regional, B2B and agency hosted stores.
2. Record each one's product, line and version from composer.lock and bin/magento --version, plus any applied security patches.
3. Read APSB26-73 and map each store to the build or patch it needs.
4. Confirm pub/media/custom_options/ is denied by the web server on every store, and that no .php file under pub/media can reach PHP.
5. Apply the fix in staging, test checkout, deploy to production, and confirm on every node.
6. Upgrade Adobe Commerce Events if you use it.
7. Run the compromise checks: upload directory, backdoor file names, CMS blocks and pages, admin users, logs.
8. Rotate credentials on any store with findings.
9. Confirm the earlier Adobe Commerce KEV entries (including CVE-2025-54236) are closed on every store.
10. Add a CI gate so an affected version cannot be redeployed.

For this flaw, the fix itself has to come from Adobe, because Adobe Commerce and Magento are Adobe's platforms. But a Magento store is also a large Composer dependency tree of open source PHP packages and container images that you build and ship yourself, and the same habits that close the gap on a platform fix close it on those dependencies too.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The demo shows an npm change, not a Magento change. For a store repository you would make the same kind of request against composer.json and composer.lock, and review the diff and run your checkout tests before you commit.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For an agency or a host with many store repositories, that is how you scan each store's code and lock file without sending source anywhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask an assistant to look up a CVE's affected and fixed versions and its KEV status while you plan the work. Whether a given CVE is in your workspace's data depends on your account, so always confirm against the NVD record and Adobe's bulletin.

Click through it at your own pace, or open it full screen.

To try it on your own stores, download Safeguard or start with the CLI documentation.

Quick check

Sources

• CISA Known Exploited Vulnerabilities catalog entry: CVE-2026-48356
• CISA KEV catalog, machine readable feed (version 2026.10.27)
• NVD: CVE-2026-48356
• NVD API record for CVE-2026-48356
• Adobe security bulletin APSB26-73, the canonical source for fixed builds (also linked from the KEV entry at adobe.com); adobe.com may refuse automated requests, so open it in a browser
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk (10 June 2026)
• CISA BOD 26-04 Implementation Guidance
• MITRE CWE-434: Unrestricted Upload of File with Dangerous Type
• Magento 2 source: nginx.conf.sample
• Public research: PolyShell, unrestricted file upload in Magento and Adobe Commerce (17 March 2026, updated 12 May 2026)
• Public research: PolyShell mass attack wave (30 March 2026)
• Public research: Magento CMS block loader campaign (24 October 2026)
• NVD: CVE-2025-54236