How far could the Chainalysis breach reach—and what would it take to contain it? This is Lantern Cybersecurity Daily. Also ahead: how does OpenSSH let attackers into accounts with passwords disabled? Plus, the push to revoke exposed secrets. First, Chainalysis and those live tokens. Tap follow so the next episode finds you.
Alexander Martin, writing in The Record from Recorded Future News:
In its latest update, posted Wednesday night, the company said it had discovered “certain customer information including names, usernames, password hashes and live tokens for all Chainalysis users were exposed to a malicious actor.”
Chainalysis says an attacker used “offensive agentic techniques.” That phrase can wait. Wednesday's update says exposed information included password hashes and live tokens, with all users affected. That includes people using its blockchain analytics services in law enforcement and national security, according to the company's customer description. On October 30, Chainalysis said it had found no evidence credentials or session tokens were accessed; Wednesday's disclosure changes that picture substantially. Live tokens put session access high on the response list. I'd want Chainalysis to confirm which tokens were invalidated and which sessions customers need to end—changing a password alone shouldn't be treated as the all-clear. And customers deserve that account in plain language. Chainalysis hasn't explained “agentic,” and its statement doesn't establish that an AI agent caused this breach. It also doesn't specify whether every exposed data category applies to every user.
Here's BleepingComputer:
A newly disclosed flaw involving OpenSSH and musl, dubbed "*sshole," allows attackers to log in to certain Alpine Linux and other musl-based Linux accounts configured to block password authentication simply by entering an oversized password. The flaw only affects OpenSSH servers running on Linux distributions that use the musl C library, including Alpine Linux, OpenWrt, Buildroot, and Yocto, under certain authentication configurations.
Running OpenSSH on Alpine Linux, OpenWrt, or another musl-based system? This deserves a configuration check. BleepingComputer reports a login bypass affecting certain accounts whose password hashes were replaced with an asterisk to block password access—not accounts with valid password hashes. Researcher Ozgun Kultekin traces it to a 2016 OpenSSH change. When a password exceeds musl's 256-byte limit, its hashing function returns an asterisk—the same value stored for those blocked accounts. OpenSSH can treat that error as a match and let someone in. An error matching another error. Lovely. Kultekin says exploitation also requires PAM authentication to be disabled, so check the library, authentication settings, and affected accounts before interrupting the whole engineering team. But prioritize that check on exposed servers. Those account owners deliberately blocked password access; the reported failure is in how OpenSSH and musl handle that choice.
This one comes via Sina Kheirkhah at watchTowr Labs. If your team runs Barracuda Email Security Gateway to filter company mail, watchTowr's November fifth report deserves a patch check. Researchers describe chaining an authentication bypass with command injection to get root access without logging in. Quite a set of privileges for something guarding the inbox. And keep the evidence straight: that's watchTowr's reported attack chain; confirmed attacks against customers are a separate question. The advisory table lists version 9.4.0.029 as the ESG fix, so check the appliance's actual version—not just whether an update was scheduled. The scope needs care, too. The command-injection flaw also lists Barracuda's load balancer, archiver, and several web-security products; the authentication bypass lists ESG. Don't assume every listed product has the same unauthenticated path to root—check its advisory and applicable fix.
From Lawrence Abrams at BleepingComputer:
DigiCert warns it suffered a data breach after a server migration mistakenly exposed an internal business system to the internet, allowing unauthorized access to customer information and identity documents. The certificate authority says the breach affected a small portion of its archived customer data, including names, business email addresses, phone numbers, and business addresses.
DigiCert calls this a small portion of its archived customer data. For someone whose passport or driver's license was in that archive, “small” offers very little comfort. Affected DigiCert customers had contact information exposed, and some records also contained identity documents. DigiCert says it's still reviewing those documents to identify who's affected—so customers receiving notices may still be waiting on that crucial distinction. The incident report on Mozilla's Bugzilla traces this to a February 2025 migration: a system previously behind a VPN became internet-accessible. Outsiders could register accounts, and an authorization flaw let those accounts read archived customer information. Read-only access is plenty when the prize is a passport. DigiCert discovered unauthorized accounts in June 2026 and initially concluded they couldn't access customer information. That assessment needs explaining alongside the breach notices: what changed, and how will each affected customer learn which documents were exposed?
BleepingComputer writes:
Truffle Security has launched the Secrets Revocation Program, a free initiative that helps API key issuers revoke 1.4 million publicly exposed secrets that remain valid. Since 2022, the company has discovered secrets embedded in public repositories, packages, container images, datasets, and applications.
Truffle Security says 81 percent of the leaked keys it reported last year still worked six months later. Apparently, a notification email has a very limited ability to revoke credentials. For companies whose exposed API keys still grant access, their customers’ data can be at risk too. Truffle’s free Secrets Revocation Program aims to help key issuers revoke 1.4 million publicly exposed, still-valid secrets—that’s the company’s count, not a count of confirmed break-ins. Getting issuers involved makes sense. But for a small team, revoking a production key also means replacing it wherever it runs; otherwise, the cleanup can become an outage. Yes—and six months of continued access is a dangerous answer to that dependency problem. Truffle found these secrets in places including container images and Git histories, so deleting a line from the latest code won’t disable the credential. Replace the exposed key, then revoke it.
If you follow cybersecurity, you may also like AI Daily Briefing: top AI news for engineers, founders, and investors, every weekday, with real capabilities versus demo hype explained fast. Find it wherever you listen to podcasts.
Links to every story are in the show notes, so you can explore the reporting and follow up on whichever developments caught your attention. Thanks for listening, and we’ll be here for the next episode. That’s Lantern Cybersecurity Daily for today. This is a Lantern Podcast.