Package 1Observed campaign

Borrowed doors: OAuth, app passwords, and linked devices

What happened

Google Threat Intelligence Group described three distinct suspected Russian cyber-espionage clusters—UNC6293, UNC7005, and UNC5976—using legitimate authentication and messaging workflows against selected people in Europe and the United States. The trick is uncomfortable because the login screen may be genuine. The attacker supplies the context, persuades the target to complete a valid workflow, then asks for the resulting URL, code, consent, app password, or device link.

Evidence and timeline

GTIG tracks UNC7005 from at least February 2026, UNC5976 from March, WhatsApp device-linking activity in May and June, an UNC6293 OAuth-code campaign in June, and defense-related targeting from August 6–13. Google published its consolidated report August 20. Campaigns attributed to UNC6293 were usually small—fewer than five users at a time. UNC5976 created at least 12 domains or infrastructure items over roughly three months; Google disabled associated cloud projects. Citizen Lab’s June 18, 2025 app-password case provides earlier context, not a 2026 victim count.

Exposure predicate and observed in the wild

Exposure requires a person to act inside an attacker-arranged flow: share a code, approve consent, create an app password, or link a messaging device. A legitimate Google, Microsoft, or WhatsApp page is not malicious by itself. GTIG says the campaigns are real and targeted. It assesses all three clusters have a Russian nexus with high confidence, but only moderate confidence connects UNC6293 and UNC7005 to an ICE RELIC initial-access subcluster. That is an intelligence assessment, not a court finding.

What succeeded, failed, or remains unknown

Google disabled UNC5976 projects, after which GTIG assessed the actor began moving away from Google infrastructure. High-friction, phishing-resistant controls reduce the room for consent tricks. What remains unknown includes the full HEADRUSH infection chain, a file possibly staged in one WhatsApp lure, and the total number of people compromised. Personal accounts are a blind spot: enterprise telemetry cannot show what happens in a private mailbox or messenger.

Treasure Coast relevance

Port St. Lucie, Jensen Beach, Fort Pierce, and Vero Beach are not named as incident locations, and I found no basis to imply otherwise. The relevance is occupational: defense suppliers, nonprofits, local government staff, researchers, executives, and MSP customers can be selective targets, while any household can benefit from reviewing linked devices and stale grants.

Immediate actions and detection

1. Tell high-risk users that a real login page can still sit inside an attacker’s story. Verify invitations through a separately obtained number or address.
2. Remove obsolete app passwords; review OAuth grants, active sessions, forwarding rules, recovery methods, and linked WhatsApp devices.
3. Use phishing-resistant security keys or a high-risk protection program where appropriate. Do not share verification codes.
4. For suspected compromise, preserve the lure and account alerts, then revoke sessions and reset credentials from a known-clean device.

Recovery, good news, bad news, confidence

Recovery means revoking the durable access—not merely changing a password—and checking connected applications and devices. Escalate when a high-risk user approved an unknown grant, shared an app password, or sees an unfamiliar linked device. Good news: grants and sessions are reviewable, and strong enrollment policy can prevent app-password creation. Bad news: familiar interfaces lower suspicion and personal-account activity may escape corporate logs. Confidence: high for GTIG’s observed workflows; preserve the stated attribution hedges and unknown victim denominator.

Direct sources

• Google Threat Intelligence Group: Going with the Flow(s)
• Citizen Lab: Same Sea, New Phish

Package 2Build-host incident

The dependency that worked the night shift

What happened

The Rust Security Response Team verified a supply-chain attack involving a malicious build-time dependency. The legitimate crates arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9 were published with a dependency on attacker-controlled proc-macro1. Its Cargo build script downloaded malicious material. Because build scripts execute while compiling, application code did not have to call the affected crate for the dangerous path to run.

Evidence and timeline

The Rust team received the report at 07:15 UTC on August 20. The three malicious legitimate releases were online for approximately 86, 90, and 107 minutes respectively: arrayref was deleted at 08:41:40 UTC, internment at 09:04:11, and append-only-vec at 09:25:24. The project deleted attacker-controlled crates, removed the malicious releases, restored clean versions maliciously yanked through the compromised owner account, and locked that account.

Exposure predicate and observed in the wild

The high-risk predicate is a developer or CI host that freshly resolved and built one of those exact releases during the window, including an unlocked update. The crates.io API’s 245,385,500 all-time and 53,905,601 recent arrayref downloads cover the package across versions. They are not malicious-release downloads, unique devices, executions, or victims. RustSec advisories said there was “no evidence of actual usage,” while the public issue contained first-person Linux and build-host execution reports. The publication-safe classification is publicly self-reported execution, not project-confirmed.

What succeeded, failed, or remains unknown

The rapid registry response shortened availability and restored clean resolution. A lockfile or cached malicious archive can establish exposure but not, by itself, execution. The compromise route into the maintainer account, malicious-version download count, victim count, and any external actor attribution remained unknown.

Treasure Coast relevance

Risk is high for local software shops, contractors, CI providers, and businesses compiling Rust; it is low for households and SMB endpoints that never build Rust. A company in Vero Beach is not more exposed than one elsewhere, and no local incident is alleged.

Immediate actions and detection

1. Pause fresh dependency resolution on relevant build systems.
2. Before cleaning, preserve Cargo.lock, registry caches, CI logs, process history, and endpoint/network telemetry.
3. Inventory the exact three releases and project-listed attacker crates without executing samples.
4. If a build may have run, isolate the host and rotate every credential reachable by its build identity from a clean system.
5. Restore clean version ranges, regenerate and review lockfiles, then rebuild in a known-clean environment.

Recovery, good news, bad news, confidence

Deleting a crate cache is not recovery from possible host execution. Escalate to incident response when logs show build-time execution, when high-value signing or deployment credentials were reachable, or when evidence cannot establish integrity. Good news: the malicious releases were removed within hours and exact scope is known. Bad news: build identities often carry broad secrets, and a clean lockfile does not evict an implant. Confidence: high for versions and timestamps; low for victim prevalence.

Direct sources

• Rust Project incident report
• RustSec arrayref advisory
• RustSec internment advisory
• RustSec append-only-vec advisory
• RustSec public issue

Package 3Active + conditional

Two servers at the edge: Zimbra active, NetScaler conditional

What happened

Zimbra CVE-2026-73570 is an unauthenticated OS command-injection issue in a specific SNMP-enabled configuration, fixed in 10.1.20. CERT Polska reported an active exploitation campaign on August 17. NetScaler CVE-2026-19490 is a critical authentication bypass on qualifying Gateway or AAA systems, while CVE-2026-19489 is a high-severity memory overflow that the vendor says can cause unpredictable behavior or denial of service—not confirmed code execution.

Evidence and timeline

Zimbra first disclosed its SNMP issue June 26 and announced 10.1.20 as the permanent fix July 20 at 09:15:40 UTC. CVE records appeared August 13; CERT Polska’s newer August 17 alert reported active exploitation. For NetScaler, the vendor record was created August 10, its change log says initial publication August 19, and checked CISA enrichment on August 20 listed exploitation as “none.” On August 21, CISA added Zimbra CVE-2026-73570 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of August 24, 2026 and known ransomware-campaign use marked “Unknown.” This is a new government escalation—not the first disclosure or first exploitation warning. Neither NetScaler CVE appeared in KEV at this update cutoff.

Exposure predicate and observed in the wild

Zimbra exposure requires a version before 10.1.20, optional zimbra-snmp, enabled notifications—including CERT Polska’s snmp_notify and running swatchdog detail—and attacker-controlled SMTP reaching the path. Treat it as actively exploited, without inventing an actor, victim count, or geography. NetScaler CVE-2026-19490 requires Gateway/AAA roles, with SAML-action conditions for listed newer builds. CVE-2026-19489 requires SIP ALG on a Large Scale NAT group. Checked primary signals did not establish active NetScaler exploitation.

What succeeded, failed, or remains unknown

Zimbra 10.1.20 supplies the permanent fix, but patching cannot prove an already targeted host is clean. Citrix-managed cloud services and managed Adaptive Authentication were updated by the provider; customer-managed appliances still need owner action. The NetScaler CNA ranges conflict with the vendor bulletin by appearing to include the fixed builds. For remediation, use the vendor bulletin. NetScaler victim prevalence and Zimbra campaign size remain unknown.

Treasure Coast relevance

Home relevance is low. Local MSPs, nonprofits, schools, medical practices, and small businesses that self-host Zimbra or run customer-managed NetScaler VPN/AAA services have direct exposure if predicates match. That is a configuration-based relevance statement, not evidence of compromise in Port St. Lucie or neighboring communities.

Immediate actions and detection

1. For Zimbra, confirm all prerequisites, preserve logs and file metadata, and review the prior 30 days for service restarts and unexpected files under the Zimbra identity.
2. Upgrade Zimbra to 10.1.20 or later. If indicators exist, contain before broad cleanup and rotate mail/admin credentials from a clean system.
3. For NetScaler, inventory exact build, FIPS/NDcPP status, role, SAML actions, SIP ALG, LSN, and every HA member.
4. Prioritize exposed CVE-2026-19490 Gateway/AAA systems, install the branch-specific fixed build, restart as required, and verify the actually running version.

Recovery, good news, bad news, confidence

A qualifying Zimbra host with indicators needs persistence review and possibly a trusted rebuild; involve an incident responder or CERT when integrity is uncertain. For NetScaler, unexplained authentication or availability events deserve review even after patching. Good news: fixed versions and configuration predicates are explicit. Bad news: Zimbra exploitation was reported before some teams may see KEV, and edge systems hold valuable trust. Confidence: high for classifications; bounded “none” signals are not proof of permanent absence.

Direct sources

• CERT Polska notice 145/2026
• Zimbra security advisories
• Zimbra 10.1.20 release
• NetScaler CTX696939
• CISA KEV snapshot feed

Package 4Boundary failure

The sandbox had a door; the agent carried the key

What happened

Two separate disclosures land on the same design lesson. In isolated-vm, guest-reachable type confusion could corrupt host memory, reliably crash the host, and in a private demonstration hijack host control flow—making host code execution potential, not a reported field campaign. Adversa AI described “Cryptographic Context Injection,” where encrypted instructions in untrusted content were decrypted by an agent runtime and then treated as trusted output, allowing a reported Grok browsing demonstration to send private chat context outward.

Evidence and timeline

The isolated-vm advisory, GHSA-864f-rcv7-6rh4, was published August 7 and marks all versions through 7.0.0 vulnerable. Patched releases are 7.0.1, published August 5, and 6.2.0, published August 6; the timing reflects coordinated release before advisory publication. npm recorded 992,716 downloads from August 13–19, a registry traffic count—not deployments or victims. Adversa says it reported the Grok chain June 3, followed up August 4 and 10, reproduced it August 19, and published August 20 at 10:00 UTC. No public xAI technical response was located in the frozen research.

Exposure predicate and observed in the wild

For isolated-vm, untrusted guest code needs at least one ivm.Reference, or host code must accept caller-influenced transfer behavior. Merely finding the package does not prove reachability. For the agent chain, untrusted content must reach a code-capable agent that also sees sensitive context, can call an outbound tool, and lacks provenance or consent gates for resolved arguments. Neither checked primary record establishes in-the-wild exploitation. The isolated-vm result is a laboratory/private demonstration; the Grok chain is detailed researcher-reported evidence without a public success-rate denominator or vendor confirmation.

What succeeded, failed, or remains unknown

Upgrades exist for both supported isolated-vm branches. Endor Labs withheld the stronger exploit, reducing public weaponization but also limiting independent reproduction. Adversa withheld payload details and recommends harness-level controls. Ciphertext frustrates static prompt filtering because dangerous meaning appears only after execution. Unknowns include reachable isolated-vm deployment count, Grok reproduction outside the researchers’ accounts, fleet prevalence, current xAI mitigation, and any real-world abuse.

Treasure Coast relevance

Ordinary households have low isolated-vm exposure. Local SaaS firms, automation shops, AI-agent builders, plugin hosts, and MSP-developed tools may have material risk. A small business using a hosted chatbot is not automatically vulnerable; architecture and tool permissions decide the case.

Immediate actions and detection

1. Inventory the actually loaded isolated-vm version, including bundled and global copies; upgrade 7.x to 7.0.1 and 6.x to 6.2.0.
2. Restart every affected process or container. Verify runtime state, not only the lockfile.
3. Until upgraded, stop processing untrusted JavaScript or withdraw guest references where operationally safe.
4. Run untrusted web content in a no-secret, no-tool context. Pass structured results into privileged contexts instead of raw runtime output.
5. Hard-deny or require confirmation for new outbound destinations and irreversible actions; log the final resolved arguments.
6. Hunt for unusual native crashes and for the sequence untrusted input → code execution → external action. A crash is a signal, not proof of escape.

Recovery, good news, bad news, confidence

If a sandbox service exposed host secrets and shows suspicious crashes or actions, preserve logs and container/host evidence, rotate accessible credentials, and rebuild where host integrity is uncertain. Good news: isolated-vm has fixed branches, and agent-harness controls can survive model changes. Bad news: network filtering does not repair an in-process boundary, while prompt filters cannot safely “read” strong ciphertext without execution. Confidence: high for isolated-vm advisory scope; medium for the Grok disclosure; low for prevalence.

Direct sources

• isolated-vm GitHub advisory
• npm registry metadata
• Endor Labs technical report
• Adversa AI disclosure

Package 5Operational technology

Machines with consequences: PLCs, cold rooms, and command buses

What happened

U.S. agencies warned of an active cyber threat involving reconnaissance and capability development against exposed or poorly protected Siemens S7 PLCs, including AI-assisted scripts disguised as monitoring tools. Separately, repository advisories documented dangerous command paths in NASA/JPL’s AIT-GUI ground-system software. A verified ThreatsDay lead added 23 Copeland XWEB Pro vulnerabilities and Danfoss AK-SM 800A issues affecting refrigeration controllers.

Evidence and timeline

Joint advisory AA26-231A, dated August 19, covers S7-200, S7-300, S7-400, listed S7-1200 CPUs, and S7-1500 variants including safety controllers. It describes reconnaissance and capability development, not a confirmed destructive event. AIT-GUI 2.5.2 was released August 12; GHSA-p9r8-2q67-fp86 followed August 13 with CVSS 3.1 9.4 and says versions through 2.5.1 are affected. A separate unreviewed global record, CVE-2026-60112, scores the missing-authentication path 9.8 under CVSS 3.1. Claroty reports Copeland fixed XWEB Pro in firmware 1.13 and Danfoss fixed AK-SM 800A in R4.3.1.

Exposure predicate and observed in the wild

S7 risk depends on a listed PLC being Internet-exposed or insufficiently segmented and outdated or weakly protected; vendor and integrator access can supply unseen paths. Agencies call the threat active but name no actor, victim count, or confirmed operational damage. AIT-GUI consequence requires a reachable web service attached to meaningful command endpoints without compensating authentication or isolation. The published browser proof was local/mock, not a spacecraft or mission test, and no mission compromise is reported. Refrigeration findings were laboratory research with publicly reachable interfaces noted, but no checked exploitation claim.

What succeeded, failed, or remains unknown

AIT-GUI 2.5.2 honors a configured host, defaults to localhost, adds same-origin checks, and confines script paths. Yet tagged source still creates sessions from an unauthenticated root route, and non-browser clients without Origin/Referer are outside that browser check. Treat 2.5.2 as meaningful hardening, not proof of credential authentication. For refrigeration, fixes exist. Across all three stories, deployment counts, compensating controls, and realized physical impact remain unknown.

Treasure Coast relevance

Home relevance is low. SMB relevance is high for local manufacturers, water and wastewater operators, farms, marinas with industrial controls, commercial facilities, grocers, restaurants, pharmacies, healthcare cold storage, and contractors who remotely manage those systems. This is sector relevance only; no Port St. Lucie, Jensen Beach, Fort Pierce, or Vero Beach victim is claimed.

Immediate actions and detection

1. Inventory controllers, engineering workstations, firmware, remote vendors, and every direct or indirect Internet path.
2. Before a planned network, access, logic, or firmware change, preserve controller logic, configurations, logs, engineering-workstation state, and relevant timelines. If damage is actively continuing, contain immediately while preserving what you safely can.
3. Remove direct exposure where possible, enforce an IT/OT DMZ and MFA for remote access, and restrict programming to approved engineering stations.
4. Test PLC firmware and engineering-software changes in a safe development environment; do not turn an emergency patch into an unsafe plant event.
5. Baseline S7 communications, alert on unauthorized writes and off-hours changes, inspect unapproved monitoring tools, and compare online logic with trusted offline copies.
6. For AIT-GUI, after preserving the current listener, access, and command-path state, upgrade to at least 2.5.2, bind to localhost or an isolated management network, add strong authenticated access in front, and verify effective listeners, firewall paths, and command-bus connectivity.
7. For Copeland/Danfoss, preserve and back up configuration first, apply 1.13 or R4.3.1+ respectively, and verify physical temperatures independently during an incident.

Recovery, good news, bad news, confidence

Preserve controller logic, audit logs, configurations, and engineering workstation evidence before disruptive recovery. Coordinate with the vendor, integrator, CISA/FBI, or a qualified OT responder when safety or continuity is at stake. Good news: concrete segmentation, authentication, monitoring, and firmware actions exist. Bad news: operational consequences can outrun ordinary IT playbooks, and a vendor pathway may bypass assumed isolation. Confidence: high for advisory behavior and patch discrepancy; low for real-world AIT-GUI or refrigeration impact.

Direct sources

• Joint U.S. advisory AA26-231A
• Siemens ProductCERT services
• AIT-GUI repository advisory
• AIT-GUI 2.5.2 release
• Claroty Copeland research
• Claroty Danfoss research

Package 6Mobile banking

The phone that kept talking after the network went dark

What happened

ThreatFabric analyzed Manic, a blend of banking malware and spyware capable of encrypted store-and-forward relay through nearby infected devices when direct server access is unavailable. Zimperium described ToxicPanda 2.0 with expanded commands, overlays, and on-device fraud control. IBM examined a current GoldDigger campaign using airline and retailer impersonation plus Accessibility-driven interaction.

Evidence and timeline

ThreatFabric traces Manic-associated infrastructure to February 2026, development services to late March and April, retained builds to late May, and a strengthened deployment to July. Its configuration monitors 169 package IDs; that is a target catalog, not 169 victims. ToxicPanda 2.0 has 167 remote commands, a PIN workflow for more than 140 banking or crypto apps, and overlay configurations for 349 financial institutions or app targets across 16 countries. Those are capability counts, not breached institutions. IBM calls GoldDigger’s current infection “massive” but publishes no denominator, so the phrase stays attributed and unconverted.

Exposure predicate and observed in the wild

Each described path starts with installing a malicious or impersonating Android app and granting dangerous access such as Accessibility, notifications, VPN, device administration, or related special permissions. Manic’s mesh additionally needs another infected device within radio range; code support for a four-hop default is not proof that multi-hop theft occurred broadly. ThreatFabric calls Manic actively distributed in the wild. ToxicPanda and GoldDigger reports establish samples and campaign artifacts but do not disclose unique-device, successful-fraud, or loss totals.

What succeeded, failed, or remains unknown

Researchers recovered high-impact capabilities: lock/PIN capture, overlays, UI viewing and control, notification and location collection, and on-device transaction support. Zimperium observed attacker-controlled AWS-hosted delivery, which does not mean AWS was compromised. IBM could not retrieve GoldDigger’s external virtualization component, so that feature’s full real-world operation remains unvalidated. Named operators, prevalence, realized relay use, and total losses are unknown.

Treasure Coast relevance

Manic’s target set is Ukraine-heavy and GoldDigger’s reported concentration is mainly South Africa and the United Kingdom, but sideloading, retailer impersonation, and Accessibility abuse travel well. Local relevance is medium to high for users who install apps from messages or unfamiliar pages. No Florida infection is asserted.

Immediate actions and detection

1. Install apps only from verified store or developer channels; keep Play Protect and Android security updates enabled.
2. Audit Accessibility, notification access, device administration, VPN, “install unknown apps,” all-files access, developer options, and wireless debugging.
3. Treat an ordinary shopping, airline, rewards, or utility app requesting Accessibility or device administration as a stop signal.
4. If compromise is suspected, stop using the phone for banking or MFA. Separate it from networks and nearby untrusted devices; preserve bank and messaging evidence.
5. Call financial institutions using a trusted number from a clean device, revoke sessions and rotate credentials there, then rebuild or factory-reset after evidence needs are met.

Recovery, good news, bad news, confidence

Uninstalling alone may leave account access, fraudulent payees, or stolen secrets unresolved. Escalate immediately for unauthorized transfers, unknown device-admin control, or evidence the phone served as an authentication factor. Good news: these paths require installation and high-risk grants, which users and managed-device policy can block. Bad news: Accessibility converts visual trust into remote control, and Manic’s peer relay complicates “airplane mode equals containment.” Confidence: high for analyzed behavior; unknown for prevalence and losses.

Direct sources

• ThreatFabric Manic report
• Zimperium ToxicPanda 2.0
• IBM GoldDigger analysis
• Cleafy lineage context

Package 7Confirmed malicious code

Forty thieves, thirty-seven decoys, and one important denominator

What happened

Socket linked 77 Firefox extension identities in a crypto-wallet and credential-theft investigation. The defensible count is 40 confirmed malicious identities plus 37 deceptive sports-score shells whose analyzed builds did not contain confirmed stealing code. Nine confirmed-malicious identities had earlier shell versions; those historical versions are already inside the 40 and must not be added again.

Evidence and timeline

Mozilla signing records for the original 59 analyzed versions span March 9 through August 3, 2026. Socket found another 18 linked identities through mid-August, closing the corpus at 77. The confirmed 40 break down as seven remote-switch loaders, 15 wallet-secret capture extensions, 13 modified Rabby builds exfiltrating serialized keyrings before local encryption, and five credential/clipboard collectors. The arithmetic is 7 + 15 + 13 + 5 = 40.

Exposure predicate and observed in the wild

A user must install one of the confirmed identities; several theft paths also depend on entering a recovery phrase, private key, or credential into a counterfeit interface. Socket reports malicious collection and exfiltration code in analyzed packages, which is stronger than a merely theoretical capability. But code presence does not reveal how many people installed it, entered a secret, or lost money. Socket says several listings remained live when reported and attributes removal of one listing to Mozilla; the frozen research found no independent Mozilla incident statement.

What succeeded, failed, or remains unknown

Stable extension IDs allowed researchers to connect rotating names and branding. Permissions alone failed as a trust shortcut: modest permissions do not make an extension honest. Remote-switch behavior means today’s stored package may not reconstruct what a user saw earlier. Installation totals, victims, successful thefts, financial losses, and named actor attribution remain unknown. Socket is the sole detailed corpus-level source reviewed.

Treasure Coast relevance

Relevance is high for any Firefox user in the four local communities who manages cryptocurrency or sensitive credentials. That does not mean the region was targeted. It means an exposed wallet seed has the same consequence in Jensen Beach as anywhere else.

Immediate actions and detection

1. Review Firefox extensions by stable ID, version, and publisher—not display name—and compare with Socket’s confirmed list.
2. Preserve ID/version and relevant browser evidence before removal if an incident response may follow.
3. If a seed phrase, private key, or wallet state was exposed, create a new wallet from a clean device, move remaining assets, and permanently retire the old seed.
4. For exposed passwords or clipboard secrets, rotate from a clean device, revoke sessions and tokens, and review account activity.
5. Install wallet extensions only by following the wallet vendor’s canonical site to the listing, then verify publisher and ID after updates.

Recovery, good news, bad news, confidence

Uninstalling is containment, not recovery for a disclosed seed. Escalate to wallet-provider or incident-response help when transactions are unfamiliar or business funds are involved. Good news: stable IDs and exact analyzed clusters support focused checks. Bad news: a copied private key cannot be made secret again. Confidence: high for Socket’s analyzed 40/37 split; unknown for victims and losses.

Direct sources

• Socket Threat Research: 77 Firefox Extensions Linked to Crypto Wallet and Credential Theft

Package 8Bounded research

The expired card that was not quite dead

What happened

USENIX researchers demonstrated “Zombie Cards,” a contactless-payment lifecycle weakness in tested Visa Kernel 3 configurations. A relay could alter the expiry value presented to the terminal while leaving issuer-facing Track 2 data and valid card cryptograms intact. Authorization then depended on whether the issuer treated the still-open account or PAN as enough, rather than independently enforcing the physical instrument’s expiry and replacement state.

Evidence and timeline

The paper was presented during the August 12–14 USENIX Security Symposium; UMass summarized it August 17. Researchers disclosed to Visa and affected banks in May 2025 and followed up in December. At acceptance, Visa’s report had passed triage and was under red-team reproduction according to the paper; no public Visa statement was located. Tests used two NFC-capable Android phones, SumUp Solo and Plus terminals, researchers’ own accounts, and informed merchants. No relay implementation was released.

Exposure predicate and observed in the wild

The chain needs physical possession of or sustained NFC proximity to an expired card, an active relay, still-usable card cryptographic material, a replacement account open under the same PAN, a Visa Kernel 3 path, and issuer policy that does not enforce lifecycle state. In the three-issuer end-to-end table, one Visa issuer authorized the revived scenarios, another let terminal checks pass but declined at authorization, and a Discover-kernel issuer rejected the expiry modification. The researchers explicitly do not claim ecosystem-wide measurement. No fraudulent campaign was reported.

What succeeded, failed, or remains unknown

One bounded Visa/issuer combination succeeded across several values and merchant contexts. Mastercard Kernel 2, American Express Kernel 4, and Discover Kernel 6 rejected the relevant modifications in tested configurations; these are not universal certifications. Population prevalence, total affected issuers, and mitigation deployment remain unknown. There is no CVE or network-wide patch in the reviewed record.

Treasure Coast relevance

The practical local lesson is ordinary and useful: do not leave expired cards intact in a drawer, car, office, or trash. Nothing in the study identifies Florida merchants, banks, or cardholders as victims.

Immediate actions and detection

1. Destroy chip and magnetic stripe on expired instruments according to issuer guidance; do not rely on the printed date alone.
2. Continue alerts and account review after replacement, especially where the PAN remains unchanged.
3. Issuers and payment operators should validate instrument lifecycle state, bind expiry-critical representations, forward terminal validation outcomes, and evaluate relay resistance.
4. Report unfamiliar contactless transactions promptly using the number on the current card or issuer’s verified site.

Recovery, good news, bad news, confidence

Cardholders should freeze or replace affected accounts and dispute transactions through the issuer; merchants should preserve terminal records rather than attempting reproduction. Good news: one tested issuer and other tested kernels rejected the relevant path, and no tooling was released. Bad news: lifecycle checks can split across terminal, network, and issuer boundaries. Confidence: high for bounded demonstrations, low for ecosystem prevalence.

Direct sources

• USENIX paper: Zombie Cards Back Online
• UMass research summary

Package 9Controlled experiment

The wave formed between protocols

What happened

“CDN Tsunami” examined CDNs that accept HTTP/3 from clients but speak HTTP/1.1 to origins. Researchers demonstrated bandwidth amplification through header decompression and origin-connection amplification through multiplexed requests that kept backend connections occupied. The target of the amplification is the origin’s capacity, while traffic arrives through legitimate CDN infrastructure.

Evidence and timeline

The arXiv paper, version 1 dated July 29, tested Alibaba, Baidu, Cloudflare, CloudFront, Fastly, and Tencent against the researchers’ own infrastructure. All six were susceptible to the tested header-bandwidth path and five of six to connection amplification. Static-table factors ranged from 36.41× to 66.06×; dynamic-table testing peaked near 350× around 64 streams. A measurement pipeline found 151,685 subdomains on the vulnerable CDN set, with 42,330—27.91%—also using HTTP/3 and labeled potentially vulnerable. That label establishes prerequisites, not successful attacks on 42,330 sites.

Exposure predicate and observed in the wild

A relevant site uses an affected-style CDN, enables HTTP/3 at the edge, translates to HTTP/1.1 toward the origin, and allows requests to reach the backend instead of cache. Header amplification depends on decompression limits; connection amplification depends on eager backend connection behavior and timeout coupling. The controlled origin had a 100 Mbps cap, 256-connection limit, and 300-second timeout; attacker bandwidth was capped at 30 Mbps. No primary source reported wild exploitation.

What succeeded, failed, or remains unknown

Cloudflare’s store-then-forward design resisted the tested connection path. Fastly limited fan-out but remained affected in the researchers’ test. The paper says all six vendors acknowledged disclosure; Baidu and Tencent confirmed issues, paid about $350 and $150, and deployed mitigations. With no public vendor advisories identified, those statuses remain paper-reported. Current configuration diversity and the other four providers’ fleet-wide remediation are unknown.

Treasure Coast relevance

Local e-commerce, tourism, healthcare, government, and managed websites may use CDNs, but domain presence behind a provider does not prove exposure. The risk belongs first to CDN and origin architecture, not to a resident browsing from Fort Pierce.

Immediate actions and detection

1. Inventory edge HTTP/3, origin protocol, cache-bypass behavior, header limits, backend fan-out, and timeout coupling.
2. Ask the CDN whether complete HTTP/3 requests are buffered before origin connections and whether decompressed request size and repeated references are capped.
3. Monitor origin bandwidth, connection occupancy, cache-miss ratios, and abrupt HTTP/3-correlated backend pressure.
4. Apply provider mitigations and origin-side rate/resource controls without blocking normal CDN address ranges blindly.

Recovery, good news, bad news, confidence

During an event, coordinate with the CDN and hosting provider, preserve edge/origin telemetry, and scale or shed load safely while fixing the conversion behavior. Good news: concrete request-buffering and limit controls exist, and two vendors reportedly deployed changes. Bad news: protocol translation can make small client effort expensive downstream. Confidence: high for six-provider experiments, medium for broad exposure estimates, low for current fleet-wide status.

Direct sources

• CDN Tsunami research paper

Package 10Discovery-only recap

The recap drawer: six leads worth keeping, nine left labeled

What happened

The day’s ThreatsDay roundup contained 15 subject blocks. I treated it as discovery, not as a factual source. Six subjects had enough primary evidence and local or operational relevance to retain: a post-compromise Defender-driver technique, a U.S. indictment, ErrTraffic/Cruciferra delivery through compromised WordPress sites, refrigeration controllers, Gogs, and CircleCI’s MCP server. The other nine remain inventory or non-promoted leads.

Evidence and timeline

Check Point’s August 20 lab research says a signed Microsoft Defender remediation driver can be repurposed after privileged compromise; it explicitly found no known or observed wild use. The Justice Department’s August 18 superseding indictment charges 17 Mabna Institute members and alleges targeting of 144 U.S. universities, 178 foreign universities, at least 42 U.S. companies, at least 11 foreign companies, at least five U.S. agencies, and at least two NGOs, with more than 31 TB allegedly stolen; a reward of up to $10 million covers information on five defendants. These are allegations, and defendants are presumed innocent unless proven guilty.

eSentire says several late-July ClickFix campaigns used compromised WordPress sites and that it isolated one affected customer host. A visitor still had to obey fake verification instructions. Aikido says Gogs 0.14.2 and earlier are affected by CVE-2026-52813 and 0.14.3 fixes the code-execution chain; a separate push-authorization issue had no official fixed version at publication. CircleCI’s GHSA covers @circleci/mcp-server-circleci 0.16.1–0.19.1 and fixes 0.19.2.

Exposure predicate and observed in the wild

The Defender technique is post-compromise, not remote initial access, and wild use was not established. The Mabna counts are alleged targets and data volume, not conviction or a list of compromised local institutions. ErrTraffic depends on a compromised lure site plus user execution; one host response is not prevalence. Gogs needs a vulnerable self-hosted server and a reachable path; checked research did not establish wild exploitation. CircleCI’s path requires remote transport, request authentication disabled, and network reachability beyond a trusted boundary; request-token authentication is on by default and closes the described path.

What succeeded, failed, or remains unknown

Primary sources made these six actionable without promoting every roundup item. Nine were held back: Grandoreiro samples lacked a victim denominator; OpenAI’s canonical was not directly verified while Google HEIR was product research; Kriminal AI service claims were weakly denominated; Apple ATT was regulatory news; a 12 KB backdoor appeared on exactly one workstation; the macOS PostScript read was patched without a wild campaign; n8n’s advisory dates to March 25–26 and is a reminder rather than same-day disclosure; the T-Mobile cable anecdote lacked a primary statement in the supplied chain; and the GLM-5.3 page had no extractable body. “Not promoted” does not mean false—it means insufficient fit or verification for tonight’s casebook.

Treasure Coast relevance

Local WordPress owners and Windows users should reject browser pages telling them to run commands. Self-hosted development shops should patch Gogs and narrowly configured CircleCI MCP services. Universities, labs, engineering firms, and research partners should treat the indictment as a reminder to use phishing-resistant MFA and monitor bulk downloads. No defendant, victim, or customer is placed in our four local communities without evidence.

Immediate actions and detection

1. If WordPress compromise is suspected, first preserve relevant files and database state, access and authentication logs, administrator/account state, and the incident timeline. Then contain the site, patch core/plugins/themes, remove unauthorized access or code, verify integrity, and rotate site credentials from a clean system. If damage is continuing, contain immediately while preserving what you safely can.
2. Never run commands copied from a verification page. Isolate a Windows endpoint that did and investigate the original compromise, driver/service loads, and security-control tampering.
3. Upgrade Gogs to 0.14.3+; review organizations, repositories, access creation, and unexpected filesystem changes. Treat server execution evidence as host compromise.
4. Upgrade CircleCI MCP to 0.19.2+, keep request authentication enabled, restrict binding, and rotate CI/cloud tokens if exposure is suspected.
5. For research-heavy organizations, use phishing-resistant MFA, segment valuable data, harden offboarding, and monitor anomalous downloads.

Recovery, good news, bad news, confidence

A patch closes a path; it does not evict an intruder. Preserve evidence, rotate reachable credentials from a clean system, review persistence, and rebuild when server or CI integrity cannot be established. Good news: Gogs and CircleCI have explicit fixed versions, and the Defender work was disclosed before known weaponization. Bad news: a compromised WordPress page can borrow a familiar browser to recruit the user into execution. Confidence: high for cited primary records; deliberately low or unassigned for held-back recap claims.

Direct sources

• Check Point BTR.sys research
• U.S. Department of Justice indictment announcement
• eSentire ErrTraffic/Cruciferra report
• Aikido Gogs report
• CircleCI MCP advisory