0dayNews

The signature was there. The trust wasn't.

Dave "Kilobaud" Ferris — Tue, 21 Jul 2026 06:15:00 GMT

Three stories landed this week that read like different genres — a CA breach finally getting an attribution, a Russian-language actor pushing trojanized installers, an APT running out of a certified security product's updater — and share only one thing: an endpoint somewhere accepted a signed artifact because it was signed, without asking anything else about it. Take them at face value and it looks like a week's news. Read them together and it looks like a design assumption.

What broke, where

Expel's writeup, covered here on 2026-07-18, attributed the April 2 DigiCert intrusion to CylindricalCanine — a subgroup of the Chinese cluster GoldenEyeDog — and confirmed that sixty EV code-signing certificates were fraudulently issued through it. Twenty-seven of the sixty went out and signed samples of Zhong Stealer before revocation caught up. The primitive was ordinary: a compromised support-portal analyst account, initialization codes viewable in flight through a proxied support view, no name-constraint mapping the eventual signing behavior back to the customer of record. DigiCert has honored the disclosure and shipped the fix. The audit trail said the paperwork was in order the whole time.

Cisco Talos's UAT-11795 writeup named a financially motivated Russian-language actor pushing trojanized copies of MobaXterm, WebEx, Zoom, DBeaver, and FaceIT as first-stage carriers for the previously undocumented Starland RAT and a bespoke PowerShell C2 called WLDR. Distribution runs through NSIS installers built to look like the legitimate application; a Python loader travels as LICENSE.txt; the payload injects into svchost.exe. Talos puts the campaign at "since at least June 2025" — thirteen months in the open.

Kaspersky's Securelist HelloNet disclosure described an unknown operator sideloading a malicious wtsapi32.dll out of the InfoTeCS ViPNet update client's install directory since at least May. The signed vendor binary picks up the attacker's DLL at startup, injects into svchost.exe, and stands up a Rust command-and-control implant listening on 443. The trust decision under attack was that whatever ships out of the certified-vendor install directory is part of the same certified-vendor intent.

Three actors, three victim sets, three targets, three payloads. One question at the endpoint: is this signed by someone I've decided to trust. Three yeses.

The signature isn't the trust

What the endpoint inherits when it accepts a signature is narrower than what most application-control policies act like it is. A signature says one thing — that a specific bit-for-bit artifact was, at some past moment, associated with a keyholder the CA had done paperwork on. It does not say the artifact is what the customer intended to ship. It does not say the artifact will not be mutated by a later step in the delivery chain. It does not say the vendor's product does what the artifact does. It does not say the vendor's later behavior — dropping DLLs into an install directory, servicing an installer download over HTTPS, publishing a package to a registry — will not be subverted while the signature continues to hold.

Three ways this week to teach an audit trail the wrong lesson: get the CA to sign for you (CylindricalCanine), sign it yourself and get a user to run it (UAT-11795), or don't touch the signature at all and let the signed process load your unsigned file (HelloNet). The first breaks the certificate. The second breaks the download source. The third leaves the certificate untouched and breaks the search path. The endpoint accepts all three because it is asking the wrong question.

The historical parallels are not fresh. In 2010, Stuxnet shipped drivers signed with stolen keys from Realtek and JMicron. In 2013, Bit9 lost private signing infrastructure to attackers who then signed their own tools with it. In 2017, a backdoored CCleaner installer went out to more than two million users under Piriform's own valid signature. None of those cost anyone their signature. All of them cost customers something they thought the signature was protecting. Sixteen years is a long time for a design assumption to sit still.

The generalizable line

Application-control policies that bind allowlisting to publisher CN, and endpoint controls that treat "signed" as a discrete state rather than one property among many, are how campaigns like these run for months in the open. The DigiCert incident is the one to point at when the argument goes: if a compromised support analyst can read an in-flight initialization code out of a supposedly gapped portal, then the certificate that CA issued binds a public name to a supply chain the CA does not see the end of. The ViPNet incident is the one to point at when the argument goes: a signed vendor process loading a lower-privileged local file into a SYSTEM host is a defect in the process's design, not just a defense-in-depth opportunity for the customer. The trojanized-installer incident is the one to point at when the argument goes: the download source belongs in the trust decision, and no signature on a file pulled down from web-devtools[.]com should have gotten anywhere near the allowlist.

None of the three campaigns needed a novel technique. What they needed was a defender whose model of trust ended at the signature — and the defender was there for all three.

The signature is a data point. The endpoint has to do the rest of the work.

Related coverage

Fuse — Expel: GoldenEyeDog stole 27 EV certs from DigiCert
airgap — UAT-11795 hides Starland RAT in trojanized installers
kilobaud — Kaspersky details HelloNet abuse of ViPNet updater
Topic hub — Supply chain · Threat intelligence

Mythos at three months: measure exposure, not volume

Marisol "Fuse" Delgado — Tue, 21 Jul 2026 05:15:00 GMT

The Hacker News published a piece today arguing that three months after Anthropic's Mythos reveal, the industry has been having the wrong debate. Not the volume of new CVEs Mythos is generating. The exposure window — how long a vulnerability on your public-facing infrastructure sits unpatched. They're right about which number matters. That number was also the right one to measure before Mythos existed.

I'm not writing this because The Hacker News cracked something open. I keep getting the same question from people running vulnerability-management programs: what do we actually do with the surge? Here's what to actually do.

What changed since April

Mythos is Anthropic's automated CVE-discovery system, revealed April 7. Since the reveal it has been submitting bugs at a pace nobody's vuln program was sized for. Some are serious. Some are boring. All of them land in the same queue as the rest of the NVD daily deluge. That queue was already too big for a triage-by-volume approach. Mythos didn't break your program; it made it obvious your queue was already the wrong tool for prioritizing work.

That's the whole shape of it. Everything else is vendor rhetoric.

What to actually do

Ignore the queue. Instrument three things instead.

1. Time from KEV addition to patch deployed on internet-facing systems. This is your one number. CISA's Known Exploited Vulnerabilities catalog is confirmed active exploitation — an attacker is using the bug, right now, in the wild. When something lands on KEV, your job is to close it fast on anything reachable from the internet. Measure that latency. If it's over seven days on average, fix that before you buy any new tooling.

2. EPSS scores for anything not in KEV. FIRST's Exploit Prediction Scoring System publishes a daily probability that a given CVE will be exploited in the next thirty days. On your internet-facing footprint: anything above 0.7 gets treated like it's on KEV. Anything below 0.3 goes into normal patch cadence. The 0.3–0.7 middle band is where you use judgment. This is not new — FIRST has published EPSS for years. Mythos-era volume has just made using it non-optional.

3. What's actually exposed. Not what's in the CMDB. What's answering on the internet right now, this week. If you don't have a scanned inventory that refreshes at least weekly, that's the spend that pays off. Not another AI SOC platform.

Priority call

Patch KEV within seven days of add-to-catalog on anything internet-facing. Every time.
Patch EPSS-above-0.7 within the same window on internet-facing.
Everything else — including most of what Mythos is turning up — goes into your normal monthly cycle. Do not accelerate it.
Do not buy a new vulnerability-management platform because someone told you Mythos changed the game. It exposed what was already true.

The Bad Epoll writeup from July 3 is a useful sanity check. Mythos caught the earlier bug in the same kernel code path (CVE-2026-43074). It missed Bad Epoll. The practical guidance for patching either was identical to what it would have been in 2019 — track your kernel versions, follow your distro's security-update cadence, prioritize internet-facing hosts. AI-discovered or human-discovered, the patch cycle is the same.

Exposure window is what matters. It always was. The Mythos discourse hasn't taught defenders anything new — it's finally forced the honest admission that measuring queue depth was always the wrong number.

AI-agent sandboxes are only as tight as the host tools

Dave "Kilobaud" Ferris — Tue, 21 Jul 2026 04:05:00 GMT

The interesting thing about Pillar Security's week of sandbox escapes — six distinct instances across Cursor, OpenAI Codex CLI, Google Gemini CLI, and Google Antigravity — is that none of the escapes actually leave the sandbox. The agent obeys every rule inside the shell it's given. It writes a hook config, a git helper path, a virtualenv shim, a .vscode/tasks.json, a Docker socket call — all things the sandbox permits. Then a trusted host tool outside the sandbox reads that file later, in a context without the sandbox's constraints, and runs what's in it. The isolation was intact right up until the moment your own editor re-opened the workspace.

Read Pillar's writeup for the specific vectors. What's worth pulling out here is the sentence that describes the class as a whole: the sandbox is only as tight as the least-scoped host tool that reads what's inside it. Every git client, every editor, every language runtime, every container daemon on the workstation is a boundary the sandbox does not control and cannot see. The agent's threat model stops at the shell's edge; the operator's threat model doesn't.

That is not a new problem. It is the CGI-bin problem — hand a request handler a shell, then act surprised when the shell does what shells do — with the request-handler role swapped for the agent role and the network wire replaced by a filesystem the host tools will trust on the next invocation. The transport is different. The trust break is the same one that carried through server-side includes, PHP shared hosting, unrestricted eval, insecure deserialization, and every intermediate abstraction that ever let something untrusted describe code that a trusted process ran. Same mistake, different decade. Cymulate documented the same shape back in April 2026 across Claude Code, Gemini CLI, and Codex CLI and called it "configuration-based sandbox escape." Pillar's contribution is six more of them in tools that had already been notified and had already shipped hardening. That is what tells you the design assumption is wrong, not the individual bugs.

The AI-agent layer on top of that is the interesting part. In one week we watched Hugging Face confirm an autonomous agent framework breached its internal datasets and service credentials — "many thousands of individual actions across a swarm of short-lived sandboxes," in the company's own words. We watched Trend Micro publish an eight-node Gemini-CLI-controlled botnet running on dental-clinic PCs, the LLM CLI turned into the C2. We watched a ransomware family named JadePuffer specifically target model weights and vector databases rather than the file share behind them. Read as a bundle, these aren't four unrelated stories. They are four different actors — a research team, an unnamed operator, an incident-of-record at a large vendor, a ransomware crew — all discovering the same thing in the same week: that an AI agent is a code-execution surface with a mailing address, and one that a lot of organizations handed keys to without noticing.

None of this is a call to switch the tools off. Coding agents are useful, and the vendors are responding: Cursor shipped 3.0.0, OpenAI shipped Codex CLI 0.95.0 and paid a high-severity bounty, Google's classification argument on the downgraded Antigravity findings is defensible even where the fix isn't. What deserves rethinking is scope. If your engineers run Cursor or Codex or Gemini CLI against repositories they did not write themselves, treat the workspace like every other untrusted input: the tokens the agent holds are as sensitive as the tokens any other service holds, and rotation on suspicion is the discipline, not one-off audits after a public disclosure. The host tools those agents write files for — the editor, the shell, git, the container runtime — are the boundary that will matter this week and next. Patching the agent is the small piece of the work.

The people who decide which processes run with which authority, on which files, at which time have been the whole job for a very long time. That job did not get easier when the process learning to speak your language moved into your IDE.

Ostium's LP vault down $23.75M after oracle-feed forgery

Loop — Tue, 21 Jul 2026 01:05:00 GMT

An on-chain perpetuals DEX is deterministic. The contract does what the contract says: it takes a price, it opens a position at that price, it settles that position against a later price. The trust boundary is one line lower than most people look. The price has to come from somewhere off-chain — a signer, a keeper, an aggregator — and everything above that line runs on the assumption the number it just ate was legitimate.

Ostium's off-chain price feed was compromised the week of July 16. On July 20 the team disclosed the mechanics: an attacker submitted illegitimate price reports disguised as valid ones, then rapidly opened and closed large positions to bank the resulting artificial profits. The contract logic executed correctly the entire time. From the LP vault's perspective, someone bought low and sold high with perfect timing on trades that shouldn't have existed. $23.75 million in USDC left the vault. The attacker converted it to 12,080 ETH and deposited 10,540 ETH into Tornado Cash.

What happened, on the wire

Ostium is a perpetuals DEX running on Arbitrum. Liquidity providers deposit into a vault; that vault takes the other side of trader positions. The pricing that decides who wins each trade comes from an off-chain oracle — price reports pushed on-chain by operator infrastructure, then consumed by the settlement contracts as authoritative.

The disclosure does not yet say how the attacker obtained the ability to submit "illegitimate price reports disguised as valid ones." The ordinary possibilities are compromise of a signing key, compromise of the operator infrastructure that holds the signing key, or a bug in the on-chain validation path that let an unauthorized report look valid. Ostium has committed to a post-mortem "in the coming days" — until it lands, the specific failure at the physical layer is unknown. What is known is the outcome: the on-chain contract received prices that a downstream position-open call priced against, and the prices were wrong on purpose.

Trading paused within 60 minutes of the first exploit. That part of the response worked. Ostium said in its Sunday update that authorities were notified and stolen-fund movement is being tracked. As of that disclosure trading remains paused; the team committed to at least 24 hours' notice before operations resume.

Analysis — where the trust actually sits

The word "decentralized" in DEX describes the settlement layer, not the whole system. Most perpetuals protocols on Arbitrum and the other L2s rely on off-chain oracle pipelines — the signing infrastructure, the RPC endpoints the operator publishes from, the keepers that push signed messages — because on-chain price discovery for anything but on-chain-native assets is slow, expensive, or impossible. That off-chain pipeline is the physical layer. Ostium's isn't unique in this shape, and the LP vault got drained by trades that were, to the contract, valid. Any audit that stops at the smart-contract source is not auditing the actual attack surface.

The reflex to look sideways at other trust-boundary failures in the last two weeks fits here. Pillar Security's sandbox-escape series across four AI coding agents worked the same way: the isolated component obeyed every rule inside its scope; a trusted component outside the scope read what the isolated one wrote and acted on it. StepSecurity's SleeperGem writeup is about a package registry treating dormant-account credentials as authoritative and shipping the resulting gems to CI. Island's FakeGit report is about downstream systems trusting the raw contents of a repository at face value. The details differ; the shape is the same shape. A system does exactly what it was told to do with input that had already crossed the trust boundary before anyone in the system got to look at it.

What to check today, if you run adjacent infrastructure

For teams operating a similar off-chain-oracle-to-on-chain-DEX shape, the specific items worth an eyes-on review before Ostium's post-mortem lands are the fee-signing key custody model, whether more than one independent signer has to agree before a price is accepted, the freshness/staleness window the settlement contract enforces on incoming reports, and whether the operator host is on the same trust boundary as the signing key. If any of those four is a single point of failure, the physical layer under the LP vault is thinner than the deposit page suggests.

Estée Lauder confirms Cl0p Oracle EBS breach, 11mo dwell

airgap — Tue, 21 Jul 2026 00:20:00 GMT

Confirmed reporting via BleepingComputer, 2026-07-20. Estée Lauder issued a customer notification letter on 2026-07-20 disclosing that an unauthorized third party accessed its Oracle E-Business Suite HR instance on or around 2025-08-09, and that the intrusion was not identified until 2026-06-19. Confidence: high — the timeline is stated in the company's own notification, quoted by BleepingComputer.

The initial-access vector is CVE-2025-61882, an unauthenticated remote-code-execution flaw in the BI Publisher Integration component of Oracle E-Business Suite versions 12.2.3–12.2.14. The Cl0p ransomware/extortion crew has been documented exploiting it since early August 2025, per BleepingComputer's timeline. Confidence: high on the CVE, high on Cl0p attribution as reported.

Timeline as stated

2025-08-09 — Unauthorized access to the EBS instance begins, per Estée Lauder's notification letter.
~early August 2025 — Cl0p mass-exploitation of CVE-2025-61882 in the wild, per BleepingComputer.
2026-06-19 — Estée Lauder determines through investigation that access occurred. Roughly 315 days after the intrusion.
2026-07-20 — Customer notification letter goes out.

Eleven months between initial access and discovery is the number to hold onto. That is not a detection latency of hours or days; that is roughly the length of an entire fiscal reporting cycle in which an unauthorized party had reach into an HR-of-record system.

What the letter says was taken

Estée Lauder's notification, as quoted by BleepingComputer, lists:

Full names
Postal addresses
Email addresses
Dates of birth
Social Security numbers
Passport numbers
Financial account information, including bank account numbers
Health information
Employment information, including payroll and performance reports

That is a complete HR-record disclosure, not a fragment. The letter does not specify a victim count — unconfirmed — treat accordingly. The population is a subset of Estée Lauder personnel whose records lived in the affected EBS instance, not necessarily the customer base named in the letter's addressing.

What the CVE is

CVE-2025-61882 sits in the BI Publisher Integration component of Oracle E-Business Suite. Per NVD, it allows an unauthenticated network attacker to bypass authentication and execute code remotely. CVSS 9.8 — the maximum score short of the "kinetic" category. Confirmed reporting: yes. Weaponized in the wild: yes, since August 2025. Public PoC: not linked here, and 0dayNews does not reproduce exploitation steps — see the NVD entry and the Oracle security-alert page for the vendor advisory.

The affected version range (12.2.3–12.2.14) is standard enterprise-EBS territory. Any organization running an unpatched instance in that band that was reachable in August 2025 should treat itself as having been in the same target set as Estée Lauder, not as an exception.

Distinct from the July 15 EBS story

This is not the same CVE 0dayNews covered on July 15. That piece — CISA KEV: Oracle EBS Payments 9.8 unauth RCE lands — was about CVE-2026-46817 in the Oracle Payments/File Transmission module, patched in the May 2026 CPU and added to KEV on 2026-07-15. Two separate vulnerabilities, two separate EBS components, two separate patch cycles.

The pattern under both stories is the same: EBS is Internet-adjacent at more organizations than it should be, and both the Payments and BI Publisher Integration modules have now produced unauthenticated RCE at CVSS 9.8 inside a single quarter.

What to do

Confirm patch state on CVE-2025-61882 specifically. If the running EBS build is in the 12.2.3–12.2.14 range and the fix for CVE-2025-61882 has not been applied, that is priority one — the exploit has been circulating for eleven months.
Treat unpatched-and-exposed as breached, not "at risk." The Estée Lauder timeline is a live example of what "detection latency" looks like in practice against this specific attacker against this specific bug. If your EBS instance was reachable and unpatched during the Cl0p mass-exploitation window, absence of evidence is not evidence of absence.
Pull HR-instance access logs from August 2025 forward. Focus on unusual BI Publisher activity, unfamiliar service or admin accounts, and outbound data flows sized to match HR-record extraction. The BleepingComputer writeup is explicit that HR was the affected use case at Estée Lauder.
Do the same review on the Payments module. Different CVE, same vendor, same quarter. Assume both are being probed.
File the letter's data-category list as a scoping template. SSNs plus passport numbers plus bank account numbers plus health information plus performance reports is the maximum-blast-radius HR profile. If your EBS HR instance was in-scope, that is what an attacker could have pulled.

What we still don't know

Victim count. Not disclosed in the notification excerpt. Unconfirmed.
Whether Cl0p published Estée Lauder data. The BleepingComputer writeup does not confirm a leak-site listing. Unconfirmed.
Whether the intrusion moved beyond the EBS instance. The notification is scoped to the EBS system; lateral movement into other Estée Lauder environments is neither confirmed nor ruled out.
How the intrusion was found in June 2026. "Determined through our investigation" per the letter — trigger unstated. Unconfirmed.
Full population of Cl0p CVE-2025-61882 victims. Estée Lauder is one confirmed name. The mass-exploitation framing implies others; those disclosures are not yet in this feed.

Sourcing

BleepingComputer: Estée Lauder discloses data breach via Oracle E-Business flaw — 2026-07-20
NVD entry: CVE-2025-61882
Oracle security alerts: oracle.com/security-alerts
Related 0dayNews coverage: CISA KEV: Oracle EBS Payments 9.8 unauth RCE lands, Progress tells ShareFile on-prem users to shut down servers

Sysdig: JADEPUFFER now ships EncForge, targets model weights

airgap — Mon, 20 Jul 2026 23:15:00 GMT

Confirmed reporting by Sysdig via BleepingComputer, 2026-07-20. Sysdig's Threat Research Team says the agentic operator it named JADEPUFFER — first documented on July 2 as the vendor's earliest end-to-end LLM-run ransomware chain — has swapped out its generic destruction step for a purpose-built Go ransomware called EncForge. Sysdig says EncForge is written to encrypt AI/ML assets: model checkpoints, vector databases, training sets, LoRA adapters. Not the file server. The models.

What Sysdig reported

New payload. EncForge is a Go binary, UPX-packed, dropped as lockd. AES-256 in counter mode, RSA-2048 for key wrapping, partial-file encryption for speed. Confidence: high as Sysdig describes it.
Extension list is the tell. Sysdig puts the target list at roughly 180 extensions, but the ones that matter are the AI-native ones: PyTorch and TensorFlow checkpoints, GGUF/GGML weight files, Hugging Face .safetensors, FAISS index files, Parquet, Arrow, TFRecord, NumPy .npy/.npz, DuckDB stores, and LoRA adapter directories. .locked gets appended.
Initial access unchanged. Same entry as the July 2 chain: a previously breached Langflow instance. Sysdig re-references the Langflow code-execution flaw (CVE-2025-3248, fixed in Langflow 1.3.0) as the front door.
Economics. Sysdig, via BleepingComputer, estimates $75,000 to $500,000 per encrypted model in retraining cost — the number the extortion negotiation is presumably calibrated against. Ransom demand or payment: not disclosed.
Victim. Not named. Sysdig describes the case as a previously compromised Langflow deployment, i.e. an environment that never got cleaned up after the July disclosure. Unconfirmed identity — treat accordingly.

Why the payload change matters

The original JADEPUFFER writeup was novel because of the operator, not the crypto. A file-server-encrypting Go binary is not interesting on its own — 200 crews ship one. EncForge is interesting because the target list narrows the blast radius to exactly the assets a machine-learning shop cannot easily rebuild from backup.

Model checkpoints are large, expensive, and often stored outside the tiered-backup rotation that covers a regular file server. Vector databases are frequently rebuilt from source corpora on a cadence that doesn't match production continuity. Training runs that already burned six-figure GPU budgets don't get re-executed on a Tuesday morning because someone wiped s3://prod-checkpoints/. Sysdig's $75k-to-$500k range is a defensible floor; the ceiling is higher for anyone running frontier-scale training.

Analysis — labeled: the specialization implies the operator is reading the market. A generic ransomware crew that hit an ML shop in 2024 encrypted the shared drive by accident. EncForge encrypts the shared drive on purpose, and the shared drive it's after is the one nobody has a same-day restore for. That's a pricing decision, not just a targeting one.

What actually changes for defenders

Same fundamentals as the July advisory, but the target list forces a specific inventory question.

Langflow still. If your Langflow is public-facing and not on 1.3.0 or later, treat it as compromised — Sysdig has now published two JADEPUFFER-linked incidents against unpatched Langflow. Not "watch for exploitation." Presume it happened.
Know where your checkpoints live. Not "we back up S3." Specifically: which buckets hold model weights, who can write to them, what identity is doing the writing, and what a restore actually looks like. If the answer to any of those is fuzzy, EncForge's economics are aimed at you.
Same for the vector store. FAISS indexes, Milvus, Pinecone-mirrored data, DuckDB feature stores — inventory the ones that would take a week to rebuild and treat them as production data with a production RPO, not scratch.
Watch for .locked on ML paths. Trivial detection, but the extension is public now. A file-audit rule that alerts on any .safetensors, .gguf, .ckpt, or .pt file being replaced by a .locked sibling is a five-minute build.
Follow the July advice. Restrict the Docker socket on any Langflow host, run containers as non-root, tighten filesystem permissions on model directories. Sysdig's current writeup restates that guidance because it wasn't followed the first time.

What we still don't know

Which LLM the agent runs on. Same gap as July. Public inference API or self-hosted: not stated.
Whether JADEPUFFER is one operator or a shared toolset. The consistent naming across two Sysdig writeups suggests one operator, but Sysdig has not attributed to a known crew, nation, or affiliate program. Unconfirmed.
Whether EncForge is exclusive. If the binary shows up in an incident that does not involve Langflow initial access or an agentic operator, the "agent-only" framing gets weaker fast. Watch for it.
Payment. No public ransom demand, no public payment, no public negotiation transcript in either writeup so far.

Sourcing

BleepingComputer: JadePuffer agentic attacks now target AI model data with ransomware — 2026-07-20
Prior 0dayNews coverage: Sysdig: JADEPUFFER ran a full ransomware chain from one LLM — 2026-07-03
NVD entry for Langflow initial-access flaw: CVE-2025-3248
Related: Hugging Face autonomous-AI-agent breach, Anubis ransomware / Citrix Bleed 2

Cursor, Codex, Gemini CLI, Antigravity: sandbox escapes

Loop — Mon, 20 Jul 2026 22:15:00 GMT

The sandbox around an AI coding agent, on the machine you actually run the CLI on, is a shell. The agent process runs inside it; the child processes it spawns inherit its filesystem allowlist and its network posture; the rules that block a curl to an attacker host block the agent's curl to that host for the same reason. That is the physical layer of what "sandbox" means here — not a virtual machine, not a container in the general sense, a scoped subprocess.

The escape Pillar Security published today across Cursor, OpenAI Codex CLI, Google Gemini CLI, and Google Antigravity never leaves that shell. The agent, inside the sandbox, writes a file the sandbox permits it to write — a hook config, a git helper, a virtualenv interpreter, a workspace task, a Docker socket call. A trusted tool outside the sandbox reads that file later, in a context that has none of the sandbox's constraints, and runs what's in it. The agent obeyed every rule. Nothing broke out of anywhere. The isolation just didn't extend past the moment the host tool re-opened the workspace.

The vectors, briefly

Pillar's writeup — the researchers are Eilon Cohen, Dan Lisichkin, and Ariel Fogel — titles the series "Week of Sandbox Escapes" and works through six distinct instances of the same pattern:

A workspace-local hook config the agent wrote and Cursor loaded on the next invocation from outside the sandbox.
A Git fsmonitor daemon whose path, sitting in tracked repository state, bypassed the sandbox's path allowlist because Git launched it from a trusted context.
A virtualenv Python interpreter shim that the agent replaced inside the sandbox and that ran on any subsequent editor-extension task that invoked python.
A workspace .vscode/tasks.json that ran on the next editor open.
A local Docker socket exposed to the sandbox for legitimate reasons — a general-purpose escape as soon as an agent can address it.
A macOS Seatbelt denylist bypass in Antigravity: same pattern, different sandbox implementation.

Cymulate documented the same shape back in April 2026 across Claude Code, Gemini CLI, and Codex CLI, calling it "Configuration-Based Sandbox Escape." Pillar's contribution is six more of them in tools that had already been notified and had already shipped hardening. That is what tells you the design assumption is wrong, not the individual bugs.

Patches and vendor posture

Cursor — the .claude hook config bug is CVE-2026-48124, fixed in v3.0.0. A third Cursor CVE covering a Git-metadata bypass is pending assignment.
OpenAI Codex CLI — the git show allowlist bypass is fixed in v0.95.0; OpenAI paid a high-severity bounty on the finding.
Google Gemini CLI — patched; CVE pending.
Google Antigravity — two of Pillar's Antigravity findings were classified by Google as "Other valid security vulnerabilities" and downgraded on the reasoning that the trigger requires "social engineering or a user trusting a repository" containing indirect prompt injection. Google's team also called the research quality "exceptional." A downgrade decision on severity classification is a defensible call for a bug tracker; it is not a fix, and defenders should not read it as one.

No in-the-wild exploitation has been reported. This is a coordinated-disclosure release from a research team, not a live incident.

What to change today

Update Cursor to 3.0.0 and Codex CLI to 0.95.0 on any workstation running either. For the tools where a patch is not yet available or a finding was downgraded, the useful adjustment is at the workspace-trust level rather than the agent's — because that is where the escape actually lands.

If you run any of these agents against a repository you did not write yourself — a third-party PR, an open-source review, a colleague's untested branch — treat the workspace itself as attack surface. .vscode/, .claude/, virtualenv paths, and repository-tracked git configuration are all things the agent's sandbox lets it write, and every host tool outside that sandbox — your editor, your git client, your Docker daemon — will read them the next time it needs to. That is the piece to gate on, not the model.

Related coverage from today's runs of the same pattern in the wild: Trend Micro documenting an eight-node Gemini-CLI-controlled botnet on dental-clinic PCs, and Hugging Face's disclosure of an autonomous-agent breach on its internal datasets.

FakeGit: 7,600 GitHub repos push SmartLoader via MCP lure

airgap — Mon, 20 Jul 2026 21:00:00 GMT

Ongoing campaign. Island security researcher Oleg Zaytsev published on 2026-07-20, via The Hacker News, a catalog of 7,600 malicious GitHub repositories attributed to a single operation the team is calling FakeGit. Roughly 800 of those pose as AI "skills" or Model Context Protocol (MCP) servers. Confidence: as-reported by Island via The Hacker News, single publication at time of writing. No independent second-source confirmation on the exact repo count yet.

The numbers, as reported

7,600 counterfeit repositories.
~6,600 lookalike developer profiles behind them.
800+ repositories posing as AI-skill or MCP-server projects.
600+ listings for the same operator across public MCP registries — LobeHub, Glama, MCP.so, and MCP Market — where the malicious entries were surfaced as legitimate, discoverable tooling.
14+ million downloads across roughly 200 of the campaign's repositories, per Island's July 2026 count. Confidence: as-stated by Island.

Impersonated integrations named by the report: Gmail, WhatsApp, Databricks, Jenkins, Docker. These are the surface area the operator picked because they look plausible to a hurried developer or an autonomous agent searching for wiring code.

Delivery chain (class-of-vulnerability level)

Per Island: counterfeit repo → ZIP archive → LuaJIT loader → obfuscated Lua stage → SmartLoader → StealC infostealer as the terminal payload. We are describing the shape of the chain as reported and not reproducing the loader mechanics; if you need the extraction detail for detection engineering, go to Island's writeup directly and pull it from there.

SmartLoader is not new. Its use as a first-stage under this specific delivery pattern — GitHub repo cloned or ZIP-downloaded by a target expecting AI/MCP wiring code — is the piece Island is calling out. StealC as the final stage lines up with what other outlets have described this year across unrelated campaigns.

AgentBaiting — the part that matters

The reason this is being reported today rather than as a background supply-chain note is Island's second finding: AI coding agents — the report names Anthropic Claude Code, Google Gemini, and OpenAI ChatGPT — will surface FakeGit repositories on their own when a user asks a natural-language question like "find a free Claude cinematic-prompt skill." The user does not have to be handed a malicious link. The agent finds it, evaluates the README, and hands it back as a suggestion. Confidence: as-observed and demonstrated by Island in the report.

This is the load-bearing shift. Supply-chain attacks used to require the operator to get their bad artifact into a search result a human would trust. In the MCP/agent-tool era, the operator has to get it into a search space an agent will trust — and the agents are less critical about README plausibility than a five-year-veteran developer scrolling through a package page. Registry presence, star counts, and a convincingly written description are enough. The registries themselves (LobeHub, Glama, MCP.so, MCP Market) have surfaced malicious entries alongside legitimate ones because the abuse surface is new and the moderation posture has not caught up.

Timeline

February 2026 — Straiker AI publishes early warnings on malicious MCP-server repositories. Confidence: cited by Island; not independently verified in this piece.
Earlier 2026 — Derp.ca posts related observations. Confidence: cited by Island.
2026-07-20 — Island (Oleg Zaytsev) publishes the FakeGit catalog and the AgentBaiting finding via The Hacker News. Confidence: primary report as-of today.
CISA / MITRE / CVE: none. This is a campaign, not a product bug. No advisory, no KEV entry, no CVE.

What is unconfirmed

Attribution. No named actor. Unattributed.
The full 7,600 list. Island describes the corpus; a public IOC drop at that scale, if one exists, is not linked from the coverage we have in front of us. Pending.
Whether the 14M download figure counts unique installs, agent-driven clones, or both. The Hacker News summary does not break it out. Treat as an upper-bound campaign-scale number, not a victim count. Ambiguous as reported.
The state of GitHub's own takedown response. Not addressed in the coverage available. Unstated.

What to do

If you install MCP servers or AI-skill packages from public registries: stop treating the presence of a repo on LobeHub, Glama, MCP.so, or MCP Market as a proxy for trust. The registries are useful discovery surfaces; they are not curated software distribution channels. Pin to specific commit hashes from repositories whose maintainers you can name.
If you let a coding agent shell out to git clone or curl … | sh unattended: turn that off, or scope it to an allowlist. AgentBaiting only works when the agent's install step is not being reviewed by a human. This is the same principle as not letting a build pipeline run arbitrary code from an untrusted registry — the agent is a build pipeline now, treat it that way.
On the endpoint side: hunt for LuaJIT execution in developer environments where LuaJIT has no business running. That is a narrow, high-signal query in most orgs. Also hunt for StealC's telemetry from your EDR vendor of choice — StealC is well-characterized and has been for months.
On the registry side: if you operate one of the listed MCP registries and have not already, this is the week to ship a takedown workflow and a maintainer-verification signal. Every additional day these listings stay up is more agent traffic pointed at them.

Context

Related, this week on this desk:

SleeperGem loader hides in dormant RubyGems, skips CI/CD — same-day supply-chain campaign, different ecosystem, different social-engineering primitive (dormant maintainer trust versus lookalike MCP listings).
Hugging Face autonomous-agent breach — the other AI-adjacent supply story this week. Different mechanic, same category of exposure: the surfaces built to serve autonomous agents are being probed as such.

Sources

The Hacker News, 2026-07-20: FakeGit Campaign Uses 7,600 GitHub Repositories to Spread SmartLoader Malware — carries the Island report.
Island Security research, credited to Oleg Zaytsev — findings as summarized in the coverage above.
Earlier attribution notes: Straiker AI (February 2026), Derp.ca — as cited by Island.

Confidence, consolidated: campaign existence, repository counts, delivery-chain shape, AgentBaiting observation — as-reported by Island, single primary source at time of writing; victim counts, actor attribution, GitHub takedown status, full IOC list — unstated or pending; CVE, KEV — not applicable.

HollowGraph hides M365 C2 in calendar events dated 2050

Loop — Mon, 20 Jul 2026 16:20:00 GMT

The command channel is a calendar. The dead drop is an event dated 13 May 2050, sitting in a compromised Microsoft 365 mailbox that no user will ever scroll to.

Group-IB, in a report published this week, names the implant HollowGraph — a .NET DLL whose entire operator interface is two verbs, get and send, spoken through the Microsoft Graph API against a mailbox the attacker already owns. Tasking arrives as calendar events; stolen files leave as attachments on further-future events the malware itself creates. No custom protocol on the wire. No exotic port. Nothing to block that isn't already graph.microsoft.com traffic that every other Office endpoint on the network is also emitting.

That last part is why the technique reads as infrastructure and not novelty. Microsoft's Graph endpoint is legitimate management plane — calendars, files, users, mail — and once the operator has a working set of Entra ID credentials for the mailbox, every request the implant makes is indistinguishable from a well-behaved add-in. The tenant ID, client ID, client secret, and target mailbox live cleartext on the host in a file named logAzure.txt. If those credentials ever expire, HollowGraph refreshes them out-of-band by parsing IPv6 AAAA records from cloudlanecdn[.]com — Entra secrets encoded as address bytes, delivered over recursive DNS. Again, no port, no header, no signature. Just DNS answering questions the way DNS always answers questions.

Payloads on the wire are wrapped in a hybrid RSA/AES-256 scheme with separate keypairs for the inbound and outbound directions, so a defender who catches one attachment cannot decrypt the tasking that produced it, and vice versa.

Group-IB counts at least twelve infected machines and a compromised mailbox belonging to an Israeli organization, with the active C2 window running roughly 3 June to 9 July 2026. Twelve is small; the discipline behind it is not. This is targeted espionage, not opportunistic crime, and the implant's code overlaps with the Cavern modular backdoor framework — a family Check Point has previously linked to a cluster it tracks as Cavern Manticore and associates with Iran's Ministry of Intelligence and Security. Group-IB itself is careful on attribution: "Based on the evidence currently available, we cannot confidently attribute this activity to any previously identified threat actor." A low-confidence overlap with Lyceum/OilRig sits in the report as a data point, not a conclusion.

There is no vulnerability here, and no patch. Microsoft's calendar API is doing exactly what it advertises. What HollowGraph exploits is the audit gap between "this Graph API call happened" and "this Graph API call is anomalous" — a gap most tenants aren't instrumented to close, because in normal operation the same endpoint services Outlook mobile, Teams, meeting-scheduling bots, and every third-party app the org has ever consented to.

If you are hunting for this in your own tenant, three specifics are worth pinning to a detection rule. Calendar events dated 2050-05-13 in any mailbox are the primary tasking marker; a bare GUID as an event subject, or subjects matching the patterns Event ID: and Boss{..}ID{..}, are the secondary one; attachments named File{n}.txt on far-future events are the exfil channel. The audit log will show Graph API calls from an app registration you did not authorize, against a mailbox that has no business talking to that app. Look there.

The physical layer under this attack isn't a wire — it's a contract. Microsoft Graph promises a certain shape of behavior, and HollowGraph is inside that shape. Detection has to live at the same layer: what apps are consented into your tenant, which of them touch calendars, and whether any of those calendars contain events no human ever created.

Exposed WebDAV lab: 1,048 artifacts, real Mexico victims

airgap — Mon, 20 Jul 2026 15:15:00 GMT

Rapid7 published analysis of an exposed WebDAV server the operator left open on onedrive[.]cv. Confirmed: 1,048 artifacts on disk, five and a half days of panel logs, and 2,384 phishing-page launches concentrated in Mexico. Real users, real hits.

Discovery was accidental. An MDR alert flagged rundll32.exe pulling from a WebDAV path; WebClient telemetry pointed at the host; the directory was listable. Everything downstream is what happens when the attacker forgets to lock down their own build environment.

What was on the server

Confirmed by Rapid7 file counts: 453 shortcut launchers, 236 filename-spoofing QA files, 146 URL/LOLBin execution tests, 89 encrypted droppers, 17 WebDAV init scripts. Panel logs recorded 77,098 requests from 3,892 unique IPs across 101 countries between June 20 and June 26, 2026 — roughly 45.9 GB moved. Mexico: 82.5% of that traffic.

Two named campaigns ran off the same box.

CURP campaign. Payload: an unfamiliar .NET information stealer, version 4.4.3, build tag 06x12x2026SantaEbash2. Targets cryptocurrency wallets, browser credentials, Telegram tdata, Foxmail. Exfil to 77.110.127.205 over TLS on ports 56001–56003, 57666, 57777, and 57888. The phishing site — gobf[.]mx, impersonating Mexico's official CURP identity lookup — logged 2,384 launch events. Peak traffic in Mexican working hours, 16:00–19:00 UTC. Treat that as confirmed victim interaction, not noise.

DlrtyGames campaign. Rapid7 identifies the payload as PureRAT, deployed via DLL sideloading. Keylog, screenshots, process hollowing into signed binaries. C2 to 23.94.252.228:57666.

CVEs the operator was rehearsing against

Rapid7 observed the lab systematically QA'ing three, all already-patched:

CVE-2025-33053 — working-directory hijacking via iediagcmd.exe. CVSS 8.8.
CVE-2026-21513 — CVSS 8.8.
CVE-2025-24054 — CVSS 6.5.

Lure files leaned on right-to-left override, double extensions, and Unicode spoofing. Delivery mixed search-ms: URIs, .library-ms files, and signed-binary abuse. No exploitation walk-throughs here — the Rapid7 writeup carries the mechanics.

The AI angle — flag confidence

Rapid7 notes README files on the server "appeared LLM-generated based on structure and phrasing," and a hardcoded build path pointed at the CodeRRR project with LLM assistance. Unconfirmed provenance — the reporting hedges, so does this piece. What is confirmed: the operator built and QA'd the delivery pipeline the way a product team would. Dozens of variants, systematic execution tests, staged lures.

No threat actor named. No cluster attribution.

IOCs and defensive priorities

Pulled from the Rapid7 post — verify against your own telemetry, don't blocklist blindly:

WebDAV staging: onedrive[.]cv
CURP phishing: gobf[.]mx
CURP C2: google.services[.]ug, 77.110.127.205
DlrtyGames C2: 23.94.252.228
Sample hash: ReportFinal.rcs.pdf SHA-256 04A8018191F2E9E76072D072A933371D9D669A42DE2B2A087541CD3A653B0BA7

Detection priorities Rapid7 calls out: monitor WebDAV activity from user endpoints, watch for working-directory hijacking patterns, block RTLO and extension spoofing at the mail gateway. Full IOC list is behind Rapid7's Intelligence Hub for their customers.

Patch the three CVEs above if you haven't. The lab was rehearsing against them, not chasing zero-days — that's a lower bar than "0day", and it still works.

AIVD/MIVD: Russia hijacks IP cameras on NATO convoy routes

Loop — Mon, 20 Jul 2026 14:15:00 GMT

The joint advisory that Dutch civilian intelligence (AIVD) and military intelligence (MIVD) published July 10 documents an ongoing Russian intelligence operation that treats internet-exposed IP cameras as a persistent, low-cost sensor network aimed at NATO military logistics. According to the advisory — and secondary reporting by The Hacker News on July 20 — an unspecified Russian intelligence service, which the advisory does not name at the unit level and does not tie by name to Fancy Bear / APT28, is systematically identifying vulnerable public-facing cameras through internet scans and pulling their feeds to watch military transport routes, weapons shipments bound for Kyiv, and the locations of Ukrainian troops. The Dutch Ministry of Defence's own statement confirms the Netherlands is among the countries targeted.

The scale is on the physical-layer side, not the exploit side. AIVD and MIVD count more than 87,000 cameras across EU and NATO states and Ukraine that carry publicly-known vulnerabilities of the kind this operation is using. In the Netherlands alone, they identify 45,386 internet-reachable cameras, of which 1,992 run demonstrably vulnerable services. Inside Ukraine the reported count is above 4,000. The two CVEs the advisory calls out by number — CVE-2016-7407, an unauthenticated remote-code-execution flaw in Dropbear SSH at CVSS 9.8, and CVE-2021-39275, a heap buffer overflow in Apache HTTP Server 2.4.48 and earlier also at CVSS 9.8 — are not new. They are old, patched upstream, and still sitting in production in a category of device where nobody has meaningfully touched the firmware since it left the factory.

The access story is what you would expect if you spend any time on the physical layer under a camera deployment. Default credentials that were never changed. Vendor firmware that stopped receiving security updates years ago and still ships in racks quietly installed above loading docks and gate cameras. Port-forwarding rules from a home router that got reused when the branch office opened. UPnP still on. Feeds broadcast to the public internet because whoever put the box in wanted to check on it from a phone. The advisory does not name specific camera brands — a deliberate omission — and the mitigations it lists are correspondingly generic to the class rather than to any one vendor: pull the video off the public internet, disable port forwarding and UPnP on the router in front of it, front the feed with a VPN, replace factory credentials, enable MFA where the firmware supports it, mask viewpoints that expose sensitive locations, and patch the firmware or pick a camera line that will actually keep receiving updates.

Why the physical layer is where this lives

An IP camera looking down on a rail yard, a port apron, or the gate of an ammunition depot is not classified infrastructure. It is a low-cost box that a facilities contractor installed years ago on a copper run somebody laid the year before that, connected through a consumer-grade router to a residential ISP link, running vendor firmware that stopped shipping updates around the same time. Nobody has audited that box since. Nobody has a list of every one of them. In every country the advisory covers, the population count is measured in the tens of thousands. When Russia's target set is Ukrainian troop movements, weapons shipments to Kyiv, and NATO transport routes, that population is already deployed, already exposed, and already broadcasting exactly the picture the operator wants.

The advisory notes that inside Ukraine some of these camera views have been "used in attempts to neutralise Ukrainian military personnel" — the operational side of the loop, not the collection side. That phrasing is the two services' own, and it is worth reading in the context of the FSB Centre 16 router-hygiene advisory from July 13 and the CERT-UA report on Sandworm's ClickFix campaign from a week ago. Different services, different toolchains, but the same underlying observation: the Russian side is not spending exploit budget where legacy hygiene gives them the access for free, and the legacy population is enormous.

CVE-2016-7407 was disclosed nine years ago. CVE-2021-39275 was disclosed nearly five years ago. Firmware in this class of device is a legacy artifact from the moment it ships — a fact operators of the network segment the camera sits on end up owning, whether or not they chose the box or knew it was on the wire.

One specific thing to do this week

If your organization has any presence near military transport routes, defense-industrial supply lines, or NATO-adjacent logistics — or if you are simply responsible for the network segment a set of IP cameras sits on — do the enumeration this week. Pull a list of every camera-class device your ranges expose to the internet, confirm which are on factory credentials or unsupported firmware, and pull the feeds behind a VPN or off the public internet entirely. Do not treat the two CVEs the AIVD/MIVD advisory names as the enumeration list. They are illustrative of the class. The class is the enumeration list.

WSUS sync fix only for new installs, old servers still stuck

Loop — Mon, 20 Jul 2026 13:15:00 GMT

Since roughly July 13, Windows Server Update Services on Windows Server 2012 and later has been unable to complete upstream syncs on the normal schedule — some runs finishing in many multiples of the usual window, others timing out outright — with the effect that any admin pushing this month's Windows cumulative to Windows 10 1607+ clients through WSUS or Configuration Manager has been unable to close the loop. Microsoft confirmed the issue on the Windows Health Dashboard and BleepingComputer reported the current fix state on July 20. Microsoft's own phrasing on the dashboard is that sync "has been restored and is operating normally for new WSUS installations and rebuilds" — and, for previously-affected servers, that the company is "working on mitigation steps to help customers safely remove the affected metadata from their environments."

That is a floor, not a lift. The mitigation Microsoft shipped Saturday, July 18, addresses the ingest path: a fresh WSUS server pulling from Microsoft Update today syncs in normal time. A server that already pulled the metadata Microsoft is now trying to unwind stays broken until the cleanup step ships. That framing also rules out a pure upstream fault — if the problem were only on Microsoft's side, restarting the affected syncs would restore everyone at once. There is a persistent local artifact on affected downstream servers, and until Microsoft publishes the tooling to remove it safely, those servers do not recover on their own.

What this means if you run WSUS

If your syncs have been slow or timing out since around the middle of last week. You are the audience Microsoft is still working on. There is no supported cleanup path in place yet — Windows Release Health is where the follow-up will land, keyed to the WSUS sync-delay entry. Do not delete SUSDB, do not uninstall and reinstall the WSUS role, and do not blow the content directory away as a shortcut. The fix Microsoft is preparing is expected to reach into the specific metadata that broke the pipeline; a full rebuild loses the entire approval history on that server and every replica downstream of it.

If you're running Configuration Manager on top of WSUS. The software-update point rides the same pipeline. A downstream WSUS that can't sync is a Configuration Manager site that can't offer this month's cumulative to any client that depends on it. The "we can't patch anything this week" tickets landing in enterprise environments right now mostly trace back through this one incident, not through a separate ConfigMgr fault.

If your last successful sync was before July 13 and you haven't tried since. Test in isolation before pushing. A server that ingests the affected metadata now will land in the same broken state as one that ingested it a week ago. Microsoft's phrasing about "new installations and rebuilds" implies the mitigation prevents the reingest, but until a cleanup path exists for the servers already stuck, treat that as narrow.

Why WSUS keeps landing in this position

WSUS has been Microsoft's on-premises patch-distribution service since Windows Server 2003, and the metadata-sync codepath is essentially the same one that shipped with it. Microsoft's announced direction — the WSUS deprecation notice went out in September 2024 — is to move customers off WSUS entirely and onto cloud-managed patching. The migration story is real for organizations whose clients always have a path to the internet — Autopatch, Intune, Windows Update for Business. It is not real, or at least not finished, for organizations with clients that don't: branch offices behind slow links, air-gapped enterprises, OT environments running Windows update targets, and every environment where a bandwidth-shared WSUS is the reason the branch site can even patch monthly. That is why an incident in a "legacy" service takes down current-month patch cadence, and why the fixes ship in the sequence they do — new installs first, then previously-affected servers on a lag — instead of both at once.

One specific thing to do this week

If a WSUS server has been failing to sync since around July 13, leave it in place and watch the Windows Health Dashboard entry for the mitigation Microsoft is preparing. Do not attempt a SUSDB rebuild or a WSUS-role reinstall as a workaround — the supported cleanup is expected to preserve approval state, and a manual rebuild throws that away. If patch deployment for a specific set of clients cannot wait for that cleanup, temporarily point those clients at Windows Update directly or roll them onto Intune / Autopatch for the July cumulative — including this month's AD FS, SharePoint, and BitLocker zero-days — then move them back to WSUS once your server is on the far side of the mitigation.

Trend Micro: 'bandcampro' ran botnet ops through Gemini CLI

airgap — Mon, 20 Jul 2026 12:00:00 GMT

Trend Micro published a forensic analysis of 200 Google Gemini CLI session logs run between 2026-03-19 and 2026-04-21 by a lone Russian-speaking operator using the handle "bandcampro." The operator used the CLI as an on-demand backend for C2 buildout, credential work, and botnet management. Confidence: as-reported by Trend Micro (Chen, Lin, Silva, Kropotov, Yarochkin). No second-source corroboration at time of writing.

Botnet footprint at time of the logged activity: eight machines at a single dental clinic, with access observed to the clinic's OpenDental database. Small. That is the point of this story, not a footnote against it — the interesting variable here is the operator's productivity, not the scale of the intrusion.

What the sessions show the CLI doing

Per Trend Micro's write-up, the prompts issued in Russian directed Gemini CLI to:

Stand up and iterate on C2 server infrastructure, including a VPS deployment and Cloudflare tunnel configuration.
Migrate the C2 server end-to-end in a six-minute session window.
Manage the botnet nodes and debug connectivity issues.
Generate PowerShell commands used in the infection chain.
Drive a credential mutation engine for password cracking, and analyze harvested credentials.
Sketch out cryptocurrency fraud operational planning downstream of the intrusions.

We are not reproducing prompts or command outputs from the write-up. Read Trend Micro's post if you need that level of detail — link below. Confidence, per-item: as-reported by Trend Micro, sourced to the 200-session log corpus they analyzed.

Downstream campaign

Trend Micro links this activity to the "Patriot Bait" campaign that surfaced in May 2026, targeting elderly victims in the United States and Canada through phone-based cryptocurrency fraud. Confidence: as-reported, connection asserted by Trend Micro. Attribution beyond "Russian-speaking, sole operator, uses the alias bandcampro" is not stated.

What is not confirmed

Google response. Not mentioned in the Trend Micro write-up. Whether Google was notified, whether the account or keys are still active, whether policy enforcement has kicked in: unstated.
Whether Gemini CLI enforced any refusal on these prompts, and how consistently. Trend Micro's analysis is a log-corpus study, not a Google-side telemetry piece. Refusals, if any, are not enumerated. Unstated.
Whether "bandcampro" is a sole operator or a persona sitting on top of a team. Trend Micro reports the sessions read as one-operator work. Take that as their read, not as a settled fact. Single-analyst assertion.
Second-source confirmation of any specific claim in the write-up. None at time of writing. Unconfirmed.

Why this one matters more than the botnet size suggests

The story a small dental-clinic botnet tells on its own is not much of a story. The story the six-minute end-to-end C2 migration tells is a different one: an operator who does not need to know the details of setting up VPS-hosted C2 infrastructure and Cloudflare tunneling can now stand up, iterate, and move that infrastructure by describing what they want in their first language. The floor on "operationally competent solo actor" is lower than it was six months ago. Defense-side implications:

Cloudflare-tunneled C2 to residential and small-business networks was already a hard signal to write clean detections for. It is not getting easier. If your egress visibility ends at "the tunnel came up," you are not seeing this activity.
PowerShell-generated infection chains aren't new. LLM-generated ones with a fresh coat of syntactic variation every run push signature and near-duplicate detections harder. Behavior-based coverage is where this lives.
OpenDental-class SMB verticals — small healthcare, small law, small municipal — remain the soft targets. A single-operator botnet of eight machines at a clinic is not the ceiling; it is the current, observed floor.

None of this is a Gemini-specific problem. Any capable LLM CLI, hosted or local, exposes the same primitives. Trend Micro's write-up happens to be about Gemini because that is the log corpus they got.

Sources

The Hacker News, 2026-07-20: Russian-Speaking Hacker Uses Google Gemini CLI to Control Botnet of Eight Dental Clinic PCs — coverage of the Trend Micro analysis.
Trend Micro researchers named in the report: Joseph C Chen, Philippe Lin, Lucas Silva, Vladimir Kropotov, Fyodor Yarochkin.

Confidence, consolidated: 200-session log analysis and per-task use — as-reported by Trend Micro; botnet size, target, OpenDental access — as-reported; Patriot Bait connection — as-asserted by Trend Micro; attribution beyond language and alias — unstated; Google-side response — unstated; second-source corroboration — none at time of writing.

Microsoft ships KB5121767 OOB for Dell IPF driver hold

Loop — Mon, 20 Jul 2026 11:15:00 GMT

Microsoft shipped KB5121767 on 2026-07-20 as an out-of-band update for Windows 11 25H2 and 24H2. It is the resolution for the Intel IPF driver incompatibility that had a limited set of Dell devices throwing a yellow exclamation in Device Manager next to the Intel Innovation Platform Framework Processor Participant driver, followed by unexpected shutdowns, poor performance, heat, and battery drain after the June 23 preview (KB5095093) landed. Per BleepingComputer, Dell surfaced the incompatibility in its own testing before broad rollout.

The mechanic hasn't shifted since Microsoft's original write-up. The June preview shipped a new Windows USB-C Connection Manager interface, and the Intel IPF Processor Participant driver on specific Dell models — the driver that mediates power and thermal on those boxes — did not tolerate it. Rather than back the interface out, Microsoft has patched the OS side to accommodate the existing IPF behavior. The release note phrases it carefully: KB5121767 "addresses an issue affecting a limited number of devices with an Intel Innovation Platform Framework (Intel IPF) driver that could cause changes in performance, power consumption, or system behavior." That is Microsoft-speak for the shutdowns and thermal misbehavior we covered five days ago.

How the update reaches you

Windows Autopatch with hotpatch enabled: automatic. Nothing to do.
Intune: available for expedited deployment. Push it if you have Dells sitting on the KB5101650 safeguard hold and you want them back on the July security update this week rather than next.
Everyone else: watch Windows Release Health for the safeguard hold to lift. Microsoft historically clears these within 24-48 hours of the fix shipping, which puts the affected Dells back on the normal Windows Update path without any operator intervention.

Two things worth noting about the sequence

KB5121767 is not a substitute for the July security update. It is the fix for the June 23 preview's regression, and the safeguard hold on KB5101650 exists because July's security cumulative would land on top of a broken thermal path. Once the OOB is in, affected Dells still need this month's security update — that's the one that carries July's three exploited/disclosed zero-days in AD FS, SharePoint, and BitLocker. The order is KB5121767, then KB5101650. Do not stop halfway.

The affected model list is still not public. Microsoft has not named the specific Dell SKUs in either the July 14 release-health note or in the OOB release note that shipped alongside KB5121767. The tell in your inventory remains what it was on July 15: a yellow-bang on Intel IPF Processor Participant in Device Manager. If you were hoping the OOB would arrive with a model filter attached, it did not, and any inventory sweep still has to walk Device Manager on candidate hardware. That is a real cost for anyone with a mixed Dell fleet, and it is worth flagging because it will still be true a week from now.

One specific thing to do first

On any Dell where you already uninstalled KB5095093 as a workaround — the documented path from last week's advisory — install KB5121767 before you re-offer the June preview or take this month's KB5101650. The OOB is what makes the preview's USB-C Connection Manager change safe on the affected IPF hardware. Reversing that order puts you back where you started on July 14.

ServiceNow AI Platform RCE exploited in wild: CVE-2026-6875

airgap — Mon, 20 Jul 2026 10:30:00 GMT

Exploitation reported. Threat-intelligence firm Defused told BleepingComputer on 2026-07-20 that attackers have begun exploiting CVE-2026-6875, a critical unauthenticated remote code execution vulnerability in the ServiceNow AI Platform. Confidence: as-reported by Defused via BleepingComputer. Independent second-source in-wild exploitation, at time of writing: none.

ServiceNow's own KB3137947 advisory, published a week earlier and mirrored in the NVD entry on 2026-07-13, described the flaw and stated the vendor was "not currently aware of exploitation against ServiceNow instances." That posture stood for seven days. It no longer does.

Timeline

2026-07-13 — ServiceNow publishes KB3137947; NVD ingests CVE-2026-6875 the same day. Vendor states no known exploitation. Confidence: primary source.
~2026-07-13 onward — ServiceNow deploys the security update to hosted instances; patches shipped to self-hosted customers and partners for on-prem application. Confidence: as-stated by vendor.
2026-07-20 — Defused reports observed exploitation attempts targeting ServiceNow AI Platform instances. Confidence: as-reported by Defused, single-source at time of writing.
CISA KEV status: not listed at time of writing. Watch the KEV catalog and our KEV tracker — if this lands there, the federal 21-day patch deadline clock starts.

What the advisory actually says

Per NVD's description, the flaw allows "an unauthenticated user, in certain circumstances, [to] execute code within the ServiceNow platform." The public description does not spell out the trigger conditions or the affected surface within the AI Platform. Confidence: as-published by ServiceNow via NVD. We are not filling in the mechanics from speculation, and we are not reproducing exploitation detail even if a PoC surfaces publicly.

CVSS 4.0 base score is 9.5, critical. The vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) reads: network reachable, no privileges, no user interaction, full impact on vulnerable and subsequent system confidentiality, integrity, and availability — but with attack complexity marked High. That last bit is the reason ServiceNow's initial "no exploitation observed" line held for a week: the flaw is not turn-key. Defused's reporting suggests that condition is now being met in the wild by at least one actor. Attribution: none stated.

What is unconfirmed

Which specific AI Platform builds and configurations are reachable. ServiceNow's KB is customer-gated and NVD's public description is short. Self-hosted operators should read KB3137947 directly.
Volume and targeting. Defused reports exploitation; no victim count, no vertical, no geography published at time of writing. Unstated.
Attribution. No named actor. Unattributed.
Whether hosted (Now/SaaS) instances are still exposed after ServiceNow's push. Vendor states hosted was updated. Self-hosted is where the current exposure sits. If your instance is hosted and you have not been told otherwise, treat as patched; if self-hosted, treat as at-risk until KB3137947 is applied.

What to do

Self-hosted or partner-hosted ServiceNow AI Platform: apply KB3137947 now. If you cannot patch this week, that is a choice, and one worth flagging to your risk owner today given the shift from "vendor says no known exploitation" to "single-source reports of active exploitation" inside a seven-day window.
Hosted (Now/SaaS): confirm your instance received the security update. ServiceNow states hosted was patched; verify against the KB.
Detection: the KB and NVD entry do not publish indicators. If your MDR or EDR vendor has ServiceNow-AI-Platform-specific detection notes, ask for them now, not after a triage call. This vulnerability class is exactly where "we thought hosted took care of it" gaps tend to live.
KEV watch: if this lands on CISA's KEV catalog in the next few days, the federal patch deadline is real for FCEB agencies and a strong signal for everyone else. We will update if that happens.

Context

Two recent items on this desk to place this against:

WordPress Core wp2shell (CVE-2026-60137) — same pattern this week: patch out, PoC out, in-wild exploitation reported within days.
Hugging Face autonomous-agent breach — a reminder that "AI Platform" surfaces are not exempt from the same code-execution primitives that have haunted every other enterprise SaaS surface. This one is a ServiceNow bug, not an AI-agent bug — but the label on the product is the same word, and it will be read that way in enterprise headlines this week.

Sources

BleepingComputer, 2026-07-20: Critical ServiceNow code execution flaw now exploited in attacks — the Defused disclosure.
NVD: CVE-2026-6875 — published 2026-07-13, CVSS 4.0 base 9.5.
ServiceNow KB3137947: Vendor advisory (customer-gated).
CISA: Known Exploited Vulnerabilities Catalog.

Confidence, consolidated: CVE and patch — confirmed by vendor and NVD; in-wild exploitation — as-reported by Defused, single-source at time of writing; victim count, targeting, attribution — unstated; KEV listing — not present as of 2026-07-20.

Hugging Face confirms breach by autonomous AI agent

airgap — Mon, 20 Jul 2026 09:00:00 GMT

Confirmed: Hugging Face has disclosed unauthorized access to "a limited set of internal datasets and to several credentials used by our services." The company detected the intrusion "earlier last week," disclosed it publicly on July 20, and attributes the activity to an autonomous agent framework rather than a human operator. Confidence: confirmed by Hugging Face.

The attacker was, in Hugging Face's own words, "an autonomous agent framework performing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services." Confidence on the AI-agent-as-attacker characterization: as-stated by Hugging Face — the model or framework behind it is unnamed and unattributed. Hugging Face notes only that the operator was "bound by no usage policy."

What Hugging Face says was in scope

Internal datasets. Access described as "limited." No count, no volume, no classification breakdown published.
Service credentials. "Cloud and cluster credentials" per the disclosure; used to move laterally across internal clusters after initial landing.
Two code execution paths were exploited: the remote-code dataset loader, and template injection in dataset configuration. Confidence: as-stated. No PoC published, and we are not reproducing one here.
Attacker escalation window: "over a weekend," per Hugging Face's writeup.

What Hugging Face says was NOT touched

Public, user-facing models. Confidence: as-stated by Hugging Face ("no evidence").
Public datasets. As-stated, no evidence.
Hugging Face Spaces. As-stated, no evidence.
The Hugging Face software supply chain itself. As-stated, no evidence.

What is unconfirmed

Private user repositories. Hugging Face's statement addresses public models, datasets, and Spaces. It does not explicitly speak to private repos. Unstated.
Individual user API tokens. Hugging Face is telling users to "rotate access tokens and review account activity." That guidance is consistent with either "we know some are compromised" or "we can't rule it out." Treat as precautionary, scope unstated.
Which cloud tenants and clusters were reached. No specific AWS, GCP, or Azure account names disclosed. Unstated.
Attribution beyond "an autonomous agent framework." No nation-state, no crew, no LLM vendor named. Unattributed.

Remediation Hugging Face lists

Root cause on the two code-execution paths addressed.
Attacker foothold removed; affected nodes rebuilt.
Credentials and tokens on affected services rotated.
Stricter admission controls deployed on the internal cluster surface.
24/7 detection/alerting tuned for the class of activity — Hugging Face frames this as "within minutes."

User-side, one thing: rotate your Hugging Face access token now and review recent account activity, even if you do not think you had anything sensitive stored there. That is the guidance Hugging Face is publishing, and it is consistent with the way this kind of credential-collection intrusion generally propagates.

The operational detail worth pinning

One line in Hugging Face's writeup is worth surfacing separately. To do forensics on the intrusion, Hugging Face reports it fell back to Z.ai's GLM 5.2 — a Chinese open-weight model — because Western commercial models' safety guardrails refused prompts containing the attacker's real commands and C2 artifacts. Confidence: as-stated.

Analysis: that is a real gap. The vendors whose models are the industry default for chat and code assist are, by policy, refusing to help defenders read attacker artifacts that contain the exact strings the safety filters are tuned against. Hugging Face's own recommendation is straight: "have a capable model you can run on your own infrastructure vetted and ready." If you are running an IR function and you have not tested that your commercial AI assistant will actually help you read a captured payload, that is the test to run this week. If it will not, you need a local alternative queued up before the next incident, not during one.

Context — where this fits with what we've been covering

Two threads are converging on Hugging Face's disclosure.

AI-model-repository as supply-chain surface. The reason Hugging Face's public models, datasets, and Spaces getting a clean bill of health matters is that a compromise of any of those would be a supply-chain event on the scale of a bad npm publish — worse, because the artifacts are opaque. See our coverage of ViteVenom's seven-package npm intrusion and GoldenEyeDog's 27 stolen EV code-signing certificates for the current baseline of supply-chain pressure on developer artifacts.
Autonomous agents as attackers, not just defenders. Hugging Face's framing — a swarm of short-lived sandboxes, self-migrating C2, unbound by any policy — is the first named incident we have seen at this scale where the attacker is explicitly characterized as an agent framework rather than a human operator behind a toolset. Treat the characterization as reported, not proven, until an IR firm publishes independent analysis. If it holds, the volume-and-persistence profile of intrusions in the near term looks different from what most SOCs are staffed for.

Sources

Hugging Face disclosure via The Hacker News: World's Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent — July 20, 2026.

Confidence, consolidated: intrusion confirmed by Hugging Face; AI-agent characterization as-stated, unverified; volume and specific dataset scope unstated; private-repo and individual-token exposure unstated — rotate anyway.

SleeperGem loader hides in dormant RubyGems, skips CI/CD

Loop — Mon, 20 Jul 2026 08:00:00 GMT

Three RubyGems packages — git_credential_manager, Dendreo, and fastlane-plugin-run_tests_firebase_testlab — have been pulled from the registry after StepSecurity attributed them to a supply-chain campaign it is calling SleeperGem. Per The Hacker News, the loader fetches its second stage from an attacker-controlled Forgejo instance, fingerprints for CI/CD environment variables, and only completes on what looks like a developer's laptop. Confidence on the naming, the package list, and the mechanic: as reported by StepSecurity via The Hacker News, with additional attribution notes from Charlie Eriksen at Aikido Security.

The lead is the reuse pattern. Dendreo last shipped a legitimate release in October 2020; fastlane-plugin-run_tests_firebase_testlab last saw honest work in March 2019. Both maintainer accounts had gone quiet for years — no releases, no yanks, no visible activity — which is exactly the state that makes them useful. A dormant account is a warm namespace with historical trust and no watchers. Whoever holds the credential can publish once, and the download counters and dependency graphs of every downstream project quietly light up before anyone notices the maintainer never posted about a new release. git_credential_manager is the newer piece — first published July 18, 2026 under a separately compromised account (pinkroom) and named to sit next to Microsoft's real Git Credential Manager in a search result.

The CI check is the interesting part

StepSecurity's writeup names roughly thirty environment variables the loader inspects — the standard set for GitHub Actions, GitLab, CircleCI, Travis, Jenkins, and Vercel. If any of them is present, the loader exits without dropping stage two. That is not a novel technique but it is a deliberate one: it means the SBOM tools, the automated malware sandboxes that live inside CI pipelines, and the every-PR install-and-audit runs are the last places you will see this fire. It only detonates where nobody is looking — on a developer's laptop, a bare workstation, an ops runner that isn't wearing any of the badges the loader knows to check for.

Stage two comes down from git.disroot[.]org/git-ecosystem, a Forgejo instance the operators control. From there the loader drops a native daemon under ~/.local/share/gcm/ and installs persistence three ways: a cron entry, a systemd user service, and — if the initial gem was installed under sudo — a setuid root shell at /usr/local/sbin/ping6. The ping6 path is a legacy binary name that most administrators would not stop to inspect twice; that is the point.

The git_credential_manager gem is also declared as a dependency of four additional packages in the same set: slackHtmlToMarkdown, seo_optimizer, array_fast_methods, and the two dormant gems above. A team that installed any of those between July 18 and the takedown pulled the loader whether they went looking for a credential helper or not.

What to actually do

If a developer laptop or non-CI runner installed any of those packages during that window, treat it as compromised — not paperwork-compromised, actually compromised. StepSecurity's specific guidance: remove the ~/.local/share/gcm/ daemon, tear out the cron and systemd-user persistence, check for the setuid ping6, and rotate every credential that machine had access to (git tokens first, cloud CLI creds second, browser-stored secrets third). Assume the loader had time to touch anything it could read.

The broader lesson is the one that keeps applying to package registries: an account that stops posting is not an account that stops mattering. The dormant-account attack path is cheap for the operator and expensive for the ecosystem, and RubyGems is not structurally different from npm or PyPI on this — the ViteVenom cluster earlier this week leaned on fresh namespaces, but the AsyncAPI namespace hit rode the same silent-maintainer shape. Registries that surface "last publisher activity" prominently, or require step-up reverification on a re-awakened account, close this specific door; ones that don't leave it open.

For individual Ruby developers, the shorter version: if you are about to gem install something you have not installed before, look at when its account last published and how far apart those publishes are. A three-year gap followed by a fresh release this week is a signal, not a coincidence.

wp2shell: first signs of exploitation; CVE-2026-60137 lands

airgap — Mon, 20 Jul 2026 01:15:00 GMT

Two updates since the July 18 wp2shell brief, both flagged as pending in that filing, both now landed.

Update 1 — in-the-wild exploitation. Security firm watchTowr, quoted in BleepingComputer's July 18 coverage, says the crew is "beginning to see the first signs of in-the-wild exploitation." Confidence: first-signs, single named vendor, not yet corroborated by a second vendor telemetry source. Not "widespread exploitation confirmed." Not "campaign attributed." First signs. Treat accordingly.

Update 2 — companion CVE ID. The persistent-companion tracking has resolved to CVE-2026-60137, an SQL injection in the author__not_in parameter of WP_Query. Verified independently against NVD: CVSS 5.9 (medium), published July 17. Confidence: confirmed and independently verified.

What CVE-2026-60137 actually is

Per NVD, the flaw is that WP_Query "does not properly sanitise the author__not_in parameter," which "could allow SQL Injection when a plugin or theme passes untrusted input to the parameter." Two structural notes:

This is not a second RCE. SQLi at CVSS 5.9 is not the same primitive as the CVE-2026-63030 unauthenticated RCE and does not chain to code execution on its own.
It is plugin/theme-mediated. Untrusted input has to reach author__not_in. Sites running only unpatched WordPress Core with no plugin or theme that pipes user input into that parameter are not directly in range for this one.

Per BleepingComputer, CVE-2026-60137 also touches the 6.8 branch, which the RCE-only wp2shell does not. That is the one meaningful reason to care about 60137 as more than a footnote: it extends the patched-version floor backwards into 6.8.x, which the July 18 brief did not.

Exact affected and patched versions

Both CVEs, consolidated from BleepingComputer's July 18 write-up and the wordpress.org 7.0.2 release note:

CVE-2026-63030 (RCE, CVSS 9.8, critical). In range: WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1. Patched: 6.9.5 or 7.0.2.
CVE-2026-60137 (SQLi, CVSS 5.9, medium). In range: WordPress 6.8.0–6.8.5, 6.9.0–6.9.4, and 7.0.0–7.0.1. Patched: 6.8.6, 6.9.5, or 7.0.2.

Attribution: both flaws reported by Adam Kues of Searchlight Cyber.

What changed for defenders

Nothing about the July 18 patch call has softened. In order of priority:

RCE first, still. If you have not yet updated to 6.9.5 or 7.0.2 on any 6.9.x or 7.0.x public-facing instance, that is the compromise-scale action item. The first-signs IITW report shortens the window; it does not change the response.
6.8.x is now a live patch call too. Update 6.8.x instances to 6.8.6 if they run any plugin or theme that could pass user input into author__not_in. Without a definitive audit of plugin/theme code, treat this as the working assumption for any 6.8.x instance with a non-trivial plugin surface.
KEV status. Neither CVE has been added to the CISA Known Exploited Vulnerabilities catalog at the time of this filing. With a named vendor reporting first-signs exploitation and a public PoC on the RCE, a KEV entry on CVE-2026-63030 would compress the federal-civilian patch timeline to days under BOD 26-04. Watch for it.

Confidence summary

CVE-2026-63030 RCE, patched versions, PoC public — confirmed and independently verified.
CVE-2026-60137 SQLi, patched versions, medium severity — confirmed and independently verified against NVD.
First-signs in-the-wild exploitation of CVE-2026-63030 — as-reported by watchTowr, single named vendor, not yet corroborated.
Widespread/mass exploitation — unconfirmed. Treat accordingly.
KEV addition — none at time of filing.

Related CVE stubs on this site: CVE-2026-63030 and CVE-2026-60137. Vendor hub: WordPress.

Sources

BleepingComputer: WordPress Core "wp2shell" RCE flaws get public exploits, patch now — July 18, 2026.
NVD: CVE-2026-60137 and CVE-2026-63030.
WordPress: WordPress 7.0.2 release announcement.

nginx patches heap overflow in worker (CVE-2026-42533)

Dave "Kilobaud" Ferris — Sun, 19 Jul 2026 22:05:00 GMT

F5 shipped nginx 1.30.4 (stable) and 1.31.3 (mainline) on July 15 to fix CVE-2026-42533, a heap buffer overflow in the worker process. NGINX Plus 37.0.3.1 carries the same fix. NVD scores it 8.1 (high); The Hacker News called it critical, and the delta between those two labels is worth understanding before you patch.

The bug lives in the interaction between the map directive and the ordering of variables inside a string expression — specifically, when the expression references the map's regex capture variables before referencing the map output variable. A comparable outcome is reachable, per the NVD write-up, when a non-cacheable variable is used in a string expression under certain conditions. Given that shape of configuration, a crafted request against the exposed listener can overflow a heap buffer in the worker, forcing a restart, and — on systems where address-space layout randomization is disabled or can be bypassed — allow code execution. Control plane is untouched. This is a data-plane bug only.

That configuration shape is why the score sits at 8.1 rather than 9.8. Unauthenticated remote reach, yes. Trust boundary crossed, yes. But the attacker doesn't pick the target; the target's own config has to have already assembled the vulnerable pattern. Plenty of real deployments do — regex-driven map blocks are a common way to route by host or path in reverse-proxy setups — and CVSS's calculator penalizes the "attack complexity" a step for it. Practically, that means you should still be treating this as a same-week patch, not a "critical, drop everything" one.

The wider reading is duller and older. nginx is not a fresh codebase. It sits in front of a large fraction of the busiest sites on the internet, has been audited by every party with a reason to audit it, and has been the object of a decade of continuous fuzzing campaigns. A heap overflow reachable through crafted HTTP in 2026 is not shocking; it's a reminder that the underlying language is still C, the memory model is still manual, and every regex-heavy configuration surface remains a place where a subtle sequencing bug can turn into an out-of-bounds write. The same mistake, different decade.

If you can't upgrade tonight, audit your map blocks: any string expression that touches a regex capture variable before the map's output variable is the pattern to worry about, along with any use of non-cacheable variables inside those expressions. Restructuring the config to drop that ordering — or dropping the specific map block entirely if the routing logic can move elsewhere — closes the window until the patched build lands. End-of-technical-support branches are not covered by the advisory, so if you're still running one of those in front of production, this CVE is the second reason today to move.

CERT-UA: UAC-0145 (Sandworm) runs ClickFix on Ukraine

Marisol "Fuse" Delgado — Sun, 19 Jul 2026 18:00:00 GMT

Here's what changed today: CERT-UA published alert 6318437 attributing a June–July 2026 ClickFix campaign against Ukrainian users to UAC-0145, which CERT-UA and The Hacker News' writeup both describe as a sub-cluster within Sandworm — the GRU-affiliated unit better known outside CERT-UA's own catalogue as APT44 / Voodoo Bear. Confidence: as-reported by CERT-UA, which named ten or more compromised websites as the delivery surface.

I'll be honest — the interesting part isn't that Sandworm is running ClickFix. It's that ClickFix is now the shared plumbing under enough distinct clusters that the tactic itself is what you should be defending against, not any one family's IOCs.

What CERT-UA says the operation looks like

At the class level: compromised legitimate Ukrainian sites serve a fake CAPTCHA that talks a visitor into pasting a command into a Run dialog or terminal. If they run it, the box is theirs. That is the entire ClickFix pattern — we've written about it here for TELEPUZ (April onward, likely MaaS), for ClickLock on macOS last week, and it's the same delivery envelope Microsoft flagged in the ACR Stealer surge yesterday.

Two operational specifics from the CERT-UA writeup are worth pinning:

The lure pages are served through SMARTAXE, described as a bespoke tool that rewrites the CAPTCHA page per visitor, and routed through Cloaking.House for traffic filtering — so what a researcher sees on the compromised page is not what the target sees.
Domain names for the second-stage infrastructure are pulled via EtherHiding, i.e. read out of Ethereum smart contracts at run time. The same technique appeared in the ACR Stealer campaign Microsoft attributed to Storm-0408 earlier this week. Taking down a domain does not take down the pointer.

The payload set CERT-UA names

Six families, split by role:

GHETTOVIBE — a VBS file dropped into the user's Startup autorun directory for persistence.
SCOUTCURL — a PowerShell script that performs basic host reconnaissance.
FLUIDLEECH — a loader masqueraded as an antivirus removal utility.
LOADLOOP — a second loader.
FREAKYPOLL — a Python backdoor.
COWARDDUCK — a full-featured Android backdoor, delivered as APK via messaging apps, harvesting contacts, real-time geolocation, and files matching a targeted extension list — .conf, .json, .ovpn, .txt, .doc(x), .xls(x), .pptx, .zip, .rar. Exfil rides Dropbox's API; some tasking is fetched from external servers or benign-looking sites, steamcommunity[.]com explicitly cited.

The .ovpn and .conf inclusion in COWARDDUCK's target list tells you what this cluster is actually after: VPN config files that let the operator step onto Ukrainian networks with legitimate credentials instead of exploits.

What to actually do

There's no fresh CVE to chase here, which is the whole point — ClickFix is a UX-abuse tactic and you close it with policy, not patches. In priority order:

Block Win+R for standard users on Windows fleets, and log every use where you can't. GPO: User Configuration → Administrative Templates → Start Menu and Taskbar → Remove Run menu from Start Menu. Yes, users will complain. That is a fine trade for closing the single most common ClickFix landing surface. If you can't remove it, AppLocker / WDAC to deny powershell.exe, mshta.exe, wscript.exe, and cscript.exe invocation from user-writeable paths is the next line.
Kill clipboard-launched code paths in your browsers. Enterprise policy to block clipboard read access on unknown origins in Chrome/Edge (DefaultClipboardSetting = 2, ClipboardAllowedForUrls for the tiny set you actually need) removes the "copy this and paste it" step the lure depends on. Firefox lands the same result via dom.event.clipboardevents.enabled scoped correctly.
Cut the persistence path CERT-UA named. Files landing in a user's Startup folder should be alerting, not autorunning. If your EDR isn't already flagging VBS/JS in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\, add the rule today.
Treat VPN config files as secrets on the endpoint. COWARDDUCK's shopping list — .ovpn, .conf, saved credential files — is now the shopping list for at least three unrelated Android stealers we've covered this month. DLP on those extensions leaving mobile devices, and rotate any config file that has ever been stored unencrypted on a phone.
Alert on outbound to steamcommunity[.]com from server-class hosts and workstations without a gaming population. It's a legitimate service used as C2 dead-drop by more than one cluster now; benign on a laptop, load-bearing on a domain controller.

If you have Sandworm in your threat model already — utilities, telecom, government, defense-adjacent supply chain — priority-one there is (1) and (2), fleet-wide, this week. Everyone else: still (1) and (2), but you have until next patch cycle, not tonight.

For the indicator lists — SMARTAXE staging URLs, EtherHiding contract addresses, COWARDDUCK APK hashes — go to CERT-UA's alert directly. We're not going to mirror the IOC block here; the primary source updates as the operation evolves and ours would go stale by tomorrow.

Kaspersky details HelloNet abuse of ViPNet updater

Dave "Kilobaud" Ferris — Sun, 19 Jul 2026 16:30:00 GMT

Kaspersky's Securelist team published research on Sunday describing a campaign it calls HelloNet — an intrusion set that has been abusing the update mechanism of ViPNet, the InfoTeCS-made Russian VPN and secure-networking suite certified for government and regulated environments, to gain persistence on Russian public-sector and heavy-industry targets. BleepingComputer covered it the same day. The campaign has been running since at least May 2026, according to Kaspersky, and has touched organizations in government, energy, transport, education, logistics, and industry.

Analysis, not incident reporting. What follows is a reading of Kaspersky's published research and its context, not a claim about a specific new intrusion. Kaspersky has not named the affected organizations, and the operator behind the activity is not on the record.

The mechanics, at the level worth reporting

The technique is old-fashioned in a way worth pausing on. A malicious wtsapi32.dll is dropped into C:\Program Files (x86)\InfoTeCS\VIPNet Update System\, the install directory of the ViPNet update client. Windows' standard DLL search order does the rest — when itcsrvup64.exe, a signed InfoTeCS binary that launches at operating-system startup, resolves its dependencies, it picks up the attacker's file rather than the system copy. The loader Kaspersky names HelloInjector then walks its payload into svchost.exe, and from that trusted host process the rest of the tool chain unpacks: HelloProxy as a hidden proxy and secondary loader, HelloExecutor as a shell-command runner, HelloBackdoor as a Rust-written command-and-control client listening on port 443, and HelloCleaner, whose whole job is the polite one of removing the ViPNet log lines that would otherwise record any of this happening.

None of that is novel. Sideloading a bad DLL out of a signed binary's install directory is a technique that has been in every serious intrusion set's toolbox for a decade. It keeps working because it does not need to be novel. It exploits a trust decision the defender already made — that whatever ships out of the signed vendor's install directory is part of the same signed intent — and that decision is not usually re-examined once made.

What Kaspersky is willing to say about who is behind it

Not much, and the restraint is the interesting part. The Securelist writeup assigns "low confidence" attribution to an unknown Chinese-speaking APT, and it does so on the basis of exactly two artifacts: an unused HTTP header string referencing news.sina.com, a Chinese-language news portal, and the fact that some of the Rust dependencies the operators pulled at build time came from the University of Science and Technology of China's public package mirror. Kaspersky adds that "the probability of using 'false flags' implanted by attackers to complicate the attribution process cannot be excluded."

Two data points, one of which is a build-artifact anyone with a Rust toolchain and a slow Western mirror might reasonably introduce, and the other of which is a string the malware does not use for anything, are not the load-bearing evidence a firm nation-state call needs. Kaspersky knows that and its language reflects it. The story here is not "China hit Russia"; the story is that a well-organized operator has been sitting inside the update path of certified Russian security software for two months and left just enough breadcrumbs to make readers reach for one attribution flag rather than another. Downstream coverage that sands "low-confidence Chinese-speaking APT" down to "China" for a cleaner headline is doing the operator a small favor.

The trust chain, and where it has broken before

The nearest historical fit is not SolarWinds, which is where the reflex reach goes. The nearer fit is the NotPetya distribution through the MeDoc updater in June 2017 — a Ukrainian tax-accounting product whose update path was subverted to seed a wiper across the country's public and private sectors. That was a domestically-certified, domain-specific software product's update mechanism being turned into a delivery vehicle for state-scale disruption. HelloNet is not NotPetya — it is quiet, targeted, and looks like intelligence collection rather than sabotage — but the trust decision under attack is the same one. The update client of a locally-certified security product is a durable, low-noise foothold precisely because nobody in the environment thinks of it as a place attackers would live.

The same mistake, different decade. The direction is reversed — Ukrainian software as the vector into Ukrainian orgs in 2017, Russian software as the vector into Russian orgs in 2026 — but the class of decision under attack has not moved, and the cost of that decision is roughly what it was.

What defenders elsewhere should take from it

The specific product is a Russian one, and the geopolitical framing will pull most Western coverage toward the "hackers hit Russian government" angle. The generalizable observation is drier and more useful:

Signed update clients that resolve DLLs out of their own install directory are sideloading candidates by construction. InfoTeCS's itcsrvup64.exe has structural cousins everywhere — endpoint agents, backup clients, remote-management tooling, print-server utilities, niche VPN clients. The subset that launch at startup, run as SYSTEM, and resolve dependencies out of a directory a lower-privileged local user could ever write to under any misconfiguration are the ones worth an inventory pass.
Kaspersky's detection posture is EDR-ready and generalizable. Watch for process injection into svchost.exe originating from update-client processes that have no legitimate reason to inject into system services. That signature holds whether the calling binary is ViPNet's updater, a backup agent, or a printer status app — the underlying rule is that a signed update process should not be writing memory into svchost. Kaspersky lists two C2 IP addresses (5.39.253[.]206, 176.32.34[.]135) and network activity on ports 5003, 5060, and 443 among its published indicators; the full IoC set including twelve file hashes is in the Securelist writeup.
Attribution ambiguity is not a defect of the report; it is the report. Kaspersky was careful with its language, and downstream coverage should be too. A false-flag operator counts on the sharpening step that happens between the researcher's post and the headline.

The HelloNet campaign is not a novel technique in a novel place. It is a durable technique in a very specific place — the update path of a locally-trusted security product — that most defenders would not have thought to instrument. That is the reason to read the writeup carefully, not the reason to reach for a country name.

Sources

SonicWall SMA1000: Volexity names UTA0533, IoC list out

Marisol "Fuse" Delgado — Sun, 19 Jul 2026 15:00:00 GMT

Volexity's writeup on Friday put a name to the actor who was inside SonicWall SMA 1000 appliances before SonicWall's July 14 advisory went out: UTA0533, a previously undocumented cluster. Earliest observed compromise was June 22, three weeks before the CVEs went public. That's the honest timeline — three weeks of quiet root access on internet-facing boxes.

That matters because until now the pre-disclosure detection was Rapid7's MDR call and SonicWall PSIRT's confirmation. Neither published a toolkit. Volexity's Sean Koessel and Steven Adair did, and if you patched the unauthenticated SSRF and the command-injection chain and haven't hunted the appliance since, this is the hunt list you didn't have on Wednesday.

What UTA0533 dropped

Four named artifacts. Two are custom, two are open-source repurposed. Names, paths, sizes as Volexity published them:

ROOTRUN — /usr/bin/xzfind, 13.1 KB. A small setuid ELF that gives the attacker root via setuid() on demand. Once dropped, they don't need to re-exploit the chain to elevate — they just call the binary.
KNUCKLEBALL — /usr/lib/python3.11/site-packages/deploy_new.py, 79.6 KB. Python script that injects two embedded JARs into legitimate SonicWall Java processes at runtime. The script is the delivery vehicle; persistence lives in the JARs.
Suo5 — agent_wp8.jar, 33.7 KB. Open-source HTTP forwarding proxy. Reachable at /workplace/error.jsp on the appliance's external interface. This is the tunnel: attacker traffic in, internal network out.
ORANGETAIL — agent_wp9.jar, 21.3 KB. Custom Java web shell modeled on Behinder. Reachable at /workplace/dialogs/errorDialog.jsp on the external interface. This is the command shell.

The two JSP paths are the load-bearing detection. Both look like legitimate SonicWall paths, both are reachable pre-auth from the internet, and neither should be returning 200 in your access logs. If they are, and your appliance was on a vulnerable build before July 14 (12.4.3-03245, -03387, or -03434, or 12.5.0-02283, -02624, or -02800), assume UTA0533 or someone running the same tooling was on it.

The other appliance

Volexity worked two compromised boxes in the same engagement. On the second one, on top of the NGINX Unit config modification that Rapid7 and SonicWall already flagged, the attackers dropped /var/tmp/lib.sh and used it to run tcpdump — capturing unencrypted LDAP credentials off the wire. If your SMA1000 pointed at an on-prem AD that still speaks plain LDAP anywhere, rotate those service accounts before you rotate anything else. The credentials on the box are one problem; the credentials that walked past the box on the wire are another.

Priority call

If you patched to 12.4.3-03453 or 12.5.0-02835 by the CISA BOD 26-04 deadline of July 17 and stopped there, the honest question this weekend is whether ROOTRUN or ORANGETAIL is still sitting on the appliance. The order:

Check for the four artifact paths above — /usr/bin/xzfind, deploy_new.py, and the two JSP paths in access logs. Any hit is compromise, not exposure. Re-image, don't patch over it. Rapid7's IoC list from Wednesday covers the log signatures; Volexity's covers the artifacts on disk. Use both.
Pull pcap or session history if you have it and look for LDAP traffic sourced from the appliance interface. If lib.sh ran on your box, LDAP creds are already out.
Rotate what actually crossed the box: LDAP service accounts, admin accounts on the appliance, MFA seeds for anyone whose token was issued through the SMA1000.

Volexity noted "available evidence suggests the threat actor was less successful moving laterally or gaining access to other systems." That's not a green light — that's a note that they got root on the appliance and stalled at the perimeter. The weekend job is to keep it that way.

LegacyHive: PoC drops for unpatched Windows LPE zero-day

Marisol "Fuse" Delgado — Sun, 19 Jul 2026 06:15:00 GMT

A researcher publishing as "Nightmare Eclipse" dropped a proof-of-concept on GitHub last week for a Windows local privilege escalation they're calling LegacyHive. There's no CVE ID yet, there's no patch, and Microsoft's on-record response is that it "is aware of the reported vulnerability and is actively investigating the validity and potential applicability of these claims." That is the position of a vendor that has not yet decided whether it's going to ship a fix, and the honest read is that defenders should assume nothing on the patch clock this week.

What the bug is

The vulnerability lives in the Windows User Profile Service and abuses the per-user classes registry hive — usrclass.dat, the file that backs HKCU\Software\Classes. Analyst Will Dormann summarized the mechanism plainly in the BleepingComputer writeup: "successful exploitation would allow non-admin users to modify the classes registry hive and gain automatic code execution when the admin account logs into a compromised system."

That last clause is the whole game. This isn't a straight-line escalation where the attacker's process ends up running as SYSTEM the moment they run the exploit. It's an ambush: the standard user rigs the hive, waits for an administrator to sign in on the same box, and then the admin's own logon walks into code execution in the admin session's context. On a workstation used only by one non-admin user that's low value — but on a shared machine, an RDP jump box, a shared VDI image, or any endpoint where a helpdesk or endpoint-management account regularly logs on interactively, that pattern is exactly how a standard-user foothold becomes tenant admin overnight.

Nightmare Eclipse published the PoC with the mechanics deliberately clipped. Per their own note: "The PoC was stripped down as an attempt to prevent public exploitation, the original PoC did not require additional user credential." Read straight, the public GitHub version needs standard-user creds on the target to fire; the internal version they held back did not. That's a limited restraint — everyone with valid domain creds already meets the public-PoC bar, and someone with real motivation is going to reconstruct what was cut.

What's not confirmed

No CVE ID has been assigned. MSRC has not published an advisory, and NVD has nothing to point at.
No confirmed exploitation in the wild. BleepingComputer's writeup doesn't cite any active-exploitation telemetry, and CISA has not added anything matching this pattern to KEV.
Affected-version detail is thin. The disclosure describes "up-to-date Windows systems" without enumerating client vs. server SKUs or build numbers. Until Microsoft ships an advisory, treat every currently supported Windows build as in scope for planning purposes.

Anything past that in the next few days that isn't traceable to MSRC, CISA, or the researcher's own repo is speculation. Do not build detection or a comms narrative around it.

Priority order

There's no patch to schedule. This one is a detection-and-blast-radius conversation, not a patch conversation.

Pull Kevin Beaumont's Defender for Endpoint detection queries and get them running. Beaumont published queries specifically for this technique — hunt for standard-user processes writing to usrclass.dat in ways that don't match normal COM/shell association changes, and for admin logons on hosts where the touched hive belongs to a non-admin user. If you don't run Defender for Endpoint, port the intent to whatever EDR you do run: file writes to \Users\<non-admin>\AppData\Local\Microsoft\Windows\UsrClass.dat from processes that shouldn't be touching it, followed by an admin-session logon on the same host, is the signature.
Cut interactive admin logons on shared endpoints. If a helpdesk account, a domain admin, or an endpoint-management account routinely logs in interactively on machines where standard users also sign in — RDP jump boxes, kiosks, VDI images, shared engineer workstations — that is the exact detonation surface this PoC needs. Rotate to remote-management tooling that doesn't drop an interactive session on the endpoint, or restrict which endpoints those admin accounts are allowed to touch.
Assume Tier-0 hygiene is load-bearing until the patch lands. LAPS on local admin, no domain admin sessions on user endpoints, no shared service accounts running with more rights than they need. None of that is new advice — LegacyHive is the reminder that the boring version of privileged-access management is what actually catches this class of bug when the vendor timeline slips.
Track MSRC, not press coverage. The MSRC update guide is the source of record for when this gets a CVE and a build number. Everything else is downstream. When a CVE ID appears, come back and re-check whether your standing detection is looking at the right artifact — the fix may end up moving where the vulnerable code lives.

The honest timeline

2026-07-17 — Nightmare Eclipse publishes the PoC on GitHub and BleepingComputer reports it. Will Dormann and Kevin Beaumont provide analysis and detection guidance. Microsoft issues its "aware and investigating" statement.
2026-07-19 — No CVE assigned, no patch, no in-wild exploitation confirmed. Public PoC still requires standard-user credentials on the target.
Whenever Microsoft decides — CVE, advisory, build number. Not this Patch Tuesday — the July drop already shipped last week.

An unpatched LPE with a public, credentialed PoC is not a five-alarm fire. It's a working reminder that the shared-endpoint, interactive-admin-logon pattern is a standing tax on your privilege model, and every zero-day of this shape is going to keep charging it until you fix the pattern rather than the individual bug.

Metasploit adds HTTP-to-SMB NTLM relay, RISC-V payloads

Marisol "Fuse" Delgado — Sun, 19 Jul 2026 03:20:00 GMT

Rapid7's Metasploit wrap-up landed on 2026-07-17 with one module worth reading before the rest of the drop: server/relay/http_to_smb — a Windows HTTP-to-SMB relay that takes incoming NTLM HTTP authentication and relays it to SMB targets to open a session against them. Contributed by jheysel-r7. That's the whole news.

What to actually do

NTLM relay from HTTP to SMB is a documented technique with public tooling behind it already; what ships this week is a first-class Metasploit module for it.

Priority order for tonight:

Require and enforce SMB signing on every server, not just domain controllers. Group Policy Microsoft network server: Digitally sign communications (always) set to Enabled, and the client-side equivalent set the same. If you have to leave one exception, write it down and put a review date on it.
Turn off NTLM where you can, and where you can't, restrict where NTLM traffic is accepted with the Restrict NTLM policies. Kerberos-only inside the estate is the destination; NTLM disabled outbound at the edge is the minimum.
Inventory what still triggers NTLM over HTTP. Intranet portals with Windows Integrated Authentication, print servers, MFP scan-to-share, WSUS, WebDAV endpoints, IIS sites nobody remembers standing up. Wherever a browser or an HTTP client can be walked into an NTLM prompt is the ingress the module's server side consumes.
Confirm Extended Protection for Authentication (EPA) is on and channel binding is actually configured on inbound HTTP surfaces where NTLM is accepted — not just that the checkbox was ticked in a build spec somewhere.

None of that is a Metasploit reaction. It is the standing SMB-hardening list Microsoft has published for years. The module is the reason to open it back up tonight.

The rest of the drop

Two other pieces of the wrap-up matter for infrastructure planning, not for tonight's on-call.

RISC-V shell payloads. The framework now carries 32-bit and 64-bit RISC-V shell payloads, both staged and stageless, plus four Byte XORi Encoder variants (contributor: bcoles) for the same architectures. Per Rapid7, coverage is for both target widths staged and stageless. For any fleet that already includes RISC-V hardware — embedded appliances, IoT gateways, dev-board deployments — Metasploit's shell-payload coverage now extends to those hosts.

Linux Fetch Multi and 421 new payloads. Fetch payloads are the small stager-fetching primitives that pull the real payload down over FTP, HTTP, HTTPS, or TFTP after initial access. The Multi variant now identifies architecture on the fly at runtime, so a single payload does not need to be pre-picked for x86-64 versus ARM64 versus anything else. The 421 new Linux/Windows fetch-style payloads across those four protocols expand the variant space defenders using byte-signature detection have to enumerate. Detect on the behaviour (unusual outbound FTP, TFTP to internet destinations, HTTP GETs of small binary blobs from unfamiliar hosts), not the byte pattern.

Two smaller enhancements sit alongside those: CertificateTrace now surfaces the TLS peer certificate on HTTPS connections in framework logs, and the Windows service PE template moved to an injected-segment methodology. Neither changes anyone's exposure. Both change the outputs and generated binaries the framework produces. Re-tune detection rules that were keyed on the prior artefacts when there is a slow week.

The priority call

SMB signing first. RISC-V asset inventory second — put a review date on the ticket rather than leave it open indefinitely. Retune EDR fetch-behaviour rules third, when there is time. The relay module is the reason to check the first item tonight rather than defer it again.

Sources

Rapid7. Metasploit Wrap Up: An HTTP to SMB relay plus Payload Improvements, 2026-07-17.
Metasploit Framework. Module documentation for server/relay/http_to_smb.
Microsoft. Overview of Server Message Block signing — configuration reference.

Microsoft ties ACR Stealer surge to WebDAV, blockchain C2

Loop — Sat, 18 Jul 2026 22:20:00 GMT

Microsoft's Threat Intelligence team on 2026-07-16 published a follow-up writeup describing a surge in ACR Stealer activity against enterprise customers between late April and mid-June 2026 — the same infostealer, tracked previously as Amatera and AcridRain, that Microsoft's Defender Experts team detailed on 2026-07-17. The delivery lure is the same paste-and-run ClickFix dialog. The plumbing under it is what changed in this window.

The delivery chain

Per BleepingComputer's coverage of the Microsoft writeup, the observed campaigns run this sequence:

ClickFix lure. A page instructs the user to open the Windows Run dialog, paste a command, and press Enter. Standard ClickFix, unchanged from prior chains.
WebDAV fetch. The pasted command invokes either mshta.exe or rundll32.exe against a remote WebDAV share. The initial-stage payload never touches local disk under its own name — it is fetched and executed straight out of the SMB/WebDAV mount.
Python loader. The staged component is bundled as a Python loader, which handles the in-memory injection of ACR Stealer itself.
Persistence. A scheduled task is registered under a name that mimics a software-update task; timestamps on any files that do land are back-dated, and PowerShell history is cleared post-execution.
Collection. ACR Stealer reads Chromium Login Data and Web Data databases, decrypts saved credentials and session tokens via DPAPI, and walks the local OneDrive and SharePoint sync roots for PDFs and Microsoft 365 documents. Desktop and Downloads are enumerated for the same file types.

The steps above are Microsoft's, as reported by BleepingComputer's Bill Toulas. The stealer's target set — browser session tokens plus M365 sync-root files — matches what was documented in the Defender Experts breakdown yesterday. The delivery-side changes are what warrant covering this as a separate news beat.

What is new in this window

Two mechanics show up in the July 16 writeup that were not the focus of the Defender Experts post:

WebDAV as the first-stage host. WebDAV is old plumbing. It has been shipping in Windows since IIS 5.0, it is still enabled by default on client SKUs, and mshta.exe and rundll32.exe will both happily execute content pulled from a remote WebDAV share as if it were local. Blocking outbound WebDAV — Server Message Block over HTTP, port 80/443 to arbitrary internet hosts — has been a defender recommendation for years and remains widely unfinished business in enterprise environments. That is the surface this campaign is using.
Blockchain dead-drop resolvers for C2 updates. Microsoft describes ACR Stealer's operators using an EtherHiding-style technique to publish updated C2 endpoints as data written into on-chain transactions on a public blockchain. The stealer reads the current endpoint from the chain rather than from a hardcoded domain or a fast-flux DNS pool. The practical consequence for defenders: takedown of a domain or a hosting provider does not break the campaign — the operators publish a new endpoint on-chain and the deployed samples pick it up on the next check-in. Steganographic JPEG payloads are also cited as a delivery-time obfuscation for some of the intermediate stages.

Both mechanics are documented elsewhere in prior campaigns — WebDAV abuse for mshta staging is a decade-old tradecraft, and EtherHiding was named publicly by Guardio in 2023 — but their combination in a live infostealer campaign at this scale is the reason Microsoft is warning enterprise customers directly rather than filing this as a routine Defender writeup.

Analysis: the lure is stable, the plumbing rotates

Analysis, not incident reporting. The pattern here matches what has been visible in ChainVeil and ViteVenom's npm supply-chain work reported earlier today: the front door to the endpoint has not changed — someone in the enterprise still has to paste a command and press Enter, or install a package they should not have — but the back-office infrastructure keeps migrating to substrates that are harder to take down. Public blockchains for C2 endpoints, WebDAV as a legacy-enabled hosting layer, MaaS operator handoffs between vendors like SheldIO and whichever group is now running Amatera. Nothing in this stack is new to 2026. All of it is still, in most environments, load-bearing.

What to actually do

The defenses Microsoft lists are the same short list that has been on defender whiteboards for years:

Application control against the loader binaries. WDAC or AppLocker rules that block mshta.exe, rundll32.exe, powershell.exe, and any bundled python.exe from executing content sourced from user-writable paths or from remote UNC/WebDAV mounts. This is the single control that would break both delivery chains documented here.
Egress WebDAV block. Deny outbound PROPFIND, MKCOL, and related WebDAV verbs to non-corporate destinations at the proxy or firewall. A user pasting a net use or \\host@SSL\path command should not get a routable path off the network.
DPAPI-scope review. Chromium browsers store passwords and session cookies under the user's DPAPI master key. Any process running as the user can decrypt them. There is no browser-side patch for that; the mitigation is limiting which processes can spawn under interactive user tokens in the first place.

One specific, useful item to close on: check whether your WDAC baseline includes a deny rule for %WINDIR%\System32\mshta.exe with arguments containing http://, https://, or a UNC prefix. If it does not, that rule alone would break step 2 of the chain above for every campaign in Microsoft's writeup. It is a five-line addition to an existing policy. It is also, in most environments audited over the last three years, missing.

7-Zip 26.02 patches XZ heap overflow, no auto-update

Marisol "Fuse" Delgado — Sat, 18 Jul 2026 21:00:00 GMT

7-Zip 26.02 shipped today with a fix for a heap-based buffer overflow in the XZ decompression path. The write-up is Zero Day Initiative advisory ZDI-26-444; BleepingComputer's coverage went up a few hours after the release. Credit to Landon Peng at Lunbun LLC, who reported it to Igor Pavlov on 2026-06-05 and disclosed publicly on 2026-07-15. A CVE has been assigned but has not landed on NVD or MITRE yet — I'm not going to print the number until it does, because half the mis-cited CVEs on the internet come from repeating a placeholder somebody read once and never checked again.

What changed

ZDI rates it 7.0, high. The parser mishandles specially crafted XZ chunked data and overflows a heap buffer, giving an attacker the ability to execute code in the context of the user who opened the file. No privileges required to trigger it. User interaction is required — someone has to actually open the archive or visit a page that loads it into a viewer wired up to 7-Zip. Attack complexity is high, which is ZDI's way of saying it's not a one-liner to make it fire on demand across every build; that is not a reason to relax.

No active exploitation has been reported. That was also true of the 7-Zip parser bugs that Russian threat actors picked up and ran with in 2025. The honest timeline on parser flaws in an archiver installed on tens of millions of endpoints is measured in weeks, not quarters.

What to actually do

Push 26.02 to every managed Windows endpoint you own. 7-Zip does not have an auto-updater. If your MDM/config-management doesn't already have a 7-Zip package definition, this is your reminder to add one — the tool ships on developer, admin, and analyst boxes across every org I've worked with, and none of it phones home.
Sweep your build agents, sandbox VMs, and forensic workstations. These are the machines that open untrusted archives for a living. They also tend to run whatever 7-Zip version was installed the day the image was cut. Rebuild the base image or push the MSI, don't just tell the team to update.
Check %ProgramFiles%\7-Zip\7z.dll version on any host you can't push a package to. 7-Zip runs from a lot of side-loaded install directories. Version string of the DLL is authoritative; the shortcut in the Start menu is not.
Do not treat this as more urgent than the KEV work in your queue this week. SharePoint CVE-2026-58644 and the two Fortinet FortiSandbox additions are unauth RCEs against internet-exposed services with confirmed exploitation. The 7-Zip bug requires a user to open a file. Priority order matters.

Priority call

Patch it inside your standard weekly window. Move it up if your users routinely open archives from untrusted sources — recruiter attachments, sample code from candidates, malware samples, vendor-supplied firmware bundles. That population is small, high-value, and exactly the target profile the 2025 campaigns hit.

The thing worth saying out loud: 7-Zip is one of the load-bearing bits of Windows tooling that ships without any of the delivery infrastructure the modern patch conversation assumes. There is no update daemon, no signed update channel wired to WSUS, no browser-style silent update. Every time one of these parser flaws lands, some percentage of the install base will still be running the vulnerable build next year. If you own the endpoint policy, the answer is a package. If you don't, the answer is telling your users, in one sentence, to open 7-Zip and check Help → About and update if the number isn't 26.02.

Sourcing

Zero Day Initiative: ZDI-26-444, 7-Zip XZ Decompression Heap-based Buffer Overflow Remote Code Execution Vulnerability
BleepingComputer: Update now — 7-Zip fixes RCE flaw exploitable with malicious archives — 2026-07-18
7-Zip download page
Related: HollowByte: 11-byte OpenSSL DoS — another this-week disclosure where the interesting story is the release plumbing, not the bug itself

Two indicted over $43M laundered from investment scams

airgap — Sat, 18 Jul 2026 18:15:00 GMT

Confirmed. U.S. prosecutors on Thursday charged two New York residents with running a Queens- and Brooklyn-based network that allegedly laundered $43 million in investment-fraud proceeds through 140 bank accounts and roughly 45 shell companies, routing the money to accounts in China. Both defendants face a single count of conspiracy to commit money laundering. Maximum exposure: 20 years.

Named in the indictment, per the Justice Department release reported by BleepingComputer on July 17, 2026: Zhuoying Chen, 27, and Haojie Zhang, 38. Prosecutors say the two managed a network of more than a dozen co-conspirators between 2020 and 2022. Homeland Security Investigations led the enforcement action; HSI Executive Associate Director John A. Condon is quoted in the release describing the pair as running a "sophisticated, illicit network" for nearly two years.

Confidence: high on the charges as filed. The mechanics, dollar amount, and dates are the government's allegations, not adjudicated fact — standard "indicted, not convicted" caveat applies.

What the government says the operation looked like

The upstream fraud is the pig-butchering pattern that has dominated investment-scam volume for three years: cold outreach on social media or messaging apps, weeks of trust-building, a fake trading dashboard showing rising balances, then a push to increase deposits before the money vanishes. Chen and Zhang are not charged with running that scheme. They are charged with cleaning what came out of it.

Prosecutors describe the pipeline in three layers:

Front end: approximately 45 shell companies incorporated to hold accounts.
Middle: 140 U.S. bank accounts opened in those companies' names, receiving victim deposits.
Back end: transfers out to accounts in China, moving proceeds beyond U.S. reach.

That structure is unremarkable as a laundering typology. What's notable is the scale sustained for two years without an intermediary bank filing a Suspicious Activity Report loud enough to shut it down earlier.

Where this sits in the 2025 numbers

The IC3 and FTC totals for 2025 put investment-fraud losses at $8.6 billion, up from $6.5 billion the year prior — a roughly 32% year-over-year increase. Investment fraud alone accounted for 49% of reported scam incidents in 2025. Cases like the Chen/Zhang indictment are one of the few reliably visible signals on where that money actually goes after it leaves victims' accounts: through domestic shells, out to jurisdictions with limited U.S. cooperation. The unindicted upstream — whoever ran the scam sites and dashboards that fed the 140 accounts — is not addressed in the public filing.

What this changes for defenders

Not much in the short term. This is an enforcement outcome, not a technique disclosure. But three things are worth flagging:

Detection remains downstream. The pipeline reportedly ran two years. Bank AML controls did not catch it in time. Anti-fraud teams at financial institutions should expect the KYC-around-shell-company patterns in the indictment to inform coming FinCEN guidance.
The victim-facing side is unchanged. Same pig-butchering playbook. Same social-first lure. Employee-awareness content and consumer messaging around unsolicited "investment mentor" DMs on Telegram, WhatsApp, and dating platforms still holds.
This is one node, not the network. Two indictments do not dent $8.6 billion in annual losses. Treat the takedown as one data point, not a trend break.

Full BleepingComputer writeup is here. DOJ press release referenced but not directly linkable at time of publication.

NadMesh botnet raids exposed AI tools for 3,811 AWS keys

Marisol "Fuse" Delgado — Sat, 18 Jul 2026 16:15:00 GMT

A Go-language botnet called NadMesh turned up in early July running exactly the internet scan you'd write if you were an attacker with a rented VPS and a working knowledge of the current AI-tooling shelf. Per The Hacker News' writeup, a Shodan harvester feeds the scan queue and the queue targets six things: ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio. Image generators, local model runners, and workflow builders — the "spin it up in fifteen minutes to see if the demo works" tier of the stack. The operator's own dashboard claims 3,811 unique AWS keys collected.

That last number is the story. Three thousand eight hundred and eleven AWS access keys pulled off machines whose owners, in most cases, thought they'd spun up a private research toy. Kubernetes service-account tokens on the same haul.

What NadMesh is actually doing

None of the targeted services are new attack surfaces. ComfyUI, Ollama, Open WebUI, Gradio — these ship dev-friendly defaults (bind to 0.0.0.0, no auth in the base config, credentials read from the surrounding environment) because that is what makes the getting-started page work. n8n and Langflow are workflow builders whose whole selling proposition is running arbitrary steps against your cloud accounts; they hold the AWS keys, the Kubernetes tokens, and the SaaS credentials by design.

Shodan indexes all of them by fingerprint. A scanner that hits Shodan on a schedule, filters for "response body contains this string," and pipes the hits into a small library of per-tool config-readers gets you exactly the tenant-level credentials NadMesh is showing on its dashboard. It is not a vulnerability chain. It is a directory listing.

The Langflow prong is worth flagging on its own. This is the second wave of Langflow-adjacent trouble in a month — CISA added the Langflow IDOR CVE-2026-55255 to KEV on July 7, and Sysdig documented the JadePuffer group ransoming AI-agent stacks through Langflow two weeks before that. NadMesh doesn't need a CVE to work — the exposed instance is the exposure. If it's reachable from the internet with the defaults on, that's the finding.

What to actually do

Priority order, do them today:

Take exposed AI dev tools off the internet. Not "add basic auth." Off the internet. Bind ComfyUI, Ollama, Open WebUI, and Gradio to a private interface or put them behind a VPN or SSO reverse proxy. Anything a Shodan fingerprint can identify from the outside is already being scanned by something. NadMesh is one operator; there are others.
Rotate every AWS key and Kubernetes token that the exposed service could read. Environment variables, ~/.aws/credentials, mounted service-account tokens, IAM role sessions cached on the box. If a workflow builder had access to a credential last week, treat it as compromised this week. Rapid7's AWS IAM persistence hunt runbook from July 15 is the shape of the follow-through: don't stop at the rotation — go look for the new IAM user, the CreateAccessKey call, the federated-role handoff.
Audit n8n and Langflow deployments specifically. Not for CVEs, for exposure. Public URL, no auth, no IP allowlist — that trio is the win condition for this operator. If you patched n8n's CVE-2026-59208 cross-issuer token exchange last week and the instance is still reachable from the internet, the patch closed one door and NadMesh is walking through the front one.
Check egress logs for the last thirty days. Look for outbound calls to Shodan-adjacent scanner ranges hitting your AI-tool ports, and for any of your own instances making STS GetCallerIdentity calls to AWS from IPs you don't recognize. If a key walked, it will announce itself when the operator tries it.

Priority call, no ambiguity: step 1 is not optional. Steps 2–4 assume step 1 is already done. A rotated key that goes back into an exposed n8n instance gets scraped again inside a day.

The honest timeline

The paste-a-command-and-press-Enter class of failure that carried ACR Stealer through enterprise fleets last week has a matching cloud-side version, and NadMesh is it: a class of failure that patching does not fix, because there is no bug to patch. The default is the vulnerability. The scanner running against it doesn't need to be sophisticated. It needs to be running, and it is.

Nothing about this is going to slow down. The tooling shelf keeps growing — a new local model runner ships every couple of weeks and the getting-started defaults follow the same pattern each time — and Shodan indexes them within days. Assume the next NadMesh is being written this month. Firewall accordingly.

Expel: GoldenEyeDog stole 27 EV certs from DigiCert

Marisol "Fuse" Delgado — Sat, 18 Jul 2026 15:00:00 GMT

The April 2 DigiCert incident is finally attributed. Per Expel's writeup as summarized by The Hacker News, the intrusion belongs to CylindricalCanine, a subgroup of the Chinese cluster tracked as GoldenEyeDog / APT-Q-27. Sixty fraudulently issued EV code-signing certificates got revoked. Twenty-seven of them were used to sign Zhong Stealer.

That last number is the one that matters. This wasn't hypothetical trust compromise. Twenty-seven certificates from a public CA went out and signed malware in the wild before the revocation caught up. If your endpoint controls trust code-signing signatures — and most do, that's the whole point of EV — every one of those artifacts had a green checkmark on the way in.

What Expel says happened

Per the writeup, the operator delivered a malicious .scr file dressed as a screenshot through DigiCert's customer support chat on April 2, 2026. A support analyst opened it. From there the interesting bit is the design flaw, not the phish: initialization codes for EV cert issuance were viewable by a compromised analyst account through the support portal proxy. DigiCert's own quote from its Mozilla disclosure is honest about it — "the threat model did not account for the scenario in which initialization codes ... could be viewed by a compromised DigiCert analyst account."

That's the primitive. The actor could pull the init code for a customer request in flight and stand up a matched signing cert on the customer's own account. No name-constraint on the accounts meant nothing checked whether the actor's later signing behavior matched the legitimate customer. The audit didn't fire because the paperwork looked right.

DigiCert has since deployed code changes on both the U.S. and E.U. platforms that mask initialization codes from proxied support portal views over both UI and API. Reasonable fix. Should have been the design.

Zhong Stealer, and the harder lesson

Of the sixty revoked certificates, twenty-seven map directly to Zhong Stealer samples. Related loader activity for this cluster was documented as far back as November 2025, and Web3 targeting from the same actor surfaced in March 2026 — this crew was operating for months before the April intrusion, and they knew what they wanted out of a CA compromise: signed loaders that endpoint tools wouldn't flag on trust.

Analysis: signed-malware campaigns don't need a big-CA breach to work. Attackers regularly stand up their own limited-issuance certs or buy leftovers on the market. What a CylindricalCanine-style compromise gets you is bulk plus reputation. Twenty-seven certs, all traceable to a name-brand issuer, with real customer accounts backing them. That's a different tier of trust to burn.

What to actually do

Priority order:

Pull the DigiCert revocation list and cross-check it against signing certificates observed in your environment over the last 90 days. Not just installed roots — actual code you allowed to run because it was signed. If you can't get that from your EDR, that's the gap. Fix it.
Alert on newly-issued EV code-signing certs appearing in your fleet for the first time. First-seen certificates from a legitimate issuer are the noisy but honest detection for this class of abuse. Tune the volume down by thumbprint allowlisting for publishers you actually consume.
Do not rely on publisher name alone in application-control policy. Bind allowlists to specific cert thumbprints, not "signed by anyone whose CN matches X." That's the design flaw the abuse rides on.
Ask your CAs the boring question: what's their support-portal threat model? Not the pen test, not the SOC 2. Ask whether a compromised support analyst can read customer initialization data in flight. DigiCert's answer, to their credit, is now no. Others' answers, largely, are still yes.

Revocation is not detection. If a signed artifact landed on your box in March, the revocation list posted in April doesn't stop it from being on your box. You have to go look.

Abbott confirms Exact Sciences hit; LabCentral disputed

airgap — Sat, 18 Jul 2026 14:15:00 GMT

Confirmed: Abbott Laboratories has disclosed unauthorized access to legacy Exact Sciences systems inside its Cancer Diagnostics business, and is separately investigating a claim of a LabCentral customer-portal breach in its Core Laboratory unit. Two incidents, two different extortion posts, one week. Confidence on the Cancer Diagnostics intrusion: confirmed by Abbott. Confidence on the LabCentral claim: disputed by Abbott, unresolved.

The confirmed one — Exact Sciences via vishing

Per Abbott's statement to BleepingComputer, the intrusion touched internal legacy Exact Sciences systems in the Cancer Diagnostics business. Abbott says it "does not impact any business operations, product or product availability" and that no material financial impact is expected. Confidence on that framing: as-stated by Abbott.

The extortion side: the data-theft group ShinyHunters claims responsibility. Mechanics as posted on the crew's leak channel and summarized by BleepingComputer:

Vishing — employees called and social-engineered into surrendering credentials or approving MFA prompts.
Access path — the compromised credentials/prompts were used against Microsoft Entra SSO, landing session tokens with reach into internal SaaS.
Reach after landing — the crew names Microsoft Entra, ServiceNow, SharePoint, Databricks, and Coupa as staging points from which data was pulled.
Timeline — the operator claims mid-June access; the extortion post surfaced this week with an initial July 18 deadline, since extended to July 21.

Volumes claimed by ShinyHunters — treat as the operator's numbers, not Abbott's:

30M+ customer PII rows (names, emails, phone, addresses, DOBs), including 1M+ Social Security numbers.
22M+ doctor-patient conversation notes.
20M+ medical orders.
Internal documents, contracts, and customer records exfiltrated from the SaaS estate above.

Confidence on the volume: operator's claim, unconfirmed. Abbott has not counted the exposure publicly. The pattern — vishing → Entra SSO → downstream SaaS — is the same one we covered on Microsoft's ShinyHunters / Salesforce OAuth writeup last week, on the Pink-O / UNC-066 Entra passkey-vishing chain earlier this month, and on the Odido / Dutch-speaker ShinyHunters vishing arrests reported by the Politie on July 10. Same crew, same access technique, different victim.

The disputed one — LabCentral

A separate operator using the handle ShadowByt3$ posted a claim against LabCentral, the customer portal used by Abbott's Core Laboratory business. Method as claimed:

Compromised customer credentials — not employee credentials.
Portal API endpoints — abused with the customer-tier session rather than internal SSO.
Alleged exfiltration — manufacturing certificates, product manuals, technical specifications, regulatory documents, product-requirement archives, and assay files.

Abbott's response: acknowledged as a potential incident, but publicly disputed the characterization, stating the LabCentral portal contains "publicly available technical product reference documents." Confidence: disputed — Abbott says the material was already public; the extortion post says otherwise. Neither position has been independently corroborated at time of writing.

Notably, this is a second, unrelated actor posting against a second Abbott property in the same week — not a rebrand, not the same operator claiming two properties. Two independent brands filing extortion claims against the same target inside a seven-day window is worth flagging on its own, whether or not either side of the second claim survives scrutiny.

What Abbott has said

Both incidents: incident response activated, external cybersecurity experts engaged, law enforcement notified.
Exact Sciences intrusion: confirmed; no impact on operations, product, or availability; no material financial impact expected.
LabCentral claim: acknowledged as under investigation; characterization disputed on the grounds that the affected portal houses publicly available reference documents.
SEC 8-K: not filed as of this writing. Confidence: unfiled, not "will not file" — that reads as ongoing rather than declined.

What is not confirmed

Total records exposed. ShinyHunters' 30M+ / 22M+ / 20M+ figures are the operator's numbers. Abbott has not counted, and neither NVD, CISA, nor any independent researcher has validated the file counts. Unconfirmed.
Whether SSN and PHI exposure will trigger HIPAA-covered notifications. Not stated by Abbott; volume claim implies scale but Abbott has not confirmed protected health information is in scope. Unstated.
Whether the two extortion posts are coordinated. The handles are different (ShinyHunters and ShadowByt3$), the methods are different (employee vishing → Entra vs. customer credentials → portal API), and Abbott treats them as separate investigations. Nothing in the current record links them. Independent, per the current evidence.
The extended deadline. ShinyHunters moved the extortion clock from July 18 to July 21. Whether that is a real negotiation window or just leak-post cadence: operator's claim, treat accordingly.

What survives the noise

Two things worth carrying forward:

The vishing-to-Entra chain is now the default access path for this crew. Fourth confirmed victim in three weeks. If your Entra tenant permits voice-approved MFA push, the passkey-default rollout coming to Entra in September is not "eventually" — it is the mitigation for the technique currently emptying enterprise SaaS estates. Bring it forward where you can.
Customer-facing portals with API endpoints are their own attack surface, separate from the corporate SSO story. The LabCentral claim, however it resolves, is a reminder that portal-tier credentials get compromised and reused in ways that never touch Entra or any internal identity system. Session-lifetime, rate-limits, and per-account exfiltration alerting on portal APIs are worth an audit if you have not looked in a while.

Sources

Abbott statement, via BleepingComputer: Abbott Laboratories probes two cyber incidents amid extortion claims — July 17, 2026.

Confidence, consolidated: Cancer Diagnostics / Exact Sciences intrusion — confirmed by Abbott. LabCentral claim — disputed by Abbott, unresolved. ShinyHunters volume figures — operator's claim, not independently verified. Treat accordingly.

Seven Vite-adjacent npm packages route a RAT through Tron

Loop — Sat, 18 Jul 2026 14:00:00 GMT

Seven npm packages presenting themselves as Vite plugins or Vite-adjacent tooling have been pulled from the registry after Checkmarx tied them to a campaign it is calling ViteVenom, which the firm characterizes as an expansion of the earlier ChainVeil operation. Per The Hacker News, each package delivers a remote access trojan through a four-tier command-and-control chain that walks through public blockchains — Tron among them — before landing on the operator's real infrastructure. Confidence on the count, the codename, and the blockchain routing: as reported by Checkmarx via The Hacker News. Full package list and hash indicators sit with Checkmarx's own writeup.

Why Vite plugins as the lure

Vite is the build tool a large share of new React, Vue, and Svelte projects reach for by default. Its plugin surface is normal npm — anyone can publish a vite-plugin-* package, and developers install them on trust because the ecosystem is young and the package names look like the ones already in their package.json. That is a soft target. A dev pulling in a new plugin to solve a build-time problem is not, in that moment, doing a threat model of the package's transitive dependencies. They are trying to get vite build to work before standup.

The compromise pattern here is not novel — it is the same shape as the AsyncAPI namespace hit last week and the earlier rollup-polyfill DPRK cluster. Small, plausible packages. Frontend tooling ecosystem. Payload that runs somewhere between install and first import.

The four-tier blockchain C2

The mechanic worth naming is the C2 chain, because it is the part of this campaign that is genuinely load-bearing for the operators. Traditional RAT infrastructure pins to a domain or a hardcoded IP. Take the domain, or blackhole the IP, and the RAT loses its handler. ChainVeil-style operators solve that by staging the address resolution across several public read-only channels — the Tron blockchain being one of them — where each tier only tells the payload where to look next. The final host address is stored (or derived) inside a chain transaction, which anyone can read but nobody can meaningfully take down. There is no domain to seize. There is no name server to poison. The block will still be there tomorrow.

That does not make the payload undetectable. It makes the takedown path harder. A defender still gets the same signals — a build-time or first-import outbound to something that is not registry.npmjs.org, a resolver reaching a Tron RPC endpoint from a Node process, an eventual TCP session to a residential-looking IP. Those are all noisy in the right telemetry. The novelty here is that a sinkhole the domain playbook does not close the loop the way it used to; the loop rebinds on the next fetch.

What to actually do

For engineering orgs running npm at scale, the near-term move is unchanged from the guidance in the earlier supply-chain pieces: turn install scripts off by default in CI (npm 12 exposes this as a top-level flag), require a review step before a new plugin lands in package.json, and pin lockfile resolution. On top of that, the Tron-and-friends resolution pattern is worth a specific egress rule: block or alert on any Node child process making outbound calls to well-known blockchain RPC endpoints from a build agent. There is no legitimate reason a Vite build needs to reach a Tron node, and the alert is cheap.

For individual developers, the honest advice is smaller and older: do not install a vite-plugin-* package you saw in a tweet without checking who owns the namespace and how many downloads it actually has. New packages with impressive names and no history are the ones this campaign is built for.

Checkmarx's own writeup carries the full package list and file hashes — pull those into your allow/deny tooling as soon as they are up, and treat any developer laptop or CI runner that installed one of the seven between publication and takedown as a candidate for triage, not routine.

HollowByte: 11-byte OpenSSL DoS, no CVE, silent June fix

Marisol "Fuse" Delgado — Sat, 18 Jul 2026 13:15:00 GMT

Eleven bytes of TLS. That's the payload. In return, Okta's Red Team says, an unpatched OpenSSL server sets aside up to 131 KB of process memory for a message that never arrives — and on the glibc-linked systems Okta tested, that memory doesn't come back until the process restarts. Loop that for a few thousand connections and the box tips over. Okta named the bug HollowByte and reported it earlier this year; the public writeup dropped on 2026-07-17, mirrored by BleepingComputer hours later.

What changed

OpenSSL shipped the fix in June with no CVE, no advisory, and no changelog entry pointing at it. If you rebuilt against a June-or-later OpenSSL point release, you already got the patch and never knew that's what it was. If you're still on the version you had in May, you're vulnerable and nothing in your normal patch queue is going to flag it, because nothing in the release metadata says "security fix" — that's the whole problem the disclosure is now forcing into the open.

The bug itself is a memory-allocation mismatch in TLS record parsing. The parser reserves a buffer sized for a message that the caller has told it to expect, before checking whether the connection actually delivers it. Unauthenticated. No handshake completion required. Standard glibc behavior keeps the reservation live for the life of the process, so a modest number of connections adds up. Okta's ratio is roughly 12,000-to-1 memory-to-payload, which is a bad ratio.

Nobody is claiming active exploitation. This is a DoS, not an RCE. It has not been added to CISA's KEV catalog and there is no vendor advisory to attach it to — that's the point of the disclosure, not an omission on our end.

What to actually do

Check the OpenSSL build date on every internet-facing service that terminates TLS: HTTPS, IMAPS, LDAPS, SMTPS, whatever you own. Anything linked against an OpenSSL older than the June 2026 point release for its branch is exposed. Package versions lag; use the build date, not just the marketing version string.
Rebuild or repackage against a current OpenSSL. On mainstream distributions this is a routine package update; if it isn't for you, that's the honest reason you own that pain, and this is the excuse to fix it.
Rate-limit your public TLS listeners at the edge — not as a fix, as a hedge. With HollowByte's memory-to-payload ratio, even generous per-source connection caps keep a single low-rate attacker from pushing a whole process over.
Do not chase this ahead of the CVEs actually being exploited this week. SharePoint CVE-2026-58644 has KEV status and CISA's Fortinet FortiSandbox additions had a hard patch deadline this weekend. Those are unauth RCEs with active exploitation. HollowByte is neither.

Priority call

Patch it in your next scheduled maintenance window, not tonight. If your instinct every time a named bug shows up is to push OpenSSL updates outside change control, you will burn credibility for the day it actually matters. The DoS surface is real. It is not on fire.

The part that will annoy package maintainers and downstream integrators for longer than the bug itself is the release process. A memory-exhaustion DoS in the library that ships in every mainstream Linux distribution, patched without any of the metadata that would let downstream automation notice, is the exact shape of the problem software-supply-chain auditors already spend their days chasing. Expect the OpenSSL project's release hygiene to catch louder criticism than the vulnerability. That criticism is fair. It also doesn't patch anything.

Sourcing

The Hacker News: OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests — 2026-07-17
BleepingComputer: HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload — 2026-07-17
Related: Agent Data Injection: the bug under every AI agent — same shape of problem in a different layer: a class-level defect in a load-bearing component, no clean patch, disclosure forcing the conversation

WordPress Core RCE (wp2shell): CVE-2026-63030, PoC public

airgap — Sat, 18 Jul 2026 13:05:00 GMT

Confirmed: a critical unauthenticated remote code execution vulnerability in WordPress Core received the tracking ID CVE-2026-63030 on July 17, 2026, published under the researcher tag wp2shell. Rapid7 issued an Emergent Threat Response write-up the same day. The Hacker News reports a working proof-of-concept is public and that a bare install with zero plugins is in range.

If you run a WordPress instance that faced the internet unpatched after July 17, treat it as compromise-adjacent until you can prove otherwise.

What is confirmed

CVE ID. CVE-2026-63030, assigned via a GitHub Security Advisory on July 17. Verified against NVD.
Vulnerability class. Unauthenticated remote code execution. No account required, no plugin required — the flaw lives in WordPress Core itself.
Attack primitive. Per The Hacker News, a single anonymous HTTP request is sufficient to run code on the target instance. Consistent with the researcher tag wp2shell.
Affected branches. Per The Hacker News, the WordPress 6.9 and 7.0 branches were in range prior to the patched release. Refer to the wordpress.org security page for the authoritative patched-version list.
PoC state. Public. The Hacker News reports the full mechanism has been published and a working proof-of-concept is circulating.

The scoring split

There is a public split on CVSS. NVD lists CVE-2026-63030 at 9.8. Rapid7's write-up notes that the GitHub Security Advisory itself classifies the severity as Critical but assigns a CVSS of 7.5. Both source severities land at Critical; the numeric gap between the two is unresolved as of this filing. Cite both if you're briefing up — the discrepancy is going to come up.

What is not confirmed

In-the-wild exploitation. As of this filing, no named vendor telemetry of active use has been published. Unconfirmed — treat accordingly. A public PoC on an unauthenticated single-request primitive against WordPress narrows the window between disclosure and exploitation to hours, not weeks; the setup for exploitation is present, the observation is not yet.
The second CVE ID. The Hacker News reports that a companion persistent-object-cache condition has surfaced alongside wp2shell and now carries its own CVE ID. That second ID is not yet reflected in the summary we have. Only CVE-2026-63030 has been independently verified against NVD; the companion is real per the outlet and tracked as a linked issue until we have the ID in hand.
KEV status. CISA had not added CVE-2026-63030 to the Known Exploited Vulnerabilities catalog at the time of writing. Expect that to change quickly if exploitation is observed against federal-civilian assets.

Why this one matters

WordPress runs a large share of the public web — that is the point of the wordpress topic hub on this site. An unauthenticated RCE in core — not a plugin, not a theme — means the exploitable surface is not gated behind third-party ecosystem choices. Every public-facing WordPress instance in the affected branches is a candidate target the moment the PoC is stable enough to weaponize, and per The Hacker News, it is.

This is a different failure mode than the plugin-side pattern we covered in Australia's ACSC CMS advisory listing 18 CVEs under exploitation, or the LLM-assisted plugin-zero-day discovery Intruder disclosed in its vending-machine write-up. Those are ecosystem-side stories. wp2shell is a core-side story, and the blast radius is correspondingly larger.

What defenders can do

Update WordPress Core. The GHSA-published patched release is the fix. Refer to the wordpress.org security page for the exact patched-version number and apply at or above it.
If you cannot patch immediately, take the instance off the public internet. For an unauthenticated single-request RCE, network-layer removal is the only reliable near-term control.
Assume any unpatched public-facing WordPress instance is a target. WordPress-hosting attack surfaces are enumerated at massive scale as a matter of course; a working PoC on an unauthenticated primitive is the trigger for that enumeration to become exploitation.
Watch for the second CVE. Track the companion persistent-object-cache condition once its ID lands.
Watch KEV. If CISA adds this one, the timeline for federal-civilian remediation compresses to days under BOD 26-04.

This piece will be updated when the companion CVE ID lands, when CISA adds wp2shell to KEV, or when in-the-wild exploitation is confirmed by a named vendor.

Sources

Rapid7: ETR: CVE-2026-63030 — wp2shell, a critical remote code execution vulnerability in WordPress Core — July 17, 2026.
The Hacker News: New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code — July 17, 2026 (updated July 18).
NVD: CVE-2026-63030.

Confidence: CVE assignment and vulnerability class confirmed and independently verified. Public PoC availability as-reported by The Hacker News. In-the-wild exploitation: unconfirmed. Companion CVE ID: pending.

Agent Data Injection: The Bug Under Every AI Agent

Marisol "Fuse" Delgado — Sat, 18 Jul 2026 10:15:00 GMT

If you run an AI agent that reads untrusted content and then takes actions — a coding assistant applying a maintainer's fix from a GitHub thread, a shopping agent summarizing product reviews before buying, a browser-driving agent that reads a webpage before clicking — the Agent Data Injection paper posted to arXiv on 2026-07-06 by Seoul National University, the University of Illinois Urbana-Champaign, and Largosoft is the threat model you were quietly pretending you didn't have. The Hacker News wrote it up on 2026-07-17; the paper is worth reading in full.

The short version: nobody had to jailbreak anything. Nobody had to get the agent to ignore its safety training. A single planted product review can make a shopping agent click "Buy Now" instead of summarizing. A single forged comment on a GitHub issue can make a coding agent run an attacker's command as if a maintainer had asked for it. The agent finishes the task the user asked for. It just quietly picks up new facts along the way.

What changed

Prompt injection isn't new. What's new is the framing and the evidence.

Woohyuk Choi and Prof. Byoungyoung Lee's group tested the attack against production agents: Claude for Chrome, Google Antigravity, and Nanobrowser on the web-agent side; Claude Code, OpenAI Codex, and Google Gemini CLI on the coding-assistant side. Every one of them fell to variants of the same technique they call probabilistic delimiter injection — planted text formatted like the structural markers the agent's context uses to separate trusted instructions from untrusted data. The agent parses the boundary wrong, promotes the planted content to instruction level, and continues.

Three defenses were tested. This is the useful part of the paper:

Randomized, unguessable element IDs. Web-agent attack success rate fell from ~49% to ~29%. That is a mitigation, not a fix.
Data provenance tracking — labeling every token by where it came from and forbidding untrusted content from steering the agent. Killed the attacks in the lab. Broke normal agent operation in the same run.
Punctuation stripping. Same story — reduced the attack, damaged legitimate behavior enough that it wasn't shippable.

None of the three is a paste-in-place patch. Per the paper, Anthropic, Google, and OpenAI acknowledged the disclosure; Nanobrowser had not responded at time of writing.

What to actually do

If you run agents in production, or you're piloting them, or you're evaluating vendors this quarter:

Assume any agent that reads untrusted content is compromised on that channel. The threat model isn't "someone jailbreaks my agent" anymore. It's "someone plants a review, a comment, a support-ticket reply, a scraped forum post, and my agent believes it." That is the working assumption from today forward. Every hard boundary — what the agent can spend money on, what it can execute, what it can commit — belongs on the outside of the agent, in code you control, not inside the model's context.
Cap the blast radius. An agent that can read arbitrary URLs and execute shell commands in the same session is one planted comment away from executing whatever a stranger typed on the internet. Separate the read-untrusted-content step from the execute-anything step with a human confirmation, a sandbox, or a policy engine. If your architecture doesn't allow that separation, the architecture is the vulnerability.
Treat agent output as attacker-controlled when it consumed attacker-controlled input. Anything an agent produces after summarizing a webpage, reading a GitHub thread, or ingesting a scraped dataset is downstream of an untrusted parser. Don't hand it to another automation without validation. Don't hand it to another agent without validation. Don't hand it to a shell.
Read the vendors' latest tool-use and agent-safety guidance and match it against your integration. Anthropic, OpenAI, and Google have all published guidance for tool-using agents that touches on untrusted-content boundaries; some of it postdates the ADI paper, some doesn't. Read the dates before you trust the recommendation.
If you were already sandboxing coding agents, keep going. Running Claude Code, Codex, or Gemini CLI inside a per-project container with no host credentials mounted was the right posture before this paper and it is the right posture after. The paper is not a reason to stop using coding agents. It's a reason not to give them credentials and shell access on your daily-driver box.

Priority call

This ranks behind actively exploited vendor CVEs on the KEV catalog — CISA's Fortinet FortiSandbox additions and SharePoint CVE-2026-58644 are still the immediate patch queue this week. ADI is a design-level bug across an entire product category, not a patch you apply and forget.

It ranks ahead of most vendor-advisory noise for anyone whose stack includes agents in production. If you're at a company that has been shipping agentic features on top of one of the tested tools — and given the list, that's most companies — this is a threat-model review, not a "monitor the situation" item. Bring it up in your next architecture review. Write down what your agent trusts and why. If the answer is "the model's safety training," rewrite it.

For everyone else — the ADI class is going to keep showing up. The pattern is the load-bearing part. The specific vendors will rotate.

Sourcing

Paper: Choi et al., "Agent Data Injection Attack" (arXiv:2607.05120) — Seoul National University / UIUC / Largosoft, posted 2026-07-06
The Hacker News: New Agent Data Injection Attack Can Make AI Agents Misclick or Run Attacker Commands — 2026-07-17
Related coverage on the operator-side version of the same problem: Trend Micro on Gemini CLI abused as a hacking agent

EU order opens Android mic, cam, screen to rival AI agents

airgap — Fri, 17 Jul 2026 22:15:00 GMT

Confirmed: the European Commission on Thursday ordered Google to give rival AI assistants the same reach into Android that Gemini already has — camera, microphone, on-screen content, an always-on hotword that fires with the display off, and background app control by imitating taps and typing. Deployment is mandatory in Android 18, deadline 1 August 2027. Confidence: high on the mandate itself; unassessed on second-order attack surface, which is the point of this piece.

The timeline the Commission wrote

1 February 2027 — draft programme terms due from Google.
1 May 2027 — final terms locked, third-party applications open.
1 August 2027 — mandatory deployment in Android 18.
1 August 2028 — concurrent hotword support (multiple assistants listening at once) deferred to Android 19.

Everything before that first date is procedural. The load-bearing decisions are the ones Google will draft between now and February.

What Google has to expose

The Commission's structure is a Qualified AI Assistant Programme (QAAP) — free third-party certification through Trusted Certification Authorities. Google writes the certification requirements. The Commission approves them. Testing is capped at four categories: user intent confirmation, data minimisation, baseline security, and what the decision calls "agentic risk" hardening.

Five features require certification before a rival can ship into them. Six do not — and the six include ambient camera and microphone access and always-on hotword detection. That is the security-relevant asymmetry in the ruling. The capabilities that indirect prompt injection would want most — the ones that let an assistant see, hear, and be woken by an attacker-controlled utterance — are the ones the QAAP does not gate behind certification. Confidence on that framing: high, drawn directly from the decision text as summarised by The Hacker News.

Google's stated objection

Google Chief Legal Officer Kent Walker said the order "threatens device security by granting external apps sensitive and powerful device permissions." Confidence on the quote: high. Confidence on the underlying claim: as-argued — Google is a party with an obvious interest, but the technical concern is not manufactured.

The Commission's own decision cites SafeBreach's 2025 work demonstrating indirect prompt injection against Gemini's Android agent through notification content — an attacker plants a payload in a notification the user never taps, and Gemini processes it as instruction on the next agent-triggered action. The Commission cites this as prior art proving the risk is real, and treats it as a reason to certify rather than to withhold. Read that as the regulator's revealed preference: they judge the competition harm from a single trusted broker to be larger than the marginal attack surface from N brokers holding the same capability. That is a policy judgement, not a technical one.

What actually changes for defenders

Nothing operationally today. Android 18 does not ship for another twelve months. The mandate is not retroactive to current Android versions. No new CVE, no new patch, no advisory to feed into a ticket queue.

What to watch, in order:

The draft QAAP terms in February 2027. Specifically: what does the certification's "baseline security" bar require, and what does "agentic risk" testing actually look like? Those two phrases are load-bearing for the entire framework and they have not been written yet. If either lands weak, every certified assistant becomes an in-band route to the exact capability set — mic, camera, screen contents, wake word with the display off, tap-and-type impersonation — that already got compromised once against a single trusted broker.
Google's response between now and 1 February. No public confirmation yet on whether Google will appeal, seek modifications, or comply on the current timeline. Treat as pending; do not file it as either resistance or acquiescence.
The hotword architecture in Android 19. Concurrent hotword — multiple assistants listening simultaneously — is deferred to August 2028, but the design decisions get made earlier. Whatever isolation model Google chooses between hotword processes is the thing that determines whether one compromised assistant can eavesdrop on another.

Prior coverage worth reading alongside this

SafeBreach's Gemini notification-injection is the same shape of problem as the Claude for Chrome trust boundary that Manifold documented last week — an AI agent reading attacker-controlled text as instruction rather than as data.
Google itself is dealing with the misuse edge of the same family: Gemini CLI being repurposed as a hacking agent, Trend Micro's writeup earlier this week.
The PNG prompt-injection work against CodeRabbit and BugBot sits in the same failure class: privileged agent, attacker-controlled input surface, no meaningful separation.

Different vendors, same underlying failure. The EU has just voted to expand the affected surface by executive fiat. That is the fact; the operational consequence is a February 2027 document nobody has drafted yet.

Sources

The Hacker News — "E.U. Orders Google to Open Android Mic, Camera and Screen to Rival AI Assistants" — 17 July 2026.

Flare finds carders still hunting clean IPs post-NetNut

Dave "Kilobaud" Ferris — Fri, 17 Jul 2026 18:15:00 GMT

Flare's research team put out a report on Thursday, covered the same day by BleepingComputer, that reads the underground carding market the way an entomologist reads an anthill — through 2,889 posts and roughly 545 discussion threads across the last two years. The single-sentence finding is not surprising. Carders are still spending most of their time on the same question they were spending it on a decade ago: where do you get an IP address that a fraud-detection model won't immediately flag.

Analysis, not incident reporting. What follows is a reading of an underground-forum study and its context, not a claim about a specific new intrusion.

The news hook

The Flare piece landed two weeks after the FBI seized hundreds of NetNut domains on July 2 and Google's Threat Intelligence Group cut the linked Popa botnet's usable pool by, as Google put it at the time, "millions" of relays. NetNut had been the household-name residential-proxy service for that side of the market — sold nominally for price-monitoring and ad-verification, used, per the government's filings, for a great deal else. Popa was the compromised-device layer under it, roughly two million home routers and IoT boxes, according to Google's figures.

Two weeks later, the underground is doing what the underground always does after a takedown, which is shopping. Flare's read of the forum posts describes a market in the awkward middle: the old vendor is unavailable, the replacements are being audited in public by their prospective customers, and the guides being reposted most often carry titles like "Getting the Cleanest Possible IPs for Carding." That is a normal state. It is also a reminder that the demand side of the residential-proxy market is not what the FBI seized; the demand side is a background condition of the internet economy.

What "clean" means in the guides

The technical checklist Flare pulls out of the posts is not a secret and it is not exploitation content — it is what any competent fraud-model builder already knows their adversary is doing. The underground writeups instruct buyers to match the proxy IP's approximate location with the billing ZIP code, the device time zone, the operating-system language, and the browser configuration presented by an antidetect browser. In other words: buy the proxy, buy the fingerprint, buy the behavioral simulation, and try to make the combination sit inside the noise that a real user would generate.

None of that is a new attack class. It is what carding has been, in different tooling and different lingo, for as long as card-not-present fraud has been a category. What has changed over the last few years is the price and the packaging. Antidetect browsers are commodity software. Fingerprint bundles are sold as inventory. Residential proxy access was, until three weeks ago, a subscription product at a public URL from a Nasdaq-listed parent.

The FBI took the URL. It did not take the demand.

The gatekeeper problem, again

There is a story security writing has been telling for years about the "underground economy" as though it were a shadow of the legitimate one — same shape, opposite sign. The Flare data is the ordinary reminder that the shape is more particular than that. What the forums are debating in July 2026 is the same thing they were debating in July 2016: which supplier is trustworthy, which supplier is a plant, which residential range has already been burned by the fraud vendors. The gatekeepers of the proxy market are the operators who can convincingly claim their pool is fresh, and their credibility with buyers rises and falls on the same signals a legitimate B2B vendor's would — uptime, responsive support, honest churn reporting on their IP pool. That is the small, awkward observation the takedowns rarely change: enforcement disrupts a specific operator, and the customer base migrates to the next operator who can pass audit.

The FBI action on NetNut was a large disruption of one particular operator with a specific dual-use posture. The Infoblox writeup on the "Lurking Lizard" 230-domain fake-7-Zip campaign a week later described a smaller, older operator running the same business model out of drop-catch domains. Flare's post-mortem sits between the two: the customers of the first are audition-testing candidates who look a lot like the second. The same mistake, different decade — the mistake being that treating the residential proxy market as a series of individual companies to be prosecuted keeps missing the fact that it is a market, and markets route around the seizure of a single supplier.

What defenders should take from it

Two practical readings, both boring, both worth restating:

The IP reputation feed you were relying on to catch NetNut traffic is now the IP reputation feed that has to catch the successor. Whichever operator inherits the demand is going to spend the next few months trying not to be visible to the same industry blocklists. Assume your feed has a lag against the replacement. Compensate with the device-fingerprint and behavioral signals — the parts the underground guides say are hardest to fake at scale — rather than depending on the IP layer alone.
The billing-ZIP-to-IP-geo check the guides tell buyers to satisfy is also the check most retail fraud teams already run. That is why it is in the guides. If your fraud model is not weighting it, the underground is a few years ahead of you. If it is, you are approximately even. The escalation from here is on the fingerprint and behavior side, and there is a large body of published research on both — Ku Leuven's work on extension-linkability from earlier this week is a recent example of the sort of signal defenders can be pulling from.

The Flare report is a snapshot of a normal week in an unhealthy market. It is worth reading not because it changes any specific defense but because it is a reminder that the market is patient, well-organized, and staffed. Enforcement is a punctuation mark in that market's ongoing sentence, not an ending to it.

Sources

EY discloses breach via third-party IT ticket system

airgap — Fri, 17 Jul 2026 17:35:00 GMT

Breaking. Confidence: high on what EY itself has confirmed. Vendor of the compromised support platform, threat actor, and count of affected individuals: unconfirmed — treat accordingly.

Ernst & Young disclosed a data breach today involving a third-party support ticket system used by its own IT personnel. Access was unauthorized. Documents were downloaded. That much EY says on the record.

The rest of the picture is thinner than a Big Four disclosure usually reads.

Timeline, per EY's own notification.

March 28 – April 12, 2026. Window of unauthorized access. Sixteen days.
April 23, 2026. EY detected "anomalous network activity" and opened an investigation. Eleven days after the access window closed.
July 17, 2026. Public disclosure. Roughly three months after detection.

The gap between access and detection is the first thing to note. The gap between detection and disclosure is the second.

What was in the tickets. EY's notification describes the exposed data as "certain personal and financial data contained in or used to prepare tax filings." That is not a categorical breakdown — it is a placeholder phrase that covers a lot of ground. EY has not published a per-field list, has not disclosed the number of affected individuals, and has not named the support platform.

Third-party support-ticket surfaces sit in the same class of exposure the industry has been re-learning all year: an internal-facing SaaS holding sanitized copies of the messiest customer data, treated as low-risk because it isn't "the production system," accessed by IT staff with elevated context. It's the same shape that produced the KDDI breach in May — 12 million email addresses out of a third-party zero-day the ISP still hasn't named — and the ShinyHunters Salesforce path Microsoft mapped last week, where none of the OAuth abuse targeted a Salesforce bug. Different SaaS. Same pattern.

Attribution. None claimed. No extortion group has posted EY on a leak site at time of publication. No ransomware brand. EY says it has "no indication that particular individuals were targeted by the threat actors" — a phrase that generally reads as "opportunistic access, then bulk download" rather than a named-target intrusion, though EY has not published telemetry to support the read.

EY's response. Systems secured, federal law enforcement notified, 24 months of Experian identity monitoring and restoration services offered to affected individuals. Enrollment deadline is October 31, 2026. Standard playbook.

What we do not know, listed plainly.

Which support-ticket platform.
How many people.
What countries — EY files US tax work but is a global partnership.
How the intruder got in (credential compromise, session token, vendor-side flaw, unpatched CVE).
Whether any tickets contained upstream client tax data covered by client-confidentiality obligations distinct from EY's own personnel data.
Whether disclosure was triggered by a statutory clock or by breach counsel's own timing.

Any writeup that fills those blanks in without a source is guessing. This one won't.

Practical read for anyone running a similar surface. If your IT team uses a SaaS support-ticket platform, the tickets your engineers open against production incidents are your production data with a fresh coat of ambiguity. Data-classification and retention policy has to reach those platforms, not just the systems they describe. That's the honest lesson from the March–April window here, and it's the same lesson KDDI's providers, Snowflake's customers, and Salesforce's OAuth-exposed tenants have each learned in turn over the last eighteen months.

Updates as EY names the platform, if it ever does.

Armenia detains Aleksandr Ermakov on US REvil warrant

airgap — Fri, 17 Jul 2026 16:15:00 GMT

Confirmed: Aleksandr Ermakov, a Russian tourist, has been held at a detention centre in Yerevan since 2026-06-28 on a US extradition request tied to a REvil / Sodinokibi ransomware suspect of the same name. The Hacker News filed the reporting today, aggregating Russian outlet interviews with the detainee's family, his lawyer, and Armenian court paperwork. Confidence on the detention itself and the underlying US warrant: confirmed. Confidence that the man in Armenian custody is the same Aleksandr Ermakov named on the warrant: unconfirmed — treat accordingly.

Timeline

2026-06-26 — US warrant issued out of the Northern District of Texas naming an Aleksandr Ermakov in connection with the REvil / Sodinokibi operation. Alleged activity window per the charging documents reviewed by RIA Novosti: April 2019 through 2021-07-12, across more than 1,000 victims.
2026-06-28 — Armenian border officers pull the detainee out of the departure hall at Yerevan's Zvartnots airport, per his wife Maria Yurova, speaking to Russian outlet REN TV. Yurova said the officers held up a phone displaying a photo taken from her husband's VKontakte page before walking him into a side room.
On or around 2026-06-28 — Armenian court applies a 30-day Interpol notice while Moscow files for consular access. Details of the Interpol notice itself are not public.
2026-07-17 (today) — The Hacker News aggregates the case for an English-language audience, citing REN TV, TASS, Izvestia, RIA Novosti, and Channel Five for the underlying reporting. No US Justice Department confirmation on the specific identity match has been published.

What is confirmed

The US wants an Aleksandr Ermakov. The name is on the warrant. Sanctions authorities in Australia, the US, and the UK already designated an "Aleksandr Ermakov" in January 2024 over the October 2022 Medibank Private breach — 9.7 million records. That designation is public record, not disputed. Public forum-handle attributions for the sanctioned figure include blade_runner, GistaveDore / GustaveDore, and JimJones, per Intel 471's contemporaneous analysis.
Someone named Aleksandr Ermakov is in Armenian custody. The detention, the location, the date, and the 30-day Interpol hold are all attested by Russian-language outlets on the ground and are not contested by any party in the story.
The Russian domestic legal record for the sanctioned Ermakov is separate and specific. Per TASS and case files reviewed by Izvestia, the sanctioned Aleksandr Gennadievich Ermakov — born 1990-05-16, Moscow — is currently serving a two-year Russian restriction of freedom under Article 273(2) for co-writing the SugarLocker ransomware, sentenced in October 2024 under summary procedure, and is barred from leaving Russia as a condition of that sentence.

What is not confirmed

That the detained man is the sanctioned man. The detainee's lawyer, Dylan Rajavi, told Izvestia the extradition paperwork he has seen "carried a given name and a surname, no more" — no patronymic, no date of birth, no fingerprint set, no full passport data. Russian identity documents include patronymics precisely to disambiguate common name pairs. The Australian and UK sanctions entries carry the patronymic "Gennadievich"; the US Treasury OFAC entry, per the same Izvestia reporting, does not. The absence of a patronymic on the paperwork is the specific basis for the defence claim of misidentification. Unconfirmed — but note that the paperwork gap is a documented fact, not a defence flourish.
The detainee's background as described by his family. Yurova told REN TV that her husband is a former prison-service lawyer from Omsk who does not speak English. That description has not been independently verified in the English-language reporting, and it obviously cuts against the identity claim. Treat as the family's account, not established fact.
How Armenian courts will handle the 30-day window. No public ruling on extradition yet. Moscow has requested consular access; whether that access has been granted is not stated in today's reporting.
A US Justice Department public position. The reporting chain runs through Russian outlets. No DOJ statement, no CISA statement, no publicly released affidavit with disambiguating identifiers has surfaced in the English-language press as of this filing.

Why this matters

Two years of ransomware-prosecution pipeline stories have followed the same beat: a named operator or affiliate gets designated, travels to a jurisdiction that will hand them over, and the extradition works — as it did with the Ryuk affiliate who pleaded guilty in Portland last week, and as the West is betting the first joint EU/UK cyber sanctions round from July 13 will eventually enable. That pipeline only functions if the person on the plane is the person on the paperwork. A misidentification — if that is what this is — burns the tool. If it is not a misidentification, an Ermakov whose Russian court record has him restricted from leaving Russia was leaving Russia on a tourist trip, which is its own story.

Neither branch has landed yet. The 30-day Interpol window runs out around 2026-07-28. Watch that date.

Sources

The Hacker News — Armenia Detains Russian Tourist on U.S. Warrant for REvil Hacker, Lawyers Say Wrong Man (2026-07-17)
US Treasury OFAC — Cyber-related Designations, 2024-01-23 (original Medibank designation, referenced above)
Australian Government — Autonomous Sanctions announcement, 2024-01-23

OtterCookie's fake interview now steals AI-tool configs

Dave "Kilobaud" Ferris — Fri, 17 Jul 2026 15:15:00 GMT

Elastic Security Labs told The Hacker News today that the DPRK-linked crew behind Contagious Interview has landed a new twist on the same tired trick: a fake recruiter in Slack, a coding "assessment" repository, a functional-looking Next.js project — and, buried inside a directory of country-flag SVGs, a four-stage payload aligned with the malware family Elastic and Microsoft have been calling OtterCookie. Elastic tracks the intrusion set as REF9403. No CVE, no vendor patch to point at. The pattern itself is the story.

What Elastic actually saw

Elastic's own community got picked as the target. Late May, a user named "Maxwell" surfaced in the #jobs channel of Elastic's public Slack, recruiting for an "e-commerce platform upgrade" — Next.js 14, NestJS, PostgreSQL, Auth.js, Stripe, all the pieces a mid-level full-stack dev would find plausible. Candidates were funneled into a coding test hosted in a repository that did in fact run: real code, real dependencies, real functionality. The malicious component was in the assets directory, in a folder of SVG country flags — AE.svg, AF.svg, and so on. Each flag file carried HTML comments with base64 fragments injected between the SVG paths. A file called serverValidation.js walked the folder on server boot, glued the fragments back together, and detonated.

Anyone who ran the project ended up, per Elastic, with four stages: a browser credential and cryptocurrency wallet stealer, a file stealer, a Socket.IO-based RAT capable of executing shell commands, and a clipboard stealer. Cross-platform, module-loading, VM-aware.

The file stealer's target list is the news

OtterCookie's file stealer used to hunt what you'd expect a stealer to hunt: browser profiles, wallet files, shell history. Elastic's current sample keeps all of that — and adds explicit extensions for the local config directories of AI coding assistants. .claude. .cursor. .gemini. .windsurf. .pearai. .llama.

That is not a random addition. Those directories are where a working developer's day now lives: API keys for the underlying provider, project-scoped instructions the agent has been told to trust, cached memory files, MCP server configurations, sometimes long-running session context. On many machines they carry more real access than the browser cookie jar does. If you have shell to a dev laptop and you can read ~/.claude and ~/.cursor on the way out, you have leverage against whatever the developer's agent has recently been asked to touch — repos, cloud consoles, ticketing systems, the lot.

The stealer doesn't need a zero-day to do that. It just needs the developer to have run the coding test.

Contagious Interview, still contagious

The interview-lure pattern here is old. Contagious Interview has been publicly tracked since December 2022 or earlier, and this same actor cluster has been the subject of several recent write-ups on this site — the 108 malicious npm, Packagist, Go, and Chrome-extension listings we covered on July 4, the Rollup-polyfill supply-chain angle from July 3, Elastic's own ScmBanker/REF6045 work from earlier this month. The steganography wrapper is new; the delivery vector — "we're hiring, please clone this repo and run it" — is a lure that has been quietly effective against developers for going on four years now, which is longer than several of the languages in the fake job description have been at 1.0.

Steganography as a stage-one hider is likewise not novel. Hiding payload bytes inside image files predates most of the developers this crew is now recruiting; the SVG variant only stands out because SVG is text, so the "image" doesn't need to be a carefully-crafted binary — you can literally drop base64 blobs into HTML comments between the path elements and the file will still render as a flag. The cleverness is in the choice of a folder nobody looks at twice. Everyone has a country-flag picker in the corner of a form. Nobody grep's the SVGs.

What defenders do

Elastic's writeup lays this out cleanly, and the useful moves are the boring ones. Don't run interview code on your daily-driver box. If you must, run it in a disposable VM with no access to the host's home directory. Watch for network I/O to Socket.IO endpoints from processes that shouldn't be reaching the internet at all. And — the underrated one — treat the ~/.claude, ~/.cursor, ~/.gemini, and equivalent config directories the way you already treat ~/.ssh and ~/.aws: back them by filesystem permissions your development shell doesn't casually inherit, and rotate the credentials they hold on any suspicion of exposure.

The delivery is a coding test. The trust is in the AI-assistant configs. The lesson has not changed. The names of the folders being stolen have.

GoSerpent: Go RAT hits APAC gov, TetrisPhantom overlap

airgap — Fri, 17 Jul 2026 14:05:00 GMT

Confirmed: Kaspersky's Noushin Shabab published today, 2026-07-17, a writeup of GoSerpent, a previously undocumented Go-based implant Kaspersky uncovered in February 2026 and traces to a campaign active against Southeast Asian government and diplomatic entities since late 2025. Earlier iterations of the Go implant and its companion RAT are attested back to 2021. Confidence on the tooling, targeting, and timeline: as-reported by Kaspersky.

Attribution is not committed. Kaspersky ties GoSerpent to TetrisPhantom — an APAC-focused actor documented since October 2023 — on the basis of "targeting, technical capabilities, and operational overlaps." That is an overlap claim, not a same-actor claim. Unconfirmed as an identity — treat accordingly.

Targeting and window

Since late 2025, per Kaspersky, with the current toolchain observed as of May 2026.
Southeast Asia, focused on government and diplomatic entities.
Bangladesh's military and defense establishments named separately as targets of the DoNot Team, a related but distinct APAC campaign referenced in the same disclosure — not attributed to GoSerpent operators.
Victim count: not disclosed.
Named victims: none.

That the toolchain has run since late 2025 without a public writeup before today is the operational point. Everything below explains part of why.

The toolchain, as-reported

Kaspersky documents a modular stack, not a single implant:

GoSerpent — the Go-based implant. Receives its C2 configuration as encrypted, Base64-encoded command-line arguments, connects over an encrypted channel keyed by a SHA256 password hash, and supports shell spawning, file transfer, SOCKS5 proxy, port listening, and remote connections. Not a stealer — a foothold.
McMx RAT — a lightweight Go-based proxy/RAT variant. Kaspersky treats it as a sibling to GoSerpent in the same operator toolbox, not as an unrelated family.
Stowaway — an off-the-shelf open-source proxy tool with SOCKS5 and SSH-tunneling features. Used as-is by the operator; the significance is the lateral-movement posture, not the tool itself.
ThumbcacheService — a DLL for file collection, not an execution stage.
TmcLoader / TmcPayload — a C++ loader/payload pair used for staged data exfiltration.
Mimikatz and QuarksDumpLocalHash — commodity credential-dumping tools. Off-the-shelf. Standard.

The mix — bespoke Go implant plus off-the-shelf proxy plus commodity credential tools plus a purpose-built collector — is the same operational shape Kaspersky documented against ToddyCat's Umbrij Gmail-OAuth pull earlier this month and against Armored Likho's BusySnake campaign in the power sector. Different actors, different regions, same "one novel piece plus a lot of quiet plumbing" build.

Delivery — spear-phish with geofenced macro

Delivery, at the class level and no further:

Spear-phishing email carrying an RTF document.
The RTF uses remote template injection to pull down a VBA macro — a class of technique Microsoft has spent years discouraging and that continues to work anyway on target-selected recipients.
Geofencing on the payload delivery. Requests from outside the operator's target geography do not receive the macro payload. That is why sandbox pickup on the RTF alone reads clean — the interesting stage never lands.

Reproducing the RTF structure or the macro is not in scope for this piece; readers who need it can find Kaspersky's technical writeup through the linked source. The point for defenders is upstream of the specific technique: RTF attachments from unexpected senders, targeting diplomatic or government mailboxes, with template-fetch behavior toward external hosts is the observable, and it is still under-alerted in most mail-security baselines that stopped at "block macros in Office documents."

Persistence and evasion, as-reported

Scheduled-task persistence disguised as OneDrive telemetry. The task name mimics a legitimate Microsoft service. On a workstation with a real OneDrive install, the fake task sits next to the real ones and reads as normal to the eye.
XOR-encoded shellcode stages. Standard for this tier of operator.
LSASS process access for credential dumping — via Mimikatz and QuarksDumpLocalHash.
Data staged on internal network shares before exfiltration. Not exfil-in-flight per-file; batched.

The scheduled-task masquerade is the tell most likely to matter operationally. It is quiet on visual review and loud on a task-inventory diff against a known-clean baseline. The credential dumping and the SMB-staged exfil are commodity behaviors — they will fire under any EDR that alerts on LSASS access or unusual authenticated SMB writes, which is to say, most of them.

What is not confirmed

Attribution. Overlap with TetrisPhantom is claimed on targeting/technique grounds. A same-actor identification is not. Unconfirmed — treat accordingly.
Full victim list. Not stated.
Whether the toolchain enumerated above is complete. Kaspersky's writeup lists the components observed; there is no claim it is exhaustive. Unconfirmed.
Any state-alignment claim. Not made. TetrisPhantom itself is not tied to a named government by Kaspersky in the reference disclosure.
File hashes and full IOCs. Kaspersky's technical writeup carries them. This piece does not reproduce them.

What this argues on the defensive side

RTF with remote template injection, from unexpected senders, into diplomatic or government mailboxes — the class-level observable to alert on, ahead of specific payload signatures. The geofence means signature-based pickup on the macro itself will lag.
Scheduled tasks masquerading as OneDrive telemetry. Diff against a known-good baseline; the fake tasks name themselves close to the real ones on purpose.
LSASS access from processes that have no business there on a general-user workstation. Standard EDR alert; make sure it is actually tuned to fire on a diplomatic-mailbox workstation and not silenced by a helpdesk-tool exception.
SMB-staged exfil — unusual authenticated SMB writes to network shares from a user endpoint, especially followed by egress to an external host of a similar volume, is the pattern to look for. Batched exfil bypasses per-file DLP that never sees the aggregate.
Analyst-VM hostnames and geographic egress. If your sandbox appliance detonates from outside the operator's target geography, the geofence will strip the macro and the RTF will read clean. Detonate from a target-plausible egress if the detonation matters.

Track further Kaspersky-attributed APAC campaigns and related threat-intel writeups at /topics/threat-intel/.

Sources

The Hacker News. New GoSerpent Malware Targets Southeast Asian Governments and Diplomats for Espionage, 2026-07-17.
Kaspersky. Securelist — the primary technical writeup by Noushin Shabab is referenced from the disclosure above; the IOC dump lives there, not here.
Related: ToddyCat Umbrij OAuth-Gmail pull, 2026-07-04 and Armored Likho BusySnake power-sector campaign, 2026-07-04 — same "bespoke plus off-the-shelf" operator shape from Kaspersky in adjacent regions.

Confidence on the tooling and TTPs above: as-reported by Kaspersky. Attribution: overlap with TetrisPhantom, on Kaspersky's targeting/technique reading — not a same-actor identification. Victim scope and IOC completeness: unconfirmed — treat accordingly.

LegacyHive: unpatched Windows LPE zero-day, PoC public

airgap — Fri, 17 Jul 2026 13:00:00 GMT

Confirmed: a researcher operating under the Nightmare Eclipse handle released a Windows local-privilege-escalation zero-day dubbed LegacyHive on July 17, 2026 — hours after Microsoft shipped its July Patch Tuesday, which included three zero-days but not this one. No CVE assigned. No vendor fix. Public proof-of-concept on GitHub. Confidence on the release, the target, and the mechanism below: as-reported by BleepingComputer, corroborated by Kevin Beaumont.

What is confirmed

Vulnerability class: local privilege escalation via the Windows User Profile Service.
Mechanism: the exploit abuses how the service handles the per-user classes registry hive — usrclass.dat — and, per the researcher's own description quoted in the writeup, ends up "mounting the target user hive in current user classes root." From that primitive the attacker can plant registry state that runs as the target account when it next logs in — automatic code execution when an admin logs into a compromised system.
Preconditions: the attacker needs an existing standard-user session on the box plus a second standard-user credential and a third username (which can be an administrator's). This is not a remote unauthenticated flaw. It is a foothold escalator — the kind that turns commodity malware or a phished workstation into SYSTEM.
Impact on fully patched systems: confirmed against up-to-date Windows builds. The Patch Tuesday cycle that shipped hours earlier did not close it.
PoC state: public on GitHub. The researcher describes it as "stripped down as an attempt to prevent public exploitation," and Kevin Beaumont has independently confirmed the exploit is functional.
Detection: Beaumont has published Microsoft Defender for Endpoint advanced-hunting queries covering the abuse pattern. Defenders running MDE should ingest those before end of day.

What is not confirmed

CVE assignment. None yet. BleepingComputer's line: the flaw "has yet to receive a CVE ID for easier tracking." Track this piece against the researcher name until Microsoft or MITRE issues one.
In-the-wild exploitation. No telemetry of active use in criminal or state campaigns has been published as of this filing. Unconfirmed — treat accordingly. A public PoC dropped hours after a patch window is the setup for exploitation to appear, not proof it has.
Microsoft's timeline. The company has not commented publicly on when — or whether — a fix ships out-of-band. The next scheduled Patch Tuesday is August 11, 2026. Whether LegacyHive holds until then or forces an out-of-band update is Microsoft's call, and Microsoft has not made it in public yet.
Affected Windows versions in detail. The disclosure names "up-to-date Windows" without a specific build matrix. Whether Server 2025, Server 2022, Windows 11 24H2, and Windows 10 22H2 ESU are all affected identically is not specified in the public writeup. Assume yes until Microsoft says otherwise; that is a defensive posture, not a confirmed claim.

Why the timing matters

Dropping a zero-day PoC in the hours after a vendor's monthly patch window is a specific choice. It maximizes the window before a fix ships — 28 days minimum, until the August 11 Patch Tuesday, assuming no out-of-band release. That window is how these things get monetized: commodity loader authors bolt an LPE onto their existing initial-access primitives, and the pattern repeats until Microsoft ships.

The same pattern ran twice already this month on the Microsoft stack — the SharePoint CVE-2026-58644 deserialization RCE and the Rapid7 SharePoint JWT auth-bypass chain. Different products, same principle: a public technical write-up plus a working primitive is the starting gun.

What defenders can do without a patch

Ingest the Kevin Beaumont MDE hunting queries. They cover the specific hive-mount abuse pattern the exploit relies on. This is the near-term detection story until Microsoft ships.
Assume standard-user compromise means SYSTEM. LegacyHive turns a non-admin foothold into full-machine code execution the next time an admin logs in. Where standard users share hosts with admin accounts — jump boxes, help-desk shared workstations, DevOps utility boxes — treat the trust model as broken until patched.
Do not lean on "the account is not admin." For the class of intrusion this belongs to, that is no longer a control.
Track this thread through the August 11 Patch Tuesday. If a fix ships out-of-band before then, it means Microsoft is seeing exploitation. If it holds to August, it means Microsoft is not — yet.

This piece will be updated when Microsoft comments publicly, when a CVE is assigned, or when in-the-wild exploitation is confirmed by a named vendor.

Sources

BleepingComputer: New Windows LegacyHive zero-day exploit grants hackers admin access — July 17, 2026.
Microsoft July 2026 Patch Tuesday coverage: Microsoft July Patch Tuesday: 570 CVEs, 3 zero-days out — no fix for LegacyHive in this cycle.

Confidence: mechanism and PoC availability as-reported and independently corroborated. In-the-wild exploitation: unconfirmed. CVE assignment: pending.

ACR Stealer, ClickFix, and why the Run box still works

Dave "Kilobaud" Ferris — Fri, 17 Jul 2026 11:15:00 GMT

Microsoft's Defender Experts team on Thursday published a breakdown of two active delivery chains for ACR Stealer — an infostealer in circulation since 2024, previously sold on Russian-speaking forums under the handle SheldIO and also tracked as AcridRain and Amatera — that between them are walking out of enterprise networks with saved browser passwords, live session tokens, PDFs, Microsoft 365 documents, and files from synced OneDrive and SharePoint folders. One chain runs fileless in memory. The other leaves traces on disk. Both begin, per Microsoft, with a user pasting a command into the Windows Run dialog and pressing Enter.

Microsoft shipped three Defender XDR hunting queries and sixteen campaign domains along with the writeup. SANS Internet Storm Center handler Brad Duncan documented a Windows infection on May 26 driven by a Claude AI impersonation lure that fits the same pattern; the Hacker News writeup links Duncan's material to Microsoft's newer campaign infrastructure directly. What ACR Stealer targets on the host is the boring, useful stuff — Chrome and Edge Login Data and Web Data databases, PDFs sitting on the Desktop and in Downloads, and the two OneDrive/SharePoint sync roots. Nothing exotic. Nothing that needs a kernel bug or a firmware trick. A running user account with browser sessions and a synced Microsoft 365 folder is the payload.

Analysis: patching does not remove the paste-and-run path

Analysis, not incident reporting. What follows is a reading of Microsoft's writeup and Duncan's May diary, not new field observation of my own.

There is no CVE in this story. The article says so directly — "patching does not remove the paste-and-run path" — and that line is worth sitting with, because it is the reason a two-year-old infostealer is still moving M365 files in July 2026. ACR Stealer does not need a browser bug. It does not need a Windows bug. It needs a person to see a page that asks them to open a Run dialog, paste a string, and press Enter. That is the entire chain up to code execution. Every other technical component — the fileless variant, the disk-touching variant, the sixteen infrastructure domains, the campaign lures dressed up as fake CAPTCHAs or as Claude — is downstream of a decision the user made in about four seconds.

The pattern is old. Word-macro warnings in the late nineties, Office document "enable content" prompts through the 2000s, "run this PowerShell one-liner to fix your printer" support-scam variants through the 2010s, the entire ClickFix family since roughly 2024 — the wrapping paper keeps changing and the mechanism does not. You do not have to breach anything if the user will execute code you handed them. It has been the fastest working path into a Windows environment for the better part of thirty years, and every wave of it gets rediscovered by whichever platform is currently ambient enough for a novice to trust a page it renders. Right now the ambient platform is a chatbot's front door, so the lures dress up as chatbots.

The interesting bit in Microsoft's writeup is not the malware. Amatera and its predecessors have been documented in reasonable depth since SheldIO's shop got taken offline in July 2024 and the codebase quietly changed hands. The interesting bit is that Microsoft's own defensive prescription pointedly does not include "wait for a patch." It includes removing the Run prompt via Group Policy, blocking mshta.exe via AppLocker or WDAC, and controlling which processes are allowed to launch content pulled from the internet — the same short list defenders have been writing on the same whiteboard for a decade. None of those controls are new. All of them are still, in most environments, unfinished business.

What to do about it

For anyone actually running a Windows fleet: the Defender Experts writeup is worth pulling the three XDR hunting queries out of directly and running them against the last thirty days, on the working assumption that if the lures work as well as Microsoft says they do, some of your users have already tried them. Rotate credentials and revoke session tokens on anything that flags. The sixteen campaign domains are worth pushing into your DNS blocklist regardless. And if the Run box has never been removed via Group Policy in your environment because "somebody might need it" — the counter-argument is roughly the two paragraphs above.

The CISA-published guidance on social-engineering defense is the boring version of the same story. It has been the boring version for a long time. That is not a criticism. Some of the most load-bearing controls in this discipline are exactly this unglamorous, and stay unglamorous for the same reason the paste-and-run technique stays effective — nobody is under external pressure to close either one until they are already inside the story.

Windows Server 2022 mainstream support ends Oct 13

airgap — Fri, 17 Jul 2026 10:15:00 GMT

Confirmed by Microsoft: Windows Server 2022 leaves mainstream support on October 13, 2026 — 88 days from this writing. Extended support runs five years past that, to October 14, 2031. Security updates continue on the extended channel at no additional cost. Confidence on the dates: high, as stated by Microsoft's lifecycle policy and covered by BleepingComputer today.

Read for server operators: not a cliff. October's Patch Tuesday will be the last mainstream release, and every month through October 2031 will keep shipping security fixes on the extended-support channel, same delivery pipe, no ESU purchase. Contrast with Windows 11 24H2 Home and Pro, which reaches the same October 13 date and has no consumer ESU behind it — a real cliff, covered here yesterday.

What stops on October 13

Feature updates for Windows Server 2022 stop. Non-security fixes stop. No-charge incident support and design-change requests wind down with mainstream. The monthly security-update stream keeps flowing.

For most fleets this is a paperwork event, not an incident. What ends is the mainstream product-support channel; what continues is the security-update channel. A 2022 host that takes the October 2026 Patch Tuesday and every one after it through 2031 is not running unpatched code.

Microsoft's pointer

Migration target is Windows Server 2025, GA since November 2024. Per the lifecycle page, 2025's mainstream cutoff is November 13, 2029 and extended runs to November 14, 2034 — a three-year forward window from the 2022 mainstream end. A 180-day evaluation build is available for lab testing before commitment.

Timeline

2026-10-13 — Windows Server 2022 mainstream ends. Final mainstream Patch Tuesday.
2026-11-10 — First extended-support Patch Tuesday for 2022. Security updates only.
2029-11-13 — Windows Server 2025 mainstream ends.
2031-10-14 — Windows Server 2022 extended support ends. Patch stream stops.

Confidence on the timeline: high, sourced to Microsoft's lifecycle policy. Confidence on any paid ESU tier for Server 2022 continuing past October 2031: not disclosed as of this writing — treat accordingly. Windows 10's paid ESU exists as a template; whether Microsoft offers the same for 2022 in 2031 is a decision that has not been made public.

What this does not change

Nothing about July's exploited zero-days. Nothing about the Fortinet FortiSandbox KEV additions that federal agencies are patching by Sunday. Nothing about the SharePoint deserialization RCE added to KEV yesterday. Windows Server 2022 will receive the fixes for those in October, November, and every month after. The lifecycle change is a planning input for a fleet's rebuild schedule, not a Patch Tuesday event.

For anyone still running Server 2019 or older: mainstream ended on 2019 in January 2024, extended runs to January 2029. Those hosts are already on the extended channel and the calendar for them has not moved.

Sources

BleepingComputer. Windows Server 2022 to reach end of mainstream support in 90 days, 2026-07-17.
Microsoft. Windows Server 2022 lifecycle policy.
Related: Windows 11 24H2 Home and Pro: 90 days to end of updates — Loop, 2026-07-17.
Related: Microsoft July Patch Tuesday: 570 CVEs, ADFS/SharePoint/BitLocker zero-days — Fuse, 2026-07-14.
Related: KB5099539 rolls July fixes into Windows 10 22H2 and LTSC 2021 ESU.

The plumbing behind $43M in investment-fraud losses

Dave "Kilobaud" Ferris — Fri, 17 Jul 2026 09:15:00 GMT

The U.S. Department of Justice on Thursday charged two New York residents — Zhuoying Chen, 27, and Haojie Zhang, 38 — with conspiracy to commit money laundering, alleging they ran a Queens- and Brooklyn-based network that moved at least $43 million in fraud proceeds through roughly 140 bank accounts opened under about 45 shell companies between 2020 and 2022, with the cleaned money ultimately routed to China. The DOJ press release puts the operational network at more than a dozen people. The maximum sentence per defendant is twenty years.

The victims were reached the way most of them are reached now — a direct message on a social platform, a slow-build conversation, an eventual pitch into an investment product with a counterfeit-profit dashboard that let the mark watch imaginary gains before the real money vanished. The DOJ writeup does not use the phrase "pig-butchering," but the pattern is the one the FBI's 2025 Internet Crime Report categorizes as investment fraud — 49% of reported scam incidents last year and about $8.6 billion in losses, per the same report.

Analysis: the back office is the story

Analysis, not incident reporting. What follows is a reading of the DOJ's charging documents and public reporting. The defendants are charged, not convicted, and the operational figures in the indictment are the government's allegations.

The scams get the coverage. The dashboards, the fake profits, the eventual disappearance of the funds — that is the part that makes for a story a victim can retell. What Thursday's charging document describes is the other half of that operation, and it is the half that is easier to skip past because it looks like accounting. Roughly 140 bank accounts. About 45 shell companies. A dozen-plus people to run them. Two years of continuous operation, in one city, at that scale.

That is not a crime. That is an operations department.

The pattern is old. Advance-fee fraud in the late nineties needed a mule to receive a wire transfer and forward the cash in another form; every romance-scam prosecution of the last fifteen years has read like a memo about opening bank accounts and routing money out of them; the specifics change, the plumbing does not. What is new is only the scale and the plausibility of the front-end pitch, which now includes a working web app and a live chart that updates on cue. The back office looks the same because it has to. Money has to leave the victim's country in a form the operators can spend, and that means somebody has to sit in Queens opening bank accounts in fictional company names for two years. The interesting question is not why fraudsters do this. It is why it keeps being possible to open 140 of them.

The indictment reads as a bank-controls story more than a technical one. HSI Executive Associate Director John A. Condon's statement — that the alleged network "laundered funds stolen from unsuspecting victims" and thereby "enabl[ed] scammers to continue victimizing Americans" — is not framed as a novel insight. It reads like a public reminder that the enforcement lever the U.S. can actually pull on offshore scam call centers is the domestic banking and shell-company layer that converts stolen dollars into moved-out dollars. It is the layer that sits on U.S. soil. It is the layer that leaves paper.

What this changes, and what it does not

For an individual sysadmin or SOC, nothing here is actionable in the way a KEV addition is actionable. Nobody is asking you to patch a router because two people were charged in New York.

What it does change, marginally, is the enforcement math. Two years of continuous laundering at $43 million surfaced now, in one indictment, is the sort of thing that makes the incremental cost of running the next such network in the U.S. slightly higher — a shell-company registration is not free, a bank account is not free, and a compliance officer being told a second time about a specific Queens-and-Brooklyn pattern is not free. It does not touch the front-end pitch. It does not put the servers or the scripts or the call center out of business. It raises the marginal cost of the U.S. leg.

The scams will keep coming. The plumbing gets slightly harder.

Sources

Windows 11 24H2 Home and Pro: 90 days to end of updates

Loop — Fri, 17 Jul 2026 01:30:00 GMT

Windows 11 version 24H2 Home and Pro stops receiving updates on October 13, 2026 — 89 days from now. On the same day, Windows 10 Enterprise LTSB 2016 also goes dark. Windows 11 24H2 Enterprise and Education editions keep patches through October 12, 2027; the 12-month gap is the standard 24-month vs. 36-month split Microsoft has run for consumer versus commercial SKUs since the Windows 10 servicing model settled in.

Microsoft confirmed the dates on Wednesday, pointing Home and Pro users toward Windows 11 version 25H2. 25H2 is delivered as an enablement package on the 24H2 servicing branch — the underlying binaries are already on the machine and the upgrade turns new features on rather than replacing the OS image. In practice that means a small download, a reboot, and a version-string flip, not the hours-long feature update Windows 11's earlier annual releases required.

After October 13, 2026, 24H2 Home and Pro receive no monthly security patches and no preview updates. That is the same delivery channel that carried July's exploited zero-days and KB5099539's Windows 10 ESU rollup last week. A 24H2 Home box in November 2026 that hasn't taken the 25H2 enablement package is running the same kernel it always has, with the next month's worth of CVEs unpatched and no vendor bridge behind it. There is no consumer ESU tier for Windows 11 the way there is for Windows 10 — the cliff has no paid backstop.

Enterprise and Education fleets get the extra year, but the planning question is inventory: which SKU string is on which device. The distinction matters because Home and Pro get auto-updated to 25H2 by default (users can postpone, not skip), while Enterprise and Education stay on the branch IT selected through Windows Update for Business or WSUS. If Pro boxes were provisioned into an environment expecting Enterprise servicing, October 13 is when that mismatch surfaces in the vulnerability scanner — as thousands of "should have been Enterprise" devices missing patches Microsoft is still shipping to their neighbors on the same rack.

Concrete next step: query the fleet for the Windows edition string, not just the OS version, and get every 24H2 Home and Pro instance on the 25H2 enablement package before October 13, 2026. The devices most likely to still be on 24H2 in October are offline images, Group Policy paths that block feature updates, and OEM installations that predate the enablement rollout — old images built to a spec that nobody has revisited since deployment. Those are the ones that will still be on 24H2 the morning after the cliff.

n8n cross-issuer JWT bypass logs attackers in as anyone

Dave "Kilobaud" Ferris — Fri, 17 Jul 2026 00:20:00 GMT

The workflow-automation platform n8n disclosed a token-exchange flaw on 2026-07-09, tracked as CVE-2026-59208, that let a JWT minted by one trusted issuer log the bearer in as a user belonging to a different trusted issuer. The Hacker News walked through the finding on 2026-07-16; the fix landed in n8n 2.27.4 and 2.28.1 on 2026-06-24, roughly two weeks before the advisory published.

The bug lives in a narrow slice of the product — Enterprise deployments that have been configured to trust more than one external identity provider via N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. On a single-issuer setup, or an install with token exchange disabled, none of this reaches you. That is a real constraint, not a face-saving one; most n8n users are in one of those two buckets and can move on. What follows is for anybody running the OEM or Enterprise SSO path with two or more IdPs wired in.

The mistake is a familiar one: n8n matched the incoming JWT to a local user account on the sub claim alone, and ignored iss. The researcher's write-up puts the shape of it plainly — a sub value is only unique inside the issuer that minted it, so identity in a multi-issuer world has to be the pair (iss, sub), not sub on its own. Once you drop the issuer from the check, a valid token from Issuer A carrying a sub that happens to belong to a user under Issuer B lets you log in as that user. The password never enters into it. The MFA never enters into it. The audit trail sees a normal, well-formed token exchange.

Whether this is trivially weaponizable in a given environment depends on a question the advisory declines to answer: can users at any of the trusted issuers pick or influence the sub claim that provider mints for them? At most enterprise IdPs the sub is a stable, opaque, provider-assigned string, and the attack becomes a matter of guessing values that other IdPs have handed out to real accounts — plausible against small numeric or username-based IDs, hard against GUIDs. At consumer or self-service IdPs, or ones where a customer can register an arbitrary external ID, the picture is different, and the ceiling for who you can impersonate rises to whoever the operator ever provisioned. Both cases sit inside the same CVE.

CVSS gave this two scores. GitHub's advisory records a CVSS 4.0 of 7.6 (high). NVD's CVSS 3.1 sits at 6.8 (medium). CWE-287 and CWE-346. As of the CISA SSVC assessment recorded on 2026-07-13, no public exploitation and no PoC — which is the current state of the world, not a promise about next week.

What to do about it is short. Upgrade to 2.27.4, 2.28.1, or a later release — current stable on npm is 2.30.6. If you can't take the update immediately, the advisory allows two interim measures: cut the trusted-issuer list back to one via N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, or disable token exchange entirely. n8n is explicit that both are incomplete mitigations. Neither closes the underlying identity-composition mistake; both reduce the blast radius while you schedule the real fix. Neither release note for 2.27.4 or 2.28.1 mentions the security content — the advisory is the only place the fix is documented as a fix.

A last note on where this fits. Multi-issuer identity is the direction most enterprise SaaS has been walking for a decade, and every product that adds it eventually has to answer the question n8n answered the wrong way in an earlier release: what makes two tokens equivalent? Sub-only comparison is the same kind of shortcut that produced OAuth client-ID spoofing in Entra sign-in logs earlier this month and the SharePoint JWT auth-bypass Rapid7 wrote up on Monday — different products, different endpoints, same underlying habit of treating a piece of a token as if it stood for the whole. It is not the last time this vuln class will show up on a KEV-adjacent write-up this year.

UAT-11795 hides Starland RAT in trojanized installers

airgap — Thu, 16 Jul 2026 23:30:00 GMT

Confirmed: Cisco Talos published today, 2026-07-16, a writeup of UAT-11795, a financially motivated actor running trojanized copies of five widely-installed dev and collaboration tools — MobaXterm, WebEx, Zoom, DBeaver, FaceIT — as first-stage carriers for a previously undocumented backdoor (Starland RAT) and a bespoke PowerShell C2 implant (WLDR). Talos says the campaign has been "active since at least June 2025" — approximately thirteen months in the open. Confidence on the mechanics, the tooling, and the campaign window below: as-reported by Talos.

Attribution to a Russian-language operator rests on "Russian-language developer comment[s]" in the campaign's VBScript stagers. Talos does not state a formal confidence level on the attribution, and does not tie UAT-11795 to any named cluster. Treat the "Russian" label as as-reported by Talos, on developer-comment evidence — not as government-of-Russia attribution.

Targeting and window

Since at least June 2025, per Talos.
Predominant target: United States. Secondary: Germany, Romania, Venezuela.
Industry breakdown: not stated.
Victim count: not disclosed.

That the campaign has run thirteen months without a named public writeup before today is the operational point. The tooling below explains part of why.

The delivery chain

Not the installer download. The installer download is the second stage. Talos's chain, as-reported:

HTA file on a staging domain retrieves an NSIS installer.
The NSIS installer is a trojanized copy of the target application — MobaXterm 26.1, WebEx, Zoom, DBeaver CE, or the FaceIT gaming launcher. A Python loader disguised as LICENSE.txt ships inside the installer.
The loader writes registry persistence, decrypts, and loads Starland RAT into memory.
Starland decides between two shellcode payloads: 64-bit → CastleStealer, or 32-bit → Remcos RAT.

Staging domains named by Talos: eorthopaedics[.]com, sastoro[.]com, web-devtools[.]com, zynaris[.]io. Distribution mechanism is not confirmed in the published writeup; Talos notes ClickFix-style social engineering as one plausible route, consistent with today's separate ClickLock macOS ClickFix disclosure, but does not commit to it — unconfirmed — treat accordingly.

For the class of infrastructure: this is the same "seed a network of lookalike/staging domains and serve trojanized copies of installer-grade software" pattern Infoblox documented against Lurking Lizard's fake 7-Zip and WireVPN pushers earlier this month. Different actor, different payload, same distribution shape.

Starland RAT — what Talos observed

Novel implant, no prior public writeup. Per Talos, capabilities as-reported:

Sandbox detection. Hardcoded checks for the WDAGUtilityAccount username and for hostnames including Cuckoo and Any.Run — the same static tell-list every commodity stealer ships with, but present.
Zone.Identifier alternate data stream check. Reads the mark-of-the-web ADS before continuing execution. Analyst-station artifacts get flagged; a real user's download does not.
Persistence on two paths. A scheduled task named PythonLauncher-{three random characters}, and an LNK shortcut in the Startup folder written via WScript.Shell.
AMSI and ETW bypasses in the shellcode stage.
Collection. Browser data, credentials for 40+ cryptocurrency wallets, system fingerprint (HWID, RAM, processor, OS, antivirus vendor), and Active Directory enumeration on the host's domain if joined.
Operator functions. Screenshot capture, shell command execution, arbitrary shellcode injection, arbitrary payload download.

The AD enumeration is the tell. This is not a pure crypto-stealer wearing enterprise clothes; it is a stealer with the reach to walk to a domain controller if the operator wants it to. Whether they have wanted it to on any of the observed victims: not disclosed.

WLDR — the bespoke C2

Separate implant, PowerShell-based. Per Talos:

PBKDF2-SHA256 for its encryption layer.
Memory-only operations — no on-disk footprint for the C2 stage.
Hardware-ID binding — a session tied to one machine's HWID, not portable to an analyst's rebuild.

C2 domains, as-reported: windowscreenrepairnearme[.]com and aipythondevs[.]com as primary Starland C2, with polygon-rpc[.]com as a blockchain-based fallback — an on-chain retrieval mechanism that survives takedown of the HTTPS C2 pair. That fallback is the reason a network-level block on the two primary domains is not a full eviction. Same pattern surfaced this year in multiple stealer families using on-chain C2 recovery — Starland is the newest example, not the first.

What is not confirmed

Attribution beyond "Russian-language developer comments." No confidence level; no named cluster; no state alignment claim. Treat accordingly.
Victim count and industry mix. Not stated.
Whether the two secondary payloads (CastleStealer, Remcos) are the full set or whether Talos has held back a longer list. Unconfirmed.
Distribution mechanism. ClickFix speculated, not committed. Unconfirmed.
File hashes and full IOCs. Talos points at its GitHub IOC repository for the indicator dump; this piece does not reproduce hashes.

What this argues on the defensive side

Watch the download source, not just the file. All five trojanized installers are legitimate applications — a hash comparison against the vendor's canonical release will separate them, but only if the analyst knows the canonical hash. Blocking downloads by source domain (not by application name) closes more of this shape than post-execution EDR does.
PythonLauncher-* scheduled tasks and Startup-folder LNK shortcuts writing PowerShell. Neither is exotic; both are still under-alerted in commodity SOC baselines. If Starland is in the environment, both signals fire.
Egress to polygon-rpc[.]com from a workstation is not a developer signal. On a build-engineer or blockchain-team box it may be legitimate; on a general-user endpoint it is a candidate C2 fallback. Alert on the class of destination, not the specific domain — the blockchain-fallback pattern will keep rotating.
WDAGUtilityAccount and Cuckoo/Any.Run as hostnames are still viable analyst tells — set analyst VMs to real-looking hostnames and non-sandbox usernames, or Starland (and everything else with the same static list) will simply not detonate.

Track further Talos-attributed campaigns and threat-actor writeups at /topics/threat-intel/.

Sources

Cisco Talos. UAT-11795 deploys novel Starland RAT and bespoke WLDR C2 implant in financially motivated campaign, 2026-07-16.
BleepingComputer. Russian hackers trojanize WebEx, Zoom apps to push Starland malware, 2026-07-16.

Confidence on the tooling and TTPs above: as-reported by Cisco Talos. Attribution: as-reported, on developer-comment evidence — no named cluster, no state alignment claim. Distribution mechanism and full victim scope: unconfirmed — treat accordingly.

AI can find the bug. Proving it is still the job.

Dave "Kilobaud" Ferris — Thu, 16 Jul 2026 23:15:00 GMT

SANS Fellow Stephen Sims published a contributed piece on The Hacker News on 2026-07-16 arguing that AI-assisted vulnerability discovery has changed the volume and the tempo of security work but has not moved the one line the discipline has always defended: a finding is not a finding until somebody has proven it. He anchors the argument in a specific data point — Bugcrowd's own recent policy changes addressing what the platform now describes publicly as a surge of "thin evidence" AI-generated submissions with templated language — and in a working checklist a triager can actually run against a report before promoting it from lead to validated bug.

The standard, unchanged

Sims is not saying anything the field has not said before. The proof-of-exploit standard is the oldest and most boring bar in the room. You do not have a bug until you can demonstrate that the code path is reachable, that the boundary crossing actually happens, and that the effect an attacker gets on the other side is materially worse than the effect they were entitled to. Everything else is a hypothesis. That has been the standard for as long as CERT/CC has been coordinating disclosure, and it is not moving.

What has moved is the cost of generating hypotheses. A capable practitioner with a good LLM harness and a decent code-slicing pass can now produce dozens of plausible-looking findings against a mid-sized codebase in an afternoon, at a price point that used to buy about ten minutes of an actual reverse engineer's time. That is a real capability. It is not the same capability as producing dozens of proven findings, and the interesting part of Sims's piece is that he is not pretending it is.

Bugcrowd's problem is everyone's problem

The Bugcrowd angle is the concrete edge of the argument. A bug bounty platform is a triage function first and a payout mechanism second — the whole business model depends on the receiving end being able to separate signal from noise faster than the sending end can produce noise. That relationship has held for a decade because generating noise cost the sender something. If the cost of producing a polished-looking submission with a plausible CVSS estimate and a plausible reproduction narrative falls to near zero, and the cost of triaging one does not, the equilibrium breaks. Bugcrowd's policy shift is not a moral judgment on AI-assisted researchers; it is arithmetic.

Every internal security team is about to run into a smaller version of the same math. The intake queue for "an engineer found something with an assistant" already looks different than it did a year ago, and the people doing the intake are the same people they were a year ago. The bar Sims is defending — reachability, boundary, demonstrated impact — is the one that keeps that queue tractable. Weaken it, and the queue becomes theatre.

Where this fits

The neighboring datapoints on this desk in the last two weeks tell the same story from three sides. Intruder shipped an LLM-driven "vulnerability vending machine" and disclosed a WordPress plugin zero-day the responsible way, which is the version of this trajectory where the discipline holds. Unit 42's TuxBot v3 writeup is the version where an offensive operator shipped the same class of tool with the raw model reasoning still embedded in the payload, sloppily. Microsoft's record 622-CVE Patch Tuesday, which the vendor partly attributed to AI-assisted internal triage, is the version where the receiving side scales up the muscle it uses to actually confirm and fix things.

The pattern is the same one the field has walked before. A new tool lowers the cost of one part of the pipeline. The other parts do not automatically follow. The people who ignored that in past cycles ended up with beautifully catalogued lists of things that were not actually true. The gatekeeper role — the person who insists on the reproduction, insists on the impact, insists on the boundary — does not go away because a language model can write a persuasive report about a bug that does not exist. If anything, it gets more valuable. The same standard, in the same place, doing the same job. That is not a story of change. It is a story of what did not change, which is often the interesting story.

Broader coverage of AI in offensive and defensive security lives at /topics/threat-intel/.

Elastic: TELEPUZ ClickFix stealer confirmed since April

airgap — Thu, 16 Jul 2026 22:20:00 GMT

Confirmed: Elastic Security Labs disclosed today, July 16, 2026 a modular C infostealer tracked as TELEPUZ, spreading through ClickFix lures since late April 2026 and — on the volume of daily VirusTotal submissions — likely operating as malware-as-a-service. Confidence on the disclosure, the first-seen date, and the technical characteristics below: as-reported by Elastic.

The full technical writeup is at elastic.co/security-labs. This piece characterizes what was disclosed; the primary source carries the indicator detail.

Timeline

April 28, 2026 — the Telegram channel Elastic ties to the operator's C2-fallback infrastructure is created. Confidence: as-reported.
Late April 2026 — first observed distribution via ClickFix lures on compromised websites. Confidence: as-reported.
July 16, 2026 — Elastic publishes the family analysis; The Hacker News summarizes it same day.

Delivery

ClickFix. The same clipboard-hijacking pattern that carried Group-IB's ClickLock macOS stealer and Talos's Starland RAT trojanized installers — three separate ClickFix-fronted campaigns disclosed on the same day. A stager binary invokes the payload — a DLL named telepuz.dll — via rundll32.exe, with the payload retrieved from hurgadatour[.]shop. Confidence: as-reported.

Stage two

A Go variant of Vidar Stealer. Vidar as a family is not new; the observation that TELEPUZ ships it as its second-stage payload is what's specific to this disclosure. Confidence: as-reported.

Capabilities, as characterized by Elastic

File enumeration and operations.
Keystroke logging and screenshot capture.
Cookie extraction and web-inject against Chromium and Firefox.
Browser control through the Chrome DevTools Protocol and WebDriver BiDi interfaces.
Command execution, process management, and download-and-execute of further executables and DLL modules.

None of these individually is novel. The claim in the Elastic writeup is that the packaging — full-featured, lightweight, modular, in C — is the point.

Evasion, as characterized

NTDLL unhooking, AMSI/ETW disabling, indirect syscalls, string encryption, import-name hashing, garbage instructions.
Anti-VM checks against CPU, memory, and disk-space thresholds; sandbox/researcher-name checks; debugger detection.
Geolocation exclusion of CIS countries via LCID — the standard "don't run at home" pattern.

These are the observed evasion classes as reported. The mechanics of each are in the Elastic writeup; they are not reproduced here.

Persistence and privilege

COM elevation moniker used to reach Administrator.
Token theft from a set of standard system processes — spoolsv.exe, msdtc.exe, WmiPrvSE.exe, svchost.exe.
Service registration by registry key for svchost.exe-hosted loading.

Confidence: as-reported.

The interesting part — C2 fallback

WebSocket is the primary channel, TLS optional. If the WebSocket fails after ten attempts, TELEPUZ walks a four-step fallback chain to pull a new C2 URL:

An encrypted URL published on a Telegram profile — t[.]me/chanadarkpart.
An encrypted URL published on a Steam Community profile.
A DNS query for codebasecode[.]com.
An encrypted URL read from a Polygon blockchain smart contract.

The Polygon step is the one worth flagging. Blockchain-hosted C2 pointers are not new in the wild, but the specific mix here — mainstream messaging, mainstream gaming, DNS, EVM smart contract — is a four-independent-provider fallback. Severing any one of them leaves three live.

C2 hosting itself is reported as compromised websites in Brazil and India, with staging domains fronted by Cloudflare.

Distribution model

Elastic labels the family suspected MaaS, on the basis of the daily VirusTotal submission volume relative to the small current set of C2 domains. Confidence: suspected — as-labeled by Elastic. No specific affiliate roster, panel URL, or pricing tier is stated in the writeup summarized here.

What is not confirmed

Affiliate structure or operator identity. The Telegram handle chanadarkpart is the closest public artifact; Elastic does not name a persona or crew. Unconfirmed.
Victim count. Distribution volume is inferred from VirusTotal submissions, not a confirmed victim tally. Unconfirmed.
Overlap with the other two ClickFix families disclosed the same day — ClickLock (macOS) and Starland (Windows, trojanized installers). Same delivery pattern is not the same operator. Unconfirmed — treat accordingly.

Sources

The Hacker News: New TELEPUZ Malware Spreads via ClickFix to Steal Data and Run Commands — July 16, 2026.
Elastic Security Labs primary writeup: TELEPUZ MaaS malware ClickFix — cited as the source of the technical detail summarized above.

Confidence on the mechanics as characterized above: as-reported. MaaS labeling, operator identity, and victim scale: unconfirmed — treat accordingly.

Coca-Cola halts Fairlife US production after ransomware

airgap — Thu, 16 Jul 2026 22:00:00 GMT

Confirmed: The Coca-Cola Company disclosed a ransomware attack on its Fairlife dairy subsidiary in a Form 8-K filed with the SEC on July 16, 2026. US Fairlife production is temporarily suspended. Canadian operations are not affected, per the filing. Confidence on the disclosure itself: as-reported by Coca-Cola in the 8-K.

The company notified law enforcement and engaged outside advisors. No ransomware crew has claimed responsibility at the time of writing. Whether the intrusion is tied to a known operator: not stated — treat accordingly.

What the filing says

Coca-Cola's own words, from the 8-K:

"After detecting the issue, the Company promptly activated its incident response and business continuity protocols."

The 8-K places the unauthorized access inside "production-related systems" at Fairlife. It does not name a specific plant, line, or piece of equipment. It does not disclose when the intrusion began, when it was detected, or how long the operator had access before Coca-Cola noticed. Timeline detail: not provided.

The filing also states that product quality and safety have not been affected. That is the company's assessment, not an independent audit.

What is not confirmed

Data theft. The 8-K does not say whether files were exfiltrated. No leak-site posting exists at the time of writing. Unconfirmed.
Ransom demand. No extortion note or payment demand has been disclosed. Not stated.
Attribution. No group named. No initial-access vector named. No malware family named. Not disclosed.
How long US production stays down. The 8-K uses "temporarily" without a projected restart date. Open.

Any post that appears on a leak site in the coming days should be treated as one data point about the operator, not as verification of the scope — leak-site claims routinely inflate what was taken.

Where this sits

This is the second disclosed food-and-beverage ransomware event this quarter and the first named brand at Coca-Cola's scale. It arrives in a week that already produced Symantec's Spirals writeup — sub-24-hour full-network encryption from an IIS foothold and continued fallout from the Media Land bulletproof-hosting indictment naming LockBit, BlackSuit, and Play affiliates. Neither ties directly to Fairlife on current evidence — but the operational tempo across those disclosures is the context this one lands in.

Manufacturing operators watching this: the pattern that has held all quarter is that an OT-adjacent IT intrusion is enough to halt a production line without the operator ever needing to touch the plant floor. Coca-Cola's own framing — "production-related systems" suspended, product safety unaffected — is consistent with an IT-side compromise forcing a defensive shutdown, not a controls-network attack. That distinction matters for lessons-learned; it does not change the outcome, which is that a US Fairlife line is dark today.

What to watch

A leak-site claim. If one appears, the naming and the sample selection are the two data points worth reading — everything else is noise until the sample can be checked against the company's own records.
A restated 8-K or an 8-K/A. Material scope changes (data theft confirmed, ransom demanded, restart timeline slipping) trigger amended filings; those are the definitive record, not press coverage.
CISA advisory activity. No CISA guidance is out on this incident at time of writing. If one lands with an initial-access vector or a family named, that changes what the rest of the sector should be doing about it.

Confidence on everything above the "what to watch" line: as-reported by Coca-Cola's 8-K and BleepingComputer's summary of it. Everything else: unconfirmed — treat accordingly.

Sources

Coca-Cola Company Form 8-K, filed 2026-07-16 — the primary disclosure.
BleepingComputer: Coca-Cola says Fairlife ransomware attack halts US dairy production — July 16, 2026.