Daily Cybersecurity News – August 4, 2026

What happened

A credential-stealing npm worm that first appeared in keyv@6.0.0 on August 4, 2026, spread beyond the Keyv and Cacheable namespaces into hundreds of packages across multiple organizations.

SafeDep verified 353 poisoned versions across 79 package names; its monitoring put the wider footprint at 442 versions across 353 names, while Aikido later reported at least 868 packages across 1,381 versions. The malicious release used a preinstall script (node setup.mjs) to run a credential-stealing bundle that harvests GitHub, npm, cloud, Vault, Kubernetes, database, and private-key material, then abuses stolen npm publishing access to poison further packages. The Keyv repository also retained separate Claude Code and VS Code hooks that can execute the payload once a user trusts the workspace or permits the project configuration.

Who is affected

Developers and CI/CD environments that installed affected versions of keyv, cacheable, flat-cache, cache-manager, and hundreds of other packages across multiple organizations on npm.

Any workstation or runner that executed an affected version should be treated as credential-exposed. Earlier npm clients and install paths that permit lifecycle scripts remain at risk; npm 12 blocks unapproved dependency lifecycle scripts by default.

Why it matters

This is a self-propagating supply-chain worm that turns a single compromised package into a spreading infection via stolen publishing credentials. It harvests high-value secrets (registry tokens, cloud keys, private keys, GitHub Actions memory) and can silently republish malicious versions under legitimate package names.

Exposure is determined by exact resolved versions and lockfiles rather than latest tags, making detection and cleanup operationally painful. Compromised credentials enable further lateral movement and package poisoning.

How it could have been prevented

Audit lockfiles and package-lock/yarn.lock/pnpm-lock for exact versions of known-affected packages (starting with keyv@6.0.0 and related cacheable packages) and remove them. Treat any machine or CI runner that executed an affected version as fully credential-exposed: revoke and rotate all tokens, keys, and secrets only after first removing the malware's credential-revocation watcher (rotating first can trigger an attacker handler).

Pin dependencies, enable npm's lifecycle-script blocking (or use npm 12+ defaults), enforce package allow-lists or provenance checks, and scan for unexpected preinstall/postinstall scripts. Review and remove any untrusted Claude Code or VS Code workspace hooks. Monitor npm publish activity and enable 2FA/hardware keys on publishing accounts.

What happened

Thieves siphoned more than $88 million in bitcoin from Coldcard hardware wallet users by exploiting a firmware vulnerability originally discovered in March 2021. Galaxy Research reported at least 1,367.05 BTC (about $88.6 million) stolen from 4,585 addresses; earlier sweeps hit high-value wallets first, reaching roughly $30 million in the first 10 minutes in one analysis.

Canadian maker Coinkite (Coldcard) confirmed the legacy vulnerability is now being actively used, destroyed its remaining inventory of devices manufactured with the vulnerable firmware, halted shipments, and released a patched firmware. The devices use high-security system locks that cannot be upgraded until a user initializes them, so shipping unpatched units risked users missing the fix.

Who is affected

Owners of Coldcard Bitcoin hardware wallets running the vulnerable pre-patch firmware whose seeds or wallets were generated or used in a way that exposed them to the flaw. Thousands of addresses were drained; individual losses included wallets of $1.8M and pairs totaling $4M.

Anyone still holding unpatched Coldcard inventory or devices that have not been updated is potentially at risk until they migrate funds and apply the fixed firmware.

Why it matters

Hardware wallets are trusted as offline air-gapped stores of high-value crypto. A firmware flaw enabling mass theft undermines that trust and forces physical destruction of inventory plus emergency fund migration.

The attacker prioritized largest wallets, showing reconnaissance of the victim population. Recovery may require the original device, and the company is coordinating with law enforcement but has not confirmed victim compensation. AI-assisted code review was cited by a Coinkite official as helping adversaries find latent bugs faster.

How it could have been prevented

If you own a Coldcard, immediately check firmware version against Coinkite's advisory, apply the patched firmware only via official channels, and move funds to a newly generated secure wallet on a verified clean device if exposure is suspected. Do not dispose of affected devices yet-they may be needed for recovery.

Generate new seeds only on patched hardware, verify device authenticity and firmware signatures, avoid reusing seeds across devices, and treat any device that may have been initialized or used with vulnerable firmware as potentially compromised for high-value holdings. Prefer multi-signature setups and keep significant holdings offline with verified air-gapped procedures.

What happened

Cybercriminals are cloning popular GitHub repositories for AI tools and developer resources to distribute a Windows-based MaaS infostealer, according to Netskope Threat Labs. The group shifted from earlier ClickFix social-engineering delivery (first reported April 2026) to trojanized repos tracked as TroysDen’s.

Attackers clone well-known repos (Claude-branded tools, ComfyUI, AI coding assistants, Python security guides, Rust frameworks), keep the root page looking authentic with the original contributor listed, and add the payload in a benign-looking subdirectory or by modifying installation URLs. The payload arrives as a ZIP with lua51.dll (legitimate LuaJIT), a renamed LuaJIT interpreter (compiler.exe), Application.bat, and gc.txt; the batch launches the interpreter on the text file, which reconstructs and runs SmartLoader malware inside a Prometheus VM. C2 is resolved at runtime via EtherHiding on the Polygon blockchain.

Who is affected

AI developers, researchers, and engineers who clone or follow installation instructions from impersonated GitHub repositories for popular AI frameworks, coding assistants, and related tools.

Windows users are the primary target for this MaaS infostealer; the campaign abuses trust in GitHub's social proof and authentic-looking project pages.

Why it matters

Developers routinely clone repos and run install scripts with high privileges, making them high-value targets for credential and secret theft. The multi-file loader design (code in plain text, legitimate DLLs, interpreter rename) evades many automated scanners and sandboxes that inspect files in isolation.

Blockchain-based C2 (EtherHiding) lets operators rotate infrastructure without updating the malware. Successful infection yields screenshots, device info, and a full infostealer payload for further credential and data theft, potentially compromising AI projects, API keys, and cloud accounts.

How it could have been prevented

Only clone and install from official organization/user accounts and verified commit histories; double-check URLs, stars/forks, and recent activity before running any install script. Prefer package managers with lockfiles and integrity hashes over manual ZIP downloads from GitHub.

Inspect installation instructions and subdirectories for unexpected binaries, batch files, or modified URLs. Run untrusted code in isolated VMs or containers, enable endpoint detection for LuaJIT/unusual interpreters, and monitor for outbound connections to blockchain RPCs or suspicious C2. Use least-privilege accounts for development work and rotate secrets regularly.

What happened

Russian threat actor Midnight Blizzard (tied to foreign intelligence, sub-cluster Storm-2945) has spent months targeting users of public Wi-Fi at hotels and conference centers in a campaign Microsoft calls CaptiveCrunch. Activity dates to February 2026, with traffic manipulation observed since early May; it builds on earlier ReliaQuest research and shows signs of AI assistance.

By compromising captive portal networks and manipulating DNS/HTTP traffic, attackers redirect victims to Microsoft 365 phishing pages, Entra ID device-code phishing, or fake browser/OS update pages using ClickFix social engineering to deliver malware (including possible Android APKs). Two malware families are used: CornFlake (Go-based Windows RAT with keylogging, clipboard/screenshot/audio/video surveillance, browser credential theft, file exfil, persistence as svchost32.exe) and ChocoShell (in-memory PowerShell stealer for browser cookies, passwords, M365/Azure AD tokens, and Wi-Fi credentials). Operators use an unauthenticated web C2 panel called FruitStone.

Who is affected

Travelers, conference attendees, and business users who connect to public or hotel/conference captive-portal Wi-Fi networks and then authenticate to Microsoft 365 or download purported updates.

Organizations whose users access M365/Entra ID from untrusted networks are exposed to credential and token theft that can lead to cloud account takeover.

Why it matters

Hotel and conference Wi-Fi is widely treated as convenient but is an ideal interception point. Compromising the captive portal ecosystem (possibly via shared management services) lets attackers scale across venues rather than hacking each hotel individually.

Stolen M365 tokens and credentials enable persistent access to email, files, and cloud resources; the RAT provides long-term device control while the stealer prioritizes cloud tokens. This is a nation-state-linked operation blending network-level redirection with social engineering and custom malware.

How it could have been prevented

Treat hotel, airport, and conference Wi-Fi as untrusted: prefer personal cellular hotspots or known-good VPNs that start before any captive portal interaction. Never enter M365 or corporate credentials on pages reached via public captive portals; use phishing-resistant MFA (FIDO2/passkeys) and conditional access policies that restrict legacy auth and risky sign-ins.

Educate users on ClickFix lures (fake update prompts that tell users to run commands). Monitor for anomalous M365 sign-ins, token usage, and device code flows. On endpoints, detect persistence like %APPDATA%\svchost32\svchost32.exe and unusual PowerShell credential access. Segment guest networks and harden captive portal infrastructure if you operate it.

What happened

CISA added CVE-2026-18577 (CVSS 8.1) affecting N-able N-central to its Known Exploited Vulnerabilities catalog on August 3/4 2026 after confirmed active exploitation. The flaw is an incomplete patch for CVE-2026-18556 that enables authentication bypass and account takeover in N-central versions through 2026.3.1.

Successful exploitation gives remote attackers administrative access to vulnerable N-central servers; they can then abuse the built-in Take Control feature to pivot into managed endpoints and deploy persistence. Huntress observed targeting across multiple organizations with post-exploitation recon, process enumeration, lateral movement, and use of VPN exit nodes (Mullvad/NordVPN). N-able reported a limited number of customer compromises. Fixed in version 2026.3 HF1.

Who is affected

Organizations running N-able N-central (remote monitoring and management platform) versions through 2026.3.1, especially internet-exposed instances. MSPs and their downstream customers are high-value targets because compromise of the RMM yields broad access to managed endpoints.

Federal Civilian Executive Branch agencies face binding KEV remediation deadlines.

Why it matters

RMM platforms are force-multipliers for attackers: one compromised management server can push tools, ransomware, or persistence to every managed device. Authentication bypass to admin plus Take Control makes this a direct path to enterprise-wide impact.

Active exploitation with observed lateral movement and living-off-the-land tunneling (Cloudflared) means unpatched instances are under immediate threat. Incomplete prior patching shows the difficulty of fully closing auth bypass classes.

How it could have been prevented

Upgrade N-central immediately to 2026.3 HF1 or later. If patching is delayed, restrict network access to the N-central management interface (VPN/allow-list only, no direct internet exposure) and monitor for the published IoCs: svchost.exe in user Documents folders, a service named Cloudflared, and inbound connections from 173.249.252.200, 87.249.138.34, 37.19.210.32, 68.235.46.214.

Review Take Control / MSP Support session logs for anomalies, enforce strong admin authentication and least privilege, and hunt for lateral movement from the RMM server. Federal agencies must follow CISA KEV timelines.

What happened

Data center security firm Lava reports that a 22-year-old vulnerability in Baseboard Management Controller (BMC) firmware-CVE-2013-4786 in the IPMI 2.0 RAKP authentication protocol-exposes password-derived authentication hashes before login on over 24,000 internet-accessible server-management interfaces.

Nearly 37,000 internet-exposed interfaces run IPMI; an unauthenticated remote party that can reach UDP port 623 can obtain an HMAC-SHA1 response and perform offline password cracking. Lava also found 6,240 hosts accepting an empty username with a weak password. BMCs provide highly privileged out-of-band control (power cycle, firmware updates, sensors, configuration) often sharing credentials across IPMI, Redfish, and web interfaces.

Who is affected

Data centers, enterprises, and cloud/colocation providers with BMCs exposed to the internet on UDP/623 running vulnerable IPMI 2.0 implementations. Tens of thousands of management interfaces are reachable; weak, default, or reused passwords dramatically increase real-world risk.

Any environment where BMC credentials are shared with host or other management planes is especially exposed.

Why it matters

BMCs are among the most privileged components in a data center-compromise can mean full host control independent of the OS. Offline hash cracking turns a network-reachable management port into scalable credential recovery without noisy online brute force.

Decades-old protocol design flaws persist in production hardware. Internet exposure of management interfaces remains a systemic hygiene failure that turns theoretical crypto weaknesses into mass opportunistic attack surface.

How it could have been prevented

Immediately remove BMCs and IPMI interfaces from public internet exposure; place them on isolated management networks with strict allow-lists, VPN, or zero-trust access. Change all default and weak BMC passwords to long, unique credentials; disable unused IPMI/RAKP features where possible and prefer more modern management (Redfish with proper auth) over legacy IPMI.

Audit for empty-username or default-credential acceptance, monitor UDP/623 traffic, and inventory all out-of-band management controllers. Treat BMC credentials as tier-0 secrets and rotate them if exposure is suspected. Apply vendor firmware updates that harden authentication where available.

What happened

An op-ed highlights how zero-knowledge proofs (ZKPs) could let companies prove they are affected by a specific critical vulnerability-or satisfy an agreed security question-without revealing underlying sensitive data such as full software inventories, network diagrams, or vulnerability scan details that attackers could exploit.

The company keeps scan data local; a cryptographic tool evaluates it against a precise agreed question (e.g., “Does vulnerability X exist in this defined set of systems?”) and produces a proof of the yes/no answer. Valid proofs cannot be forged for a false answer under the agreed rules. This addresses long-standing barriers to pre-incident vulnerability and control sharing that legal protections and ISACs have not fully solved.

Who is affected

Critical infrastructure operators, enterprises, and government agencies that need rapid visibility into exposure across pipelines, power, telecom, and other sectors but are reluctant to share raw asset and scan data.

Regulators and information-sharing bodies seeking better pre-incident risk data without creating new attack roadmaps or legal/exposure risks for participants.

Why it matters

The most useful pre-incident data (what is running, where defenses are weak) is exactly what companies fear leaking. Traditional sharing creates secondary risk if the shared data is breached, subpoenaed, or misused.

ZKPs offer a path to verifiable answers without data exfiltration, potentially unlocking faster collective response to widespread flaws while preserving proprietary and security-sensitive details. Adoption still requires agreed questions, tooling maturity, and trust in the cryptographic setup.