DEV Community: Etairos.ai

Encrypted Reasoning Was Never Private: Weaker Models Decoded 315,320 Hidden Thinking Blocks

Etairos.ai — Wed, 12 Aug 2026 14:04:47 +0000

TL;DR

what: Encrypted reasoning objects returned by the OpenAI, Anthropic, and Google reasoning APIs turned out to be portable across sessions, users, and models, so a weaker model in the same family could be prompted to transcribe a stronger model's hidden reasoning back into plaintext.

Researchers decoded 315,320 hidden reasoning blocks harvested from 6,708 publicly published AI agent trajectories and recovered 704 distinct privacy artifacts from genuine user sessions: 62 API keys, 33 passwords, 24 access tokens, and seven private keys. No encryption was broken. No key was stolen. The opaque blocks were simply pasted into a cheaper model from the same provider family, and that model read them back out loud.

The paper, Stealing Reasoning Traces from Proprietary LLM APIs, targets a design feature rather than an implementation bug. When an application manages conversation state manually or statelessly, reasoning models need a way to carry chain-of-thought across API calls without handing the plaintext to the client. OpenAI returns encrypted reasoning items that the app replays. Anthropic carries full reasoning inside an encrypted signature. Google uses encrypted thought signatures. All three are meant to be opaque to the developer holding them.

The flaw: portability, not cryptography

The attack required an intact encrypted reasoning block and API access to a compatible model from the same provider. That is it. The researchers found the blocks were accepted and processed regardless of which session, which account, or which model they were submitted under. Feed a block produced by a frontier model into a smaller sibling, prompt that sibling to transcribe what it sees, and the hidden reasoning comes back as text.

The paper calls the smaller model a "fuzzy" decoder. The three used were Claude Haiku 4.5 for Claude traces, GPT-5.6 Luna for GPT traces, and Gemini Robotics ER-1.6 for Gemini traces. The economics here are worth sitting with: the cheapest tier in a vendor's lineup was sufficient to strip the confidentiality off the most expensive tier's internal state.

⚠️ The threat model most teams never wrote down — An encrypted blob your application handles but cannot read looks like a black box. Under this flaw it behaved more like an encoded string with a vendor-hosted decoder available to anyone with an API key. If your logging, tracing, or eval pipeline treats reasoning fields as inert binary, that assumption is what failed.

What was actually sitting in the logs

The team scraped public agent trajectories, the kind routinely committed to repos for reproducibility, benchmarking, or debugging. After excluding benchmark-sourced data to isolate real user sessions, the 704 artifacts broke down as follows.

62 API keys, 33 passwords, 24 access tokens, and seven private keys recovered from genuine sessions
64 of the 704 artifacts appeared only inside hidden reasoning and nowhere in the visible trace
315,320 thinking blocks decoded in total across 6,708 trajectories
Disclosure went to the three model providers plus Microsoft and Hugging Face, indicating the exposure spanned hosting and tooling platforms, not just the model APIs

That 64 number is the one to bring to your engineering leads. Those secrets survived sanitization. A developer who scrubbed the readable conversation before publishing, checked the visible text, and shipped the trace still leaked credentials, because the credential lived only in the opaque field nobody thought to inspect. Standard secret-scanning tooling running over a committed transcript would not flag base64 ciphertext as a finding.

Four abuse paths, including invisible prompt injection

The researchers demonstrated four uses for the technique: stealing proprietary reasoning for model distillation, extracting private data from other users' published traces, recovering harmful content concealed behind a safe-looking visible answer, and hiding prompt injections inside opaque reasoning blocks.

The injection proof of concept is the most operationally interesting. The team crafted a reasoning block carrying a malicious instruction, then replayed it into an unrelated task. The receiving model added an attacker-directed upload action, and the injected instruction never appeared in visible text at any point. For anyone running guardrails that inspect prompts and completions as strings, that is a payload channel your filters do not parse.

Scope, and what the paper does not claim

This is not arbitrary access to other people's chats. The attacker needs to obtain an encrypted block first, typically from a published agent log, plus API access to a compatible model. The identifiable victim group is developers who published raw agent traces with reasoning objects intact, which is a bounded population and probably not the only one at risk. The authors are also explicit that they lack ground-truth plaintext for proprietary reasoning, so they cannot guarantee every reconstructed trace is an exact copy. Fidelity checks relied on reasoning-token counts tracking the providers' reported thinking-token totals plus qualitative comparison.

The work extends May 2026 research by Johns Hopkins cryptographer Matthew Green, who showed encrypted reasoning blocks could be replayed across sessions and accounts but did not land a reliable extraction technique. Green reported the replay behavior through bug bounty channels. By his account OpenAI called the report unreproducible and Anthropic said it saw no security implications in the replay or side-channel behavior. This paper turns that same replay primitive into a working extraction method and quantifies the fallout.

Current state and the open questions

The researchers say the demonstrated attacks stopped working after mitigations, and their reproducibility statement puts the main extraction attack as non-reproducible as of August 2026. There is no documented exploitation in the wild. But no provider has publicly acknowledged the flaw or tied its documentation changes to this research, so the "it's fixed" claim rests entirely on the researchers' own testing rather than vendor confirmation.

Encrypted reasoning remains in all three APIs, with handling changed. OpenAI still instructs developers to replay encrypted reasoning items when manually managing stateless history. Google says its backend handles thought compatibility when a session switches models. Anthropic now states that thinking blocks are tied to the model that produced them and should be stripped when switching models, because other models ignore them. The second open question is the one nobody has answered: hundreds of thousands of reasoning blocks are already sitting in public repositories, and whether those remain decodable is entirely separate from whether fresh attacks still succeed.

Do this week — Treat encrypted reasoning fields as secret material, not metadata. Strip reasoning blocks and opaque reasoning fields from any trace you publish, share with a vendor, or attach to a ticket. Stop committing raw API transcripts even after the visible text has been sanitized. Audit existing public repos, gists, eval datasets, and observability exports for reasoning objects already shipped, and rotate any credential that passed through an agent session whose trace went public.

The durable lesson

The visible-text boundary is not the trust boundary. Every AI observability platform, eval harness, and agent framework that persists full API responses is now holding a category of data it was never scoped to protect. Ask your teams a direct question: where do reasoning fields land in our logging pipeline, who can read that store, and what leaves the building attached to a bug report. If the answer takes more than a day to produce, that gap is the finding.

Originally published on RedEye Threat Intelligence.

Attackers Shut a Polish CHP Turbine by Pivoting Through a Private Cellular APN

Etairos.ai — Tue, 11 Aug 2026 20:04:48 +0000

TL;DR

what: Attackers pivoted from a compromised wind farm through a distribution operator's private cellular APN into a Polish CHP plant and switched Siemens S7-300, S7-1200, and S7-1500 controllers to STOP mode on December 29, 2025.
impact: A steam turbine and the process-water treatment system were shut down and cogeneration was interrupted at a plant heating roughly 50,000 residents, with 10 Moxa serial servers and switches factory-reset and the intrusion path destroyed to kill the logs.
fix: There is no patch: CERT Polska's lead recommendation is to enable client isolation on private APNs, treat the APN as untrusted from the OT side, strip management services from APN-reachable interfaces, and replace default credentials like the WAGO PFC200's admin login.
who: Any utility, wind farm, or industrial operator whose remote sites ride a shared private APN run by a third-party grid operator, a configuration CERT found is common in Poland and believes is widely deployed elsewhere.

On December 29, 2025, an attacker switched Siemens S7-300, S7-1200, and S7-1500 controllers into STOP mode at a Polish combined heat and power plant, shutting down a steam turbine and the process-water treatment system and interrupting cogeneration at a facility that heats roughly 50,000 residents. Activity inside the plant network ran from about 5:30 a.m. to about 10:10 a.m. Recovery began around 7:30 a.m. while the intruders were still inside. Customers lost neither heat nor electricity.

CERT Polska disclosed the incident on August 8, 2026, after an investigation lasting more than three months. Poland's prime minister said in January that two CHP plants had been hit. This is the second. The finding that matters for everyone else: the attacker reached the plant's industrial control network through a private APN, a dedicated cellular data network run by the local distribution system operator. CERT says that is, to the best of its knowledge, the first observed instance of that attack vector in a real-world cyberattack.

The route in

The chain started at a wind farm, a separate facility from the plant. Its FortiGate served as both firewall and VPN concentrator, with the VPN exposed to the internet and accounts permitted without multi-factor authentication. The attacker held administrative privileges on the device and likely used them to pull VPN credentials that reached every network segment.

From there the pivot went through a Teltonika RUTX50 cellular router. Investigators recovered repeated successful SSH logins but could not establish how the attacker obtained the password, which had been changed from default during deployment. No published RUTX50 firmware flaw hands an unauthenticated attacker credentials: the two RUT-series bugs in CISA's 2023 Teltonika advisory, CVE-2023-32349 and CVE-2023-32350, both require existing privileges, and the modem flaws only cause denial of service. An unpublished flaw is not ruled out. Mobile-operator logs led CERT to assess the attacker most likely used SSH tunneling through the router to reach the APN.

Starting December 18, the attacker scanned the private APN and found a WAGO PFC200 controller at the CHP plant exposing its web administration interface with default admin credentials. Subsequent SSH activity suggests the service was enabled through that interface, and timestamp correlation led CERT to assess the attacker most likely tunneled through the WAGO into the plant's OT network. On December 25, the attacker connected to three Siemens PLCs over the S7 protocol, which CERT considers most likely reconnaissance for the destructive actions eleven days after the initial APN scan.

⚠️ The APN was the vulnerability — The wind farm and the CHP plant are separate facilities, and neither of them runs the network that linked them. The private APN was configured to allow arbitrary devices on it to talk to each other, so a compromise at one remote site reached a controller at another. CERT's surveys found Polish organizations running private APNs commonly permit any-device-to-any-device traffic, and it believes similar configurations are widely deployed in other countries.

Compliance that governed data, not devices

The distribution operator required communications to the wind farm substation's remote terminal unit to run over serial DNP3.0, and that requirement was met. No equivalent requirement covered the cellular router's management interface, which sat on a second interface, an Ethernet port on a VLAN behind the compromised firewall. The wind farm satisfied the rule it was given and still supplied the way in. The requirement governed how data travelled, not how the device carrying it was administered. That gap is worth auditing in any operator contract that specifies protocols without specifying management-plane controls.

No malware, no CVE, no patch

CERT's report does not establish a CVE as the cause of the intrusion, and investigators could not determine whether a Teltonika router vulnerability was exploited. The router's SSH service, the controller's web interface, and the permissive APN were all working as configured. None of the destructive activity required malware and the report describes none. Every step used a supported device function invoked over the protocols the plant already runs.

Siemens S7-300, S7-1200, and S7-1500 controllers switched to STOP mode and password-protected, halting the turbine and process-water treatment
Seven Moxa serial device servers and three switches factory-reset, given changed passwords, and assigned unreachable IP addresses such as 127.0.0.1
CERT assesses with high confidence that the timing indicates those actions were automated
WAGO PFC200 partition table corrupted, leaving the device unable to boot and yielding no useful logs

Burning the path behind them

About 30 minutes after the last observed activity at the plant, the attacker factory-reset the Teltonika router, changed its administrator password, and assigned it the unreachable address 127.0.0.1. The FortiGate was then factory-reset and its logs lost. The SSH login records that anchored much of CERT's timeline survived only because RutOS versions earlier than 7.07 retain their event database across a factory reset. Newer firmware does not, which means the same anti-forensics on a current build would have left investigators far less to work with.

Detection was worse than the forensics. Maintenance was underway when the turbine stopped, so the operator logged the interruption as probable contractor error and reported it for information only. CERT opened an incident because it already knew of similar events. A destructive OT attack presented as a maintenance mishap and was very nearly filed as one.

What to do this week — Audit your private APN configuration and enable client isolation. Treat the APN as untrusted from the OT side: segment and restrict traffic across it, remove unnecessary management services from APN-reachable interfaces, and change default credentials on every device the APN can reach. If a third party operates the APN your remote sites share, get its client-isolation posture in writing rather than assuming your own segmentation covers you.

Why this generalizes

Nothing in this chain is Poland-specific. Shared private APNs are standard for reaching remote wind, solar, substation, and plant equipment, and the operator running the APN is usually not the operator running the assets on it. Where client isolation is off, every device on that APN is a peer of every other, and the weakest remote site defines the security of the strongest. The mitigations here are configuration changes available today, which also means their absence is a decision rather than an unpatched flaw.

Two concrete checks: enumerate every device your APN SIMs can reach and confirm the answer is only what you intended, and inventory management interfaces exposed on APN-side or VLAN-side ports of edge routers, where compliance requirements about data protocols say nothing. The WAGO controller in this incident still had default admin credentials eight days before a turbine stopped.

Originally published on RedEye Threat Intelligence.

CSS in Email Is Now an Exploit Primitive: Six Webmail Clients Broken at Black Hat 2026

Etairos.ai — Sun, 09 Aug 2026 14:05:03 +0000

TL;DR

what: PortSwigger's Gareth Heyes demonstrated at Black Hat USA 2026 that HTML and CSS inside an email can escape the message boundary and manipulate the surrounding webmail UI across Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail.
impact: Working chains captured a password typed into a spoofed Microsoft sign-in screen, reconstructed a Medium email-login token to take over the account, leaked a Slack token via prompt injection through Claude Cowork's Gmail connector, and exposed recipient IP addresses and email-open times.
fix: No CVEs were assigned; Fastmail fixed two CSS mutation bugs and a Proton Mail proxy bypass stopped working on retest, but Outlook label-jacking and Gmail's image-set() bypass still worked as of the August 6, 2026 publication, and the vendor guidance is to isolate HTML mail in sandboxed iframes with strict CSS character allow lists.
who: Every organization using browser-based webmail, especially those that have connected an AI assistant to a mail account.

A password typed into what looks like a Microsoft sign-in prompt inside Outlook can now be captured in real time by the sender of the email you are reading. No JavaScript executes. No attachment opens. No link is clicked. The payload is CSS.

PortSwigger researcher Gareth Heyes presented the work at Black Hat USA 2026 on August 6. It covers six major webmail clients — Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail — and the demonstrated outcomes include password capture, third-party account takeover, token exfiltration, hijacked UI clicks, and manipulation of AI assistants that read mail on the user's behalf. The public repository of proof-of-concept code remains available as of August 8. There is no report of exploitation in the wild.

The core problem: sanitizers approve one thing, browsers build another

Every webmail client renders untrusted attacker-controlled content inside the same DOM as the trusted interface — your folder list, your compose window, your account menu. The security boundary is a sanitizer, not an origin. Heyes attacks that boundary two ways.

Abuse what the sanitizer already permits. Elements and CSS features on the allow list are combined into a gadget chain that reaches outside the message body.
Create a parser discrepancy. Feed the sanitizer markup it approves, then rely on the browser or the application's own JavaScript to mutate that markup into something the sanitizer never evaluated.

The second class is the harder one to defend. A sanitizer that is provably correct about the string it inspects is still wrong if the application later rewrites that string into new DOM nodes.

Outlook: a select element disguised as a password field

The Outlook chain is the clearest illustration of how small primitives compose into credential theft. Allowed label elements let attacker content trigger controls that live outside the message boundary — label-jacking. Application JavaScript then converts sanitized custom attributes into new DOM nodes that carry CSS the sanitizer's allow list never covered. A media-query parsing trick escalates that into arbitrary CSS.

With arbitrary CSS in the trusted UI, the attacker styles a select element to look like a password field. The victim types. In Firefox, the roughly one-second option-selection timer resets whenever the select is moved offscreen, so each keystroke is captured and transmitted in real time rather than after a delay. The paper does not state whether the full Outlook password-capture chain has been fixed; label-jacking was confirmed still working at publication.

⚠️ Copy-paste is an attack surface — The Yahoo Mail and AOL Mail chain exploits a race: in Firefox, pasted HTML briefly retains active CSS before sanitization runs. In the Medium demo, the attacker starts an email-login flow, the victim copies attacker-supplied CSS, and pastes it into a Yahoo or AOL draft. The resulting requests reveal enough of the 12-character login token for the attacker's server to reconstruct it and sign in as the victim. Any workflow that instructs users to copy content and paste it into a webmail compose window should be treated as untrusted input.

Exfiltration when CSP blocks outbound requests

Content Security Policy blocking external resource loads is the standard mitigation for CSS-based data leaks. Heyes routes around it with a click-based technique that needs no network request from the page at all.

Given style injection and a numeric token rendered as text in the email, CSS selectors determine which digits appear and how many times each occurs. Non-matching links are hidden; the matching link is stretched across the page. The victim's next click — anywhere — sends the digit set and their frequencies to the attacker's server. It is a lower-bandwidth channel than an image beacon, but for short numeric tokens it is sufficient, and it defeats the assumption that CSP alone contains style injection.

AI connectors turn a rendering bug into a token breach

The AI-adjacent findings are the most operationally significant, because they convert a UI-integrity flaw into direct credential loss in another SaaS product.

On Gmail, the image-set() CSS fallback could still issue an external request despite sanitization — confirmed working at publication. Heyes and PortSwigger colleague Pete Hendy chained it to an indirect prompt injection delivered by email and processed by Anthropic's Claude Cowork through a connected Gmail connector. The attacker first triggers a legitimate Slack token confirmation email. When the victim asks Cowork to process their inbox, the injected instructions cause it to retrieve that token and place it into an HTML draft. Viewing the draft leaks the token out.

A parallel Fastmail demo targeted OpenAI's Atlas AI browser. CSS pseudo-elements and opacity split what the human sees from what the model reads: the visible text is harmless, the hidden text is an instruction. Asking Atlas to translate the visible text caused it to open tabs and encode the victim's name in URL fragments. OpenAI is deprecating Atlas, scheduled to stop working August 9, 2026 — but the technique generalizes to any agent that ingests rendered HTML.

The rest of the findings

Fastmail "CSS hotwiring" — redirects user clicks into unintended, multi-step UI actions inside the mail client.
Fastmail image-proxy bypass — an escaped backslash abusing the allow-listed user.fm domain reveals when an email was opened.
Proton Mail IP disclosure — a separate vector exposed the recipient's IP address, against documentation stating the service is designed to hide personal IP and exact open time.
Fastmail patched two CSS mutation bugs; a Proton Mail proxy bypass stopped working on retest.

What to do

There is no CVE to track and no patch queue to drain. This is a class of defect in how webmail renders untrusted HTML, and the fixes are architectural on the provider side.

Defensive priorities — Providers: isolate HTML email in sandboxed iframes as the primary control, then apply strict character allow lists for CSS validation, check for CSS gadgets before permitting custom attributes, block select menus and dangerous selectors, and prevent attacker-controlled image requests and allow-listed proxy domains. Enterprises: audit which AI assistants and connectors have read access to corporate mailboxes and treat every email body as prompt-injection input; require re-authentication for any credential prompt that appears inside a mail client rather than at the identity provider; and warn users that a login form rendered inside a message pane is never legitimate.

The practical detection angle is weak — CSS payloads look like formatting, and the exfiltration channels here are a click, an image request to an allow-listed domain, or an AI agent doing exactly what it was told. Prioritize the connector inventory. A rendering bug that only defaces a UI is an annoyance; the same bug wired to an agent with mailbox and Slack access is a credential breach.

Originally published on RedEye Threat Intelligence.

The Snowflake Hacker Pleaded Guilty. The Real Story Is That He Never Needed an Exploit.

Etairos.ai — Sat, 08 Aug 2026 20:05:53 +0000

TL;DR

what: Connor Riley Moucka, 26, of Kitchener, Ontario, pleaded guilty in Seattle federal court to computer fraud, wire fraud, aggravated identity theft and conspiracy over the 2024 breaches of Snowflake customer accounts.
impact: At least 165 organizations were compromised and records on at least 100 million people were exposed, with victim companies reporting more than $9.5 million in actual losses, excluding losses to their own customers.
fix: Snowflake has enforced MFA by default for human users on accounts created since October 2024 and its documentation puts the final phase, blocking passwords as a sole factor for remaining human and service users, between August and October 2026, with reader and trial accounts exempt.
who: Any organization running a SaaS or cloud data platform where credentials predate the current MFA policy, service accounts sign in with passwords alone, and no network allow list constrains where logins can originate.

On Wednesday, in a federal courtroom in Seattle, a 26-year-old from Kitchener, Ontario named Connor Riley Moucka pleaded guilty to computer fraud, wire fraud, aggravated identity theft and a related conspiracy. The case covers the 2024 breaches of Snowflake customer accounts: at least 165 organizations compromised, records belonging to at least 100 million people exposed, and $495,000 that Moucka personally took from ransoms and data sales. Sentencing is set for October 27. He faces a two-year mandatory minimum on the identity theft count and up to 30 years on the rest.

Strip away the courtroom and the case is uncomfortable for a different reason. There was no exploit. There was no flaw in the platform. What got the attackers in was old passwords, harvested years earlier by infostealer malware, never rotated, protecting accounts that had multi-factor authentication switched off.

A half-million-dollar crime with no zero-day in it

Mandiant, which investigated alongside Snowflake and tracks the actor as UNC5537, found that every incident it worked traced back to customer credentials stolen by infostealers. Some of those credentials had been harvested as far back as November 2020 and were still valid years later. At least 79.7% of the accounts the group used had prior credential exposure. The compromised instances had no network allow lists, so a valid password from anywhere on the internet was a valid password.

Mandiant's own assessment is blunt: the campaign "is not the result of any particularly novel or sophisticated tool, technique, or procedure." The firm attributed the reach to two things — the sheer size of the infostealer market, and credentials left unrotated for as long as four years. That is the entire tradecraft. Buy or scrape a credential dump, try the logins, find the tenants where nobody turned MFA on, and pull the warehouse.

⚠️ Four years of dwell time in a password field — A credential stolen in November 2020 was still working in 2024. That is not an intrusion detection failure. It is a credential lifecycle failure, and no EDR product on your network would have caught it, because the login was legitimate.

The 165 number has quietly changed meaning

Worth flagging for anyone citing this case in a board deck. The figure 165 began life in 2024 as a notification count — the number of organizations Mandiant and Snowflake notified as potentially exposed. Prosecutors now use the same number for customers actually compromised. The Justice Department's own release does not settle on one figure either, citing over 165 organizations in the body while Assistant Attorney General A. Tysen Duva's statement says over 150.

The financial number is firmer and more useful: victim companies suffered more than $9.5 million in actual losses. That figure excludes losses to their own customers, which is where the bulk of the harm from a 100-million-person exposure actually lands.

What actually walked out

The stolen data was not marketing lists. It included non-content call and text history, payroll records, Drug Enforcement Administration registration numbers, passport numbers and Social Security numbers. AT&T confirmed in July 2024 that records of calls and texts for nearly all its cellular customers between May 1 and October 31, 2022 were taken from its workspace on a third-party cloud platform.

Prosecutors also said Moucka re-extorted at least one victim, threatening further disclosure using the stolen data of a government officer and members of a then-former government officer's immediate family. The department named neither. W. Mike Herrington, special agent in charge of the FBI's Seattle field office, called the tactics "calculated and predatory."

The RedEye take

The Justice Department has never named Snowflake — not in Wednesday's announcement, not in the October 2024 indictment. The victim is identified only as a U.S. software-as-a-service provider. Snowflake and Mandiant named the platform themselves in 2024, which is to the vendor's credit and worth remembering: the company that got publicly attached to this campaign is the one that chose transparency, and it was not the one with the vulnerability, because there was no vulnerability.

That framing matters because the shared-responsibility line in this case is not ambiguous. Snowflake shipped a platform that supported MFA. Customers left it off. Customers left credentials in place for four years. Customers did not configure network allow lists. Every one of those is a tenant-side control. If your cloud security program is built on the assumption that the provider's security posture is your security posture, this case is the counterexample with 100 million names attached to it.

The harder read is on defaults. Snowflake has enforced MFA by default for human users on accounts created since October 2024, but password-only sign-ins are not gone. Its documentation, checked by The Hacker News on August 6, puts the final phase between August and October 2026, rolling out account by account. Only then are passwords blocked as a sole factor for every remaining human and service user. Reader and trial accounts are exempt. Read that timeline again: the industry spent two years knowing exactly how this happened, and the last password-only login on the affected platform closes roughly four months from now, at best. Secure defaults arriving two years after the breach that proved they were necessary is the actual scandal in this story.

What defenders should learn

Treat infostealer exposure as an inventory problem, not an incident. 79.7% of the accounts used in this campaign had prior credential exposure. Feed stealer-log monitoring into your identity system and force rotation on match — do not wait for an alert to correlate.
Service accounts are the gap the MFA mandate does not close. Snowflake's rollout blocks passwords as a sole factor for human and service users only in the final phase between August and October 2026. Audit every non-human identity in your SaaS tenants now and move them to key-pair or OAuth before the vendor forces it.
Network allow lists are the control nobody enabled and everybody had. The compromised instances had none. A tenant-level IP restriction would have made a stolen password useless from a residential VPN, and it costs nothing but a change ticket.
Credential age is a metric you can actually report. Some of these passwords were harvested in November 2020 and still worked in 2024. Track maximum credential age per SaaS tenant the way you track patch latency, and set a hard ceiling.
Check the exemptions in your vendor's security rollout, not just the headline. Reader and trial accounts sit outside Snowflake's password ban. Every default-on announcement has a carve-out list, and that list is your remaining attack surface.

One in custody, one still out —

Of the two men charged in 2024, only Moucka is in U.S. custody. Co-defendant John Erin Binns remains outside it as of the court's August 4 case update. Cameron John Wagenius, the former Army soldier prosecutors have tied to the same intrusions, pleaded guilty in a related case in July 2025. Moucka's sentencing on October 27 will close one file in a campaign that is still not fully accounted for.

Source: The Hacker News, "Snowflake Hacker Pleads Guilty Over Breaches Affecting at Least 100 Million People," Swati Khandelwal, August 6, 2026 — https://thehackernews.com/2026/08/snowflake-hacker-pleads-guilty-over.html

Originally published on RedEye Threat Intelligence.

Metabase Zero-Day Hits CVSS 10.0: Unauthenticated SQL Injection Gives Full Admin

Etairos.ai — Sat, 08 Aug 2026 14:05:31 +0000

TL;DR

what: Metabase disclosed that an unauthenticated SQL injection flaw in its BI platform was exploited in the wild as a zero-day, letting remote attackers write to the application database and grant themselves administrator access.

Metabase is telling self-hosted customers to patch now. An unauthenticated attacker can inject arbitrary SQL into the Metabase application database and promote themselves to administrator on the instance. CVSS 10.0. No CVE identifier was assigned. The vendor found the bug because someone used it against Metabase Cloud first, which makes this a confirmed in-the-wild zero-day rather than a theoretical maximum-severity rating.

The blast radius is not the BI tool. It is everything the BI tool connects to. With admin on a Metabase instance, an attacker changes application configuration, extracts the stored credentials for every connected database, reads any data reachable through those connections, and exports it. Metabase sits deliberately in the middle of an organization's data warehouses, production replicas, and analytics stores, holding standing credentials to all of them. Compromising it is closer to compromising a credential vault than compromising a dashboard.

What is affected

Six release branches are in scope, all versions 1.58 and above. Metabase ships parallel Open Source and Enterprise version lines, which is why the advisory uses the x. prefix — substitute 0. for OSS and 1. for Enterprise builds. Every branch got its own patch release:

>= x.58.0 and < x.58.23 — fixed in x.58.24
>= x.59.0 and < x.59.20 — fixed in x.59.21
>= x.60.0 and < x.60.16 — fixed in x.60.17
>= x.61.0 and < x.61.10 — fixed in x.61.11
>= x.62.0 and < x.62.8 — fixed in x.62.9
>= x.63.0 and < x.63.3 — fixed in x.63.5

Note the last line. The 63 branch was vulnerable below x.63.3 but the fix landed in x.63.5, not x.63.4. If your patch automation naively bumps to the first version above the vulnerable range, you will land on a build that does not contain the fix. Verify the exact target version rather than trusting a range comparison.

Metabase Cloud instances have already been updated by the vendor. If you self-host — on-prem, in a container, on an EC2 instance somebody spun up for the analytics team two years ago — the patching is yours to do.

⚠️ Workaround if you cannot patch today — Block the /api/session/reset_password endpoint at your reverse proxy, WAF, or ingress. That is the vendor-recommended temporary mitigation and it is a single rule. It is a stopgap, not a fix — the endpoint block buys you a maintenance window, nothing more. Patch to the exact fixed version for your branch as soon as you can schedule it.

How to tell if you were hit

Metabase has not released details of the malicious activity, but it did publish a compromise indicator that is unusually easy to hunt for. Look in your Metabase application logs or your server ingress logs for this two-request sequence:

POST /api/session/reset_password returning HTTP 400
immediately followed by GET /api/user/current returning HTTP 200

A failed password reset followed by a successful authenticated identity check is the signature of the exploit completing. In the vendor's own words, if you find that pattern, it is likely your instance has been compromised. Write the detection now and run it against retained logs, not just live traffic — the flaw was exploited before it was disclosed, so your window of interest starts well before the advisory date.

Post-patch cleanup

Patching does not evict an attacker who already established persistence. If your /api/session/reset_password endpoint was reachable from the internet, Metabase advises treating the instance as suspect and working through the following after the update:

Revoke all active sessions by connecting to the Metabase application database and deleting every row in the core_session table
Review all API keys and delete any you do not recognize
Audit administrator accounts for accounts or permission changes you did not make
Rotate credentials for every connected database — assume they were read
Review data warehouse logs for unauthorized access from the Metabase service account
Review Metabase activity and query history for queries nobody on your team ran

The credential rotation is the step teams skip and the one that matters most. Metabase stores connection credentials so it can query on your behalf; an admin-level attacker exports them and then no longer needs Metabase at all. Rotating them is what actually closes the intrusion path into the warehouse.

Confirmed downstream victim

PC maker Framework has notified all of its customers that data was accessed during the incident. Exposed fields include customer names, addresses, phone numbers, email addresses, and login IP addresses. Framework says no order or payment information was accessed. That is a useful calibration of the damage profile: attackers pulled whatever the compromised Metabase instance's connections could reach, which for a retail-adjacent company means the customer table.

This is a pattern, not an outlier

Exactly three years ago Metabase patched CVE-2023-38646, a CVSS 9.8 pre-authentication remote code execution flaw that saw mass scanning within days of disclosure. Two maximum-tier pre-auth bugs in the same product in three years should change how you deploy it. Internal analytics tooling ends up internet-facing because someone wanted dashboards accessible from a phone, and then it inherits an attack surface it was never hardened for.

Get BI tooling off the public internet —

Two actions this week. First, inventory every Metabase instance you run, including the ones shadow IT stood up, and confirm each is on the exact fixed release for its branch. Second, check whether any of them are reachable without going through your VPN or identity-aware proxy. A pre-auth CVSS 10.0 in a tool that holds warehouse credentials is only a catastrophe if an unauthenticated attacker can reach the endpoint. That part is within your control today.

Originally published on RedEye Threat Intelligence.

CISA Adds TeamCity CVE-2026-63077 to KEV: Unauthenticated RCE on the Agent Polling Protocol

Etairos.ai — Fri, 07 Aug 2026 14:05:49 +0000

TL;DR

what: CISA added JetBrains TeamCity CVE-2026-63077, a CVSS 9.8 untrusted-deserialization bug in the agent polling protocol, to the Known Exploited Vulnerabilities catalog on August 6, 2026.
impact: An unauthenticated attacker who can reach the server bypasses authentication and runs arbitrary OS commands as the TeamCity server process, exposing stored credentials, configurations, and the integrity of every build artifact downstream.
fix: Apply JetBrains' patched on-premise TeamCity release immediately and, until then, block untrusted network access to the agent polling endpoint.
who: Any organization running on-premise TeamCity, especially instances exposed to the internet; TeamCity Cloud is not in scope, and FCEB agencies were bound to the August 8, 2026 deadline under BOD 26-04.

CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog on August 6, 2026, confirming that attackers are already exploiting a CVSS 9.8 deserialization flaw in on-premise JetBrains TeamCity. The bug requires no credentials. An attacker who can reach the TeamCity server over the network bypasses authentication checks entirely and executes arbitrary operating system commands with the privileges of the server process.

Federal Civilian Executive Branch agencies had two days. Under Binding Operational Directive 26-04, the remediation deadline for CVE-2026-63077 was August 8, 2026. That is the shortest end of the KEV window and a reasonable signal of how CISA is weighting this one.

What the vulnerability is

CVE-2026-63077 is a deserialization of untrusted data flaw reachable through the TeamCity agent polling protocol. That protocol is the channel build agents use to check in with the server for work. It is, by design, a listening service that accepts input from machines outside the web UI's authentication path, which is exactly why the authentication bypass matters here.

In CISA's wording, TeamCity "contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol." JetBrains describes the same chain: an unauthenticated attacker uses the polling protocol to sidestep authentication checks and execute arbitrary OS commands. There is no user interaction step, no privilege prerequisite, and no second-stage requirement. That combination is what produces the 9.8.

The precise blast radius depends on how the TeamCity server process is running. If it runs as root or as a local administrator, which is common in installations that were stood up quickly and never revisited, code execution as that process is code execution as the host.

Why a build server is the wrong thing to lose

TeamCity is a CI/CD orchestrator. Compromising it is not equivalent to compromising an application server. Per JetBrains, a successful attack can expose TeamCity data, configurations, and stored credentials, modify server state, and compromise the integrity of build artifacts and downstream pipelines.

Unpack the credential exposure specifically. A production TeamCity instance typically holds VCS tokens with write access to source repositories, cloud provider keys used by deployment steps, container registry push credentials, artifact repository tokens, and code signing material. An attacker with server-process code execution reads those out of the configuration store and immediately holds authenticated access to systems that never saw an attack against themselves.

Artifact integrity is the second-order problem. An attacker who can modify build configurations can inject code into artifacts that are then signed, published, and consumed by every downstream system that trusts the pipeline. That is a supply chain compromise that looks like a normal release to everyone consuming it. Detection depends on comparing what the build produced against what the source actually says, which most organizations cannot do retroactively.

⚠️ Assume credential compromise, not just code execution — If your TeamCity server was internet-reachable and unpatched, patching does not undo the exposure. Every secret stored in or accessible to that instance should be treated as compromised: VCS tokens, cloud keys, registry credentials, signing keys, and service accounts. Rotate them, then review artifacts built during the exposure window against source.

What is not known

Be precise about the gaps, because they change how you prioritize. As of CISA's KEV addition, the exploitation method in the wild has not been published, the threat actors behind the attacks have not been identified, and the scale of the campaign is unknown. JetBrains had not updated its advisory to confirm active exploitation at the time of CISA's listing.

None of that is a reason to wait. Historically, TeamCity authentication bypasses have gone from KEV listing to broad opportunistic scanning fast, and the profile here favors mass exploitation: a single unauthenticated network request against a service that is frequently exposed because remote build agents need to reach it.

Immediate actions

Patch on-premise TeamCity to the fixed release from JetBrains now. This is the only complete remediation. TeamCity Cloud instances are not affected by the on-premise advisory.
If you cannot patch within hours, remove the server from internet exposure. The agent polling endpoint should be reachable only from known build agent addresses, enforced at the network layer rather than in application configuration.
Inventory your exposure honestly. Check for TeamCity listeners on 8111/TCP and any reverse proxy that fronts the server, including instances stood up by individual engineering teams outside the central asset list. Shadow build servers are the common failure here.
Rotate every credential stored in TeamCity if the instance was exposed and unpatched at any point since disclosure. Prioritize anything with write access to source control, cloud infrastructure, or artifact registries.
Review server logs for anomalous agent polling requests, unexpected build configuration changes, new or modified build steps, and administrative account creation. Deserialization exploitation often leaves malformed request artifacts before it leaves anything else.
Compare recently published artifacts against source. Focus on the window between disclosure and patch, and on anything signed or pushed to a registry that downstream consumers trust.

Hardening beyond the patch

This CVE is a reminder that CI/CD servers are usually the least segmented high-value asset in an environment. They need network reachability to source control, cloud accounts, registries, and production deploy targets, so they accumulate the union of everyone's privileges while sitting on a general-purpose network.

Two structural changes reduce the cost of the next TeamCity RCE. First, run the server process as a dedicated unprivileged account, not root or local administrator, so process-level code execution is not host-level code execution. Second, move away from long-lived static secrets in the build server toward short-lived credentials issued per build through OIDC federation, so a credential dump has a usable lifetime measured in minutes.

Treat KEV additions as a scanning signal — CISA's KEV listing is public. Attackers read it too, and a KEV entry for an unauthenticated pre-auth RCE reliably precedes an uptick in internet-wide scanning for that service. The window between listing and mass exploitation attempts is typically measured in days, not weeks.

Bottom line

CVE-2026-63077 is a pre-authentication remote code execution flaw in a system that holds the keys to your software supply chain. CVSS 9.8, no credentials, confirmed exploitation, and a two-day federal remediation deadline. If you run on-premise TeamCity, patch today and rotate what that server was holding.

Originally published on RedEye Threat Intelligence.

Zbtlink Ships ENDLESSDOORS: 21 Firmware Images, One Unauthenticated Root Shell

Etairos.ai — Thu, 06 Aug 2026 20:04:51 +0000

TL;DR

what: VulnCheck disclosed ENDLESSDOORS, a factory-shipped backdoor present in all 21 firmware images Zbtlink published across 20+ router models spanning more than two years.
impact: The implant runs as root disguised as a kernel worker, beacons out every 35 seconds with no authentication, and will spawn a live interactive root shell for whoever answers, meaning any on-path or DNS-controlling attacker takes the router without needing inbound access.
fix: No patched firmware exists yet; Zbtlink pulled the affected images from its download page and says validated builds are in progress, so hunt for /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg, and /etc/init.d/skworker and block egress to the four known C2 endpoints now.
who: Anyone running Zbtlink hardware or OEM/ODM devices built on Zbtlink stock firmware, especially the CPE2801, WE-series, WG-series, and Z8102AX-2DSIM models used in industrial, cellular-router, and kiosk deployments.

Every single firmware image Zbtlink published, all 21 of them, ships with a backdoor. Not a debug flag, not a hardcoded credential you have to guess. A userland implant that runs as root at boot, phones home to Chinese infrastructure as often as every 35 seconds, and executes whatever the server on the other end sends back with no handshake, no negotiation, and no authentication of any kind. VulnCheck named it ENDLESSDOORS. It covers at least 20 router models and firmware releases spanning more than two years.

The important detail for defenders is not that the router is backdoored by the vendor. It is that the backdoor is unauthenticated in both directions. Zbtlink's C2 does not prove who it is to the implant, and the implant does not prove who it is to the C2. That turns a vendor maintenance channel into a shared resource. Anyone on the network path, and anyone who can influence DNS resolution for the callback domain, inherits root on the device.

What the implant actually is

ENDLESSDOORS is a lightly customized build of rctl, a remote control tool uploaded to GitHub on January 14, 2015 and never touched again. It is roughly the simplest C2 you can write: the server listens on port 7000, clients connect out, and the server either pushes individual shell commands or tells the client to spawn a reverse shell.

The protocol has effectively two verbs. The implant opens a connection, sends a hello message carrying the device's LAN MAC address as its identifier, and then runs whatever comes back as root. One reserved string, rctlbash, tells the implant to open a second connection to port 7001, allocate a pseudo-terminal, spawn /bin/sh, and bridge it. As VulnCheck's CTO Jacob Baines put it, the vocabulary is run this as root, and give me a root shell.

On the AX3000 that VulnCheck analyzed, the implant presents itself as a process named kworker. Real kworker processes are kernel threads. This one is a userland process running with root privileges, sitting in a process list alongside the legitimate kworker entries where a casual ps sweep slides right past it. The init script that launches it at boot is named skworker, one character away from blending in.

⚠️ No inbound access required — This is not a listening service you can firewall off at the perimeter. The implant initiates the connection outbound, which means CGNAT, a consumer NAT, or a locked-down inbound ACL provides zero protection. The attack surface is the DNS resolution and the network path to the C2, not the router's WAN interface.

The hijack problem

Because there is no authentication or certificate pinning, control of an ENDLESSDOORS implant reduces to control of a name. Whoever owns the resolution of rbdg4nzqadui.wikaba[.]com, or the address it currently resolves to, can command any implant that tries to reach it. That is a domain on a free dynamic DNS-style provider with a random-looking label. Registrar takedown, DNS hijack, sinkhole, upstream ISP interception, or a hostile resolver on the path all lead to the same place: an attacker-controlled root shell on the device, without the attacker ever needing to find the router or scan for it. The routers volunteer.

That is the part IT managers should internalize. Even if you extend Zbtlink every benefit of the doubt about intent, the design means the vendor is not the only party who can use it. The channel is open to anyone who gets in the middle.

Affected models and infrastructure

Every firmware listed on zbtlink.com's download page embedded the rctl implant and started it at boot via the skworker init script. Affected models:

CPE2801, WE1026-5G-WD, WE1326, WE2007, WE2008-DSIM, WE2416
WE3326, WE5927, WE5931, WE5931AC, WE826-T3-DSIM
WG108, WG1602, WG1608-DSIM, WG209, WG2105, WG2107, WG259, WG3526
Z8102AX-2DSIM

All of them dial the same set of four primary and secondary endpoints: zbtctl.epplink[.]net (47.100.190[.]96), 47.107.224[.]89, online-string[.]com (45.32.81[.]152), and rbdg4nzqadui.wikaba[.]com (43.248.136[.]125). Two hardcoded IPs and two domains gives you a clean, low-false-positive detection surface. Any of these appearing in DNS or NetFlow logs is worth an immediate investigation.

Vendor response

Zbtlink has pulled the affected firmware from its download channels, replacing the page with a notice that it detected firmware security vulnerabilities and that patched, security-validated builds are in development. No timeline and no fixed version number has been published.

A Zbtlink spokesperson told The Hacker News the feature is solely intended for after-sales maintenance, that it is generally retained only on sample units to assist customers with software debugging, and that the company specializes in OEM and ODM customization work where customers deploy their own firmware rather than ZBT defaults. VulnCheck's finding is that the implant appears in 21 of 21 published images, not a sample subset. Take the explanation for what it is; the mitigation posture does not change either way.

The OEM blast radius

Zbtlink's own admission that it is primarily an OEM/ODM shop is the reason this story is larger than a brand name most Western buyers have never heard of. These boards ship inside other companies' products: cellular gateways, industrial routers, kiosk and vending connectivity, digital signage, fleet telematics, and white-label CPE. If a downstream integrator built on the stock Zbtlink image rather than a custom one, that integrator's product carries ENDLESSDOORS under a different logo and a different model number, and it will not appear on VulnCheck's list. Asset inventories keyed on brand will miss those units. Behavioral detection on the four C2 endpoints will not.

What to do now

Detection and containment checklist — There is no patch to apply yet, so containment is network-side and filesystem-side. Treat any confirmed device as fully compromised: an interactive root shell has been reachable for the life of the deployment, so credentials, configs, VPN keys, and anything traversing the device should be considered exposed.

Block egress to 47.100.190[.]96, 47.107.224[.]89, 45.32.81[.]152, and 43.248.136[.]125, plus DNS resolution for zbtctl.epplink[.]net, online-string[.]com, and rbdg4nzqadui.wikaba[.]com.
Alert on outbound TCP to ports 7000 and 7001 from any network infrastructure segment. Legitimate routers do not initiate those.
On accessible devices, check for /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg, and /etc/init.d/skworker. A kworker entry with a userland parent, an executable path, or an open socket is the implant, not a kernel thread.
Hunt historical DNS and NetFlow for the four endpoints going back as far as retention allows. A 35-second beacon interval leaves an unmistakable trail.
Query procurement and integrator documentation for Zbtlink-sourced boards inside other-branded products, since the model list will not catch rebadged hardware.
For devices in sensitive segments, move them behind a filtering gateway or replace them outright rather than waiting on patched firmware with no ship date.

The broader lesson is one the industry keeps relearning. Perimeter thinking assumes the threat arrives from outside and tries to get in. A factory-shipped, outbound-initiating implant inverts that entirely: the device you installed to protect the network is the one calling out, on a schedule, offering root to whoever picks up. Egress monitoring on infrastructure devices is not a nice-to-have. On low-cost OEM hardware it is the only control that would have caught this.

Originally published on RedEye Threat Intelligence.

4,407 Rockwell PLCs Sit on the Public Internet, 22 in Cities Hit by Water Utility Attacks

Etairos.ai — Thu, 06 Aug 2026 14:05:13 +0000

TL;DR

what: Forescout's August 3 scan found 4,407 internet-facing Rockwell PLCs worldwide, including 22 in US cities where water utilities reported attacks since July 27.

Forescout scanned the internet on August 3 and counted 4,407 exposed Rockwell Automation programmable logic controllers. 2,844 of them are in the United States. Twenty-two sit in cities where water utilities have reported cyberattacks since July 27, and 19 of those 22 ride the same mobile carrier network. Forescout could not confirm that any of the 4,407 were compromised, and the number counts controllers, not utilities or victims.

The part that should change your Monday: the effects described publicly in those water incidents did not require a vulnerability exploit. Attackers changed IP addresses and set passwords on controllers that were already reachable from the internet. Operators lost visibility, and in some cases control, of connected equipment. No CVE, no memory corruption, no zero-day. Just a device answering unauthenticated requests on a routable address.

What the exposure actually looks like

The reachable surface is EtherNet/IP on TCP port 44818. Depending on device configuration, an unauthenticated connection to that port lets an attacker identify the controller (vendor, product code, firmware revision, sometimes the project name) or write settings to it. That identification step is what makes mass scanning viable: an attacker does not need to guess what they hit, the device tells them.

Two independent snapshots agree on the scale. A July 30 Censys pull found 4,148 exposed Rockwell/Allen-Bradley EtherNet/IP hosts. Forescout's August 3 pull found 4,407. Different platforms, different queries, different days, so the figures are not directly comparable, but both clear 4,100. Forescout's historical series puts the June 2026 low at 4,169, down 47% from 7,814 in March 2020. Six years of ICS security advocacy cut the exposed population roughly in half and then flattened out.

Device breakdown from Forescout's results:

MicroLogix 1400: 50% of exposed controllers
MicroLogix 1100: 8% of exposed controllers
Both families were named specifically in the FBI and EPA advisory
The MicroLogix 1100 was discontinued by Rockwell on April 30, 2022, so a meaningful slice of this population is running end-of-life hardware

The cellular modem is the real attack surface

More than 70% of the US-based exposed controllers are on large mobile carrier networks. Censys attributed 59% of its 4,148 hosts to Verizon Business, AT&T Mobility, and T-Mobile USA. This is the classic small-utility remote-site pattern: a lift station or a well house with no fiber, a cellular router dropped in for SCADA polling and remote troubleshooting, and a public IP handed out by the carrier with nothing filtering inbound traffic.

Nineteen of the 22 controllers found in affected cities were on the same carrier network. That clustering matters more than the raw count. It suggests a shared integrator, a shared modem deployment template, or a shared APN configuration, and the FBI warned explicitly that similar third-party network setups may let attackers repeat a successful compromise across every customer sharing the vulnerable configuration. One integrator's default becomes a target list.

Federal guidance, in one line — The FBI and EPA recommend strong authentication, current firmware, and logging on cellular modems, with remote access isolated behind a private APN, a VPN, or an equivalent architecture. If your remote sites answer on a public carrier IP today, a private APN from the same carrier is usually a support ticket, not a capital project.

CVE-2017-16740 is a footnote, not the story

Forescout found that 19 of the 22 controllers in affected cities ran firmware susceptible to CVE-2017-16740, a Modbus TCP buffer overflow rated 8.6 by Rockwell. It affects MicroLogix 1400 Series B and C on firmware revision 21.002 and earlier, and Rockwell fixed it in revision 21.003. That patch has been available since 2017.

Two caveats keep this from being the headline. Exploitation requires Modbus TCP to be enabled, which Forescout could not verify on those hosts. And nothing in the reported attacker behavior needed the flaw. Forescout's own framing is the right one: firmware updates fix specific bugs but do not make direct public exposure of a PLC acceptable. Patch to 21.003 because nine-year-old known-vulnerable firmware on a control device is indefensible, not because it closes this campaign.

Recovery if you are already locked out

Rockwell advisory SD1790 covers the specific scenario operators are hitting: an attacker set a password on the controller and the owner can no longer connect. The procedure resets a MicroLogix 1400 or 1100 to factory defaults, after which you redownload a known-good project file. SD1790 carries no CVE because it is recovery guidance, not a vulnerability disclosure.

⚠️ The recovery path assumes a backup you may not have — Factory reset wipes the controller logic. SD1790 only works if you hold a current offline copy of the project file. The FBI reported that at least one victim discovered modified PLC project files after noticing ladder logic discrepancies across several sites, which means the on-device copy cannot be trusted as your restore source. Pull and hash offline copies of every controller program now, before you need them.

Open questions the advisories do not answer

Neither the government alerts nor Forescout's analysis explains how attackers found, selected, or initially accessed their targets. No agency has attributed the campaign. Even the scope is unsettled: the FBI and EPA July 30 public service announcement covers utilities in at least seven states, and as of August 6 the FBI page still says seven while Forescout's writeup describes the announcement as confirming at least 12. Treat the state count as unresolved, not as a bound on who is affected.

Do this week

Inventory every controller with a public IP. Search your carrier bills and modem management portals for static public addressing, not just your firewall rules.
Confirm whether TCP/44818 is reachable from outside. Test from an external host, not from the plant network.
Move remote sites to a private APN or force all SCADA traffic through a VPN terminating inside your network. Nothing on a control network should answer an unsolicited inbound connection.
Update MicroLogix 1400 Series B and C to firmware revision 21.003 or later, and disable Modbus TCP if you are not using it.
Build a replacement plan for MicroLogix 1100 units. The line has been discontinued since April 2022 and will not receive further fixes.
Export, store offline, and hash every PLC project file. Compare ladder logic across sites that should be identical.
Enable and centralize logging on cellular modems and controllers so an IP change or password set is something you detect rather than something an operator reports.

The 4,407 number will move with the next scan. The underlying condition will not, until someone takes the controllers off the public internet.

Originally published on RedEye Threat Intelligence.

Pass-the-Key: Malware Hijacks Google-Synced Passkeys Straight Off the Endpoint

Etairos.ai — Tue, 04 Aug 2026 14:05:33 +0000

TL;DR

what: Researchers detailed "Pass-the-Key" attacks in which infostealer-class malware on an already-compromised endpoint abuses Google Password Manager's passkey sync and device-enrollment flows to place an attacker device inside the victim's credential sync fabric.
impact: Any account protected by a synced passkey — Google, Microsoft, GitHub, banking, SaaS admin consoles — can be authenticated into from attacker infrastructure without the victim's phone, password, or an MFA prompt they would recognize.
fix: No CVE has been assigned because this abuses designed sync behavior; mitigate with device-bound passkeys or FIDO2 hardware keys for privileged accounts, enforce Google Advanced Protection, and treat any endpoint infostealer detection as a full passkey-reset event.
who: Organizations that moved admins and executives onto synced passkeys in Google Password Manager and assumed the credential was hardware-bound.

The pitch for passkeys was that stolen credentials stop mattering. Pass-the-Key breaks that pitch — not by cracking cryptography, but by walking through the sync layer that makes passkeys usable in the first place. Malware sitting on a machine you already lost can enroll attacker-controlled hardware into the victim's Google Password Manager sync group and then produce valid WebAuthn assertions for every synced passkey on that account. No credential phishing. No push-bombing. No prompt the user would recognize as hostile.

With more than 15 billion accounts now passkey-enabled across the major identity providers, and with most enterprise rollouts defaulting to synced rather than device-bound credentials, the exposed population is not niche. If your privileged users authenticate with a passkey that lives in Google Password Manager, this is your threat model now.

What actually breaks

A passkey is a WebAuthn credential: a private key that signs a challenge from the relying party. The phishing resistance comes from origin binding — the browser will not sign a challenge from evil-corp-login.com for an origin of accounts.google.com. That property is intact. Pass-the-Key does not attempt to defeat it.

Instead it attacks the layer beneath: the synchronization fabric. To move a passkey between a laptop, a phone, and a tablet, the provider wraps the private key material and replicates it through the user's account, gated by a recovery secret and a device-enrollment ceremony. That ceremony is the target. Malware with local access to browser process memory, the Chrome profile directory, and the OS-level token store can harvest the material needed to satisfy enrollment and present itself as a legitimate new device. Once enrolled, the attacker's machine receives the same synced credentials the victim has, and every subsequent signature is cryptographically valid because it is cryptographically valid. The relying party has nothing to reject.

⚠️ This is not a passkey bug — which is why it is worse — There is no patch to apply, no CVE to close, and no vendor advisory that resolves it. Sync-enrollment is intended behavior. The attack requires prior endpoint compromise, which means the industry's answer — "assume the endpoint is trusted" — is exactly the assumption that fails. Treat every infostealer hit on a passkey-enrolled endpoint as an authenticator compromise, not just a session-cookie cleanup.

The chain, step by step

Initial access via commodity loaders — malvertising, fake installers, ClickFix-style paste-to-run lures, or a trojanized dev tool. Nothing exotic.
Local collection: the Chrome profile directory, DPAPI-protected state on Windows, Keychain items on macOS, and in-memory browser artifacts are pulled in a single pass alongside conventional cookie and password theft.
Sync-state extraction: the malware recovers the material needed to satisfy Google Password Manager's device-enrollment check rather than trying to lift a raw private key.
Attacker device enrollment: an attacker-controlled browser or emulated client joins the sync group and pulls down the synced passkey set.
Assertion replay: the attacker authenticates to relying parties directly from their own infrastructure, producing signatures that pass origin and signature-counter checks cleanly.
Persistence: because the attacker device is a legitimate sync participant, a password reset alone does not evict it.

Why your detections will miss it

Post-enrollment, there is no anomalous authentication artifact at the relying party. The assertion is well-formed, the AAGUID is a legitimate software authenticator, and the signature counter increments normally. Impossible-travel and IP-reputation logic will fire only if the attacker is sloppy about proxying — and infostealer operators have been buying residential proxy pools in the victim's ASN for years. Conditional access policies keyed on "phishing-resistant MFA satisfied" will happily wave the session through, because it was satisfied.

Hunt on enrollment, not authentication — The only high-fidelity signal is the device-enrollment event itself. Pull Google Workspace admin audit logs for new device additions and password-manager sync joins, correlate against known endpoint inventory, and alert on any enrollment from an ASN, OS build, or client fingerprint that does not match a managed asset. In identity providers, alert on new authenticator registration for privileged accounts as a P1, not an informational event.

Fixes that actually change the outcome

Move admins, executives, finance, and anyone with production access to device-bound credentials — YubiKey, Titan, or platform authenticators configured non-syncable. A hardware key cannot be enrolled into a sync group by software.
Enable Google Advanced Protection Program for high-value accounts; it enforces hardware-key attestation and restricts recovery paths the attack depends on.
In Workspace, restrict which devices may join sync via context-aware access, and require managed-device posture for credential sync.
Rewrite your infostealer playbook: revoke sessions, rotate passwords, and additionally deregister every authenticator on the account and re-enroll from a known-clean device. Cookie invalidation alone leaves the attacker enrolled.
Shorten session lifetimes and require step-up reauthentication with a hardware key for privileged operations, so a valid assertion is not a permanent skeleton key.
Instrument EDR for reads of Chrome profile and Keychain/DPAPI artifacts by non-browser processes — that access pattern remains the earliest reliable indicator.

The takeaway

Passkeys still kill credential phishing, and nobody should slow a rollout over this. But the marketing conflated two different guarantees. Phishing resistance is a property of origin binding. Theft resistance is a property of key storage — and a synced passkey is stored, ultimately, in software that malware can reach. Sort your accounts by blast radius, put hardware behind the top tier, and stop treating endpoint compromise as a containable event when your authenticators live on the endpoint.

Originally published on RedEye Threat Intelligence.

N-able N-central Auth Bypass Exploited in the Wild After First Patch Missed an Alternate Path

Etairos.ai — Mon, 03 Aug 2026 14:05:22 +0000

TL;DR

what: Attackers exploited an authentication bypass in N-able N-central to gain remote administrative access to RMM servers and reach the customer endpoints those servers manage.
impact: From a compromised N-central server the attackers used Take Control to reach managed endpoints and registered Cloudflare tunnels as Windows services, keeping access alive after the N-central route was cut.
fix: Upgrade every N-central server to build 2026.3.1.7 (released August 2) — the earlier 2026.2 fix for CVE-2026-18556 was incomplete and the bypass returned as CVE-2026-18577 — then hunt managed endpoints for tunnel persistence.
who: Managed service providers and internal IT teams running self-hosted N-central, plus every downstream customer whose endpoints those servers administer.

N-able confirmed that attackers exploited an authentication bypass in N-central to gain remote administrative access to customer servers and then reach the endpoints those servers manage. The company's first fix did not close the hole. Build 2026.3.1.7, shipped August 2, is the first unaffected version. Anything earlier is exploitable, including builds that received the original patch.

N-central is the remote monitoring and management platform MSPs and internal IT teams use to administer customer fleets. Administrative access to the server is administrative access to everything it touches. That is the blast radius here.

One vulnerability, two CVEs, one incomplete fix

The original flaw is CVE-2026-18556, titled "unauthenticated administrative account takeover" in N-able's own CVE record and classified under CWE-288, authentication bypass using an alternate path or channel. It covers releases through 2026.1. N-able fixed that path in 2026.2.

It then found a different way to reach the same underlying vulnerability that the 2026.2 fix did not block. That became CVE-2026-18577, and it expanded the affected range to every build before 2026.3.1.7. N-able assigned both CVEs itself and scored each 8.2 on CVSS 4.0. Finland's national cyber security centre stated in an August 2 advisory that all versions available before the emergency hotfix were vulnerable.

Neither CVE record names the vulnerable endpoint or the request sequence, and N-able has published no code-level root cause. Defenders are patching and hunting on indicators alone.

⚠️ Upgrading to 2026.3 is no longer sufficient — N-able's initial instruction was to move to 2026.3. That guidance is superseded. Only 2026.3.1.7 blocks the second exploitation path. Hosted NCOD instances are being upgraded automatically on a schedule communicated directly to partners; self-hosted servers are the customer's responsibility and are where the confirmed exploitation happened.

The intrusion chain

N-able began investigating on July 31 after an unusual volume of licensing errors from on-premises customers. It found an attacker had remotely gained administrative access to servers running 2026.1 and earlier. The post-exploitation sequence N-able described:

Authentication bypass grants administrative access to the N-central server, no credentials required.
The attacker uses Take Control, N-central's built-in remote access feature, to reach managed endpoints — legitimate functionality, legitimate tooling, no malware needed for the pivot.
On reached endpoints, the attacker registers a Cloudflare tunnel as a Windows service. The tunnel connects outbound to Cloudflare's edge, so it requires no inbound firewall rule and no open listening port.
Running as a service, the tunnel survives reboots. N-able said the tunnels preserved access after the route through the N-central server was revoked.

Nothing suggests Cloudflare was compromised. The attackers abused a legitimate tunneling service, which is why the traffic looks unremarkable at the perimeter. This is the part that matters operationally: patching N-central does not remove persistence installed on a different machine. If you find evidence of compromise, you have a second, separate hunt-and-remove job across every managed endpoint.

What Huntress observed

Huntress published a rapid response on August 3 covering exploitation in its customer base. It clarified to The Hacker News that the activity involved a single self-hosted N-central instance inside one partner account. The attackers accessed nine organizations under that account and reached one endpoint in each. On the evidence available so far, post-compromise activity was limited to enumerating running processes before the attackers disconnected.

Notably, Huntress said it did not observe the Cloudflare installation activity N-able described in its notifications to affected customers. Either the tradecraft varies by victim or the operators were still triaging targets in this case. Huntress is continuing to review for additional indicators.

Indicators and hunting guidance

N-able published six attacker IP addresses:

173[.]249[.]252[.]200
87[.]249[.]138[.]34
37[.]19[.]210[.]32
37[.]153[.]90[.]88
92[.]118[.]112[.]181
68[.]235[.]46[.]214

Huntress identified the four addresses from N-able's initial list as Mullvad or NordVPN exit nodes, which caps their value: a hit is a lead, not a verdict, and absence proves nothing. Correlate any match against N-central UI, network, and endpoint logs. Huntress also published three attacker domains: mousears.synology[.]me, wagoosh.direct.quickconnect[.]to, and who-ripped-one.direct.quickconnect[.]to.

On the host side, N-able told customers to look for svchost.exe in users' Documents folders, a service named Cloudflared, or traffic to the published addresses. For unauthorized Take Control activity, Huntress recommended checking ui_access_control.log and correlating it with C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz on Windows endpoints. Investigate sessions tied to apparent N-able support identities such as mspsupport@n-able.com.

Those logs appear during normal operations too — ui_access_control.log and the BASupSrvc archives are generated by legitimate Take Control sessions. Their presence is not proof of compromise. Build a baseline of expected technician sessions and times first, then hunt for what falls outside it. Treating every log entry as an IOC will bury your team.

Priority actions

Confirm the exact build of every N-central server you operate. Do not assume 2026.3 is patched.
Upgrade self-hosted instances to 2026.3.1.7 now. Confirm the schedule for hosted NCOD instances with your N-able contact rather than waiting.
Review N-central admin account activity and Take Control session logs from before July 31, since exploitation start date is undisclosed and may predate N-able's investigation.
Sweep managed endpoints for cloudflared services and svchost.exe outside System32, particularly in Documents folders.
Audit outbound connections to Cloudflare tunnel infrastructure from servers and workstations that have no business reason to make them.
Rotate credentials and API keys accessible from any N-central server you cannot clear.

What N-able has not said

The company has not disclosed how many customers were affected beyond "a limited number," how many downstream devices were reached, when exploitation began, who is behind it, or whether any data was taken. It has also not explained why the 2026.2 fix missed the alternate path. Until that root cause is public, treat 2026.3.1.7 as the current known-good state rather than a guarantee that a third path does not exist. Assume this is not finished.

Originally published on RedEye Threat Intelligence.

Adform's trackpoint-async.js Was Poisoned to Rewrite Crypto Wallet Addresses on Downstream Sites

Etairos.ai — Sun, 02 Aug 2026 20:04:46 +0000

TL;DR

what: Attackers appended two obfuscated malicious blocks to trackpoint-async.js, a legitimate Adform tracking library served from s2.adform[.]net to customer websites.
impact: Any visitor who copied or typed a Bitcoin, Ethereum, or Tron address on a page loading the script could have had it replaced with an attacker address at the moment of payment, across sites that were never themselves breached.
fix: Adform removed the malicious code on July 27, 2026; there is no CVE or patched version, so remediation is clearing browser caches, forcing a fresh pull of the script, and verifying wallet addresses before every transfer.
who: Visitors and customers of the roughly 1,800 organizations running Adform tracking tags, particularly anyone handling crypto payments in a browser.

Attackers modified trackpoint-async.js, a JavaScript file that advertising technology company Adform serves from s2.adform[.]net, and turned it into a browser-side cryptocurrency address swapper. Anyone who visited a site carrying the affected script and copied or typed a Bitcoin, Ethereum, or Tron address may have ended up pasting an attacker-controlled address instead. Adform detected the incident on July 27, 2026, removed the code, notified affected clients, and reported it to authorities.

The mechanics matter less than the delivery path. Adform's own implementation documentation describes the tracking code as something that can run on a single page, on selected sections, or unconditionally across an entire website. Compromising that one shared resource gave the attackers execution on unrelated downstream sites without touching any of them. Adform's 2025 annual report puts the platform at roughly 1,800 customers, 1.5 billion ads displayed daily, and ad activity in more than 180 countries. Those numbers describe the platform, not this incident, but they frame the ceiling.

What the payload actually does

Max Maass published a captured copy of the script on July 27. The sample shows two malicious blocks appended to the end of the legitimate library, with replacement strings obfuscated behind a six-byte XOR key. The two blocks overlap in purpose but cover different input paths.

Block one hooks the copy event and additionally polls the clipboard every four seconds, replacing any string matching a supported address pattern.
Block one also fires an HTTP request to 84.32.102[.]230:7744 on page load, carrying the hostname and path of the page the visitor is on.
Block two walks the document's text nodes and rewrites values in input, textarea, and contenteditable elements, restoring cursor position afterward so the edit is not visually obvious.
Block two hooks the value setter on input and textarea elements, so programmatic writes get rewritten in transit, and intercepts copy, cut, paste, and input events.
Both blocks carry hardcoded replacement addresses for Bitcoin, Ethereum, and Tron patterns. Kevin Beaumont, who disclosed the compromise, reported the addresses appeared to vary.

The practical consequence is that clipboard hygiene does not save you. Because the second block hooks the value setter and rewrites form fields directly, an address typed by hand or written by a page's own script gets swapped the same way. Beaumont's description is blunt: "Even if you notice the address is wrong and recopy the wallet, it keeps replacing it."

⚠️ The cache is the lingering exposure — Adform removed the malicious file, but a browser that fetched the poisoned trackpoint-async.js may still be serving it from local cache. Until that cache entry is evicted or replaced, the swapping behavior continues on any page that loads the script. Adform is explicitly telling users to clear browser cache and to verify wallet addresses before sending funds.

Detection was effectively zero

Beaumont reported that at the time of disclosure, the file and its associated URLs, domains, and IP addresses returned no detections on VirusTotal. That is worth sitting with. The payload was appended to a file that is expected to be present, served from a hostname that is expected to be present, on sites where advertising and analytics JavaScript is background noise. There is no anomalous domain to flag and no new process to catch on the endpoint. Adform also says the code was not designed to install software or establish persistence and operated only while an affected page stayed open, which is precisely what keeps it out of the reach of endpoint tooling.

The timeline does not reconcile

Adform's notice identifies July 27, 2026 as the affected date. Beaumont says he observed malicious activity via Adform over the preceding week. Those two statements have not been reconciled publicly, and the gap is not academic. Exposure math depends entirely on duration, and no defensible estimate of impressions, sessions, or affected sites can be built until someone publishes the real window.

There is a similar hedge on exfiltration. Adform says it found no evidence that the code transmitted visitor IP addresses or information about the websites they visited, then adds in the same incident notice that "technical analysis indicates that such transmission may have been possible." The captured sample is unambiguous on intent: the first payload builds a request carrying page hostname and path to an external host. Whether it landed with the operator is not established by the sample alone.

What is still unknown

How many websites actually carried the poisoned file, and how many page loads received it. Adform has not published this count, and it is the only number that measures the incident rather than the platform.
How the attackers reached Adform's deployment path in the first place. No initial access vector has been disclosed.
Whether any funds were successfully diverted, and to which addresses.
Who did it. Adform has not publicly identified the attacker, and the incident notice lists no indicators of compromise.

What to do now

Treat this as a third-party script incident, not a malware incident, because there is nothing on disk to hunt for.

Search web proxy, CDN, and DNS logs for requests to s2.adform[.]net and specifically for trackpoint-async.js, covering at minimum July 20 through July 28, 2026, to establish whether your properties or your users were in scope.
Hunt egress logs for connections to 84.32.102[.]230, particularly on port 7744. This is the one hard network indicator in the public sample.
Inventory every third-party tag on customer-facing and payment-adjacent pages. Ad tech, analytics, chat widgets, and A/B testing scripts all execute with full DOM access.
Deploy Subresource Integrity where the vendor serves a versioned, static file, and a Content-Security-Policy that constrains which origins can execute script. SRI would have broken this file the moment its bytes changed.
Force cache invalidation for affected assets and instruct users who transact in crypto to clear browser cache rather than assuming the vendor's fix propagated.
Add a verification step to any workflow where a wallet address moves between a browser and a transaction: confirm the full string, not the first and last four characters.

SRI is the control that fits this failure — Subresource Integrity pins a hash of the third-party file, so an appended payload causes the browser to refuse execution instead of running it. It is not universally deployable because many vendors update their scripts without versioning, but on any asset a vendor keeps static it converts a silent supply-chain compromise into a hard load failure you can alert on.

The broader takeaway is scope asymmetry. One JavaScript file on one CDN put wallet-rewriting code into the browsers of visitors to sites that were never themselves attacked, with zero detections at the time of disclosure. Every third-party tag on your pages is an unaudited code execution path in your users' browsers, and it stays that way until you either constrain it with policy or accept the vendor's security posture as your own.

Originally published on RedEye Threat Intelligence.

Coldcard Firmware Flaw Cut Seed Entropy to 40 Bits, Enabling a $70M Bitcoin Sweep in 41 Minutes

Etairos.ai — Sun, 02 Aug 2026 14:04:13 +0000

TL;DR

what: A build-configuration error in Coldcard firmware, introduced in March 2021, silently routed BIP-39 seed generation to MicroPython's deterministic Yasmarang PRNG instead of the STM32 hardware RNG.

On July 30, 2026, a single attacker drained 1,196 Bitcoin addresses in 41 minutes, moving 1,082.65 BTC worth roughly $70.2 million at the time. Galaxy Research mapped the sweep and tied it to a firmware defect in Coldcard, the Bitcoin-only hardware wallet built by Canadian firm Coinkite. The flaw had been shipping since March 2021.

Originally published on RedEye Threat Intelligence.