[{"content":" CVE-2026-84869Exploited in the wildcritical CVSS9.9 — ConnectWise as CNA CISA KEVNot listed as of the 8 Sep catalog AffectedScreenConnect client — cloud and on-premise Fixed inReported as 26.6.5 — confirm with the vendor before planning a rollout Do thisPatch the client, and deselect TransferFiles on every role and session group What broke On 3 September, Huntress published research on modified ConnectWise ScreenConnect clients that behave like a worm. The rogue client watches for a new Host connection, registers script files with ScreenConnect\u0026rsquo;s virtual file-transfer system, and queues them to that Host with the action set to run. The Host executes them. Every new connection is a new infection.\nThe same day, ConnectWise issued a mitigation-only advisory about file transfer, with no CVE and no version upgrade required.\nThat has since changed, and if you read the earlier coverage you have stale information:\nCVE-2026-84869 was published 8 September. CWE-862 missing authorisation plus CWE-269. CVSS 9.9. Description: a condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorisation or Host confirmation. It affects the client, not the server. Cloud and on-premise are both in scope. One thing to be precise about: ConnectWise has not publicly confirmed a technical link between the file-transfer flaw and the Huntress campaign. The two arrived together and describe the same capability, but treating \u0026ldquo;the advisory is about this campaign\u0026rdquo; as vendor-confirmed fact would be overstating it.\nWho is affected Any ScreenConnect deployment where remote sessions are established with hosts you do not fully control — which is most MSP-shaped deployments.\nOn the fixed version: reporting points to 26.6.5, with all prior versions affected. I could not confirm that version number against ConnectWise\u0026rsquo;s own bulletin — the vendor page returned 403 on repeated attempts, and it rests on a single tracker. Verify the version against ConnectWise directly before you plan a rollout around it. I would rather flag that than print a number you act on and find wrong.\nHow victims are reached Three routes, all social rather than technical:\nFake Quick Assist tech-support scams Phishing delivering a malicious ScreenConnect.ClientSetup.msi SEO-poisoned fake refund lures impersonating a well-known retailer\u0026rsquo;s tech support None of these need a vulnerability. The CVE is what turns one compromised host into many.\nWhat the payload does Enough detail to recognise it, and no more.\nA staged VBScript chain runs from the user\u0026rsquo;s temp directory. The first stage profiles the host before anything else happens — it checks for an existing ScreenConnect installation, enumerates security products by name (Huntress, CrowdStrike, SentinelOne, Sophos, Cisco AMP and Malwarebytes are all explicitly checked for), and measures available RAM against a 5GB threshold. The result is written to a file, and where the host looks unattractive the chain aborts.\nThat profiling step is itself a defensive signal: this campaign decides whether to proceed based on whether it thinks you have EDR.\nLater stages retrieve a payload from cloud file hosting and decrypt it through several layers of obfuscation before execution. Three payload variants have been observed, selected by the profile result:\nUser-level backdoor — a second ScreenConnect instance under the attacker\u0026rsquo;s control. Persistence and privilege escalation — a UAC bypass through a hijacked protocol handler, an AMSI bypass, and — the one that matters most operationally — adding all of C:\\Users as a Microsoft Defender exclusion path. Tunnelling and mining — a tunnelling utility masquerading as Themes.exe, XMRig renamed to SearchIndex.exe, and a known-vulnerable WinRing0 driver installed as svcdrv64.sys. This variant also disables Defender reporting and notifications, and turns off HVCI memory integrity. That last variant leaves the machine measurably less defended than it found it, and those changes survive removal of the malware.\nHow to detect it The durable detection is in the ScreenConnect audit log, not in the filenames. Huntress explicitly warns that the script names will change. What does not change is the shape of the activity:\nScreenConnect audit log entries showing RunFiles or RanFiles where Process: Guest.\nThat is the behaviour the CVE describes, and it holds regardless of what the payload is called this week.\nSupporting signals, in rough order of usefulness:\nScreenConnect.WindowsClient.exe spawning wscript.exe. This is what Huntress alerted on. Generalise it: any Windows Script Host or PowerShell execution parented to a ScreenConnect session process. Run key HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run with the value name WindowsServiceHost, pointing at a .vbs in the user\u0026rsquo;s AppData. A Defender exclusion covering C:\\Users. Almost nothing legitimate does this. If you can query exclusion paths across your estate, that single check is worth running today whether or not you use ScreenConnect. Unexpected Themes.exe, SearchIndex.exe, or svcdrv64.sys — legitimate-looking names in illegitimate places. HVCI or Defender reporting silently disabled. Network indicators, from the Huntress IOC table: 45.13.237[.]190 (associated with tele-sync.opik[.]net), 131.123.40[.]98 on port 8041, 146.59.55[.]107, 45.32.192[.]150, 15.204.185[.]204. Domains borertors92.anondns[.]net and homehub.opik[.]net. A backdoored ScreenConnect instance ID of 7a4d7d66502d4260 has also been reported.\nOf those, 146.59.55[.]107 appears only in the Huntress table and not in any secondary coverage — no reason to doubt it, but you should know which indicators have one source and which have several.\nOn file hashes: Huntress published them and I am deliberately not reproducing them here, because I could not verify them to my own satisfaction against the primary source. Pull them from the Huntress IOC table directly. A wrong hash in a detection rule is worse than no hash — it produces confident silence.\nWhat to do 1. Patch the client, once you have confirmed the fixed version with ConnectWise.\n2. Remove the file-transfer permission, which works immediately and needs no upgrade:\nAdministration → Security → Roles → edit each role → for each session group, open Scoped Permissions and deselect TransferFiles (or TransferFilesInSession on older versions). This has to be repeated across every role — one missed role is an open path.\nEven after patching, this is sound defence in depth for MSP-style deployments. Very few workflows genuinely need every role to push files into every session.\n3. Reimage compromised hosts. Huntress\u0026rsquo;s judgement is that the chains are too extensive for in-place cleanup, and given the Defender exclusions, disabled HVCI, and installed vulnerable driver, that is hard to argue with. Rebuild from known-good media.\n4. Audit for ScreenConnect you did not install — including on-premise instances — and for secondary remote-access tools such as UltraViewer or Quick Assist showing up on affected machines.\nThe part worth remembering The interesting property of this campaign is not the malware, which is unremarkable. It is that the remote access tool itself is the propagation mechanism, using a documented product feature working roughly as designed, and that the initial access is a phone call rather than an exploit.\nDetections keyed to script names will decay within weeks. A detection keyed to a guest process running files inside a support session describes the actual capability, and will still be true after the payload is rewritten.\nReferences Huntress — Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity, 3 September 2026 ConnectWise — ScreenConnect security bulletin, 8 September 2026 NVD — CVE-2026-84869 ","permalink":"https://infosecpwn.com/posts/2026-09-09-screenconnect-rogue-clients-cve-2026-84869/","summary":"Modified ScreenConnect clients that infect every host they connect to. The durable detection is in the audit log.","title":"Rogue ScreenConnect clients: hunt the session, not the filenames"},{"content":" CVE-2026-13181 · 13182 · 13183 · 13184high CVSS8.1 and 7.5 — Progress as CNA; no NVD primary score EPSS0.00208–0.00502 — 11th to 41st percentile CISA KEVNot listed as of the 8 Sep catalog AffectedTelerik UI for ASP.NET AJAX 2010.1.309 – 2026.2.519 Fixed in2026.2.708, released 8 Jul 2026 Do thisUpgrade. Public exploit code was published 7 Sep, two months after the fix. What broke Tanto Security published research on 7 September describing a chain of four vulnerabilities in Progress Telerik UI for ASP.NET AJAX that ends in remote code execution. All four were fixed in July.\nThe chain, in order:\nCVE What it is CWE CVSS CVE-2026-13184 Integrity protection can fall back to a predictable default key CWE-321 7.5 CVE-2026-13182 Client-state handling distinguishes decrypt failures from parse failures CWE-209 7.5 CVE-2026-13183 The same distinction leaks through response timing CWE-208 7.5 CVE-2026-13181 Attacker-influenced type resolution feeding an unsafe sink CWE-470 8.1 All scores are Progress\u0026rsquo;s own as CNA. NVD has published no primary metrics.\nOne correction worth making, because it has been repeated: CVE-2026-13181 is not type confusion. It is unguarded type resolution — a type name taken from attacker-supplied metadata reaches a type-resolution call with no allowlist and no base-type constraint, and the resulting object\u0026rsquo;s properties are then populated from attacker-supplied data. CWE-470, not CWE-843. The distinction matters if you are writing detections or triaging by class.\nThe July fix replaced AES-CBC with AES-GCM. That is a neat single move: GCM is authenticated, so tampered ciphertext fails its tag check before anything is decrypted or parsed. That removes the padding oracle, the decrypt-versus-parse split, and the timing shadow of that split, all at once.\nWho is affected Vulnerable: 2010.1.309 through 2026.2.519 — a fifteen-year range. Fixed: 2026.2.708 (2026 Q2 SP1), released 8 July 2026. The July bulletin actually covers ten CVEs, 13181 through 13190, not just the four in this chain. Same affected range, same fixed version. If you are upgrading anyway you get all ten; if you are assessing exposure, do not scope your assessment to four.\nThe preconditions are the whole story The full RCE chain requires configuration that a default install does not have:\na reachable page containing a RadAsyncUpload control, and server-side code whose FileUploaded handler reads UploadResult — Telerik itself never reads it, and that getter is what performs the type resolution, and an explicitly set, non-default Telerik.AsyncUpload.ConfigurationEncryptionKey There is an uncomfortable irony in that third item: setting ConfigurationEncryptionKey is a Telerik-recommended hardening step. The full chain lands on deployments that followed earlier advice.\nTwo caveats that get lost when this is summarised as \u0026ldquo;needs non-default config\u0026rdquo;:\nThose preconditions gate the full chain. The oracles (13182, 13183) need only a reachable RadAsyncUpload, and information disclosure applies more broadly. CVE-2026-13184 is the exact inverse. It triggers when configuration is absent — no ConfigurationHashKey, no explicitly configured machineKey. That is a default-ish deployment, not a hardened one. So \u0026ldquo;we didn\u0026rsquo;t configure that, we\u0026rsquo;re fine\u0026rdquo; is wrong in both directions. Check which case you are in.\nIs it being exploited? Not that anyone has confirmed. None of CVE-2026-13181 through 13190 appear in CISA KEV as of the 8 September catalog, and there are no confirmed in-the-wild reports.\nOne vendor threat-intelligence page claims to be tracking \u0026ldquo;ongoing exploitation attempts\u0026rdquo; but gives no dates, volumes, or specifics, and nothing corroborates it. Treat that as unverified.\nEPSS, once again, is not your friend here:\nCVE EPSS Percentile CVE-2026-13181 0.00502 41.1 CVE-2026-13182 0.00320 24.6 CVE-2026-13183 0.00320 24.6 CVE-2026-13184 0.00208 11.0 Half a percent, and the eleventh percentile at the bottom end.\nNow the part that those numbers do not know about: Tanto published working exploit code on 7 September, in a public repository. EPSS is a prediction based on observed exploitation, and it has had no time to observe anything.\nThis is the real point of the post. The patch is two months old. The weapon is two days old. If you scoped this in July, read \u0026ldquo;no confirmed exploitation\u0026rdquo; and deferred it, the input that justified deferring has changed even though every number on the dashboard looks the same. Telerik UI for ASP.NET AJAX has four separate entries in KEV from earlier years — this product line has a consistent history of mass exploitation once public code exists.\nWhat to do Upgrade to 2026.2.708 or later. That is the actual fix and it resolves all ten July CVEs.\nIf you cannot upgrade immediately:\nLock the web root so the application pool account cannot write to it. This both blocks the persistent payload and produces a signal when something tries. Relocate the RadAsyncUpload temp folder outside App_Data. Set an explicit machineKey with HMACSHA256 validation and autogeneration disabled, then recycle the app pool. This closes 13184\u0026rsquo;s fallback path. If RadAsyncUpload is unused, disable the handler outright: Telerik.Web.DisableAsyncUploadHandler = true. Disable cookie-based storage in RadPersistenceManager and RadDockLayout, and do not derive storage keys from user input (13185, 13186). One vendor mitigation to treat carefully Progress lists customErrors set to On or RemoteOnly as a mitigation for CVE-2026-13182, and it appears as mitigation #1 in the July bulletin.\nThe researchers say plainly that this suppresses only the error-text oracle. The timing variant, CVE-2026-13183, still works — they demonstrated a stable signal from Melbourne to us-east-1 across roughly 221ms of round-trip time using a timeless timing technique.\ncustomErrors is partial hardening. It is not a fix, and it should not be the reason an upgrade gets deferred.\nHow to detect it Progress states there are no visible symptoms and that exploitation leaves no obvious trace in standard ASP.NET error logs. Neither Progress nor Tanto has published network IOCs, Sigma rules, or YARA rules. That gap is real and I would rather say so than paper over it.\nWhat you do have is behavioural:\nw3wp.exe spawning cmd.exe. Tanto\u0026rsquo;s words: this \u0026ldquo;almost never happens in normal operation and is worth alerting on outright.\u0026rdquo; Strongest single signal. New or off-schedule .aspx files in the web root. The on-disk payload is encrypted at rest with no recognisable web-shell strings, so content signatures will miss it. Hunt on file creation and timeline, not on content. A mixed-mode DLL — a native PE that also carries a .NET assembly manifest — under the RadAsyncUpload temp folder, or w3wp.exe loading a DLL out of App_Data. Well off the normal path. Repeated failed attempts are the tell for the memory-only variant, which touches no disk and dies on app-pool recycle. File integrity monitoring will not see it. The pattern Two months between the fix and the public exploit is a long, quiet window, and it closes without any dashboard changing colour. Nothing about CVE-2026-13181 looked different on 6 September than it did on 8 September — same CVSS, same EPSS, same absence from KEV — except that working code now exists.\nIf your prioritisation reads only scores, this is the shape of thing it will miss.\nReferences Progress Telerik — Critical RCE Chain Bulletin, July 2026 Progress Telerik knowledge base articles for CVE-2026-13181 through 13184 Tanto Security — Telerik research writeup, 7 September 2026 NVD — CVE-2026-13181, 13182, 13183, 13184 FIRST EPSS CISA Known Exploited Vulnerabilities catalog ","permalink":"https://infosecpwn.com/posts/2026-09-09-telerik-rce-chain-public-exploit/","summary":"Progress fixed this in July. Public exploit code landed in September. EPSS still reads 0.5%.","title":"The Telerik RCE chain: a two-month-old patch and a brand-new weapon"},{"content":"What this site is infosecpwn publishes defender-focused analysis of vulnerabilities and intrusion campaigns that are actually being exploited.\nMost security news tells you that something is broken. This site is written to answer the questions you have twenty minutes later, when someone asks whether it affects you:\nWhat broke — the vulnerability class, in plain terms. Who is affected — exact products and version ranges. Is it being exploited in the wild — with dates and sources. What to patch — fixed versions, workarounds, and the post-patch steps vendors bury in paragraph nine. How to detect it — IOCs, log queries, and hunting guidance. What this site will not publish This is a defensive publication. It does not publish:\nProof-of-concept exploit code Step-by-step exploitation walkthroughs Payloads, gadget chains, or working attack tooling Where exploitation detail matters for understanding impact, it is described conceptually and the reader is pointed at the vendor advisory. If you need weaponized detail, this is the wrong site — and that is deliberate.\nIndependence This is an independent project with no connection to any employer. Nothing here is sourced from anyone\u0026rsquo;s internal work, customer data, or private vulnerability disclosures. Every claim traces back to a public source, and those sources are cited.\nNo vendor sponsors this site\u0026rsquo;s coverage, and no vendor sees a post before it publishes.\nCorrections Security writing ages badly and sometimes starts wrong. If something here is inaccurate, tell us and we will fix it in place, with a dated note saying what changed. Corrections are never made silently. The address is on the Contact page.\n","permalink":"https://infosecpwn.com/about/","summary":"What infosecpwn covers, what it deliberately does not publish, and how it stays independent.","title":"About"},{"content":"Email hello@infosecpwn.com\nWe read everything and reply to most of it.\nWhat\u0026rsquo;s worth sending Corrections. Fastest route to a fix. Point at the specific claim and what\u0026rsquo;s wrong with it. We will correct the post and note the change. Tips on active exploitation. Especially if you\u0026rsquo;re seeing something in your own telemetry that hasn\u0026rsquo;t been written up yet. Detection improvements. If a query or rule here is noisy or wrong in your environment, that is useful to know. What isn\u0026rsquo;t Guest post and link-insertion offers. The answer is no. Requests for exploit code or attack assistance. See About. Vulnerability reports for third-party products — take those to the vendor or a coordinated disclosure program rather than here. Responsible disclosure for this site If you find a security issue in infosecpwn.com itself, email the address above. It is a static site with no user accounts and no database, so the surface is small — but we would still like to know.\n","permalink":"https://infosecpwn.com/contact/","summary":"How to reach infosecpwn — corrections, tips, and everything else.","title":"Contact"},{"content":"No warranty Everything on this site is provided as-is, for informational purposes. Security information ages quickly: version numbers change, vendors revise advisories, and exploitation activity shifts week to week. A post is accurate to the best of our knowledge on the date it was published, and no further.\nVerify against the vendor\u0026rsquo;s own advisory before you act on anything here.\nNot professional advice Nothing here is professional, legal, or compliance advice, and reading it creates no advisory relationship. Your environment is not ours. Patch guidance that is correct in general can be wrong for you — test changes before deploying them.\nIntended use This site is written for defenders: people who need to patch systems, write detections, and answer \u0026ldquo;are we affected?\u0026rdquo;\nIt does not publish exploit code or exploitation walkthroughs, and nothing here is intended to enable unauthorized access to any system. Testing against systems you do not own or have explicit written permission to test is illegal in most jurisdictions.\nIndependence This is an independent project with no connection to any employer. No content is sourced from any employer\u0026rsquo;s internal work, customer data, or non-public vulnerability disclosures.\nWe have no financial relationship with the vendors whose products are discussed.\nExternal links Links to vendor advisories, research writeups, and other third-party material are provided for reference. We do not control that content and are not responsible for it.\nLimitation of liability To the fullest extent permitted by law, we accept no liability for any loss or damage arising from use of, or reliance on, anything published here.\n","permalink":"https://infosecpwn.com/disclaimer/","summary":"Limits on the accuracy, applicability, and intended use of anything published here.","title":"Disclaimer"},{"content":"Last updated: 9 September 2026\nThe short version This is a static site. It has no accounts, no logins, and no database. It does not ask you for personal information, and it does not sell anything about you.\nIt does use a content delivery network, which processes request data in order to deliver pages and block attacks. The details are below.\nWhat this site collects directly Nothing that identifies you personally.\nThe site is served through Cloudflare, which processes standard web request data — IP address, user agent, requested URL, timestamp — in order to deliver pages and block attacks. We use aggregate analytics to see which pages are read. These are counts, not profiles.\nIf you email us, we have your email address and whatever you wrote. We keep it, we do not publish it, and we do not add it to any list.\nEmail newsletter If you subscribe to the newsletter, we store your email address with the email provider used to send it. You can unsubscribe from any email, and unsubscribing removes your address. We do not sell or share the list.\nCookies Essential: Cloudflare may set cookies necessary for security and delivery. Preferences: your light/dark theme choice is stored locally in your browser and never leaves it. Most browsers let you block or delete cookies. The site works fine without them.\nYour rights Depending on where you live, you may have the right to access, correct, delete, or restrict processing of personal data relating to you, and to object to processing or lodge a complaint with a supervisory authority. To exercise any of these, email the address on the Contact page.\nChildren This site is aimed at security professionals. It is not directed at children under 13, and we do not knowingly collect information from them.\nChanges If this policy changes materially, the date at the top changes and the change is noted here.\nContact Questions about this policy go to the address on the Contact page.\n","permalink":"https://infosecpwn.com/privacy/","summary":"What infosecpwn.com collects, what third parties collect, and how to control it.","title":"Privacy Policy"},{"content":" CVE-2026-75650Exploited in the wildIn CISA KEVcritical CVSS10.0 — Adobe as CNA; no NVD primary score EPSS0.00676 — roughly 50th percentile CISA KEVAdded 8 Sep 2026 · due 11 Sep · forensic triage flagged AffectedCommerce 2.4.4–2.4.9 · B2B 1.3.3–1.5.3 · Open Source 2.4.6–2.4.9 Fixed inHotfix VULN-39341 (APSB26-146) Do thisPatch, then rotate the encryption key and every credential it protected What broke CVE-2026-75650 is an unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source. Adobe published the fix in bulletin APSB26-146 on 7 September with a priority 1 rating. Sansec, who found it, calls it StyleSmuggler — that name is theirs, not Adobe\u0026rsquo;s, so expect to see both.\nThe class is CWE-1336, improper neutralisation in a template engine. Conceptually it runs in two stages: an attacker gets malicious code stored in the application\u0026rsquo;s data — for instance by causing a failure report to be generated — and Magento then executes that code later, while rendering an email. The styles properties are what let it slip past existing safeguards, hence the name.\nAdobe PSIRT scores it 10.0. Worth knowing that this is Adobe\u0026rsquo;s own score as CNA; NVD has not published a primary score of its own. The Scope:Changed metric is what takes it to a perfect ten.\nSansec has not published the full gadget chain yet, and this post is not going to speculate about it.\nWho is affected Product Affected versions Adobe Commerce 2.4.4 – 2.4.9 Adobe Commerce B2B 1.3.3 – 1.5.3 Magento Open Source 2.4.6 – 2.4.9 (per Adobe) There is a discrepancy in that table worth taking seriously. Adobe\u0026rsquo;s bulletin lists Magento Open Source from 2.4.6, but Sansec states every version from 2.4.4 onward is affected, and notes Adobe tested the hotfix as far back as 2.4.4. If you run 2.4.4 or 2.4.5 Open Source, treat yourself as in scope rather than out of it.\nBeing fully patched was not a defence. Sansec\u0026rsquo;s first confirmed victim was running 2.4.6-p15 with the July and August 2026 patches applied and a clean security:patch-status. This was a zero-day; patch discipline bought nothing.\nIs it being exploited? Yes, and it was being exploited before a fix existed.\nSansec\u0026rsquo;s timeline puts first confirmed exploitation at 4 September, 22:20 UTC. Adobe\u0026rsquo;s hotfix landed on 7 September. That is roughly three days of exposure with nothing to apply.\nWithin 50 minutes of that first confirmed attack, Sansec\u0026rsquo;s scanner was flagging the same implant on unrelated stores. Some coverage has rendered this as a single server being fully compromised in 50 minutes; the primary source says something a little different and, frankly, more alarming — that is how quickly it was spreading across unconnected victims.\nCISA added it to the KEV catalog on 8 September with a remediation deadline of 11 September — a three-day clock, issued under BOD 26-04. The KEV entry also carries forensicTriage: Yes, meaning affected agencies are expected to investigate, not merely patch.\nA note on EPSS CVE-2026-75650 currently scores 0.00676 on EPSS — roughly the 50th percentile.\nIf your prioritisation pipeline keys on EPSS, this vulnerability looks utterly unremarkable: actively exploited, in KEV with a three-day deadline, CVSS 10.0, and sitting at 0.68%. EPSS is a prediction trained on observed exploitation over time, so it lags hardest exactly where it matters most — on brand-new zero-days. For comparison, last year\u0026rsquo;s SessionReaper (CVE-2025-54236) now sits at 0.945, but it did not start there either.\nDo not let anyone read 0.68% as \u0026ldquo;we have time.\u0026rdquo;\nWhat to do 1. Apply the hotfix. VULN-39341, distributed as VULN-39341-composer-patches.zip from repo.magento.com and applied as a composer patch. This is a hotfix, not a full release. Confirm it took:\nvendor/bin/magento-patches -n status | grep \u0026#34;39341\\|Status\u0026#34; 2. Scan before you assume you are clean. Patching does not remove an implant that is already there. Adobe is explicit that rotation alone does not invalidate credentials an attacker already holds.\n3. Rotate — and rotate wider than the encryption key. This is the step that gets skipped, and skipping it makes the patch cosmetic. Successful exploitation exposes the Magento encryption key, which protects stored integration and payment configuration. Rotate at the source, not just inside Magento:\nThe Magento encryption key All admin passwords REST, SOAP and GraphQL integration tokens; OAuth client secrets Payment gateway API credentials — at the provider, not in Magento\u0026rsquo;s config Database credentials, SSH and deploy keys Third-party extension API keys On cloud deployments, redeploy after rotating.\nHow to detect it Start with the email. The execution trigger is Magento\u0026rsquo;s standard Payment Transaction Failed Reminder. An unexplained burst of those is an investigation trigger. Nobody needs to open the email — the code runs at render time, and the attack works even if delivery fails.\nProcess names. The implant masquerades as an ordinary system process: [kworker/u:8:0], fc-cache, chronyd, or gvfsd-user. The chronyd choice is deliberate — it invites an analyst to dismiss it as the legitimate time daemon.\nSansec\u0026rsquo;s checks:\ncrontab -l | grep -i gvfsd ps -eo pid,comm,args | grep -iE \u0026#39;kworker|fc-cache|chronyd\u0026#39; grep -r \u0026#39;crontab command not allowed\u0026#39; /var/log/ grep -ril \u0026#39;x_trace_\u0026#39; var/report/ find pub/media -name \u0026#39;*.php\u0026#39; Two caveats on those, both important:\nPersistence is written straight into the cron spool file rather than through crontab -e, so there is no REPLACE line in syslog to find. One build relaunches with no cron entry at all. An empty crontab is not evidence of a clean host. The strongest signal is on the network. The implant\u0026rsquo;s command-and-control mimics NTP, and does it imperfectly in two ways you can alert on:\nIt emits nine 48-byte datagrams roughly 10ms apart, every 60 seconds. A real NTP client sends one. Every datagram is marked NTPv4 server mode. A client has no reason to ever send that. Either one on its own is a usable rule. Together they are close to unambiguous.\nOther indicators: malware download host 247.cdnflare[.]xyz; a truncated User-Agent matching no real browser, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36.\nDo not stop at the background process Sansec observed a second, unrelated actor on the same victims, dropping a small PHP web shell into pub/media/catalog/product/cache/ under randomised directory names. It returns 404 unless a specific request header is present, which is why casual crawling of the media directory will not find it. It was preceded by reconnaissance that exfiltrated over chunked DNS labels.\nFinding and removing the Rust implant does not mean the host is clean.\nThe part worth remembering Session storage hardening did not help. One merchant watched an attempt fail against session storage and succeed eight seconds later through a file uploaded via Magento\u0026rsquo;s custom options.\nThere is no configuration that saved anyone here, and there was no patch to apply for three days. What was actually under each operator\u0026rsquo;s control was the second half: how fast the hotfix went on once it existed, and whether the credential rotation happened. That second part is still, for a lot of stores, undone.\nReferences Adobe Security Bulletin APSB26-146 Adobe Commerce Knowledge Base — APSB26-146 remediation guidance Sansec — StyleSmuggler 0-day research and IOCs NVD — CVE-2026-75650 CISA Known Exploited Vulnerabilities catalog ","permalink":"https://infosecpwn.com/posts/2026-09-08-magento-stylesmuggler-cve-2026-75650/","summary":"Adobe shipped a hotfix for the Magento flaw exploited since 4 September. Applying it is the easy half.","title":"Magento CVE-2026-75650: patch, then rotate everything the key touched"}]