Loading today’s stories
Security1 distinct publisher3 min readPublished
Sansec reproduced an unauthenticated code-execution chain on clean 2.4.7, 2.4.8 and 2.4.9 installs, and the first victim it saw was already on Adobe's newest patch level for its release line.
The Watch · Security desk
build
GitLab bundles a zero-click GraphQL flaw with a CSRF bug, and only one needs a victim1 distinct publisher
build
Arista names four fixed VCO builds for a command injection already in use1 distinct publisher
security
One malformed CIP message faults a Logix controller until someone power-cycles it1 distinct publisher
build
Stop timing your GraphQL tests and start counting loader calls1 distinct publisher
Compiled by The WatchSomething wrong?How this is made
The chain is short. Stage one plants PHP inside a file Magento writes itself, a failure report for example. Stage two triggers the platform's standard Payment Transaction Failed Reminder email, which makes Magento execute the file it just wrote [20]. No login is involved at any point [1].
Sansec's first victim ran 2.4.6-p15 with Adobe's July and August 2026 updates applied, the newest level Adobe offers for that line and the one its August bulletin labels 2.4.6-2026-aug [6], and it was still hit. The store Disrex captured attack traffic from ran 2.4.7-p2, which Adobe's version history dates to August 2024, eight levels behind 2.4.7-p10 [12] and about 25 months old by the September 5 compromise [3]. Patch level did not sort exposure: both ends of that spread fell.
Sansec Shield covered the store Disrex labels Store A, and Store A was hit at 23:10 UTC on September 4, hours before Sansec's first blocking rules went live [13]. The publicly available alternative is the Disrex repository, whose README says it was written with AI assistance in a few hours during a live incident, has not been reviewed, contains Apache rules that were never run against a live Apache server, and carries cleanup commands that were mostly written rather than executed [14]. The rules come from real captured attack traffic [11], but they have not been tested as a control.
Detection assumptions that work on Magento card skimmers do not transfer. The binary sits at ~/.local/share/.gvfsd/gvfsd-user in the site user's home directory, outside the web root, and the process presents as [kworker/u:8:0], the naming convention of a Linux kernel thread [15]. Disrex measured a stripped, statically linked Rust binary of roughly 1.9 MB built for x86-64 and arm64, with the cron line written straight into /var/spool/cron/crontabs/ so no crontab replacement appears in the system log [16]. On one of its two compromised stores the implant opened no outbound connection at all: 28 connections to the store's own Redis on port 6379, reading Magento session storage, and not one packet to Sansec's listed download host or command-and-control address across two captures of more than 200 MB each [18]. Integrity monitoring scoped to the web root sees none of that, and neither does egress alerting.
The cron entry restarts the process every five minutes, which is 288 restarts in a day [4]. One store carried the same line 1,728 times, and the implant re-added it within a second of removal [17]. If each duplicate were one cycle, 1,728 lines would be six days of appends [5], putting that infection before Sansec's September 4 start date. Sansec has not dated that store, and the observed re-add interval is a second rather than five minutes, so the arithmetic is a question for the responder, not a dwell time.
Adobe's next scheduled security release is September 8, and whether it covers this bug is not known [10]. Attacks began September 4 [2], so the floor on the window is four days [2]. Adobe's Commerce bulletin index has shown nothing after the August 11 update, 26 days as of September 6 [3][1]. There is also no CVE, which means nothing lands in a vulnerability feed and nothing shows up in a supplier questionnaire [3].
Ranked by verification strength, evidence, and original report placement.
Attackers are exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce that lets them run malicious code on an online store's server without logging in, according to an advisory published on September 5 by Dutch e-commerce security company Sansec.
Sansec discovered the flaw, named it StyleSmuggler, and said attacks started on September 4, adding that it was publishing early because stores were being compromised at the time.
As of September 6, Adobe had not published an advisory, a CVE identifier, a patch or a workaround, and its Adobe Commerce security bulletin index listed nothing after the August 11 update.
A successful attack gives the attacker code execution on the store's server and installs a persistent backdoor.
Sansec said all current versions are affected, including 2.4.9, and that it reproduced the full unauthenticated chain on clean Magento Open Source installations of 2.4.7, 2.4.8 and 2.4.9.
Sansec's first victim ran 2.4.6-p15 with Adobe's July and August 2026 security updates applied, the latest patch level Adobe offers for that release line and the one Adobe's August bulletin labels 2.4.6-2026-aug.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 5, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Chain reproduced; vendor has not confirmed it
The strongest item in the record is Sansec's reproduction of the unauthenticated chain on clean 2.4.7, 2.4.8 and 2.4.9 installs, backed by Disrex handling infections it did not learn about from Sansec. Working against that: no CVE, no Adobe confirmation of affected versions, no reproduction on Adobe Commerce or Cloud, and a Disrex repository whose README disclaims review of the very rules and cleanup commands it ships. All of it reaches readers through one outlet relaying two vendors' write-ups.
Four incidents named; no known total
Concrete, timestamped compromises do exist: Store A at 23:10 UTC on September 4, two more stores on September 5, one attack blocked. What is missing is the denominator, since Sansec will not say how many stores it has seen, and the infection with the richest forensics was running a patch level from August 2024, which makes it a poor stand-in for the current install base.
'Fully patched' rests on one store
The claim that patched stores are being backdoored traces to a single victim, Sansec's first, on 2.4.6-p15 with the July and August 2026 updates applied. The reproduction on clean 2.4.9 supports the underlying flaw independently, so the framing is not invented. Two details sit below the headline: the stores with detailed forensics were badly out of date, and Sansec says it has no indication the backdoor was used on Shield customers hit before its rules shipped.
Both disclosers sell the remedy
Sansec's interim advice sorts the world into Shield customers and everyone else, and the advisory doubles as proof that its rules were blocking traffic within hours of the first hit. Disrex responds to Magento incidents commercially and published a named rules repository mid-incident. Neither incentive discredits the technical work, and Sansec disclosing that a Shield customer was compromised before its rules went live runs against its own interest.
Mechanics hold up; scope stays thin
Mechanism and indicators are described in enough detail to act on, and two parties arrived at them separately, which is why the technical core holds up. Scope is where confidence drops: version coverage beyond Magento Open Source is asserted rather than demonstrated, the number of victims is unknown, and Adobe has not entered the record at all as of September 6.