On Tuesday, N-able shipped a hotfix. By Thursday morning, attackers were mining cryptocurrency on servers that had installed it. Which is one way to grade a patch. It's Friday, November 13, and this is Lantern Cybersecurity Daily. Today's thread is trusted access: management tools, build pipelines and vendors that already hold the keys. After N-central, a secret stealer riding hijacked GitHub accounts, the ScreenConnect intrusions at dozens of organizations, Expedia's vendor breach, and an employee data leak at TSMC.
Lawrence Abrams, writing in BleepingComputer:
The researchers then checked the associated IP addresses and confirmed that all 21 hosted N-central installations, including 19 running version 2026.4.1.26, the latest Hotfix 2 release issued on November 10.
We covered this on Tuesday and again Thursday. What's new: on Thursday, November 12, researcher Sean Bales released two more exploits, 4EverAble2Shell and Agent2Shell, tested against that Hotfix 2 build. Within hours, Previdian's honeypot saw probing, and Huntback says at least 21 production servers in at least seven countries were compromised and running a Monero miner. So the patch from two episodes ago isn't the end of this. The catch, per Bales, is that 4EverAble2Shell needs the Legacy API enabled. N-able says that's off by default and is telling on-premises customers to make sure it stays off. It has also disabled the Intune integration and is restricting other features. Keep both accounts straight. N-able's advisory says it saw no signs of compromise from the new flaws; independent researchers report confirmed compromises. Agent2Shell, the Windows SYSTEM exploit, is still only Bales's claim. For a team running N-central, this one earns the interruption. Check for requests to the ServerUI endpoint, an unexpected xvd service, or files under tmp dot xvd. And if you find them, BleepingComputer's advice is to treat it as a full root compromise, not just a miner to delete. Cryptojacking is the polite version of what root on an RMM server allows.
From Endor Labs researchers Sriram Subramanian, Henrik Plate and Bhavik Malhotra:
Why it matters: at least 1,806 repositories have already had credentials stolen, and at least 50 of the hijacked accounts publish packages to npm, Go, Packagist, PyPI or crates. Stolen publishing tokens can be used for a follow-on wave of malicious package releases.
Since Tuesday, November 10, Endor Labs says, an attacker has logged in as real developers with stolen credentials and pushed a stealer called wfx into more than 8,900 repositories, including nextcloud's docker repo and twenty webdriverio repos. It runs in GitHub Actions and takes repository secrets, cloud credentials, registry tokens and AI provider keys. And it cleans up after itself. The malicious commit gets reverted within seconds and the workflow run and its logs are deleted. So scanning your current code finds nothing. Endor says the tell is a gap in workflow run numbers. How the accounts were taken isn't confirmed. One victim reports a leaked GitHub CLI token. That's an identity problem before it's a code problem: a long-lived token sitting in a config file carries the developer's whole write access. The part I'd act on first: Endor says the stealer tries to backdoor cloud access, including rewriting an AWS role trust policy so any account can assume it. So rotating secrets alone, in its words, isn't a full recovery. If your developers can write to an affected repo, check those trust policies too.
BleepingComputer, on the ScreenConnect attacks:
However, the vulnerable versions allowed the access key to remain blank if an administrator had never configured one. When this occurred, an attacker could supply an empty access key and pass the extension's authentication check, allowing them to issue remote commands through the ScreenConnect environment.
An empty password field that works as a password. Classic. This is a second remote-management story, and it's new to the show. Huntress counts at least 288 endpoints across 48 organizations hit within 90 minutes, a third of them in the first ten. Huntress believes the way in was RMM+, a third-party ScreenConnect extension, versions 1.0.31 and 1.0.32. Attackers used Run Command to plant rogue ScreenConnect clients of their own. Then there's SCKit, a toolkit meant to jump from an infected customer device to the technician who connects to fix it. Huntress and Blackpoint say they haven't seen that step succeed, and Blackpoint's test against a patched client failed. ConnectWise disabled five possibly related extensions across about 400 partner environments, and stresses that having one doesn't mean you were breached. According to The Record, as summarized by CVEGuru, on-premises admins should disable RMM+ manually and run client 26.6.5 or later. ConnectWise also warns that disabling extensions and resetting credentials won't remove backdoors already installed. So it's a hunt, not a checkbox. Look for extra remote-access clients on endpoints you manage.
Adriana Lee, writing in Skift:
Expedia Group confirmed Thursday that attackers reached its systems through a compromised third-party data platform provider, in a supply chain cyberattack that also affected multiple companies.
Expedia's confirmation followed claims by an extortion group called n0n that it stole Expedia data. Expedia says it contained the issue, is investigating with outside experts, and that its platforms are safe for travelers and partners. It hasn't named the vendor or said what data was exposed. Here's why it sounds familiar. On Tuesday we covered Qubole, where Wiz and Sentra documented an actor using Qubole-linked credentials to get into customer clouds between October 14 and 26. Skift notes Qubole was a onetime Expedia vendor, and Sentra found former customers never revoked Qubole's access. But that link is unconfirmed. Expedia hasn't said its breach is related to Qubole, and researchers haven't named Expedia as an affected customer. And n0n's theft claim is still just a claim. The lesson holds whether or not it's Qubole. When a vendor relationship ends, revoke the access it had. The contract can expire while the IAM role carries on.
From CNBC TV18:
“TSMC has found that some of our current and former employee data was made available on an external website without authorisation. Currently, we have found no evidence that TSMC’s systems have been compromised,” read TSMC's November 12 filing with the US Securities and Exchange Commission.
TSMC says the data came through an external cloud service provider, and that production and customer data weren't affected. It has contacted affected employees and is working with the provider, investigators and an outside security firm. The sellers claim roughly 46,000 records, about 6.9 gigabytes. They're asking 3 Bitcoin, around 220,000 dollars, and threaten to publish everything if nobody buys within a week. Their sample reportedly has 499 records with 19 fields each. The reported fields are the worrying part: national ID numbers, home addresses, banking details and emergency contacts. TSMC hasn't confirmed the count or the fields; those come from the sellers and press reports. Either way, the people exposed are employees, and the company owes them a clear account of what was taken. Same pattern as Expedia: the main systems are fine, the provider wasn't. Sooner or later, your vendor's cloud ends up holding your data.
If you want the other half of the AI story, try The Data Center Daily. It's a daily briefing on AI compute: hyperscaler capex, the power grid, semiconductor supply, and energy markets reshaped by intelligence at scale. Look for it in your podcast app.
That's the week. The reporting behind every segment is linked in the show notes. Lantern Cybersecurity Daily returns Monday, November 16. Have a good weekend. You've been listening to a Lantern Podcast.