PolyShell: When a File Upload Becomes an Attack Path in Magento

A file-upload endpoint can look harmless during a web penetration test. The application accepts a file, stores it in a media directory and returns a successful response.

But three questions determine the actual security impact:

• Can an unauthenticated user reach the upload functionality?
• Can the attacker control the type, name or location of the stored file?
• What will the web server do when someone requests that file?

PolyShell, tracked as CVE-2026–48356, demonstrates why those questions belong in the same assessment.

On 27 October 2026, CISA added the vulnerability to its Known Exploited Vulnerabilities catalog. Adobe had published a security update on 14 July. Recent reporting from Sansec describes a wider campaign involving malicious files and storefront content, including hundreds of stores associated with PolyShell-related access.

For penetration testers, this is not just a lesson in upload validation. It is a lesson in tracing an input-validation flaw through storage, server configuration, persistence and the customer-facing application.

Research cutoff: 29 October 2026. The analysis below separates the documented vulnerability, the conditions required for code execution, and the evidence of subsequent compromise.

1. Vulnerability snapshot

The score discrepancy is worth understanding rather than silently choosing one value. Adobe's bulletin scores the issue at CVSS 3.1: 9.6, including low availability impact. The NVD/CVE record lists 9.3, with no availability impact. Both rate it critical; neither requires privileges for the attack described.

Sources: Adobe security bulletin APSB26–73, NVD CVE record, CISA KEV catalog.

2. What is actually broken?

Sansec's original technical analysis, published on 17 March 2026, describes a file-upload path in Magento's REST API associated with cart-item custom options.

When the relevant option is processed, the application accepts a file_info object containing file data, a MIME type and a filename. The uploaded content is written under:

pub/media/custom_options/quote/

According to Sansec, the vulnerable path lacks three important controls:

1. Option validation: the supplied option ID is not adequately verified against the product's actual options.
2. Option-type enforcement: file-upload processing is not properly restricted to a legitimate file-type option.
3. Extension validation: dangerous extensions are not adequately blocked.

The remaining image-header check is insufficient to establish that the content is a safe image.

This is where the term polyglot comes in: a file can be constructed to satisfy an image-format check while also containing content interpreted differently by another component.

The security failure is not simply that a file has an unusual extension. It is that the application trusts insufficient evidence about the file's contents and intended use.

Sansec identifies the anonymous guest-cart routes as affected paths:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

In an installation, these routes appear under the applicable REST prefix, commonly /rest/ and a store code.

These are useful defensive investigation pivots, not a reason to send exploit payloads to a live store. Sansec also reports that GraphQL mutations use a different code path and are not affected by this particular flaw.

Source: Sansec — PolyShell technical analysis.

3. From upload primitive to code execution

A penetration tester should separate the attack into distinct stages.

Stage A: Reachable upload functionality

The guest-cart API is designed to support customers who have not logged in. That is normal application behavior, but it means the relevant route can be exposed to unauthenticated requests.

The assessment question is whether the API enforces the expected relationship between the product, its custom options and the type of file it is permitted to accept.

A route being publicly reachable is not, by itself, a vulnerability. The weakness arises when the route accepts an unauthorized file operation.

Stage B: File written to disk

The application writes the uploaded content to its media directory. Even if the server refuses to execute the file, the upload may still succeed.

That distinction matters because an application-level patch and a web-server rule address different layers:

• The application fix should prevent the invalid upload.
• The web-server configuration should prevent files in upload directories from being interpreted as executable code.

A web-server rule alone does not necessarily stop a malicious file from being stored.

Stage C: Server-side interpretation

Whether the uploaded file becomes remote code execution depends on the web-server configuration and PHP handler behavior.

Sansec identifies vulnerable configurations involving older nginx behavior, custom nginx rules that pass uploaded PHP files to FastCGI, and certain older Apache configurations.

A store with the same vulnerable application code can therefore have a different practical outcome depending on its execution boundary.

This is a key assessment lesson: a file-upload finding should describe both the upload primitive and the verified impact.

If you have demonstrated an unauthorized file write but have not demonstrated code execution, report the file-write primitive and explain the execution risk. Do not label every upload as confirmed RCE.

Conversely, if execution is possible, the resulting process generally inherits the privileges of the web-server/PHP service. That does not automatically mean root access, and the impact must be established separately.

Source: Sansec's technical analysis and configuration guidance.

4. What the recent exploitation reports tell us

The latest reporting makes the post-exploitation phase particularly important.

On 26 October, The Hacker News reported Sansec's findings on a campaign affecting 953 online stores, mostly running Magento. Sansec estimated that 471 stores had received a malicious loader through PolyShell, while another 102 had files uploaded through PolyShell or SessionReaper, a separate vulnerability.

The campaign involved JavaScript loader code placed in Magento CMS blocks. Some observed versions filtered visitors based on browser characteristics, reducing what scanners and automated analysis would see. The exact final payload was not established in the reporting.

One reported case also involved a Magento store with no missing core patches that had a rogue administrator account used to inject malicious content.

These details should be interpreted carefully:

• The figure of 953 refers to the wider campaign, not 953 confirmed PolyShell compromises.
• The 471 figure is Sansec's estimate of stores injected through PolyShell.
• The rogue administrator case demonstrates why a clean patch status does not prove that a system has not been compromised.

Source: The Hacker News, 26 October 2026–953-store campaign.

Why patch status and compromise status are separate questions

A patch can stop an attacker from repeating the original upload operation. It cannot automatically remove files already written to disk, delete unauthorized administrator accounts or reverse changes to CMS content.

That means incident response must investigate both:

1. The original access path: is the vulnerable upload behavior fixed?
2. The resulting system state: did an attacker leave files, accounts, scripts, credentials or other persistence behind?

For a store that was exposed before the July update, the second question deserves particular attention.

5. Public PoC and research review

The goal of a PoC review is to establish what the evidence proves — not to repeat the repository's strongest marketing claim.

Sansec's technical analysis is the primary technical reference for the upload flaw. Adobe's bulletin is the primary reference for the vendor's affected and fixed builds.

A third-party PoC index for CVE-2026–48356 identifies a public repository associated with an unauthenticated guest-cart upload demonstration. The available description says that the PoC creates a guest cart, submits a polyglot file through the custom-options path, and checks whether the returned JSON contains the uploaded filename.

That proof criterion matters.

A filename appearing in the response demonstrates evidence of the upload operation; it does not, by itself, demonstrate that the server executed the file.

A complete impact assessment would need to establish the behavior of the deployed web-server configuration as well. The third-party index is not an independent security audit of the repository, so its description should not be treated as conclusive validation of every claim.

For safe assessment work, use the public research to understand the affected code path, and verify the fix in an isolated staging environment. Do not run a web-shell PoC against a production storefront or a third-party target.

6. Safe, authorized validation workflow

The following workflow is designed for an authorized penetration test or a defensive review. It does not require deploying a web shell.

Step 1: Inventory every Magento installation

Include production, staging, QA, migration copies and agency-managed storefronts.

From the relevant Magento installation, inspect the version:

bin/magento --version

bin/magento --version

For Magento Open Source, inspect the applicable Composer package:

composer show magento/product-community-edition

composer show magento/product-community-edition

For Adobe Commerce, inspect the applicable enterprise package:

composer show magento/product-enterprise-edition

composer show magento/product-enterprise-edition

These checks help identify the installation, but they are not a substitute for confirming the actual security patch level.

Step 2: Verify the exact fix

Adobe's APSB26–73 bulletin lists the following fixed releases:

• Product: Adobe Commerce Fixed release: 2.4.9–2026-jul, 2.4.8–2026-jul, 2.4.7–2026-jul, 2.4.6–2026-jul, 2.4.5–2026-jul, 2.4.4–2026-jul
• Product: Magento Open Source Fixed release: 2.4.9–2026-jul, 2.4.8–2026-jul, 2.4.7–2026-jul, 2.4.6–2026-jul
• Product: Adobe Commerce B2B Fixed release: Corresponding -2026-jul releases across the affected B2B lines
• Product: Adobe Commerce Events Fixed release: 1.21.0

Do not assume that a major version number alone proves the fix is installed. Adobe's affected-version table includes 2.4.9, while its solution table specifies the 2.4.9-2026-jul build. Confirm the precise release or applied security patch against the vendor bulletin.

Source: Adobe APSB26–73.

Step 3: Review upload and execution boundaries

In a staging environment, verify that:

• Guest-cart operations reject invalid file options.
• File upload processing is limited to legitimate product options.
• Unapproved file types and extensions are rejected.
• Files in pub/media/custom_options/ cannot be interpreted as server-side executable code.
• The relevant web-server rule takes precedence over any generic PHP handler rule.

Use harmless test files and normal application validation. A successful request status alone is not proof that the upload controls are correct.

Step 4: Inspect files already on disk

Review pub/media/custom_options/ and its subdirectories for unexpected files, especially scripts or files with image extensions that contain unexpected content.

Useful investigation signals include:

• New or modified files that do not match normal store activity.
• Unexpected PHP-family extensions in upload directories.
• Suspicious file timestamps correlated with guest-cart API traffic.
• Files that are present despite the store having been patched afterward.

A suspicious file should be investigated, not automatically deleted before evidence is preserved.

Step 5: Review the CMS and administrator accounts

Inspect Magento's CMS blocks and pages for unauthorized scripts or unfamiliar external domains.

Review administrator accounts, role assignments and account-creation events for changes that cannot be explained by normal operations.

Sansec's October reporting identified loader domains including additionalver[.]com and deepveindrilling[.]com. Treat these as investigation pivots from the reported campaign, not as a complete or permanent blocklist.

Correlate CMS changes with file timestamps, application logs, administrator activity and outbound connections. A malicious script in a CMS block may survive removal of the original uploaded file.

7. Detection and telemetry

A useful detection strategy correlates activity across the application, file system and web server.

Application and access logs

Review requests to guest-cart item routes for unusual upload-related activity, repeated validation failures and unexpected request patterns.

The routes are legitimate storefront functionality, so an alert should not assume that every guest-cart request is malicious. Prioritize anomalies that correlate with unexpected files or subsequent administrative changes.

File-system monitoring

Alert on new executable-looking files in media and custom-option directories, especially when those files are created shortly after suspicious API requests.

File extensions alone are not enough: inspect file contents and execution behavior using an approved forensic process.

CMS and identity auditing

Monitor changes to CMS blocks, CMS pages, administrator accounts and role assignments.

A compromised storefront may have multiple persistence mechanisms. If the attacker has already gained administrative access, looking only for a web shell can miss a database-backed loader.

MITRE ATT&CK mapping

• T1190 — Exploit Public-Facing Application: appropriate for the initial exploitation of the exposed REST API.
• T1505.003 — Web Shell: appropriate when evidence confirms a server-side web shell was planted.
• T1059.007 — JavaScript: potentially relevant to execution of malicious JavaScript in a browser, depending on the observed activity.

Map techniques to evidence from the actual incident. An upload vulnerability does not prove that every subsequent technique occurred.

8. Remediation and recovery

The immediate priority is to apply the relevant Adobe security update, including to staging and secondary instances. CISA's KEV listing is an additional reason to prioritize remediation, but the patch is only one part of recovery.

A practical response sequence is:

1. Confirm the exact affected product and security patch level.
2. Apply the relevant APSB26–73 fix and verify it on every deployed node.
3. Restrict access to, and execution from, upload directories using supported web-server configuration.
4. Preserve logs and investigate suspicious files, CMS content and administrator changes.
5. Remove confirmed unauthorized persistence through a controlled incident-response process.
6. Rotate affected credentials and secrets if compromise is established or reasonably suspected.
7. Re-test the upload validation and execution boundary in staging.
8. Monitor the store for renewed suspicious uploads, CMS modifications and unexpected outbound activity.

Adobe's July bulletin stated that it was not aware of exploits in the wild for the issues it addressed. Sansec subsequently reported exploitation activity, and CISA added CVE-2026–48356 to KEV on 27 October. Those statements have different publication dates and sources; the later exploitation reporting should inform today's response priority.

Sources: Adobe's bulletin, Sansec's research, CISA KEV catalog.

9. What I would take into a penetration test

PolyShell reinforces three practical lessons.

First, test the entire file lifecycle. Follow the upload from authorization and validation through storage, retrieval and server-side handling. A successful upload is only one piece of the impact assessment.

Second, test the boundary between application code and server configuration. The same application weakness can have very different consequences depending on whether the upload directory is publicly accessible and whether the server interprets uploaded files as code.

Third, validate the post-exploitation state. A fixed version can still contain malicious files, unauthorized administrators or scripts injected into database-backed content.

For red teamers, the useful exercise is to establish which controls prevent the upload, which controls prevent execution, and which telemetry detects suspicious persistence. For defenders, the key question is whether patch verification and compromise assessment are treated as separate tasks.

A patch closes a known route in. It does not prove that nobody came through it before the fix was applied.