Mass Exploitation and Targeted Compromise of Magento and Adobe Commerce

All identifying details of the merchant, its service providers, its personnel and its infrastructure have been removed from this paper. Public indicators are reproduced from public research only.

Public release. The current version of this paper is published at www.intersecworldwide.com/magento-adobe-commerce-security-white-paper.

Since 2024 the Adobe Commerce and Magento ecosystem has absorbed a sequence of large scale, automated exploitation waves.

Four vulnerabilities and one exfiltration technique stand out: CosmicSting (CVE-2024-34102, 2024), SessionReaper (CVE-2025-54236, 2025), PolyShell (the file upload weakness covered by Adobe bulletin APSB25-94 and named by Sansec in March 2026), StyleSmuggler (CVE-2026-75650, a September 2026 zero day), and a payment skimmer that exfiltrates card data over WebRTC DataChannels and was observed being delivered through PolyShell. Independent security research records the first three as mass events measured in thousands of stores, not isolated incidents, and the fourth as under active exploitation before a fix existed (Sansec, 2026a, 2026c, 2026d; The Hacker News, 2025). Separately, general purpose botnets probe the same hosts continuously for any exploitable weakness.

This paper sets out a practical conclusion drawn from that public record and from a payment card forensic investigation Intersec Worldwide completed in 2026: ecommerce merchants face two layers of activity at once. The first layer is broad and automated. THREAT ACTORS scan the internet, select victims by vulnerability rather than by name, and deploy commodity webshells and skimmer kits at machine speed. The second layer is targeted and hands on. After an environment is breached, THREAT ACTORS adapt to the specific store, seize privileged accounts, and establish persistence that survives routine cleanup. A single environment can show both layers operating in parallel and can also be probed by unrelated general purpose botnets in the same period.

The defensive implication is direct. Patching is necessary but not sufficient, and for the PolyShell weakness a patch did not exist for the supported release lines at all: the fix reached production only in Adobe Commerce 2.4.9 on 12 May 2026 (Adobe, 2026b), so every store on 2.4.6, 2.4.7 or 2.4.8 was exposed for the whole exploitation wave with nothing to install.¹ A stolen encryption key keeps working after the vulnerability that exposed it is fixed. A strict Content Security Policy does not stop exfiltration that leaves over WebRTC. Effective defense pairs prompt patching, or the web server mitigation when no patch exists, with key rotation, administrator account and integration token review, network egress controls, and continuous monitoring of the live checkout page. One gap deserves separate attention: Magento Open Source does not produce an administrative action log at all, which is both a forensic blind spot and a PCI DSS Requirement 10 problem that no amount of configuration inside the platform will close (Section 5.4).

1 Bulletin APSB25-94 (14 October 2025) shipped 2.4.8-p3, 2.4.7-p8 and 2.4.6-p13 as the fix versions for those lines, but the upload handler change that closes PolyShell existed on that date only in the 2.4.9-alpha3 pre release (Adobe, 2025b; Searchlight Cyber, 2026). Section 8.2 explains why a bulletin date must not be read as a patch availability date.

The vulnerabilities below are not theoretical. Each has public proof of concept or public technical analysis, documented mass exploitation, and named research from more than one independent vendor. The dates and figures in this section are drawn from that public research and are cited in the reference list; where this paper could not confirm a figure against a primary source on 10 September 2026, the figure has been removed rather than repeated.

CosmicSting is an unauthenticated XML External Entity (XXE) vulnerability in Adobe Commerce and Magento. In plain terms it lets an attacker read secret files from the store's server without any login or password. Through it, THREAT ACTORS submit crafted XML to read files from the server; the typical objective is the secret encryption key stored in app/etc/env.php . With that key THREAT ACTORS forge administrator API tokens, modify content blocks through the Magento API, and inject payment skimming JavaScript. Public reporting recorded about 4,275 merchants, roughly five percent of all Adobe Commerce and Magento stores, compromised during the summer of 2024, and named major brands among the victims (The Register, 2024). The point for defenders is that patching CVE-2024-34102 does not invalidate a key that was already stolen; the key must be rotated, and researchers warned that stores that removed malware without rotating keys were reinfected within days (The Register, 2024).

1.2 SessionReaper (CVE-2025-54236)

SessionReaper (CVE-2025-54236) is an improper input validation vulnerability in the Adobe Commerce and Magento REST API, rated CVSS 9.1. It allows customer account takeover and, under certain conditions (particularly file based session storage), unauthenticated remote code execution (Adobe, 2025a; The Hacker News, 2025).

Adobe released an emergency hotfix on 9 September 2025 (Adobe, 2025a). A draft of the fix had circulated the week before the scheduled release, which matters because attackers compare a patch against unpatched code to reconstruct the flaw it closes; the vulnerability itself was reported privately and was not disclosed ahead of the fix. A public technical analysis appeared on 22 October 2025, and automated exploitation began the same day, with more than 250 attempts against multiple stores from five addresses in the first 24 hours (The Hacker News, 2025). At that point about 62 percent of Magento stores had still not installed the update six weeks after its release; by 26 October the attacks had reached 49 percent of all stores, and 16 to 18 percent of stores carried one or more injected backdoors (The Hacker News, 2025, citing Sansec). Observed payloads included PHP webshells uploaded through the customer address file upload path, phpinfo probes, and backdoors planted as fake session files. Adobe folded the SessionReaper fix into the October 2025 patch releases, including 2.4.6-p13 (Adobe, 2026a).

1.3 PolyShell (Adobe bulletin APSB25-94)

PolyShell is an unauthenticated file upload weakness in the Magento REST API guest cart path that leads to remote code execution. THREAT ACTORS upload a polyglot file, a single file that is valid in two formats at once (for example a GIF image that also contains executable PHP), and the platform writes it to a web reachable media directory; where the web server executes PHP from that directory, the attacker then requests the file and runs code (Sansec, 2026a; Searchlight Cyber, 2026). Sansec published the technique on 17 March 2026, having first observed exploitation on 16 March, and mass exploitation followed within days: more than fifty scanning addresses were engaged at once, and Sansec reported on 30 March that 471 stores had been compromised in a single hour, with a

secondary backdoor named sprayed across compromised stores and a loader domain injected into

store content (Sansec, 2026a, 2026c; The Hacker News, 2026).

The patch record for PolyShell is unusual and is stated here precisely because it was misread in earlier drafts of this paper.² Adobe changed the upload handler on 14 October 2025 only in the 2.4.9 pre release branch

(2.4.9-alpha3). The security patches that bulletin APSB25-94 shipped for the production lines (2.4.8-p3, 2.4.7-p8, 2.4.6-p13) did not carry that change, and neither did the March 2026 (APSB26-05; Adobe, 2026g) or May 2026 (APSB26-49; Adobe, 2026c) security patches for those lines. The first production release that closes the weakness is Adobe Commerce 2.4.9, released on 12 May 2026 (Adobe, 2026b), which for a store on an older line is a major version upgrade, not a patch. Between 17 March and 12 May 2026, and for any store still on 2.4.6, 2.4.7 or 2.4.8 today, the operative defense is a web server rule that prevents PHP execution from the media upload directory (Section 8.1). After gaining code execution, THREAT ACTORS commonly drop a secondary backdoor and inject browser side skimming code.

The newest evolution in skimming is a payment skimmer that loads its payload and exfiltrates stolen card data over WebRTC DataChannels rather than ordinary web requests. WebRTC traffic runs over encrypted UDP, not HTTP. Two consequences follow. First, security tools that inspect HTTP traffic never see the stolen data leave. Second, a Content Security Policy that blocks unauthorized HTTP connections does not govern WebRTC, so a store with a strict policy is still exposed. Sansec first documented this channel on 24 March 2026 at a car maker it describes as worth more than 100 billion dollars, and RH-ISAC recorded the skimmer being delivered through the PolyShell weakness, whose mass exploitation had been under way since 19 March 2026 (Sansec, 2026b; RH-ISAC, 2026).

The skimmer reuses a valid Content Security Policy nonce taken from an existing script on the page and executes during browser idle time, both of which reduce its visibility (RH-ISAC, 2026).

A further ecosystem level vector does not exploit a platform flaw at all. It ships malicious code inside trusted third party components. In May 2025 Sansec disclosed that 21 commercial Magento extensions from three vendors (Tigren, Meetanshi and MGS) had been backdoored on the vendors' own distribution servers. The malicious code, hidden in a file normally used for license checks, had been present in packages for about six years and was activated in April 2025, giving THREAT ACTORS the ability to run arbitrary code on every store that had installed an affected extension. Between 500 and 1,000 stores were estimated compromised, including one belonging to a 40 billion dollar multinational; a fourth vendor's tag manager extension was also found compromised on at least one site, with the point of compromise (vendor or site) unconfirmed (Sansec, 2025; BleepingComputer, 2025).

This is the same risk class that produced the Polyfill.io incident, in which a widely used JavaScript library served from a content delivery network was taken over and used to push malicious code to more than one hundred thousand websites at once (Sonatype, 2024). The common thread is that the victim never installed anything malicious. They trusted a component, and the component was compromised upstream. The 2025 Verizon Data Breach Investigations Report found a third party involved in 30 percent of breaches, double the share of the previous year (Verizon, 2025). For a Magento operator the attack surface is therefore not only the platform and the host; it is every extension, script and supplier the storefront loads.

1.6 StyleSmuggler (CVE-2026-75650), September 2026

The pattern continued while this paper was being finalized. On 5 September 2026 Sansec published StyleSmuggler, an unauthenticated remote code execution zero day in the Magento template engine: attackers inject PHP through style related template properties, and the code executes when a transactional email is rendered (Sansec, 2026d; Tenable, 2026). Exploitation began on 4 September, three days before a fix existed, and multiple victim stores were confirmed across separate campaigns. Adobe released hotfix VULN-39341 under bulletin APSB26-146 on 7 September 2026, rated CVSS 10.0, affecting Adobe Commerce 2.4.4 through 2.4.9 and Magento Open Source 2.4.6 through 2.4.9, and acknowledged exploitation in the wild (Adobe, 2026d; Tenable, 2026). Adobe's guidance goes beyond the patch: merchants are told to rotate not only the encryption key but every credential that may have been encrypted with it, including server, API and integration credentials (Adobe, 2026d). That instruction is the vendor's own statement of the lesson this paper draws from CosmicSting and PolyShell: a fixed vulnerability does not undo what was taken through it.

A fixed vulnerability does not undo what was taken through it.

2 Adobe Security Bulletin APSB25-94, published 14 October 2025, lists affected versions "2.4.9-alpha2 through 2.4.6-p12 and earlier" and fix versions "2.4.9-alpha3 ... through 2.4.6-p13" (Adobe, 2025b). Searchlight Cyber (2026): "A change to the upload handler was introduced in 2.4.9-alpha3 back in October, but this change was not applied to the other non-alpha versions." Adobe's 2.4.6 releasenotes list no file upload fix in 2.4.6-p13, p14 or p15 (Adobe, 2026a); the released versions page dates 2.4.9 to 12 May 2026 (Adobe, 2026b).

The vulnerabilities above share one property: they are exploited at scale by automation. That is the first layer of the model. The second layer appears after access is gained, when activity becomes deliberate and environment specific. The two layers are distinct in tempo, in tooling, and in what they tell defenders about risk.

In the automated layer THREAT ACTORS do not choose a victim; they choose a vulnerability and let scanning find the victims. The signatures are consistent across the public record and across our forensic casework: high volume scanning from many addresses, identical payloads deployed across unrelated stores, and a short interval between a public analysis and mass exploitation. Tooling is commodity. The same polyglot webshell families, the same secondary backdoors and the same skimmer kits recur across unrelated victims, which indicates a shared criminal supply chain rather than bespoke development for each target.

2.2 Hands on layer

Once an environment is breached, a second pattern emerges that automation alone does not explain. THREAT ACTORS study the specific store, identify its trusted vendors and privileged users, and take deliberate steps to hold access. Techniques in this layer include registering a domain that closely resembles a legitimate vendor domain, driving a password reset workflow to seize a named administrator account, enrolling attacker controlled multifactor

authentication, and modifying other administrator records to broaden and preserve control. These actions are tailored to one victim and are carried out by hand. They are the reason that resetting passwords and removing a single backdoor often fails to evict the THREAT ACTORS.

A specific and effective technique in this layer is password reset capture. THREAT ACTORS first arrange for a privileged account's email address to point to a mailbox they control on a lookalike domain. They then trigger the standard forgot password flow, and a valid reset link is sent to that mailbox. With the link they complete the reset, reach the administration area, and enroll their own multifactor authentication. From that point the account is fully theirs, and ordinary recovery steps such as the legitimate user resetting a password do not help, because the account no longer routes to the legitimate user. What makes this dangerous is that the enabling change can leave no trace in application logs.

Mass exploitation of ecommerce platforms does not occur in isolation. Internet facing web servers, including Adobe Commerce and Magento hosts, sit under continuous, indiscriminate automated exploitation from general purpose botnets that are unrelated to any single platform campaign. This activity is distinct from the targeted compromise described above. It is presented separately, and deliberately, because conflating it with the platform campaign would misstate the evidence. It is included because it independently corroborates the automated half of the threat model.

3.1 Platform campaigns

The Magento specific waves are driven by automation, not by individuals working by hand. Public research recorded more than fifty distinct addresses scanning for the PolyShell weakness at the same time, and exploitation reaching hundreds of stores in a single hour (Sansec, 2026a, 2026c). The short interval between a public analysis and mass exploitation, measured in hours for SessionReaper and in days for PolyShell, is only achievable with prepositioned automated infrastructure. Distributed scanning and exploitation on this scale are the defining signature of the broad layer.

3.2 General purpose botnets

Alongside platform specific campaigns, general purpose botnets attempt to exploit any reachable web vulnerability across the internet. RondoDox is a representative and well documented example. First observed in late May 2025, it is a multi vendor "exploit shotgun" botnet that by March 2026 had been mapped to 174 different exploits covering 148 CVEs across routers, video recorders, surveillance equipment and web servers (Bitsight, 2026; Trend Micro, 2025). It gains shell access through command injection flaws, retrieves a first stage shell script downloader named

in the pattern through a remote fetch piped to a shell, and deploys a payload used for distributed

denial of service and cryptomining (Bitsight, 2026). Public reporting has tracked it exploiting recent critical flaws, including the XWiki injection (CVE-2025-24893) and the React2Shell flaw (CVE-2025-55182) (Bitsight, 2026).

3.3 Forensic observation

During the investigation our forensic investigators observed an attempted botnet recruitment against the environment. On 21 November 2025 a command injection attempt directed at a non Magento PHP endpoint carried a payload that fetched a first stage shell script downloader matching the documented RondoDox naming pattern and piped it directly to a shell. The attempt is consistent with opportunistic, indiscriminate botnet spray rather than with the targeted Magento campaign. It shows that the same infrastructure is probed continuously by automated threats that select hosts by reachability, not by platform.

3.4 Botnet assessment

The botnet dimension is not part of the targeted Magento campaign and should not be read as part of it. Its value is corroborative. An ecommerce environment already under investigation for a Magento specific compromise was, in the same period, also a target of general purpose botnet automation. That convergence reinforces the central finding of this paper: any reachable ecommerce host is a standing target for automated exploitation from more than one unrelated source at once. Defenders who scope their exposure to the ecommerce platform alone understate the automated pressure on the host.

3.5 Automated probing

Beyond the platform campaign and the botnet recruitment attempt, the same environment absorbed a steady volume of unrelated automated probing aimed at any weakness that might pay off. Investigators identified it by pattern analysis of the web access logs: distinct bursts of requests that share a tool signature (a common user agent, a fixed request shape, a short time window, or a spread of source addresses hitting the same endpoint) and that do not match normal customer traffic. Four classes stood out.

Distributed SQL injection probing appeared as 36 UNION SELECT query fragments from 13 addresses inside a single three hour window on one day.

File inclusion probing from 31 addresses over eight days targeted a known PEAR command path used to read files or run code.

Cart identifier enumeration walked through sequential guest cart identifiers for 137 days (1,028 requests from two addresses), a pattern associated with harvesting order and customer records.

Cloud metadata probing made 84 attempts over 22 days to reach the host's internal instance metadata service, the route an attacker uses to steal cloud credentials.

In this environment none of these succeeded. The metadata service exposed nothing, and the injection and inclusion probes matched scanner behavior rather than successful exploitation. The reason a THREAT ACTOR runs all of these against one host is economic. Each class targets a different prize (the database, the file system, cloud credentials, customer records), and automation makes it nearly free to try every one and keep whichever works. For a defender the lesson is that the platform vulnerability is only the loudest of many simultaneous probes, and that distinguishing scanner noise from a successful hit requires looking at outcomes rather than only at the presence of the probe.

The following observations are drawn from a payment card forensic investigation of a compromised Adobe Commerce environment that ran from April to June 2026. All identifying details of the merchant, its service providers, its personnel and its infrastructure have been removed, and no source address, account identifier or ticket reference from the investigation appears in this paper.³ The observations are presented because they show both layers of the model in one environment.

The store initially ran Adobe Commerce and later switched to Magento Open Source; the release examined here was 2.4.6-p13, the current security patch for its release line from 14 October 2025 until 10 March 2026 and one patch level behind on unrelated fixes after that. It was therefore fully patched against SessionReaper, whose fix 2.4.6-p13 includes (Adobe, 2026a), and exposed to PolyShell, for which no patch existed for its line at any point during the intrusion (Section 1.3). That combination is worth stating plainly, because it is the situation most merchants on a supported older line were in during the spring of 2026.

Our investigators documented what we assess to be several distinct THREAT ACTOR groups operating in the same environment in parallel: a defacement actor, a financially motivated webshell operator, multiple browser side payment skimmers using the WebRTC DataChannel technique, and automated vulnerability scanners. The presence of several unrelated operator groups in one store is itself a marker of ecosystem level targeting rather than a single bespoke intrusion.

Case timeline

21 Nov 2025 Botnet recruitment attempt. RondoDox-pattern downloader against a non Magento PHP endpoint. Unrelated to the platform campaign.

29 Jan 2026 Last known good. Outbound mail record shows the administrator account still on its legitimate address.

18 to 21 Feb 2026 Polyglot upload tooling activity. Three to four weeks before public disclosure.

25 Mar 2026 First confirmed successful polyglot upload. Eight days after Sansec's disclosure.

12 Apr 2026 PNG and PHP polyglot file dropper (1,159 bytes) written to the shared media volume.

13 Apr 2026 246 identical webshells in 17 minutes 26 seconds, within a population of 421 instances across two variants.

April 2026 Password reset capture takeover. Lookalike domain registered the same day; CSP saved within half an hour; a second pair of policy writes nine days later.

3 to 11 Jun 2026 Head include skimmer removed and reinserted until the compromised account path was closed.

After 11 Jun 2026 No further skimmer signal in browser side monitoring.

The automated layer was unmistakable. The earliest confirmed successful polyglot upload was on 25 March 2026, eight days after Sansec's public disclosure. On 13 April 2026 investigators recorded a burst of 246 identical webshell files written to the shared media volume in 17 minutes and 26 seconds, a cadence consistent with automated tooling rather than manual operation, within a documented population of 421 webshell instances across two variants; a third, distinct server side form, a PNG and PHP polyglot file dropper of 1,159 bytes, was written to the same volume the day before and later recovered from a container layer on a production host. A secondary persistence backdoor used a filename and activation mechanism ( accesson.php ) that matched verbatim the backdoor documented in public research on the PolyShell mass attack wave (Sansec, 2026c). Scanner traffic targeted several regional storefronts in sequence and showed a shift from low volume reconnaissance to high volume exploitation, the same pattern reported in public mass exploitation research.

The targeted layer was equally clear, and the takeover mechanism was confirmed in detail. A privileged administrator account carried an email address on a lookalike of the merchant's agency domain, a domain that public registration records show was registered the same day the takeover occurred. (For illustration only, using a fictitious agency, Redacted Company, Inc.: an administrator address at redactedcompany.example would be changed to one at redactedcornpany.example, where the letters "rn" imitate an "m". These are not the real domains, and the substitution shown is not necessarily the one used.) THREAT ACTORS triggered the forgot password flow, and a valid reset link was sent to that lookalike address. Investigators confirmed the capture by matching the reset token in the platform's outbound mail record to the token in the reset request from the attacker source. The attacker completed the reset, reached the administration area, was taken into multifactor authentication enrollment, and within the following hour and a half edited three other administrator accounts, opened a fourth, saved the Content Security Policy and saved the store design configuration that renders the checkout pages. This activity was specific to the victim and performed by hand, in contrast to the automated mass deployment described above.

One detail of this sequence deserves emphasis. Investigators could not identify the event that set the account's email address to the lookalike domain. It did not appear in the administration interface logs, the platform's own logging events, or endpoint process telemetry. The platform's raw outbound mail record later narrowed the window: the account still carried its legitimate address on 29 January 2026 and carried the lookalike by the day of the takeover in April, but the mechanism and time of the change inside that window remain unresolved. The most likely explanations are direct database modification, an application layer write not captured by available logging, or a gap in log coverage. The change that made the entire takeover possible left no visible trace, which is itself an important finding: the precursor to a reset capture attack can be invisible to the logs defenders most often rely on.

The capture was also preceded by distributed probing. In the hour before the successful reset, the forgot password endpoint was exercised from several sources in different countries, none of which completed a reset. This shows automation feeding the targeted phase: the account recovery surface was scouted broadly before a single source completed the takeover by hand. It also gives defenders an early warning signal that is easy to miss when reset attempts are treated as routine.

Several independent vulnerability vectors converged on this single environment at the same time. Alongside the polyglot upload, investigators recorded scanning for the SessionReaper flaw with its distinctive request signature (against a version that had the fix), a reverse shell tool installed on one production host, and the presence of a third party extension of the kind implicated in the supply chain advisory described in Section 1.5. Whether the installed extension copy carried the backdoor could not be resolved from the available evidence. The encryption key was not stolen through CosmicSting, for which the store was patched, but it was within the read reach of webshells running in the web server process and therefore had to be treated as exfiltrated; the defensive conclusion is the same as in the CosmicSting era. The convergence itself is the point: one store was a target for several unrelated weaknesses at once, which is the signature of ecosystem level targeting rather than a single bespoke intrusion.

The skimming activity was not a single implant. Investigators identified three distinct browser side WebRTC skimmer loaders operating against the environment, each with its own command and control endpoint and its own place of residence in the store. The first was an external loader script allowed by the Content Security Policy. The other two persisted not as files on disk but as content written directly into the store's database configuration (a footer entry and a head include entry), rendered into every page the customer browser loaded across five storefronts. The head include loader was removed on 3 June 2026, was back on the storefront by 7 June, was removed again on 8 June, was back within about a day, and was removed for the last time on 11 June. Each reinsertion came through an authenticated administrative session correlated with a compromised administrator account, not through a self healing mechanism: the account, not the file system, was the persistence. Browser side monitoring recorded the last skimmer signal on 11 June and none in the days that followed, once the account path had been closed. This is the practical meaning of database level and account level persistence: removing files does not remove the skimmer, and removing the skimmer does not remove the access that put it there.

Each reinsertion arrived through an authenticated administrative session correlated with a compromised administrator account; the account, not the file system, was the persistence. The last skimmer signal of record is 11 June; browser side monitoring recorded none from 12 June onward.

One timing detail is worth stating carefully. Polyglot upload tooling activity against this environment was recorded from 18 to 21 February 2026, three to four weeks before Sansec's first observed in the wild exploitation (16 March) and public disclosure (17 March). That activity postdates Adobe's bulletin of 14 October 2025 by about four months, but it does not postdate any patch the store could have installed, because the fix existed only in a pre release branch until 12 May 2026. The most defensible reading, held as a working theory rather than a settled fact, is that capable operators possessed working tooling for this weakness before it was publicly described, and that the bulletin and the pre release code change were sufficient for them to find it. The defensive consequence is clear. A vendor bulletin is a signal to attackers as well as defenders, and when the fix it announces is not available for a store's release line, the interval between the bulletin and the eventual upgrade path is itself a period of exposure that only a mitigation can close.

Public indicators (the Sansec published loader domains and the

research only. Nothing in this paper is derived from the merchant's customer data.

backdoor name) are reproduced from public

Two related but distinct behaviors run through the targeted activity in this environment. Anti forensics is an effort to destroy or hide evidence after the fact, so that an investigator cannot reconstruct what happened. Defense evasion is the effort to slip past controls and monitoring while the activity is happening, so that it is not detected in the first place. They are treated separately here because they call for different defenses and because the evidence for each is different.

5.1 Anti forensics

The clearest anti forensic act in this case was a permission change applied to the webshell upload directory in the middle of the mass drop. Investigators recovered a file system record showing the directory locked down to owner only access (mode 0600 ) moments after the files were written, which both narrows who can read the directory and frustrates routine listing of its contents. The forensic team captured this from the stored file system metadata. It is one of the more reliable artifacts in the case precisely because it lives below the application layer that the THREAT ACTORS otherwise manipulated.

Two further patterns belong to the same category. The most consequential change in the entire account takeover, the alteration of an administrator email address, left no trace in the application logs an investigator would normally consult, which has the same effect as deliberate evidence removal whether or not it was intended as such. And the browser side skimmer was written to erase its own injected element from the page after it ran, so that a later inspection of the live page would not find it. The defensive response to anti forensics is to capture evidence the attacker cannot reach: file system level and database level records, centralized off host logging, and tamper evident audit trails.

5.2 Defense evasion

Defense evasion appears at every stage of the activity. The initial upload used a polyglot file whose valid image header passed the platform content check while executable code rode along in the file body. The smaller of the two server side webshell variants was cookie gated, meaning it stayed inert and invisible until a request arrived carrying a specific secret cookie value, so ordinary scanning and log review would not reveal it; the larger variant read its commands from the request body. The execution probes swept more than a dozen alternate file extensions, including trailing dot variants, to find one that the server would run as code despite handler rules. The forwarded source address on a band of this activity carried the loopback address ( 127.0.0.1 ) as its first hop, which investigators assess as a forged header: it both disguises the real origin and can cause naive log pipelines to discard the true attacker address.

A structural evasion deserves emphasis because it is also a lesson about logging. The webshell took its commands from the body of the web request, and standard edge access logs do not record request bodies. The command and control traffic to that webshell is therefore structurally absent from the logs most defenders rely on, even though the file write that placed it is visible. A second gap compounded this: the platform administrative audit log had no coverage of the period in question, so administrator actions that would normally be recorded were simply not

captured, a gap that on the open source edition is structural rather than a misconfiguration (Section 5.4), and the shared storage volume on which the webshells were written was outside endpoint anti malware coverage until the storage server itself was enrolled, weeks into the intrusion.

On the browser side, the skimmer scheduled itself to run during idle moments and reused the page's legitimate script permission tokens, both techniques to blend with normal activity (RH-ISAC, 2026). The general lesson is that the events most important to an investigation are frequently the ones the default logging configuration does not capture; defenders should assume their logs have blind spots and add request body capture, application audit logging, and live page monitoring to close them.

5.3 Content Security Policy

A Content Security Policy is meant to be a defensive control. It tells the browser which script sources are permitted, so that an injected skimmer from an unapproved domain will not load. In this environment the policy was written to from inside. The administrator session that completed the reset capture takeover saved the Content Security Policy within half an hour of seizing the account, and the external skimmer loader was served from a domain the store's policy allowed. A second pair of policy writes nine days later, recorded 27 seconds apart, first disabled policy enforcement and then modified the policy to allow the loader domain; the available evidence carries two framings of that pair, a merchant initiated migration of enforcement to the edge and an unauthorized write associated with the skimmer, and this paper does not resolve between them.⁴ Either way, with the attacker domain on the allowlist, the browser treated the skimmer as authorized.

This was detectable, and the way it was detected is a useful behavioral profile. The signal was not the skimmer itself but the configuration change: a write to the security policy settings that disabled the policy and then added an unfamiliar external domain to the script allowlist within seconds. In this environment that write was recorded nine days after the same loader domain had already been observed on the checkout page and cleaned, which is why the paper does not resolve between the two framings in Section 5.3; the point for defenders is that the write is detectable on its own, whether it precedes or follows the loader. Investigators surfaced it by auditing administrator initiated changes to the stored configuration rather than by watching the storefront. The takeaway is twofold: a Content Security Policy is necessary but not sufficient, because an attacker with administrative access can simply rewrite it; and changes to the policy configuration should themselves be monitored, treating any administrator driven disabling of the policy or addition of an external script source as a high priority event.

5.4 Edition and the audit trail

The logging gaps described above are not only a matter of configuration. On Magento Open Source they are a property of the edition. The administrative action log that records which Admin user changed what, the Action Logs report, is an Adobe Commerce feature and is not available in Magento Open Source (Adobe, 2026e). What the open

source edition writes by default is diagnostic output rather than an audit trail: system, exception, debug, cron and syslog output, with database query logging available as a developer option that is off in production mode (Adobe, 2026f). The database layer does not close the gap on its own. MySQL Enterprise Audit is licensed with MySQL Enterprise Edition and is not open source, so a community deployment records database writes only if an open source audit plugin, such as the Percona or MariaDB plugin, is installed, or if binary logging is enabled and retained deliberately (Percona, 2026).

In the investigated environment this was not theoretical. The platform administrative audit log had no coverage of the period under investigation, and the single most consequential change in the intrusion, the alteration of an administrator email address that made the reset capture possible, left no trace in any application log (Section 4). An assessor reading that environment against Requirement 10 would have found no administrative audit trail to test.

The store's change from Adobe Commerce to Magento Open Source, reflected in Section 6 therefore matters for more than naming: on Magento Open Source the gap is structural and can only be closed from outside the platform, while on Adobe Commerce the Action Logs report exists but has to be enabled for the relevant action types and retained long enough to satisfy the standard (Adobe, 2026e).

4 The investigation recorded both framings for the second pair of writes and left them unreconciled because the log source that would settle it (database binary logs) was not available. The first write, by the takeover session, is not in doubt.

The observations in the previous sections were cross checked against an independent static code review of the Magento Open Source platform distribution, version 2.4.6-p13, the edition and release the investigated store ran after switching from Adobe Commerce. The review combined automated static application security testing with manual code path analysis and identified fourteen distinct code level weaknesses that enable webshell installation and persistence, three of them rated critical. The

review examined the platform distribution itself rather than any single store, which is the point that matters for defenders: the weaknesses sit in the code that every store on this version runs, so an exploit observed in one environment corresponds to a weakness present in all of them.

The table below maps what investigators observed in the environment, on the left, to the specific platform weakness that makes each technique possible, in the center, with its defensive significance on the right.

The static review examined platform distribution only. It did not examine third party extension code, so the vendor extension noted in Section 4 falls outside its scope and does not appear as a code review finding. The hands on administrator account takeover abuses an account recovery workflow rather than a platform code defect, so it likewise does not map to a code review finding. The general purpose botnet activity targeted a non platform endpoint and is outside the platform code entirely. These boundaries are stated deliberately: the mapping is offered only where observed exploitation lines up with a located, code level weakness, and is not stretched to cover activity the review did not examine.

The mapping closes the evidentiary loop. The techniques seen in the wild are not abstract: they correspond to confirmed, located weaknesses in the platform code, and because the fix for the most severe of them reached production only as a major version upgrade, web server level mitigation is the operative defense for every store that has not yet moved to 2.4.9 or later.

Shared tooling is not the same as a shared operator.

Public research shows the PolyShell webshells, the secondary backdoors and the WebRTC skimmer kit reused across many unrelated victims. Reuse on that scale demonstrates a common criminal supply chain in which kits are sold, shared and redeployed. It does not establish that a single group carried out every intrusion.

The observed sequence of actions closely matches the documented operational patterns of financially motivated THREAT ACTORS that have historically targeted ecommerce platforms. These groups typically prioritize payment data theft, use commodity webshells and skimmer kits for persistence, and operate over extended windows. The activity described in this paper is consistent with that established pattern, even though the specific operators cannot be identified from the available evidence alone. No named group is attributed here. Where infrastructure values appear identical to those in public research, the most defensible reading is the same toolkit deployed against a different victim, not proof of the same hands. The botnet activity is treated the same way: the RondoDox pattern is recognized from public research, but no operator is named from the available evidence.

The following measures address the dual threat model and the surrounding automated exploitation pressure. They assume a Magento or Adobe Commerce environment of unknown patch state and recent exposure.

01 Establish the true patch position before anything else.

Read the running version, then check the vendor's bulletin solution table and release notes for the exact release line: what the fix version for that line is, when it was released, and whether the weakness was fixed in that line at all. Apply the latest security update for the line; apply the StyleSmuggler hotfix (APSB26-146) immediately on every 2.4.x store; and plan the upgrade to Adobe Commerce 2.4.9 or later, because the PolyShell fix exists in no earlier production release (Adobe, 2025b, 2026b, 2026d).

02 Block PHP execution from media uploads until the upgrade is complete.

Configure the web server so that PHP cannot execute from the media upload directory, and confirm the rule at file system level on every application host (Section 8.1).

03 Rotate the Magento encryption key after any suspected exposure.

Exposure can come through CosmicSting, a webshell with read access to the configuration, or StyleSmuggler. Patching does not invalidate a key that was already stolen. Rotate the key, invalidate existing administrator sessions and integration tokens, and rotate every credential that was encrypted with the old key, as Adobe now instructs (Adobe, 2026d).

04 Review every administrator account and integration token.

Look for accounts whose email domain closely resembles, but does not exactly match, a known vendor domain. Remove unused accounts and tokens, enforce multifactor authentication, and confirm that multifactor enrollment is held by the legitimate user.

05 Monitor administrator email changes and password reset activity.

Because the email field change that enables a reset capture attack can occur without a visible application log entry, monitor it directly at the database or audit log level. Treat any administrator password reset whose recipient domain does not exactly match a known address as a high priority alert and treat repeated forgot password requests for administrator accounts from varied or unfamiliar sources as an early warning of an account recovery attack.

06 Restrict file upload paths that are not required for business operations.

Monitor for polyglot uploads to customer facing upload endpoints.

07 Implement network egress controls.

Block outbound UDP used by WebRTC where it is not required, because a Content Security Policy does not stop WebRTC exfiltration. Treat network layer controls as the primary defense against this channel.

08 Patch and monitor all internet facing software on the host, not only the ecommerce platform.

General purpose botnets exploit any reachable web vulnerability. Watch for first stage downloader behavior, such as a web process spawning a shell that runs a remote fetch command piped directly to an interpreter and block outbound retrieval of remote shell scripts where it is not required.

09 Monitor the live checkout page on every storefront.

Watch for unauthorized script and content changes, with a defined response interval for critical alerts. Server side configuration can be modified to inject browser side skimmers, so monitoring must observe what the customer browser actually loads, not only the stored configuration.

10 Audit every third party extension and supplier the storefront loads.

Cross check installed extensions and their versions against published supply chain advisories, obtain the component inventory from each host, and verify the integrity of license and update files inside vendor modules. Treat a trusted component as a potential entry point, because supply chain compromise installs malicious code the operator never chose.

11 Monitor administrator initiated configuration changes, especially to security settings.

Alert on any change that disables a Content Security Policy or adds an external domain to a script allow list, on changes to scheduled task definitions, and on new content written to store configuration or content tables. These are the database resident persistence and policy subversion mechanisms that survive file system cleanup.

12 Assume the default logs have blind spots and close them.

Capture web request bodies where feasible, enroll shared storage servers in endpoint anti malware coverage (agents on the application servers do not inspect a network mounted volume), centralize logs off host so they cannot be altered locally, and monitor the live page the customer browser renders. On Magento Open Source there is no application audit logging to switch on, because the Action Logs report is an Adobe Commerce feature (Adobe, 2026e); the administrative trail has to come from a third party extension, from database level auditing, or from the host.

13 Establish whether your edition can meet PCI DSS Requirement 10 at all.

Map each Requirement 10 logging obligation to the component that satisfies it: the platform, the database, the host, or a product you add. A stock Magento Open Source store does not record administrative actions, changes to administrator accounts, or access to the logs themselves, so on that edition Requirement 10 rests entirely on controls around the platform, and the gap should be closed and evidenced before an assessment rather than discovered during one (Adobe, 2026e; PCI SSC, 2024).

8.1 PolyShell exposure

The following interim controls are drawn from public research (Sansec, 2026a; Searchlight Cyber, 2026) and align with the upload path and endpoints observed in the investigation. They are appropriate for stores that cannot yet upgrade to 2.4.9 or later.

Deny web access to the media custom options upload path and ensure that rule is evaluated before any PHP handler. On nginx, a prefix match deny on /media/custom_options/ placed before the PHP location block prevents an uploaded polyglot from being executed; the nginx configuration Magento ships already contains a rule of this kind, and the investigated environment was exploitable because its web server executed PHP from that path.

On Apache, disable PHP execution in that directory through the directory configuration.

Hunt for the backdoor and skimmer. Recursively search the web root for accesson.php and for any PHP file under pub/media/custom_options/, and search CMS content, static blocks and the design configuration entries for references to the published skimmer loader domains (Sansec, 2026a, 2026c).

Monitor the exploitation surface. Watch REST activity against /rest/V1/guest-carts/ and the custom options upload path, alert on polyglot uploads, and treat any administrator password reset whose recipient domain does not exactly match a known address as a high priority event.

8.2 Reading a vendor bulletin correctly

A security bulletin date is not a patch availability date. Bulletin APSB25-94 was published on 14 October 2025, and its solution table names a fix version for every supported line, so a reader who stops there concludes that every store had a patch for PolyShell from that day and that a store compromised in April 2026 had ignored it for six months. That reading is wrong, and an earlier draft of this paper made it. The upload handler change existed only in the 2.4.9 pre release branch; the production patches the bulletin shipped, 2.4.6-p13 among them, did not contain it, and the first production release that did was 2.4.9 on 12 May 2026 (Adobe, 2025b, 2026a, 2026b; Searchlight Cyber, 2026). A store on 2.4.6-p13 was fully patched by the vendor's own table and fully exposed at the same time.

The practical rule for defenders and assessors alike: for every vulnerability, record the fix version for the exact release line, the date that version was released, and whether the running version is at, below or above it; then confirm from the release notes that the fix is actually in that version and not only in another branch. Where it is not, the bulletin is a warning that arrived without a remedy, and mitigation, not patching, is the control that counts. The same discipline applies in the other direction: SessionReaper was fixed in 2.4.6-p13, so scanning for it against that version was noise, not exposure.

The Magento and Adobe Commerce ecosystem is under sustained, automated assault, and individual merchants are caught in waves they did not invite.

The evidence reviewed here indicates that the tooling, vulnerabilities and techniques seen against a single victim are instances of broad, publicly documented mass exploitation campaigns; that the account takeover and persistence that follow are targeted and performed by hand; and that the same host is probed in parallel by unrelated general purpose botnets. Defenders who treat an intrusion as either purely opportunistic or purely targeted will misjudge it. The correct posture assumes both and assumes continuous automated pressure on every reachable service: patch where a patch exists and mitigate where it does not, rotate what may have been taken, hunt for the hands on follow through that automation leaves behind, and harden the whole host against indiscriminate botnet exploitation.

StyleSmuggler, arriving as this paper closed, is the next wave; there will be another.

Adobe. (2025a, September 9). Security update available for Adobe Commerce | APSB25-88.

https://helpx.adobe.com/security/products/magento/apsb25-88.html

Adobe. (2025b, October 14). Security update available for Adobe Commerce | APSB25-94.

https://helpx.adobe.com/security/products/magento/apsb25-94.html

Adobe. (2026a). Adobe Commerce 2.4.6 security patch release notes. Adobe Experience League.

https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/security-patches/2-4-6-patches

Adobe. (2026b). Released versions. Adobe Experience League.

https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions

Adobe. (2026c, May 12). Security update available for Adobe Commerce | APSB26-49.

https://helpx.adobe.com/security/products/magento/apsb26-49.html

Adobe. (2026d, September 7). Urgent action required: Critical security update available for Adobe Commerce (APSB26-146). Adobe Experience League.

https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146

Adobe. (2026e). Action Logs report. Adobe Experience League.

https://experienceleague.adobe.com/en/docs/commerce-admin/systems/action-logs/action-log-report

Adobe. (2026f). Enable logging. Adobe Experience League.

https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/enable-logging

Adobe. (2026g, March 10). Security update available for Adobe Commerce | APSB26-05.

https://helpx.adobe.com/security/products/magento/apsb26-05.html

Bitsight. (2026, March 11). RondoDox botnet: From zero to 174 exploited vulnerabilities.

https://www.bitsight.com/blog/rondodox-botnet-infrastructure-analysis

BleepingComputer. (2025, May 2). Magento supply chain attack compromises hundreds of e-stores.

https://www.bleepingcomputer.com/news/security/magento-supply-chain-attack-compromises-hundreds-of-e-stores/

PCI Security Standards Council. (2024, June). Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1.

PCI SSC Document Library.

https://www.pcisecuritystandards.org/document_library/

Percona. (2026, May 29). Using the Percona audit logging plugin on MySQL Community 8.0.x.

https://www.percona.com/blog/using-the-percona-audit-logging-plugin-on-mysql-community-8-0-x/

RH-ISAC. (2026, March 27). WebRTC-based payment skimmer targeting ecommerce sites via PolyShell vulnerability.

https://rhisac.org/threat-intelligence/webrtc-based-payment-skimmer-targeting-ecommerce-sites-via-polyshell-vulnerability/

Sansec. (2025, May 1). Backdoor found in popular ecommerce components.

https://sansec.io/research/license-backdoor

Sansec. (2026a, March 17). PolyShell: Unrestricted file upload in Magento and Adobe Commerce.

https://sansec.io/research/magento-polyshell

Sansec. (2026b, March 24). Novel WebRTC skimmer bypasses security controls at $100+ billion car maker.

https://sansec.io/research/webrtc-skimmer

Sansec. (2026c, March 30). Mass PolyShell attack wave hits 471 stores in one hour.

https://sansec.io/research/polyshell-mass-attack-wave

Sansec. (2026d, September 5). StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack.

https://sansec.io/research/stylesmuggler-0day

Searchlight Cyber. (2026, March 26). Magento PolyShell: Unauthenticated file upload to RCE in Magento (APSB25-94).

https://slcyber.io/research-center/magento-polyshell-unauthenticated-file-upload-to-rce-in-magento-apsb25-94/

Sonatype. (2024). Polyfill.io supply chain attack hits 100,000+ websites: All you need to know.

https://www.sonatype.com/blog/polyfill.io-supply-chain-attack-hits-100000-websites-all-you-need-to-know

Tenable. (2026, September 8). StyleSmuggler (CVE-2026-75650): Frequently asked questions about the Adobe Commerce and Magento zero-day.

https://www.tenable.com/blog/stylesmuggler-cve-2026-75650-frequently-asked-questions-about-adobe-commerce-and-magento-zero

The Hacker News. (2025, October 23). Over 250 Magento stores hit overnight as hackers exploit new Adobe Commerce flaw.

https://thehackernews.com/2025/10/over-250-magento-stores-hit-overnight.html

The Hacker News. (2026, March 20). Magento PolyShell flaw enables unauthenticated uploads, RCE and account takeover.

https://thehackernews.com/2026/03/magento-polyshell-flaw-enables.html

The Register. (2024, October 4). Thousands of stores compromised via CosmicSting: Ray-Ban, National Geographic, Cisco, Whirlpool, Segway.

https://www.theregister.com/2024/10/04/cisco_ray_ban_whirpool_cosmicsting_hack/

Trend Micro. (2025, October). RondoDox: From targeting Pwn2Own vulnerabilities to shotgunning exploits.

https://www.trendmicro.com/en_us/research/25/j/rondodox.html

Verizon. (2025). 2025 Data Breach Investigations Report.

https://www.verizon.com/business/resources/reports/dbir/