Adobe Commerce B2B

CVE-2026-75650 ("StyleSmuggler"), Magento/Adobe Commerce: unauthenticated CVSS 10.0 RCE via template-engine injection, exploited three days before Adobe's hotfix existed

Sansec found StyleSmuggler on 2026-09-04 at 22:40 UTC and published the following day specifically because stores were already being compromised, reproducing the full unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8 and 2.4.9 within hours (Sansec, 2026-09-05). The bug abuses Magento's own template engine through the styles property, reached via a POST /graphql request carrying the malicious styles parameter, to smuggle PHP past existing input safeguards, and runs in two stages: first the attacker poisons a location Magento itself writes to and later re-renders through its template filter; Sansec's own published check searches a failure report under var/report/, but Magento hosting firm Disrex Group, which handled two live compromises, found both of its infections instead poisoned var/log/system.log, a location Sansec's check misses entirely (The Hacker News, 2026-09-06), with attacker-controlled PHP; second, the attacker triggers Magento's built-in "Payment Transaction Failed Reminder" customer-notification email, and the poisoned content executes the moment Magento renders that template (Sansec, 2026-09-05). Nobody needs to open the email, and the attack succeeds even when delivery fails (Sansec, 2026-09-05). Adobe assigned CVE-2026-75650 (CVSS 10.0, CWE-1336 Improper Neutralization of Special Elements Used in a Template Engine) and shipped an emergency hotfix, APSB26-146, on 2026-09-07 at 20:20 UTC with its highest priority rating, three days after the first confirmed exploitation (Adobe PSIRT, 2026-09-07; Sansec, 2026-09-05). The fix ships as a composer patch (VULN-39341) rather than a full point release, tested against the 2026-aug release branch of Adobe Commerce, Adobe Commerce B2B and Magento Open Source 2.4.4 through 2.4.9; older versions in those branches are affected too, but Sansec reports the patch is unverified there (Sansec, 2026-09-05).

Disrex's own two compromises, reported independently of Sansec, sharpen the timeline and the triage picture. Both stores were breached inside the roughly eight-hour window between Sansec's first observed exploitation and the moment any defense existed, and Disrex states patch level was irrelevant during that window; one victim ran Magento Open Source 2.4.8 as a Sansec Shield customer with the module installed, enabled and licensed, and was still hit hours before Shield's first blocking rule went live (The Hacker News, 2026-09-06). Disrex reports a concrete false-negative worth defenders' attention: its own eComscan run on one compromised store returned clean eleven hours after the implant first executed, because the scheduled scan was scoped to the store's document root while the implant had installed itself one directory above it, under the site account's home directory, a scan-scope gap, not a detection-engine failure. Disrex also names a reliable success indicator the exploit itself leaves behind: a TypeError from array_merge() with an integer argument, logged immediately after the poisoned include executes; a stealthier variant instead returns an empty array and leaves nothing to find, so its absence does not clear a host. One of Disrex's two compromises first surfaced through exactly the "Payment Transaction Failed Reminder" tell this entry describes above: a merchant forwarded a failed-transaction email whose template variables had never resolved (raw {{var ...}} tags, a customer address on an invalid domain, a zero-value total) and that forward alone started the investigation that found the implant within the hour (The Hacker News, 2026-09-06).

Patch level offered no protection during the exposure window: the first confirmed victim ran Magento 2.4.6-p15 with the July and August 2026 security patches applied (the latest patch level Adobe offers for that release line) and a clean security:patch-status (Sansec, 2026-09-05; The Hacker News, 2026-09-06), and Sansec's own Shield product blocked a probe against an already-current 2.4.7-p10 store on 2026-09-07, confirming that current patch level was no defense during the exposure window (Sansec, 2026-09-05). Moving session storage to Redis or a database is not a mitigation either: one merchant's session-storage defense stopped one attempt, and the same operator succeeded eight seconds later by routing the poisoned payload through a file uploaded via Magento's custom options instead (Sansec, 2026-09-05). On success, the implant is a small Rust binary (Disrex describes the sample from its own compromises as stripped and statically linked) that installs itself under a hidden directory outside the web root and re-persists via a cron entry written directly into the cron spool file rather than through the crontab command, so the change leaves no corresponding audit line and an empty crontab -l is not evidence of a clean host (Sansec, 2026-09-05; The Hacker News, 2026-09-06). The implant renames its own process to masquerade as a kernel worker thread, the fontconfig cache builder, or the genuine NTP daemon, and one observed build re-dropped and renamed itself mid-run from one masquerade to another while keeping the same underlying agent identity, a process-naming change with no corresponding new infection (Sansec, 2026-09-05). It reads /proc/self/status for TracerPid before beaconing: if a debugger or tracer is attached, the implant still installs itself but never calls out, which matters for anyone attempting to reproduce or analyze it live (Sansec, 2026-09-05).

Command-and-control is disguised as time synchronization: every 60 seconds the implant sends short UDP datagrams to port 123 shaped to resemble NTP server replies, carrying a chunked telemetry record (host, user, operating system, resource usage, and implant version) rather than legitimate time data, traffic that passes most egress filtering unremarked because it looks like a routine NTP exchange (Sansec, 2026-09-05). Two details separate it from a genuine NTP client for a defender who does look: a real client issues one query per interval, where one observed build burst nine datagrams roughly ten milliseconds apart every sixty seconds; and every datagram is marked NTP server-mode, which a client has no legitimate reason to send at all (Sansec, 2026-09-05). Sansec has so far found no evidence the backdoor has been used beyond installation and beaconing (Sansec, 2026-09-05).

Sansec separately documents a second, apparently unrelated actor exploiting the same flaw: a reconnaissance probe sent as an ordinary-looking GraphQL request carries PHP code inside a request header rather than the request body, reads the host's kernel/OS string, PHP user, working directory, and whether the media directory is writable, then exfiltrates that single-line answer one fragment at a time as a sequence of externally-resolved hostname labels to a public callback service; a technique that needs no response body at all, since the operator reconstructs the answer from the callback log (Sansec, 2026-09-05). Only when that probe reports the media directory writable does the same actor follow up with a web shell planted inside the product-image cache directory, reachable solely with a custom request header (Sansec, 2026-09-05).

Every version of Adobe Commerce, Adobe Commerce B2B and Magento Open Source in the 2.4.4–2.4.9 line is affected with no authentication or user interaction required (Adobe PSIRT, 2026-09-07); Switzerland's NCSC has issued its own advisory confirming the exploitation and backdoor-persistence risk for its constituency (NCSC Switzerland / GovCERT.ch, 2026-09-07). Any public body or supplier running a storefront, ticketing portal or fee-payment system on this platform (tourism boards, cantonal shops, public-transport ticketing among them) is in the affected population even without a Swiss-specific victim yet reported.

Triage: the exploitation trigger is Magento's own "Payment Transaction Failed Reminder" email, so an unexplained burst of these messages (especially containing unresolved template placeholders or Magento's template-error fallback text) is a Magento-specific tell that costs no additional tooling to check; legitimate declined-payment traffic can produce the same notification, so treat the burst as a lead, not a confirmation. On the network side, a web-tier host that only ever needs outbound HTTPS suddenly emitting repeated small UDP datagrams to port 123 is not a legitimate NTP client, which issues a single periodic query rather than a burst of server-mode replies; filtering by process name alone is insufficient once an implant has renamed itself to match the very daemon a defender would otherwise exclude from suspicion.

CVE-2026-71362, Adobe Commerce and Magento Open Source: an unauthenticated attacker switches a customer session to another customer's account (CVSS 9.1), and a WAF vendor reports it is already blocking attempts

Adobe's 2026-08-11 bulletin APSB26-92 fixes seven vulnerabilities in Adobe Commerce, Adobe Commerce B2B and Magento Open Source, five of them rated Critical (Adobe PSIRT, 2026-08-11). The one that matters operationally is CVE-2026-71362, an incorrect-authorization flaw (CWE-863) which Adobe's own vulnerability table scores at CVSS 9.1 and records as requiring no authentication, no administrator privileges and no user interaction (Adobe PSIRT, 2026-08-11). Sansec, which reviewed the patch, describes the effect concretely: the flaw lets an attacker switch a customer session to another customer account, giving access to that account and its private customer data, and Adobe's fix changes the way Magento handles customer identity in the account session (Sansec, 2026-08-11).

The exploitation picture depends on who is speaking, and both readings belong in a triage decision. Adobe states in the bulletin that it is not aware of any exploits in the wild for any issue in the update (Adobe PSIRT, 2026-08-11). Sansec states that its Shield web application firewall already blocks exploitation attempts against this flaw (Sansec, 2026-08-11), and BleepingComputer reports that attempts to exploit CVE-2026-71362 have been detected (BleepingComputer, 2026-08-12). Nobody reports a confirmed compromised store, so this sits between "patched, quiet" and "actively exploited", which for a pre-authentication account takeover on an internet-facing storefront is close enough to the latter to act on.

The deployment detail is what will actually cost teams time. APSB26-92 ships as isolated patch files rather than a new security release or new Composer packages, and merchants must be running the latest -p release for their supported release line before the corresponding isolated patch can be applied (Sansec, 2026-08-11). A store several -p releases behind therefore has a two-step upgrade in front of it, not a patch. The affected ranges differ by product and the difference matters for inventory: Adobe Commerce is listed from 2.4.9-2026-jul down to 2.4.4-2026-jul, Adobe Commerce B2B from 1.5.3-2026-jul down to 1.3.3-2026-jul, and Magento Open Source only from 2.4.9-2026-jul down to 2.4.6-2026-jul, each "and earlier", with the fixes in the corresponding -2026-aug builds of each line (Adobe PSIRT, 2026-08-11).

For this constituency the exposure is narrower than a general Magento advisory suggests but is real: public-sector bodies that run ticketing, publication or fee-payment storefronts on Commerce or Magento hold exactly the customer records this flaw hands over, and the payment-adjacent data in those accounts is what makes a session takeover worth automating.

Detection, in vendor-neutral terms: because the flaw operates on session identity rather than injecting code, the signal is in application and web-access logs rather than on the host. Look for requests where a session identifier is presented against a customer account other than the one it was issued to, for a single session identifier or source address touching multiple distinct customer account contexts in quick succession, and for account-area page views and order-history reads that arrive without the preceding authentication sequence that normally establishes them. There is no file to find and no process to spot, a successful attack looks like an ordinary logged-in customer, which is why the post-patch session invalidation matters as much as the patch.