The backdoor called itself chronyd

The implant renamed itself chronyd, which is the real name of the NTP daemon on most Linux distributions [2].

That is not laziness. It is the name most likely to survive your hunt, because anyone filtering UDP port 123 for suspicious beacons will exclude the legitimate time daemon, and that exclusion hides this build completely.

The tuning decision you made to reduce noise is the one the operator planned around.

What happened

Sansec found a Magento and Adobe Commerce zero-day being exploited on September 4, 2026 at 22:40 UTC, and reproduced the full unauthenticated chain on clean installations within hours [2]. It named the technique StyleSmuggler. Attacks had started that same day.

Adobe published bulletin APSB26-146 on September 7 at 20:20 UTC, assigned CVE-2026-75650, rated it CVSS 10.0 and gave it priority 1, its highest [1][2]. The bulletin carries a sentence vendors do not write casually: Adobe is aware of the vulnerability being exploited in the wild [1]. Exploitation needs no authentication and no user interaction [1].

Between those two dates, stores were being compromised with no patch available. On September 6, Adobe had issued no advisory, CVE, patch or workaround [6]. The hotfix arrived three days after the first confirmed exploitation and one day ahead of Adobe’s next scheduled release [2][6].

Every version from 2.4.4 through 2.4.9 is affected, across Adobe Commerce, Magento Open Source and Adobe Commerce B2B [1][2]. Sansec reproduced the chain on clean Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and the first victim it saw was running 2.4.6-p15 with the July and August 2026 patches applied and a clean security:patch-status [2].

Why this matters

Being current was not a defence, and that is worth sitting with. The first victim had done the thing the industry tells merchants to do. Patch status clean, current branch, recent patches applied. None of it mattered for three days, because the fix did not exist yet. That is the definition of a zero-day and it is also the reason detection and network position are not optional extras on top of patching.

The payload targets money infrastructure. Adobe’s remediation guidance is to rotate the store’s encryption key and then every credential that key protected: admin passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, SSH and deploy keys, and third-party extension API keys [1][2]. That list describes the blast radius better than any severity score.

The merchants are small. Magento Open Source runs a very long tail of independent shops without a security team, a SIEM or anyone on call. The hunting this incident requires, reading cron spool files and comparing beacon shapes, lands on people whose job is selling things.

Technical breakdown

StyleSmuggler works in two stages, and the second one is the interesting half.

First, PHP is poisoned into Magento’s template system, using style properties to slip past the existing safeguards [2]. Second, the attack deliberately triggers Magento’s standard Payment Transaction Failed Reminder email, and the poisoned code executes while Magento renders that message [2].

Nobody has to open the email. Rendering is the execution, and it happens on the server, which is why the attack can still succeed when mail delivery fails entirely [2]. Anyone reasoning about this as a phishing problem has the wrong model.

Moving sessions to Redis or the database does not stop it. Sansec describes one merchant where an attempt failed against session storage and a second attempt succeeded eight seconds later using a file uploaded through Magento’s custom options, from the same operator [2].

The evasion is the part to study

When the chain succeeds, a small Rust backdoor is launched under a process name borrowed from ordinary system software. Sansec has seen [kworker/u:8:0], fc-cache and chronyd across builds, and on one host watched a single implant re-drop and rename itself from one to another, keeping the same agent ID and incrementing its own version from 2.1.4 to 2.1.5 [2].

Command and control leaves shaped like time synchronisation. Every sixty seconds the implant sends 48-byte UDP datagrams to port 123, addressed to hosts with names like ntp.timesync.to. Only the first four bytes are genuine NTP. The rest carries a chunked record with the agent ID, hostname, username, OS version, memory and disk usage, uptime, whether it runs as root, and the implant version [2]. Because it is UDP to port 123 aimed at a host called ntp dot something, it passes most egress filtering without comment [2].

Two things separate it from a real client, and both are shape rather than content. A real NTP client sends one datagram; this sends nine, about ten milliseconds apart, every sixty seconds. And every datagram is marked NTPv4 server mode, which a client has no reason to send at all [2].

Persistence varies deliberately. One cron entry was written straight into the spool file rather than through crontab -e, so syslog holds no REPLACE line to find [2]. Another build ran with no cron entry, its parent process ID 1, which means an empty crontab is not evidence that a host is clean [2]. The implant also reads TracerPid from its own status file, and when traced it still installs but never beacons [2].

A second, unattributed actor arrived through the same door on September 7, dropping a small PHP web shell into the product image cache that returns a 404 to any request without the right header [2]. Removing a background process therefore does not finish the job.

Every automated signal was blank

I checked the three feeds most teams prioritise from, on September 8, 2026, and none of them knew about this yet.

The CVE was absent from the CISA KEV catalog, whose most recent version had been released on September 4 [4]. FIRST returned no EPSS record for it at all, not a low score but zero rows [5]. NVD listed it as Received, meaning no independent analysis, with the CVSS 10.0 carried straight from Adobe’s own PSIRT as the assigning authority [3].

So on the day stores were being backdoored, the only organisation asserting anything about this vulnerability was the vendor whose product it was. Every signal a patch pipeline might gate on was either empty or repeating Adobe. That is not a failing of KEV or EPSS, both of which describe what they measure honestly. It is a description of what a genuine zero-day looks like from inside an automated process, and the answer is: like nothing.

Update, September 10, 2026. All three have since filled in, and the lag is worth recording because it is the point of this section. CISA added CVE-2026-75650 to KEV on September 8 with a remediation date of September 11 [4]. FIRST published an EPSS score on September 9, putting it at 2.1 percent and the 81st percentile [5]. NVD moved the record to Analyzed on September 9 [3]. So the feeds caught up in roughly two days, four days after exploitation began. If your process gates on them, that is the size of the window you were blind for, and it is measurable rather than theoretical.

The four breaks are the patch, the render symptom, the persistence artefact and the beacon shape. Only the first one closes the hole. The other three are how you find out whether closing it came too late.

What defenders should do Monday morning

Immediate, within 24 hours. Apply the VULN-39341 hotfix on every Adobe Commerce, Magento Open Source and Adobe Commerce B2B instance, then verify it registered rather than assuming [1][2]. Do not stop there. Hunt the host: list processes and look for the names above, read the cron spool files directly rather than crontab -l, and run find pub/media -name '*.php' to catch a web shell in the image cache [2]. If anything turns up, treat it as a compromise and not a finding to schedule.

Near term, this week. Work Adobe’s rotation list, starting with the encryption key and continuing through every credential it protected, rotating at the source rather than inside Magento only [1][2]. Write the beacon detection while the detail is fresh: repeated 48-byte datagrams to UDP 123 in bursts of nine, marked server mode, from a host that is not your time source. Then go and look at your own NTP exclusions, because that is the rule this campaign was built to walk through.

Structural, this quarter. Decide what your merchant estate does when a vendor has confirmed exploitation and no patch exists, because that state lasted three days here and will happen again. Review every exclusion in your detection stack for the same property this one had: a rule that suppresses a whole class of traffic by process name or port, with nobody named as its owner and no date for revisiting it.

Checklist

• VULN-39341 hotfix applied across Adobe Commerce, Magento Open Source and B2B
• Hotfix installation verified with the patch status check, not assumed
• Host hunted for the documented process names, including the time daemon name
• Cron spool files read directly, and an empty crontab not accepted as clean
• Media directory searched for unexpected PHP files
• var/report and system.log reviewed for the published markers
• Encryption key rotated, then every credential it protected, at source
• Detection written for burst UDP 123 traffic marked server mode
• Existing NTP and time daemon exclusions reviewed and given an owner
• Failed payment email volume and rendering checked for anomalies

Your exclusion list is readable

The technically interesting part of this campaign is not the template injection. Server-side template injection is a known class with a known fix, and Adobe has shipped one.

The part worth keeping is the naming. Somebody decided to call the implant chronyd because they had thought about what a defender does after noticing odd traffic on UDP 123, which is to exclude the legitimate time daemon and move on. The evasion is not hiding from your tools. It is hiding inside a decision you already made, on purpose, for good reasons, probably years ago, and almost certainly without writing down who owns it or when it should be revisited.

Every suppression in your stack is a statement about what you have agreed not to look at, and most were correct when written. The question is not whether to have exclusions, because you cannot operate without them. It is whether anyone could tell you today what your top twenty are, who added them, and why. If the answer is no, part of your detection coverage is maintained by nobody and documented only where an adversary can also read it: in the behaviour of your alerts.