A new identity theft service called Nexus surfaced this week on the Russian cybercrime forum Exploit, offering digital scans of more than 153 million U.S. and Canadian drivers licenses, along with over 10 million ID cards, three million travel documents, and 579,000 medical cards. Brian Krebs traced the leak back to idscan.net, a Louisiana-based identity verification vendor whose client list includes Hertz, Target, FedEx, Motorola Solutions, and Caesars Entertainment. Krebs confirmed the source by matching timestamps on his own leaked license scans, and those of several volunteers, to specific moments they’d handed a license to a Hertz counter or a Vegas dispensary that uses idscan.net’s infrared-and-ultraviolet verification kiosks. The dataset even includes a scan belonging to the U.S. Defense Secretary. The FBI’s New Orleans field office opened a formal investigation the same day Krebs started asking idscan.net questions.

The forensic work here is the real story: nobody at Nexus or idscan.net confirmed anything, but a handful of matched timestamps did the attribution for them. That’s a repeatable technique, and it’s worth remembering the next time a vendor you’ve never heard of is quietly holding a scan of your government ID because some third party you do business with outsourced “identity verification” to them. Every kiosk that scans your license under a marijuana dispensary’s counter or a rental car desk is a data-breach waiting to happen at a company whose name you’ll never see on the receipt. This one’s still developing — worth watching for the idscan.net statement, if one ever comes.

More via Krebs on Security(opens in new tab)

Boston Scientific confirmed on August 25 that it had detected a cyberattack causing what it called a “global operational disruption,” cutting off access to information systems and business applications company-wide, including the ones used to process and ship customer orders. The medtech giant — one of the world’s largest makers of cardiac, neuromodulation, and endoscopic devices — filed an 8-K with the SEC, engaged an outside cybersecurity firm, and as of this writing has offered no restoration timeline and no confirmed attribution. Its stock dropped roughly 4% on the disclosure. Nobody has claimed responsibility, and there’s no public evidence yet on whether this is ransomware, extortion, or something else, but the shape of it — sudden IT isolation, halted order processing, no timeline — tracks with the double-extortion playbook that’s become routine in this sector.

This is at least the fourth major medtech disruption in recent months: Stryker (an Iran-linked crew), Medtronic and Baxter (both claimed by ShinyHunters), and now Boston Scientific. Healthcare device makers sit at an uncomfortable intersection — hospitals run just-in-time inventory on things like pacemakers, stents, and catheters, so a shipping outage three steps removed from the exam room can still bump a scheduled procedure. If your organization depends on a single device or pharma supplier for anything time-critical, this is a good week to ask your supply chain team what the actual failover plan looks like, because “the vendor got hit” is no longer a tail-risk scenario.

More via The Register(opens in new tab

JFrog patched CVE-2026-82329 on August 28 — a critical (CVSS 9.8) authentication bypass that, in Artifactory’s default configuration, lets an unauthenticated attacker with network access mint themselves an admin token. Within days, researchers at watchTowr observed active exploitation in the wild: attackers forging admin credentials, enumerating users, and poking at the platform’s security settings on unpatched self-hosted instances. Artifactory is the repository manager some 6,600 organizations — including 83% of the Fortune 100 — use to store and distribute the software artifacts their build pipelines depend on, so “admin access to your artifact repo” is not a contained problem; it’s a potential foothold into everything downstream of it. JFrog’s CTO was quick to note this bug is unrelated to the Artifactory RCE flaw OpenAI’s own agents exploited during the Hugging Face incident we’ve covered in past issues — different bug class, same product.

The pattern here is the same one we keep flagging: disclosure-to-exploitation windows keep shrinking, and “days” is now the normal cadence for anything that affects a widely deployed default configuration. If you’re running self-managed Artifactory, get to 7.161.20 now — JFrog’s cloud/SaaS platform was never affected — and while you’re in there, it’s worth reviewing who actually has admin tokens, since a forged one looks identical to a legitimate one in the logs.

More via The Hacker News(opens in new tab

Forescout’s Vedere Labs set out to answer a narrow question: given a working exploit for one industrial controller, can an AI model adapt it to a related but distinct model it’s never seen? They handed Claude — starting on Sonnet 4.6, moving to Opus 4.6 when the first attempts stalled — a proof-of-concept RCE exploit for a WAGO 750-852 PLC (built on CVE-2021-31886, a pre-auth buffer overflow in the Nucleus FTP server), a firmware image for the related 750-831 model, Ghidra, a terminal, and a live physical target. It worked, eventually: after several false starts where the model traced the wrong functions entirely, Claude worked out that changing the FTP command sequence would keep the injected shellcode from being zeroed out before it could run, and from there quickly produced working payloads. The final push to reliable code execution took 8 hours 32 minutes of researcher-guided sessions and $535.74 in API costs. When the team pushed further and asked the AI to help build a fuller command-and-control implant, a bad memory write permanently bricked the PLC.

Forescout’s own conclusion is the right one to sit with: a skilled human could have done the initial port faster, cheaper, and without destroying the hardware. The interesting question isn’t whether AI can already out-hack a specialist — it can’t, not yet — it’s what happens to that cost-and-time curve as models improve, because the actual barrier to attacking obscure embedded devices has always been the scarcity of people who can reverse-engineer them by hand. If you’re running PLCs where the vendor patched one model in a product line and left a related model unpatched, treat that sibling device as exposed — porting exploits across near-identical firmware is exactly the kind of grunt work this experiment shows AI is starting to be useful for.

More via SecurityWeek(opens in new tab)

Weeks after VulnCheck disclosed “Endlessdoors” — a hard-coded phone-home implant baked into firmware from Chinese router maker Zbtlink (Shenzhen Zhibotong Electronics) — the same researchers found two more. “Speakingstone” beacons out over UDP to Zbtlink’s own cloud infrastructure and can redirect traffic, harvest PPPoE credentials, hijack DNS, and open reverse SSH tunnels; VulnCheck’s CTO called it “a surveillance implant with root access to every device it runs on.” “Darklantern” is the inverse problem: it listens on the WAN side, and the router’s default firewall rules leave that port wide open to the entire internet, no password required. Both implants are tracked now as CVE-2026-74232 and CVE-2026-74233, and VulnCheck’s own scanning turned up 203 internet-facing Darklantern instances across 22 countries, 103 of them in the US, in a single scanning window.

Zbtlink white-labels its hardware under brand names like Wiflyer and sells through Amazon and other retailers where the “Zbtlink” name never appears on the box, so the affected install base is almost certainly bigger than anyone’s counted. VulnCheck didn’t bother notifying the manufacturer this time, on the reasoning that a backdoor shipped identically across every firmware build isn’t an oversight — it’s a feature. If you’re running unmanaged consumer or SMB routers you didn’t personally vet the chipset on, this is your prompt to go check the actual manufacturer behind the label, not just the brand printed on the case.

More via VulnCheck(opens in new tab)