When a zero-day vulnerability hits your production infrastructure and the vendor remains silent, your incident response plan is put to the test. On September 4, Disrex Group faced this exact scenario: two Magento stores were compromised through an unpatched GraphQL vulnerability that Adobe had neither acknowledged nor fixed.
The timeline is telling. First exploitation occurred at 23:10 UTC on September 4, and the first blocking rules were available roughly eight hours later. Both breaches happened within this window, when no defense existed and patch status was irrelevant.
The Challenge
Disrex hosts Magento stores through its RexHosting brand. On the evening of September 4, a merchant forwarded an unusual email: a "Payment Transaction Failed Reminder" with unresolved template variables, a customer address ending in .invalid, and a transaction total of zero.
This email was a byproduct of an exploitation attempt. Within the hour, Disrex discovered the first implant: a Rust binary disguised as a Linux kernel thread, installed outside the web root, with a cron entry written directly to the spool file to avoid system logs. The implant had 28 open connections to the store's Redis instance, reading Magento session storage.
Store A ran Magento Open Source 2.4.8 with Sansec Shield installed and active. Store B ran 2.4.7-p2, eight versions behind the current patch level. Both were breached before any mitigation existed.
The exploit chain involved two stages: poisoning a log file with PHP code, then triggering Magento's payment failure email to execute that file during template rendering. No one needed to open the email; delivery could fail, and the code would still run.
The Environment and Constraints
Disrex operates isolated hosting: each store in its own account, single site owner, no sudo rights, and no path to other customers. The implant ran as the unprivileged site user and couldn't reach beyond that store's boundary.
The company faced two immediate constraints. First, no vendor guidance was available. Adobe had published nothing: no advisory, no CVE identifier, no patch, no workaround. Disrex had to read Magento source code on a compromised production server to understand the vulnerability.
Second, the published indicators were incomplete. Sansec's initial check searched var/report/ for the marker X_TRACE_. Both Disrex infections were poisoned through var/log/system.log instead and would have been missed. The trigger header also changed within hours: X-TRACE- with ten hex characters in the morning, the same header without TRACE by afternoon.
The Approach Taken
Disrex contained both stores the same day: eleven and fourteen hours after first contact, respectively. The response had four components.
Immediate sweep. Within an hour of finding the first implant, Disrex swept its entire hosting estate. It found the second compromised store that afternoon and a third that was attacked but not breached.
Process and file forensics. The implant disguised itself as [kworker/u:8:0], a legitimate kernel thread name. A genuine kernel thread is owned by root with no resident memory. A bracketed name on the site user with real memory usage is the implant. Disrex hashed both the file on disk and the running process from /proc/
Cron analysis. The implant wrote its restart line straight to /var/spool/cron/crontabs/, bypassing the system log. One store carried the same line 1,728 times. The implant re-added it within a second of manual removal.
Traffic capture. Disrex took over 200 MB of packet captures on each store while the implant was live. On one store, the implant made no outbound connection at all. It held 28 connections to the store's own Redis instance on port 6379 and read session storage from it. Neither capture contained a single packet to the download host or command-and-control address that Sansec had published.
The company published nginx and Apache rules that block requests carrying the exploit's parameters in the URL query string. Its own test showed the limit: the same parameters sent in a POST body or JSON body reached PHP, because web servers inspect only the query string.
Results and Metrics
Both stores were contained within fourteen hours of first contact. Disrex confirmed no lateral movement, no other affected sites on its platform, no data exfiltration, no rogue admin accounts, no injected payment skimmer, and no database backdoor.
All sessions were invalidated. Credential rotation is underway as a precaution, though the implant ran as an unprivileged user with no database write access.
The merchant's forwarded email proved the most valuable early-warning sign. It required no tooling, just attention to a broken-looking order notification. The raw template variables, the .invalid domain, and the zero total were all exhaust from the exploit passing through Magento's template filter.
What They Would Do Differently
Disrex's scheduled eComscan run at 10:00 UTC on September 5 reported Store A clean. The implant was present and active, with 1,728 cron lines in place. The scanner was pointed at the store's document root; the implant had installed one directory above it, under the account's home directory. Disrex has since widened the scan path.
The published indicators needed immediate extension. Both infections were poisoned through var/log/system.log, not var/report/. The trigger header drifted within hours. A TypeError from array_merge() with an integer argument in system.log, immediately after the include, is evidence the exploit succeeded, but a stealthier variant returns an empty array and leaves nothing in the log.
Takeaways for Your Team
Vendor silence is not vendor absence. Adobe's next scheduled security release was September 8. It was not yet known whether that release would cover this bug. Disrex could not wait.
Scope your detection tools wider than the application root. The implant installed under the site user's home directory, outside the web root. A scanner pointed at the document root will miss it.
Published indicators drift in real time. The exploit marker changed within hours. A search should match the shape rather than the exact string.
Unexpected email is signal. A failed-transaction notice with unresolved template variables, a .invalid domain, and a zero total is exhaust from exploitation. It surfaced the first breach within the hour.
Isolation contains blast radius. Each store ran in its own account with no path to other customers. The implant ran as the unprivileged site user and could reach nothing beyond that store's boundary. No lateral movement occurred.
When the vendor has no patch and no timeline, your response plan is your patch. Disrex's containment happened because it swept its estate within the hour, read source code on a live incident, extended published indicators, and treated a broken email as the signal it was.
