Daily Cybersecurity News – August 5, 2026

What happened

Hackers have stolen around $130 million in cryptocurrency by exploiting a flaw in Coldcard hardware wallets that made seed phrases predictable and brute-forceable.

Security researchers at Block traced the issue to firmware that fell back to a deterministic software pseudo-random number generator instead of the intended hardware RNG. Attackers reconstructed seeds at scale without physical access to devices. Multiple groups appear involved, per Galaxy Research and Elliptic. Coinkite issued an advisory urging firmware updates and seed migration.

Who is affected

Owners of Coldcard hardware wallets (Mk2, Mk3, Mk4, Mk5, and Q models) who generated seeds on vulnerable firmware versions dating back to March 2021.

Mk2/Mk3 firmware 4.0.1 through 4.1.9 (and some later) carried roughly 40 bits of entropy; later models had about 72 bits instead of the expected 128. Users who added sufficient independent dice rolls or strong unique BIP-39 passphrases face lower immediate risk. TAPSIGNER, OPENDIME, and SATSCARD are unaffected.

Why it matters

Cold wallets are marketed as highly secure offline storage, yet a single firmware RNG flaw from years earlier enabled remote drainage of large holdings without seed sharing or device compromise.

Victims who followed best practices still lost funds, underscoring manufacturer trust and entropy risks in self-custody. Losses reached hundreds of BTC across thousands of addresses in rapid sweeps, eroding confidence in hardware wallet security.

How it could have been prevented

Update immediately to fixed firmware (Mk2/Mk3 4.2.0+, Mk4/Mk5 5.6.0+ or Edge 6.6.0X+, Q 1.5.0Q+ or Edge 6.6.0QX+). Generate a completely new seed on the updated device, verify backups and addresses, test with a small transfer, then migrate remaining funds.

Do not generate new seeds on unpatched devices. Use strong unique BIP-39 passphrases and consider multisig. Destroy old vulnerable inventory guidance was followed by the vendor; keep old backups only until migration confirms.

What happened

In under four hours, an attacker compromised a GitHub maintainer account and released a self-replicating Mini Shai-Hulud worm variant that infected more than 440 npm packages, later expanding toward 860+ with over 2 billion combined monthly installs.

It began in the keyv package (600M+ monthly downloads) and quickly hit related ones like cacheable, flat-cache, and file-entry-cache. The malware, based on TeamPCP's open-source Mini Shai-Hulud, steals npm, GitHub, AWS, CI credentials, AI configs, and crypto wallets, then propagates by republishing poisoned versions using stolen tokens. Multiple firms including Wiz, Aikido, Microsoft, and Socket observed the same payload.

Who is affected

Developers and organizations using the compromised packages, especially keyv and cacheable family packages present in over 46% of cloud environments per Wiz.

Root packages alone had 155M+ weekly downloads. Impact spans CI/CD pipelines, cloud workloads, and any systems that installed the malicious versions during the initial wave.

Why it matters

This demonstrates how a single maintainer compromise plus wormable code can cascade across the npm ecosystem in hours, exposing secrets at massive scale and enabling further lateral movement into cloud and infrastructure accounts.

It exceeds prior Shai-Hulud waves in prevalence and speed, highlighting ongoing supply-chain fragility even with known hardening options like package aging.

How it could have been prevented

Immediately audit package-lock or yarn.lock for compromised versions of keyv, cacheable, flat-cache, file-entry-cache and related packages; pin to known-good versions or remove. Rotate all npm, GitHub, AWS, CI, and cloud credentials that may have been present on build hosts.

Enable package aging/provenance checks, use immutable installs, scan for IOCs published by researchers, and monitor for unexpected package publishes or GitHub repos with 'Shai-Hulud' descriptions. Prefer lockfiles and dependency review in CI.

What happened

CISA added three vulnerabilities to its Known Exploited Vulnerabilities catalog on August 5, 2026 (with related entries around then), confirming active exploitation: CVE-2026-9198 in Langflow (CVSS 9.8), CVE-2026-34486 in Apache Tomcat (CVSS 9.8), and CVE-2026-18556 in N-able N-central (CVSS 7.4), plus the incomplete-fix follow-on CVE-2026-18577 (CVSS 8.1).

CVE-2026-9198 allows unauthenticated attackers to chain auto-login token minting with code validation endpoints for full RCE on default Langflow deployments (fixed in 1.10.1). CVE-2026-34486 is a missing encryption issue enabling EncryptInterceptor bypass in Tomcat clusters (affects 11.0.20, 10.1.53, 9.0.116; fixed in 11.0.21, 10.1.54, 9.0.117). N-central flaws enable authentication bypass and account takeover. Exploitation of the Tomcat issue has been linked to AI-assisted campaigns by Chinese-speaking actors.

Who is affected

Users of IBM Langflow (open-source AI workflow platform) versions 1.0.0 through 1.10.0 on default configurations; Apache Tomcat cluster deployments on the listed versions; and N-able N-central instances through 2026.1 (and the incomplete patch through 2026.3.1).

Federal agencies face short deadlines under BOD 22-01. Internet-exposed instances are highest risk; Langflow has seen repeated weaponization.

Why it matters

KEV addition signals confirmed in-the-wild exploitation, requiring rapid remediation especially for government and high-value targets. Langflow RCE gives full control of AI agent platforms; Tomcat bypass undermines cluster encryption; N-central bypass threatens remote management infrastructure.

AI-orchestrated exploitation (e.g., DeepSeek agents researching and pivoting) shows evolving attacker automation that can chain multiple flaws quickly.

How it could have been prevented

Patch immediately: Langflow to 1.10.1 or later; Tomcat to 11.0.21, 10.1.54, or 9.0.117; N-central to the latest complete fix addressing both CVE-2026-18556 and CVE-2026-18577.

Prioritize internet-facing and default-config instances. Apply network segmentation, disable unnecessary endpoints, monitor for exploitation indicators, and follow CISA KEV timelines (often days for federal civilian executive branch).

What happened

More than 2,200 malicious versions of roughly 440 npm packages were published in a Mini Shai-Hulud variant campaign dubbed ChainDrop after a maintainer GitHub account compromise.

It started with 11 carriers in the keyv and cacheable namespaces, then self-propagated to hundreds more. Infected packages execute on install, drop a stealer that harvests npm/GitHub/cloud/infra credentials, encrypts and exfiltrates them (to HTTPS or public GitHub repos titled 'Shai-Hulud: Here We Go Again'), and uses stolen tokens plus GitHub Actions to republish poisoned packages and inject configs. Combined weekly downloads exceeded 500 million. Microsoft, JFrog, and others detailed the worm behavior.

Who is affected

Any developer or organization that installed affected versions of the 440+ packages, particularly high-download ones in the keyv/cacheable family and those reached via propagation.

CI/CD environments, developer workstations, and cloud setups holding credentials are directly exposed; packages span enterprise ecosystems.

Why it matters

The worm's autonomous spread via stolen publishing tokens turns one account takeover into ecosystem-wide infection within hours, stealing secrets that enable further cloud takeovers, persistence, and developer-to-developer infection via injected AI/IDE configs.

It underscores how npm's trust model and frequent credential reuse amplify blast radius far beyond the initial packages.

How it could have been prevented

Scan dependencies and lockfiles for the malicious versions; revert to clean ones and purge caches. Rotate all potentially exposed npm tokens, GitHub PATs, AWS keys, Kubernetes, Vault, and CI secrets immediately.

Enable 2FA/hardware keys for publishing, use short-lived tokens or OIDC trusted publishing, implement package provenance and aging policies, monitor for anomalous publishes or 'Shai-Hulud' GitHub activity, and run endpoint detection on build hosts.

What happened

GitGuardian researchers scanned public GitHub commits and found 4,576 unique n8n API tokens tied to 1,255 hostnames. Of 896 reachable instances, 321 still accepted at least one leaked token, granting authenticated access.

No software vulnerability is required; attackers can use standard REST API calls to read workflow definitions and execution data, invoke stored credentials against downstream systems, and in some setups extract the underlying secrets protected by N8N_ENCRYPTION_KEY. Researchers demonstrated four practical attack techniques in a controlled environment.

Who is affected

Organizations running self-hosted or cloud n8n instances whose API tokens were committed to public repositories, plus any downstream services (databases, cloud, code repos, AI, support platforms) connected via those workflows.

Over 100,000 n8n instances are visible on Shodan; many run versions with known advisories. Roughly 26% of identified hostnames and 36% of reachable ones were live and accepting tokens at test time.

Why it matters

n8n acts as a central automation hub holding high-privilege credentials for many internal systems. A single leaked token can yield workflow data, enable credential abuse, and pivot without needing an RCE or zero-day.

This expands the attack surface beyond CVEs (such as the previously exploited expression injection) into secrets hygiene failures that are trivial to exploit at scale.

How it could have been prevented

Rotate and revoke all n8n API tokens that may have been exposed; scan Git history and public repos for leaks using tools like GitGuardian. Restrict API access with IP allowlists, least-privilege scopes, and short-lived tokens where possible.

Never commit tokens; use secrets managers and environment variables. Audit workflows for over-privileged credentials, enable encryption key protections properly, keep n8n updated, and monitor API usage for anomalies. Treat n8n instances as high-value assets requiring network controls.

What happened

Connor Riley Moucka, 26, of Kitchener, Ontario, pleaded guilty in a Washington state federal court to computer fraud, wire fraud, aggravated identity theft, and conspiracy related to the 2024 Snowflake campaign.

He and co-conspirators used stolen valid credentials (some dating to 2020) to access Snowflake customer accounts between February and October 2024, stealing data from at least 165 companies. Victims included AT&T (call/text logs of 100M+ customers), Ticketmaster (560M users), Advance Auto Parts, Neiman Marcus, Santander, LendingTree, and others. They extorted victims for about $2.5 million total and sold data for another ~$495,000. Victim losses reached ~$9.5 million. Moucka faces up to 32 years; sentencing is set for October 27. He was arrested in November 2024 and extradited in 2025. Mandiant confirmed no Snowflake platform vulnerability—just credential abuse.

Who is affected

The 165+ Snowflake customer organizations whose environments were accessed, plus their end customers whose personal data (SSNs, licenses, passports, financials, DEA numbers, call logs, etc.) was stolen.

Scale includes hundreds of millions of individuals across telecom, ticketing, retail, finance, and education sectors.

Why it matters

The campaign remains one of the largest credential-stuffing/extortion sprees against a cloud data platform, showing how reused or long-lived credentials can bypass strong platform security and enable mass data theft plus double-extortion.

Successful prosecution and high potential sentence signal increased law-enforcement focus on cross-border cybercrime, while underscoring the need for customer-side controls like MFA and credential hygiene.

What happened

The commercial phishing-as-a-service toolkit Greatness has added support for device code phishing, joining its existing AiTM credential/token theft and OAuth consent abuse capabilities in a single operator panel.

It abuses the legitimate OAuth 2.0 Device Authorization Grant flow to bypass MFA and obtain access/refresh tokens. Greatness, documented since at least mid-2022 and previously focused on Microsoft 365, now also targets iCloud, Yahoo, and Google Workspace. Access is sold via Telegram subscription starting at $289/month, with dashboards, lure templates, CAPTCHA options, and bot-based licensing.

Who is affected

Users of Microsoft 365, Google Workspace, iCloud, Yahoo, and other supported platforms who can be socially engineered into completing a device code flow.

Organizations whose employees approve attacker-generated device codes on real login pages risk full account takeover. The kit lowers the barrier for less-skilled actors via easy subscription and shared infrastructure.

Why it matters

Device code phishing turns a legitimate convenience feature into an MFA-bypassing vector that yields long-lived tokens without needing to phish passwords or intercept sessions in traditional ways.

Integration into mature PhaaS platforms like Greatness accelerates adoption and volume, reflecting a broader shift of crimeware toward token-centric, multi-vector ecosystems that stay ahead of basic MFA defenses.