A fully patched Magento store got backdoored on September 4. Adobe shipped the emergency fix three days later, and installing it is not the end of the job.

Update, September 9, 2026. Adobe published APSB26-146 on September 7 at 20:20 UTC at priority 1, its highest rating. StyleSmuggler is now CVE-2026-75650 with a CVSS score of 10.0, and CISA added it to the KEV catalog on September 8 with a federal remediation deadline of September 11. The fix ships as a hotfix, not a full release: VULN-39341-composer-patches.zip from repo.magento.com, applied as a composer patch. Adobe also requires you to rotate the encryption key and every credential it protected. The patch section below has the procedure. The order of operations in this article has not changed and is the reason the update matters: check for compromise before you patch, because the implant restarts every five minutes from cron and a patched compromised store is still a compromised store.

The single sentence in this story that should worry you is not the one about remote code execution. It is this one, from Rick Bouma of the Dutch hosting provider Disrex, describing the two compromised stores his team pulled apart: “Patch status was irrelevant here, which is the part merchants most need to hear.”

Almost every piece of security advice we have written for small businesses reduces, eventually, to apply the update. We wrote it about WordPress core, about a migration plugin on millions of sites, about Linux kernel cadence, and in August we wrote a whole piece arguing that CISA’s new risk-based triage is the best free vulnerability process a small business can copy.

That advice is still right. It just has a hole in it, and this week the hole is wide open in front of roughly a hundred thousand online stores.

What actually happened, with dates

On September 5, 2026, Sansec, the Dutch e-commerce forensics firm that has found most of the serious Magento bugs of the last decade, published an advisory for an unpatched, actively exploited, unauthenticated remote code execution chain it named StyleSmuggler. Sansec published while the bug was still a zero-day, and said so plainly: “Sansec is publishing early because stores are being compromised right now.”

Sansec maintains a running timeline on the advisory page. As of this writing it reads:

Timestamp	Event
2026-09-04 22:20	First confirmed exploitation
2026-09-05 07:15	Sansec Shield blocking initiated
2026-09-05	Public advisory published
2026-09-06	New persistence indicators observed (an fc-cache variant)
2026-09-07	Implant renamed to chronyd, version string 2.1.5
2026-09-08	Adobe’s next scheduled security release

Two things are worth pulling out of that table.

First, exploitation preceded disclosure by about nine hours. This was not a proof of concept that got weaponised. Somebody had a working chain before anyone else knew the bug existed.

Second, the implant is being actively developed during the incident. A renamed process and a bumped version number three days in is not a smash-and-grab. Somebody is maintaining this.

Adobe’s position, and how it changed in twenty-four hours

When we first published this on September 7, three days after the first confirmed compromise, Adobe had published no security advisory, assigned no CVE identifier, released no patch and issued no official workaround. The Adobe Commerce security bulletin index still ended at the August 11 update. SecurityWeek said it had contacted Adobe for comment and received no response by the time it published on September 7.

That held for about eight hours after we hit publish. At 20:20 UTC on September 7, Adobe released APSB26-146 at priority 1, the highest rating it assigns. The bug became CVE-2026-75650 at CVSS 10.0, and Adobe stated it is “aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants.”

So Adobe moved faster than Sansec’s own uncertainty suggested it might, and the gap between public disclosure and an official fix was roughly forty-eight hours. Credit where it is due. The window still existed, though, and the next section is about what happens inside one.

We are not going to editorialise about the silence beyond one practical observation, which is that the absence of a CVE had a concrete downstream effect for those two days that most people did not notice. We will come back to it.

What the vulnerability actually is

Sansec has deliberately not published the full exploit chain, and no vendor has confirmed the exact vulnerable code locations. What is public is the shape of it, and the shape is the interesting part.

Stage one, injection. An unauthenticated attacker sends a request, in the observed attacks a GraphQL request, carrying PHP code smuggled through Magento’s template styles properties. Nothing executes. The payload lands, inert, inside a file Magento itself generates: a checkout failure report under var/report/, or a line in var/log/system.log.

Stage two, execution. Later, Magento renders the Payment Transaction Failed Reminder email. Rendering that template server-side is what executes the code that stage one parked on disk. No user clicks anything. Nobody has to open the email. The rendering itself is the trigger, which means the attack completes whether or not the message is ever delivered.

That two-stage structure is why this is genuinely hard to defend against with a request filter. The request that carries the payload and the event that runs it are separated in time and travel through completely different subsystems. Magento’s own error reporting is the delivery vehicle, and Magento’s own email cron is the detonator. Aikido’s write-up puts it well: the attack leverages “functionality Magento already has.”

Long-time readers will recognise the pattern from our piece on second-order SQL injection in a WordPress migration plugin. Same class of trick. Poison a store of data on one request, get it executed on an unrelated one later. Second-order bugs are hard to find, hard to fix, and hard to block at the edge, because at no single moment does any one request look obviously wrong.

Which versions are affected

This is the part where the usual advice collapses.

Version	Status
Magento Open Source 2.4.7	Sansec reproduced the full chain on a clean install
Magento Open Source 2.4.8	Sansec reproduced the full chain on a clean install
Magento Open Source 2.4.9 (current)	Sansec reproduced the full chain on a clean install
Magento Open Source 2.4.6-p15	First confirmed real-world victim
Adobe Commerce	Same codebase, same exposure

The first victim was running 2.4.6-p15 with the July 2026 and August 2026 security updates applied and a clean patch-status report. Disrex separately confirmed two more compromised stores on 2.4.8 and 2.4.7-p2.

So the checklist item most people reach for, “am I on the latest patch level,” returns yes and means nothing. And the second thing people reach for, hitting /magento_version on the storefront, is worse than useless here: that endpoint returns only the major and minor train (2.4) plus the edition, never the -pN suffix, and it can be disabled by the host entirely. You cannot answer this question by looking at a version string, because every version string is the wrong answer.

The number everybody is repeating is not what they think it is

Several outlets are running headlines in the form “Magento zero-day hits 111K stores.”

That figure is not a count of victims. It is StoreLeads’ Q1 2026 population count for live Magento stores, which is to say the size of the platform, quoted as though it were the size of the breach. Nobody has published a victim count. Sansec has not quantified one. Disrex documented two stores in detail. The honest statement is that the exposed population is very large and the confirmed victim count is small and almost certainly an undercount, because a backdoor this quiet is found by looking, not by noticing.

While we were checking that number we also found it is stale. StoreLeads’ own Magento report, updated September 4, 2026, gives the current figure:

Metric	Value
Live Magento stores worldwide	102,875
United States	14,130 (13.7 percent)
Germany	6,994 (6.8 percent)
United Kingdom	6,048 (5.9 percent)
Netherlands	5,274 (5.1 percent)

Canada does not appear in the top four. Magento’s Canadian footprint is real but modest, and it skews toward B2B distributors, wholesalers and multi-warehouse retailers rather than the boutique storefronts that make up most of Toronto’s online retail. If you are a Toronto small business, the honest odds are that you are not on Magento. If you are, you are probably one of the larger ones, you probably have an agency or a hosting partner, and this is the week to find out whether they are awake.

How to tell whether this is your problem

Three checks, in the order that costs you the least.

1. Do you know your platform? If your site is Shopify, WooCommerce, Squarespace, BigCommerce, or a custom build on something that is not Magento, this is not your bug. Stop here.
2. Ask your developer or host one question. Not “are we patched.” Ask: “Have you checked our server for the StyleSmuggler indicators Sansec published on September 5?” The distinction matters, because the answer to the first question is yes and the answer to the second one may not be.
3. If nobody can answer within a few hours, escalate. The implant’s cron entry restarts it every five minutes. Time spent waiting for a callback is time the thing spends running.

The order of operations, and why it matters more than the mitigation

Disrex published an emergency mitigation repository on GitHub with web server rules, a code guard and a compromise scanner. Buried in the README is a sequencing warning that is more valuable than any of the code:

Do not apply mitigations to an already-compromised system. Check first. Clean up before you deploy defences.

The reason is mechanical. The attacker persists through cron, and the cron entry re-runs every five minutes. On one Disrex store the team counted 1,728 instances of the cron line, and the implant re-added itself within seconds of removal. If you harden a box that is already backdoored, you have not evicted anything. You have locked the door on the inside and left the tenant in the house, and you have destroyed the log evidence you would need to prove what was taken.

So the sequence is: detect, contain, clean, then harden. Not the other way around, however tempting the one-line nginx rule looks at 11pm.

Two more things from the Disrex write-up that change how you look for this. On one compromised store, the implant held 28 open connections to the store’s own Redis instance on port 6379 and was reading Magento session storage, meaning the malicious activity did not necessarily look like unusual outbound traffic. And across the two stores, Disrex recorded 26 distinct source addresses, mostly from a residential proxy pool. Blocking the single loudest attacker IP would have stopped less than a quarter of the traffic. IP blocklists are not a control here.

Indicators of compromise

These are the published indicators, aggregated from Sansec and Disrex. Everything below is read-only to check.

Processes. A process named [kworker/u:8:0] owned by a non-root user. Real kernel threads are owned by root; a bracketed name under your web user is the tell. Later variants have appeared as fc-cache and, since September 7, as chronyd. The safe method is not name matching but hashing what is actually running, via /proc/<pid>/exe.

Files.

~/.local/share/.gvfsd/gvfsd-user
~/.local/share/.gvfsd/.gvfsd_<8 hex chars>.lock
/tmp/.gvfsd_<8 hex chars>.lock
/tmp/.kw_<random>

The payload is a statically linked Rust binary of roughly 1.9 MB, built for both x86-64 and arm64.

Hashes.

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Network. The download domain 247.cdnflare[.]xyz, command and control at 99.84.67[.]186:443, and attacker source addresses including 88.216.72[.]181 and 5.181.86[.]133. Note that the command and control traffic is disguised as NTP server replies, so a firewall rule that trusts time sync is not going to notice it.

Application-level traces. Search var/report/ and var/log/system.log for the marker X_TRACE_ (a variant uses X-TRACE-), and for PHP code appearing anywhere in those files at all. In system.log, look for a TypeError from array_merge() receiving an integer argument. In access logs, look for styles[, styles%5B, generatorClass, with_resolved, and cdnflare.

The one an owner can spot without a shell. An unexplained burst of “Payment Transaction Failed Reminder” emails, particularly ones with unresolved {{var ...}} template tags still visible in the body, recipient addresses on .invalid domains, and order totals of zero. Bouma calls these “exhaust from the exploitation attempt.” Sansec adds the necessary caveat: genuine declined payments produce the same notification, so this is a prompt to investigate, not proof of anything.

If you own a Magento store and you check exactly one thing tonight, check your own inbox for that email.

The mitigation everyone is recommending, and what it costs

Sansec’s interim advice is explicit: “Temporarily disable Graphql until Adobe has released an official fix.”

That is sound as far as it goes, and you should understand what it costs before you do it. GraphQL is not an optional API bolted onto the side of a modern Magento install. It is the storefront. Any headless build, any PWA Studio storefront, any mobile app, any Next.js or Nuxt front end talking to Magento as a backend, and a good deal of third-party integration traffic all run over GraphQL. Aikido states the consequence flatly: a headless or PWA storefront “goes offline the moment GraphQL is blocked.”

So the decision is not “apply a mitigation.” It is “take the store down in a controlled way, or leave the door open.” For a traditional Luma-theme storefront, disabling GraphQL is close to free and you should do it now. For a headless build it is a business decision that needs the owner in the room, and the alternative is a WAF rule plus the code guard below plus somebody actually watching the logs.

There is a second caveat. GraphQL is the vector that has been observed. It is not established that it is the only one. Blocking it addresses the current attack pattern, not the underlying flaw.

The mitigation that sounds obvious and is not available

The intuitive move, once you understand stage two, is to turn off the Payment Transaction Failed Reminder email.

You cannot. We checked Adobe’s own documentation for the feature. Under Stores > Settings > Configuration > Sales > Checkout > Payment Failed Emails, the fields are:

Field	What it controls
Payment Failed Email Sender	Which store contact appears as sender
Payment Failed Email Receiver	Which contact receives the notification
Payment Failed Template	Which template is used
Send Payment Failed Email Copy To	Additional recipients
Payment Failed Copy Method	Bcc or separate email

There is no enable or disable toggle. Adobe’s documentation assumes the feature is always on, and every setting is about who gets it, not whether it runs.

And here is the part that makes it moot anyway: the trigger is the server-side rendering of the template, not its delivery. Even if you could suppress the outbound message, the code would still execute. Suppressing delivery would remove the single most visible symptom while leaving the compromise intact, which is strictly worse than doing nothing.

We are spelling this out because it is exactly the kind of plausible fix a competent person invents under pressure at midnight, and it would make the incident harder to detect.

The unofficial patches, and how to read them honestly

Three parties have published unofficial hardening: Disrex, the independent Magento developer ProxiBlue (Lucas van Staden), and the vendor Graycore. Disrex and ProxiBlue arrived at the same guard independently, which is mild evidence that they have found something real.

The common guard adds a single check as the first statement of three Magento dependency-injection scanner methods:

if (PHP_SAPI !== 'cli') {
    throw new \RuntimeException('Magento DI scanners are CLI-only.');
}

in these locations:

setup/src/Magento/Setup/Module/Di/Code/Scanner/ArrayScanner.php        collectEntities()
setup/src/Magento/Setup/Module/Di/Code/Scanner/XmlInterceptorScanner.php  _handleControllerClassName()
setup/src/Magento/Setup/Module/Di/Code/Reader/ClassesScanner.php       includeClass()

The logic is that these scanners exist to be run during setup:di:compile from the command line, and should never be reachable from a web request. Blocking the non-CLI path closes the include that the chain relies on. If you deploy with Composer, apply it as a composer-patch rather than editing files, so it survives the next composer install. Check whether any third-party module calls includeClass() before you guard that one.

Now the honesty part, and credit to Disrex for putting it in their own README rather than making somebody else find it:

“This repository was written with AI assistance, during a live incident, in a few hours. It has not been through review, and it carries no warranty of any kind.”

Their stated limitations are worth quoting too, because they are the sort of thing that normally goes unsaid: the web server rules are “bypassable by design” since they only inspect query strings and not POST bodies; the Apache rules were never tested against a live Apache; the guard was tested on a harness rather than in a running store; and testing was limited to Ubuntu, with shared hosting, Docker and control panels untested.

That is what an emergency mitigation looks like when someone is being straight with you. Use it, in a staging environment first, understanding that it is a sandbag and not a wall. Anyone offering you a confident, tested, complete fix for a bug whose vulnerable code path has not been publicly identified is telling you something about themselves.

The CVE gap, and why our own August advice has a blind spot

In August we recommended CISA’s BOD 26-04 triage questions as the best free vulnerability process a small business can adopt, and we pulled CISA’s Known Exploited Vulnerabilities feed to show what it catches. We still think that is right.

StyleSmuggler is the case it could not see, for seventy-two hours.

The KEV catalog is indexed by CVE. For three days Adobe had assigned no CVE. During that window this bug, which was unauthenticated, remotely exploitable, confirmed exploited in the wild and unpatched, could not appear in KEV, and did not appear in any scanner, dashboard, insurance questionnaire or managed-service report that keys off KEV or off CVE identifiers at all. Every automated process in that chain reported affected stores as clean while a Rust implant read their session stores.

That window closed on September 8, when CISA added CVE-2026-75650 to KEV with a September 11 due date. We are leaving this section in rather than quietly deleting it, because the gap closing does not make the point wrong. It makes it measurable: September 4 to September 8, four days of confirmed mass exploitation with zero coverage from every CVE-driven control a small business pays for.

The lesson is not that KEV-driven triage is wrong. It is that a catalog of known exploited vulnerabilities is downstream of a vendor deciding to name one. Between “researcher publishes” and “vendor assigns,” your automation is blind, and the only thing that covers that window is a human reading vendor-independent research. For a store on a platform this heavily targeted, that means somebody follows Sansec directly rather than waiting for the number to appear in a feed.

If you find indicators, the Canadian part

If a Magento store you operate is compromised, you have obligations under PIPEDA that start before you know what was taken.

PIPEDA requires you to keep a record of every breach of security safeguards involving personal information under your control, and to retain those records for 24 months, regardless of severity. That obligation is not conditional on the breach being serious. It applies to all of them, and the Office of the Privacy Commissioner can request those records.

Separately, you must report to the OPC and notify affected individuals where the breach creates a “real risk of significant harm,” assessed on the sensitivity of the information and the probability it has been or will be misused. The OPC publishes an assessment tool for exactly this judgment call.

For an e-commerce compromise, assume the assessment leans toward reportable. Customer names, addresses, order histories and email addresses are in the database by definition, and an implant reading session storage is squarely in the “probability of misuse” column. If cardholder data touched your server at any point, your acquirer and your PCI obligations are a separate track that starts immediately.

The practical instruction: preserve evidence before you clean. Disrex’s cleanup notes say remove the cron entry before killing the process, avoid rebooting, and defer composer install. That ordering is about eviction, but it also happens to be what preserves the forensic record you will need to answer the OPC’s questions and your insurer’s.

This has happened before, and the patch rate is the real story

Sansec has named a serious Magento chain roughly once a year for a decade: Shoplift in 2015, TrojanOrder in 2022, CosmicSting in 2024, SessionReaper (CVE-2025-54236) in 2025, StyleSmuggler now.

The number worth carrying from the last one is not about the bug. It is about the response. Six weeks after Adobe shipped an emergency patch for SessionReaper, Sansec measured 38 percent of stores protected and 62 percent still vulnerable. On October 22, 2025, the day mass exploitation began, Sansec blocked over 250 exploitation attempts.

Six weeks. An emergency patch, available, free, and nearly two thirds of stores had not applied it. That is the industry’s actual patching performance on the platform, measured rather than assumed.

Which gives this week a grim symmetry. Last year the fix existed and most stores did not apply it. This year most stores would apply the fix and it does not exist.

What this does and does not say about platform choice

We are not going to use an active incident to sell anyone a migration, and we would be embarrassed to. A zero-day in a mature platform is not evidence that the platform is bad. Every platform of this size has had one. WordPress has had several this year. The vulnerability is not the argument.

The response time is.

Here is the actual distinction, and it is the same one we drew in our piece on Shopify versus a custom storefront for Toronto retailers:

• On hosted SaaS (Shopify, BigCommerce), a bug at this layer is the vendor’s emergency. Their security team patches it across every store, usually before you read about it, and your job is your own apps and theme code.
• On self-hosted software (Magento, WooCommerce, anything on your own server), the vendor writes the patch and you are the operations team. If nobody is on call, the patch existing changes nothing, which is the entire content of that 62 percent figure.

Neither model is better in the abstract. They price risk differently. SaaS trades control for someone else’s pager rotation. Self-hosting trades that pager rotation for control. What goes wrong for small businesses is choosing self-hosted for the control and then never staffing the pager, which is how a store ends up on 2.4.6-p15 with a clean patch report and a Rust implant in ~/.local/share/.

The question to ask about your own store is not “which platform is more secure.” It is: when a zero-day drops on a Friday night, whose phone rings, and did they answer this time?

The patch, and what it does not fix

We said we would update this post when Adobe’s bulletin published. It did, ahead of the scheduled September 8 release, and here is what it contains.

APSB26-146, published September 7, 2026 at 20:20 UTC, priority 1. The vulnerability is CVE-2026-75650, CVSS 10.0, classified as improper neutralisation of special elements used in a template engine, which matches the mechanism described earlier in this article. Adobe’s own wording is that it “is aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants.”

How the fix ships. Not as a full release. As a hotfix: download VULN-39341-composer-patches.zip from repo.magento.com and apply it as a composer patch, the same way we recommended applying the unofficial guards so they survive the next composer install. Verify with:

vendor/bin/magento-patches -n status | grep "39341\|Status"

What it was tested against, corrected September 11. The original version of this paragraph said Magento Open Source 2.4.4 to 2.4.9. That was wrong, and the difference matters to exactly the stores least able to absorb it, so here is the accurate version taken from Adobe’s own patch compatibility table:

Product	Versions the VULN-39341 hotfix applies to
Adobe Commerce	2.4.4 through 2.4.9, at the 2026-aug release of each line and earlier
Magento Open Source	2.4.6 through 2.4.9 only
Adobe Commerce B2B	1.3.3 through 1.5.3

If you are on Magento Open Source 2.4.5 or older, there is no official fix and none is coming. That is the free, self-hosted edition, which is disproportionately what a small store ends up running, and it is now carrying an unpatched CVSS 10.0 remote code execution bug that is confirmed exploited in the wild. You have three real options, in order of preference: upgrade to a supported line, which is the only durable answer; apply Scandiweb’s backport, which the company says covers 41 unsupported releases from 2.2.0 through 2.4.3-p3, understanding that you are accepting third-party code into your payment path on trust; or keep the unofficial guards discussed below in place indefinitely, which is the weakest of the three. Doing none of them is not a holding position. If you are on an older patch level than the August release of a line that is covered, bring that current first.

The part merchants are skipping. Adobe does not stop at “apply the hotfix.” It also requires you to rotate the encryption key and 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.

That instruction is the whole reason the order of operations in this article still governs. The hotfix closes the door. It does nothing about anyone already inside, and it does nothing about credentials that left the building between September 4 and the moment you patched. Check for compromise first, patch second, rotate third. A store that patched on September 8 and rotated nothing has changed the lock and left the old keys in circulation.

On the unofficial guards. If you deployed the Disrex mitigation or the DI scanner guard, keep them until you have applied the official hotfix and verified it with the command above, then decide. They are narrower than Adobe’s fix and there is no harm in defence in depth, but they are also unmaintained code in your deployment pipeline and somebody should own the decision to keep or remove them rather than letting them rot in place.

And it is now in KEV. CISA added CVE-2026-75650 on September 8, 2026, with a federal remediation deadline of September 11. A three-day window is close to the shortest CISA issues. If your managed service provider or your cyber insurer keys off KEV, this is the week the alert fires for them, four days after the attacks started.

The short version

• StyleSmuggler is an unauthenticated RCE chain in Magento Open Source and Adobe Commerce, disclosed by Sansec on September 5, 2026, exploited since September 4.
• Every current version is affected, including 2.4.9. Being fully patched does not help. The first victim was fully patched.
• Adobe published APSB26-146 on September 7 at priority 1. The bug is CVE-2026-75650, CVSS 10.0. Apply the VULN-39341 composer hotfix, then rotate the encryption key and every credential it protected.
• The hotfix covers Adobe Commerce 2.4.4 to 2.4.9 but Magento Open Source 2.4.6 to 2.4.9 only. On the free edition at 2.4.5 or older, no official fix is coming: upgrade, use Scandiweb’s backport, or keep the unofficial guards, but do not wait.
• CISA added it to KEV on September 8 with a September 11 federal deadline. For four days before that, no CVE-driven scanner or insurance questionnaire could see it at all.
• Check for compromise before you deploy any mitigation or patch. The implant restarts every five minutes via cron and hardening a compromised box just hides it.
• Watch for a burst of “Payment Transaction Failed Reminder” emails with raw {{var}} tags and zero totals. That is the symptom visible without a shell.
• Disabling GraphQL is the recommended interim fix and it takes headless and PWA storefronts offline. That is a business decision, not a technical one.
• Turning off the payment failure email is not possible in the Adobe admin and would not help, because the trigger is template rendering, not delivery.
• For the first four days, no CVE meant no KEV entry, which meant every CVE-driven scanner and process called affected stores clean. That is the gap worth remembering after this specific bug is closed.
• Adobe shipped 172 CVEs across ten bulletins on September 8, the same day Microsoft shipped its largest Patch Tuesday on record. We covered how to triage a month like that separately.

If you run a Magento or Adobe Commerce store in the Toronto area and you do not have someone able to run these checks tonight, get in touch. We would rather spend an hour helping you rule it out than read about it later.

Sources: Adobe’s APSB26-146 bulletin (September 7, 2026, priority 1, the VULN-39341 hotfix, the credential rotation requirement, and the patch compatibility table re-read on September 11 for the corrected version ranges, which is the source of the Magento Open Source 2.4.6 floor); Scandiweb on which versions Adobe covers (retrieved September 11, 2026, for the confirmation that there is no official fix for Magento Open Source below 2.4.6 and for the backport covering 41 releases from 2.2.0 to 2.4.3-p3); Tenable’s CVE-2026-75650 FAQ (CVSS 10.0 and the disclosure timeline); CISA’s September 8 KEV addition and the KEV JSON feed, catalog version 2026.09.08, checked directly on September 9, 2026 for the September 11 due date; Sansec’s StyleSmuggler advisory; Sansec’s SessionReaper exploitation data; The Hacker News; SecurityWeek; the Disrex emergency mitigation repository; Aikido’s analysis; Adobe’s payment failure notification documentation; StoreLeads’ Magento report; and the Office of the Privacy Commissioner of Canada on mandatory breach reporting.