More than thirty alleged zero-days went public on a Sunday night, and by Monday a remote management vendor had switched off its own hosted platform worldwide. The vendor is N-able, and the product is N-central, which managed service providers use to run their clients' machines. This is Lantern Cybersecurity Daily for Tuesday, November tenth. After N-able: the OpenSSH login flaw we covered Friday is now being exploited, a data platform's trusted AWS access turned against its own customers, and a second breach at AI inference company Fireworks.
BleepingComputer, on N-able's emergency shutdown:
N-able has taken its hosted N-central environments offline and urged on-premises customers to shut down their servers after a security researcher publicly disclosed more than 30 alleged zero-day vulnerabilities, including exploits that could let attackers take over vulnerable systems.
N-central is how MSPs and IT teams remotely manage customer devices and networks. So whoever controls that server effectively holds the keys for everyone downstream. Researcher Sean Bales posted proof-of-concept exploits late Sunday, November eighth, in a GitHub repository called Able2Shell, and told BleepingComputer the discovery was AI-assisted. The chain he rates most critical starts with an unauthenticated XXE flaw in service import and ends with commands running on the server, or a new Default Administrator account with attacker-chosen credentials. Caveats, though. Bales tested a pre-release build, 2026.4.0.31, and says he believes most, if not all, of the flaws also hit earlier versions. That's his belief, and BleepingComputer hasn't verified every flaw. But N-able confirms it's building a hotfix, which suggests at least some are real. N-able says it has seen no exploitation and no unauthorized data access, so this is public proof-of-concept code, not a confirmed compromise. The hosted shutdown on Monday spans the Americas, Europe and Asia-Pacific. N-able calls the disclosure non-responsible, promises updates every four hours, and gives no restoration estimate. For an MSP running N-central on-prem, the vendor's guidance is clear and painful: take it offline, then work out how you reach clients without it, with no date for the fix. Exploits published before a patch left the vendor choosing between downtime and exposure. The MSPs and their clients absorb that cost either way.
BleepingComputer, on the OpenSSH flaw nicknamed SSHole:
GreyNoise recorded the first successful exploitation of SSHole in the wild on November 7 at 00:46 UTC, approximately 40 hours after the fix. The researchers logged 16 successful exploitation chains targeting networks protected by GreyNoise from six source IP addresses linked to post-exploitation activity.
We covered this one Friday, when it was a fresh disclosure. The change: several security firms now confirm exploitation, and CISA added it to its Known Exploited Vulnerabilities catalog on Monday. A quick reminder of who's exposed: OpenSSH on certain musl-based Linux systems, including Alpine. Accounts whose password field is an asterisk, meant to block password logins, can be logged into, and that reaches root where the account has passwordless admin rights. The timeline is tight. The fix shipped in 10.6p2 on Thursday, November fifth, and exploit code followed about four hours later. GreyNoise watched attackers query cloud metadata services, go after password hashes and root SSH keys, and edit authorized_keys files to keep access. One got root and installed a Python command-and-control agent called TAC Agent, which never reached its server. Keep the scale in proportion. GreyNoise says its sixteen chains aren't representative of broader activity, Defused called the attempts not widespread, and watchTower tied some to botnets and cryptomining. The guidance: update OpenSSH or disable SSH password authentication, then check for unexpected password logins to asterisk accounts, SSH keys you didn't add, and TAC Agent files. Federal agencies have until Thursday. I wouldn't wait that long.
Swati Khandelwal, writing in The Hacker News, on research from Wiz:
Apart from the attack, most of the roles the attacker assumed were unused, according to Wiz's researchers. But each role still trusted Qubole's account, so the attacker's requests worked.
Qubole, a data lake platform owned by Idera, works inside customers' AWS accounts through an IAM role that trusts Qubole's account, gated by a code called an External ID. Between October fourteenth and twenty-sixth, someone holding IAM credentials from that Qubole account assumed those roles, and every attempt Wiz saw succeeded. Wiz, working with Sentra and Mandiant, says the actor read Lambda environment variables, Secrets Manager and Parameter Store values, and copied S3 data, sometimes entire buckets. It then tested the victims' own AWS keys, Entra ID secrets and Okta credentials with TruffleHog. How the attacker got Qubole's credentials hasn't been disclosed, and Wiz hasn't linked the campaign to other public activity. And the External ID is doing less than people assume. Wiz notes it's logged in plain text in CloudTrail and often stored by vendors and in infrastructure-as-code. Treat it as non-secret. Wiz's advice is specific. If you've ever connected Qubole, review CloudTrail from October first for AssumeRole calls from Qubole's account that came from outside AWS. Delete integration roles you no longer use, and add a source IP condition; Wiz says that alone would have blocked every role assumption it observed. Rotating a credential doesn't end sessions already issued, so revoke those too. And several victims lacked S3 data event logs, so nobody could tell which objects were read. Turn those on before you need them. A vendor you stopped using can still hold a working door into your account.
BleepingComputer, on AI inference provider Fireworks:
In the new breach, the threat actors accessed resource metadata (e.g., Fireworks resource identifiers, display names, descriptions, creation time), billing information (e.g., billing and shipping addresses, invoice and payment history, account balance, and credit usage), and incomplete model weights and datasets for some customers.
Fireworks hosts open models such as Llama and Mistral for developers. This is its second incident this fall. In early October, attackers reached API keys and tokens for a limited number of accounts, which Fireworks linked to a group reselling stolen model access, known as LLMjacking. This time the route ran through a supplier. In a Monday advisory, Fireworks says a third-party cloud provider hosting its R&D machines had a security incident on October twenty-third, and the next day the intruder used it to reach Fireworks development machines. Fireworks says it detected that the same day and has seen no further successful access to its customer platform since October twenty-fifth. Card numbers weren't exposed; Fireworks doesn't store them. Development machines that could reach customers' model weights and datasets, even partial ones. That's what I'd want explained. So far it hasn't been, and Fireworks hasn't named the cloud provider. It says it replaced credentials, restricted network pathways and isolated affected systems, and Palo Alto Networks' Unit 42 is investigating the full scope. Affected customers deserve a clear answer on whose weights and datasets were touched. And Google's threat intelligence group and Mandiant said last week that LLMjacking has pushed cloud AI charges as high as a million dollars. AI infrastructure gets targeted for its keys and compute, not only its data.
Two of today's breaches ran through cloud providers. For the layer underneath all that, our sister show The Data Center Daily briefs you every day on AI compute: hyperscaler capex, the power grid, semiconductor supply, and energy markets reshaped by intelligence at scale. Search for it in your podcast app.
If you run N-central, ship Alpine with SSH exposed, or ever wired Qubole into AWS, today gave you a concrete to-do list. That's the briefing. Lantern Cybersecurity Daily is part of the Lantern Podcasts family, and we'll be back tomorrow, Wednesday, November eleventh.