Please complete the form to apply for a free scan account.
We'll get back to you as soon as possible.
Turaco Labs needs the information provided to contact you about our services.
Tags:
If you run Magento or Adobe Commerce, PolyShell deserves immediate attention.
At heart, this is a file upload problem in Magento’s REST API. An attacker can abuse cart item custom options to upload a file without logging in. In some environments, that can lead to remote code execution. In others, it can still leave attacker-controlled files on disk or create a path to stored XSS and account takeover. Either way, it is not a routine housekeeping issue. It is a compromise risk.
If you are busy, the practical message is simple: patch the platform, verify the server configuration, and check whether anything was dropped into the filesystem or database before you got there. Patching closes the hole. It does not tell you whether someone already came through it.
PolyShell is an unrestricted file upload flaw affecting Magento Open Source and Adobe Commerce. The issue sits in the REST API path for cart item custom options. A crafted request can place a file into the store’s upload area, typically under pub/media/custom_options/quote/. Depending on Magento version and web server behaviour, that can become stored XSS, account takeover, or remote code execution.
The key point for merchants is that this is not only about code execution. Even where execution is blocked, an attacker may still be able to plant files on the server. Those files can become useful later during a migration, a config change, or a second-stage attack. That is why this issue needs both remediation and post-incident review.
There has already been public reporting of active exploitation against vulnerable stores. That matters because it changes the question from “could this be abused?” to “has this already been abused on some stores like mine?” For merchants, that means the right posture is not just patching but verification.
In plain terms: if your store was exposed, you should assume the possibility of malicious uploads, tampered checkout code, or hidden backdoors until you have checked properly. That is the fastest route to a calm, evidence-based response.
Start with the upload area. Searchlight Cyber points merchants to pub/media/custom_options/quote/ as the path to review. If you see unexpected files there, especially anything that does not look like a normal image or expected upload, treat it seriously.
Then widen the search. Look for unfamiliar file changes across the codebase, especially in places attackers use for persistence. Review recent changes to CMS blocks, CMS pages, and key configuration records. If there is obfuscated JavaScript on storefront or checkout pages, unexplained payment-page changes, or altered content no one on your team can account for, that is enough to justify an incident response workflow. Public reporting on the attacks notes injected loaders and payment skimming activity following exploitation.
A merchant does not need to prove the full chain of attack on day one. The immediate goal is simpler: identify unauthorized change, contain exposure, and stop further damage.
This is where ThreatView can be genuinely useful.
ThreatView is designed to detect malware in files and databases, monitor unauthorized file changes, and watch for tampering on payment pages. In practical terms, that means it can help surface the kinds of follow-on changes merchants care about after a PolyShell-style intrusion: dropped files, altered templates, injected checkout scripts, modified CMS content, and database-resident malware that would not show up in a basic file-only review.
Its file integrity monitoring is particularly relevant here. When the immediate question is “what changed, and when?”, file integrity data gives you a much better starting point than manual guesswork. It can help narrow the scope of investigation and speed up cleanup.
ThreatView also monitors payment-page scripts and detects tampering on those pages. That matters because many merchants first discover a compromise only after checkout behaviour changes or card-data abuse is suspected. Payment-page monitoring helps close that blind spot.
Put simply, ThreatView helps with the part that patching does not solve: finding what was changed, where malware may have landed, and whether the checkout experience has been tampered with.
The first step is to apply Adobe’s security update for your supported branch under APSB25-94. Adobe lists patched versions including 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15, 2.4.4-p16, and corresponding Adobe Commerce B2B updates. If your store is not on a supported branch, that is now an operational issue, not just a technical one. Adobe Security Bulletin APSB25-94
The second step is to verify the web server configuration. This matters because exploitability depends in part on how uploaded files are handled. Check that access to pub/media/custom_options/ is appropriately restricted and that dangerous execution paths are not accidentally exposed through Apache or Nginx configuration. This is the sort of quiet detail that often separates a near miss from a breach.
The third step is to inspect and clean. Review the upload path, scan for unauthorized file changes, inspect CMS and checkout content, and look for injected JavaScript or unfamiliar loaders. If ThreatView is in place, use it to identify filesystem changes, database malware, and payment-page tampering before you begin cleanup. That gives you a much more reliable - and quicker - approach to remediation.
The fourth step is basic containment. Rotate admin credentials, integration keys, deployment secrets, and any other sensitive values that may have been exposed to the application. If compromise is plausible, do not assume credentials are still trustworthy simply because you cannot see clear abuse yet.
PolyShell is serious, but it is manageable if you approach it in the right order.
First, patch the platform.
Second, verify the server configuration.
Third, determine whether anything landed in the filesystem, the database, or the checkout experience before the fix went in.
This sequence takes you from uncertainty to control very quickly.
Adobe Security Bulletin APSB25-94
Searchlight Cyber: Magento PolyShell – Unauthenticated File Upload to RCE in Magento
BleepingComputer: New ‘PolyShell’ flaw allows unauthenticated RCE on Magento e-stores
BleepingComputer: PolyShell attacks target 56% of all vulnerable Magento stores
At Turaco Labs, our ThreatView telemetry has detected a concerning spike in compromised PrestaShop websites. As of this morning, we have identified 327 hacked sites actively running payload loaders or digital skimmer malware.
PrestaShop has recently issued a security alert warning store owners about a digital skimmer threat targeting their platform. If you're running a PrestaShop store, this is an important reminder to verify your site's security.
With growing numbers of clients hosting with WP Engine, we felt it may be useful to highlight how a WordPress eCommerce site security is handled by combining WP Engine and ThreatView.
TLDR: WP Engine gives you high-performance managed WordPress hosting. ThreatView Advanced makes sure your website stays secure.
