Top 5 Cybersecurity News

This week’s Top 5 Cybersecurity News for November 13, 2026 is about access that kept working after anyone stopped watching it. A shipping giant says a legacy system inherited through an acquisition was breached. Attackers used a retired data platform’s trust into its customers’ AWS accounts. Stolen cloud keys are being turned into AI bills of six figures within hours. A remote management vendor took its own hosted platform offline after 33 alleged zero-days appeared on GitHub. And thousands of hijacked GitHub accounts planted a stealer that can leave cloud backdoors behind. Five exposure layers, one question: which access in your company still works although nobody owns it?

1) Maersk’s Breach Started in a System It Inherited, Not One It Built

Maersk disclosed on November 11 that an unauthorized actor accessed and extracted data from a local legacy system it inherited through a previous acquisition. The company says it secured the system, that findings so far strongly suggest no sensitive data was disclosed, and that it found no sign of impact on other Maersk systems or on customer and partner systems connected through APIs and EDI. Over the weekend the WhiteArmor ransomware group listed Maersk on its leak site, demanded $5 million in Bitcoin and claimed about 100 GB from the OCF/LF Logistics platform. Maersk has not linked the incident to the group, and the group’s claims, among them driver records and plaintext credentials, are unverified.

Maersk has not said when the intrusion began, how the attacker got in or how much data left, so the lesson is structural, not forensic. A system that arrives through a purchase often keeps its own logins, its own logging and its own administrators, and may sit outside the programme that protects the core. Assumption: that applies here, since Maersk calls it a local legacy system. For your own business, list every system that came with an acquisition, name an owner for each and check what it connects to. Maersk also advised customers to treat unexpected messages about the incident with caution and to verify them through their usual Maersk contact.

A statement that an incident is “isolated to a local system” is only as strong as the inventory of what that system touched. Integration plans budget for contracts and finance consolidation. Security debt rarely gets a line, yet inherited platforms are where old credentials and old administrators survive longest. Due diligence ends at signing; the exposure lasts until the last inherited system is retired or brought under the same controls as the rest.

Read more on: Maersk Statement · Cyber Security News

2) Many Customers Retired Qubole but Left Its Trust Into Their AWS Accounts Open

Wiz, working with Google’s Mandiant after Sentra flagged suspicious activity, reports that unknown attackers used compromised credentials associated with Qubole’s AWS account to call sts:AssumeRole against customer-managed integration roles, starting on October 14. Qubole is a cloud data processing platform whose customers grant it cross-account roles instead of long-lived keys. Inside customer environments the attackers probed services, took secrets from Lambda, Secrets Manager and SSM Parameter Store, and in some cases downloaded entire S3 buckets. They also used TruffleHog to test AWS credentials, found Microsoft Entra ID secrets and requested OAuth tokens with Okta client credentials. Wiz gave no victim count; SecurityWeek, citing Sentra’s findings, reports more than a dozen organizations. An actor calling itself n0n has claimed responsibility, according to a report Wiz cites, and Wiz has not confirmed that. Qubole did not respond to The Register.

Wiz says many organizations left trust policies active even after deprecating the platform, which is why the roles could still be assumed. AWS says its services were not compromised and that the roles worked as customers had configured them. Practical steps: review cross-account roles in IAM, remove those for integrations you no longer use and add conditions such as source IP restrictions. Check CloudTrail from October 1 for AssumeRole events from the Qubole account (ID 805246085872, per Wiz), and rotate every secret those roles could read. Rotation does not end sessions already issued, so revoke them as well.

A trust relationship is a standing permission, and it does not expire when the business relationship does. Offboarding a supplier is usually handled as a contract task, so the technical grant stays behind. That is how supplier concentration turns into a single point of failure: one set of stolen vendor credentials opens many customers’ doors at once, and each customer’s own controls never see the supplier’s account being used.

Read more on: Wiz Research · The Register

3) Stolen Cloud Keys Now Turn Into AI Bills, Some Reaching $1 Million

In a report published on November 2, Google Threat Intelligence Group and Mandiant describe LLMjacking: attackers obtain an API key or cloud identity through phishing, leaked source code, misconfigured environments or exposed client-side code, then run their own workloads on the victim’s AI accounts while the owner pays. Google saw charges above $100,000 in a single day and cumulative charges reaching $1 million at some organizations before access was revoked. The most common way in was exposed or stolen cloud identity tokens: IAM credentials, service account keys, GitHub personal access tokens and session tokens. One actor tracked as UNC6993 used a misconfigured service account key and ran up more than $100,000.

The report also describes a resale market. So-called LLM Mixers proxy and resell unauthorized access, and one service advertises an unlimited plan for about $60 a month. Separately, Symantec and Carbon Black describe a grey-market relay that installs genuine coding-assistant tools and rewrites their configuration, switching off the sandbox and routing every request through its own servers; employees who wanted a Western AI tool installed it. Start by inventorying every AI API key and the project it belongs to, then set per-key budgets and quota alerts, prefer short-lived credentials and keep keys out of repositories.

AI turns a stolen credential into cash at once, without the attacker having to find data worth stealing. That changes what detection looks like: the first alarm may be the invoice, not the endpoint tool, so finance and security need a shared alert path for spend spikes. Hypothesis: smaller firms that experiment with AI services without central ownership are the most exposed, because keys multiply faster than the policies that govern them.

Read more on: Google Threat Intelligence · The Hacker News

4) N-able Took Its Own Hosted Platform Offline After 33 Alleged Zero-Days Appeared Online

On November 9 a researcher published a GitHub repository called Able2Shell with 33 alleged zero-day vulnerabilities in N-central, N-able’s remote monitoring and management (RMM) platform. It includes proof-of-concept code and exploit chains that reportedly lead to full server compromise. N-able said it took its hosted N-central environment offline as a precaution, urged on-premises customers to do the same and said it had seen no active exploitation. It released N-central 2026.4 HF2 on November 10 and reports all hosted environments upgraded, according to Field Effect. The 33 flaws are the researcher’s claims. N-able has published seven CVEs fixed in HF2, which it scores between 8.3 and 9.3 on CVSS 4.0, but has not said which of the 33 findings they cover. According to Tenable, N-able’s status page reports scanning activity linked to the published code, and as of November 10 no confirmed compromise of a customer server had been reported.

An RMM platform holds privileged access to the endpoints, scripts, patching and remote sessions of every customer an MSP manages, so a flaw in it is a flaw in all of them. If an MSP manages your IT, ask whether it runs N-central, whether it has patched and what the platform can reach in your environment. For on-premises operators, Field Effect advises restricting the admin interface to dedicated networks, reviewing administrator creation, script runs and configuration changes, and rotating credentials stored in the platform.

GovInfoSecurity counts this as N-able’s fifth emergency hotfix since August 1 and argues that AI-assisted research now finds flaws and exploits faster than vendors can absorb. A vendor cannot count on 90 days to fix a flaw when the exploit code is public on a Monday. For resilience planning, list which of your operations stop if the console that manages everything has to be switched off for days.

Read more on: N-able Status Page · GovInfoSecurity

5) 4,837 Hijacked GitHub Accounts Put a Secret Stealer Into the Build Pipeline

Starting on November 10, according to Aikido Security, an attacker used stolen credentials for 4,837 GitHub accounts to plant a secret stealer in repositories those accounts could write to. It ran in at least 1,806 repositories. Each attempt began with a test pull request titled “docs: dependency audit notes”, opened in 61,764 repositories. SafeDep counted 8,093 repositories with malicious commits between 12:46 UTC on November 10 and 04:36 UTC on November 12, counting only public default branches. The stealer targets whatever a CI workflow can reach: Actions secrets, the workflow token, OIDC tokens and cloud credential files. How the attacker obtained the account credentials has not been explained.

Where the stealer ran, treat every secret and cloud role the workflows could reach as compromised. Revoke the commit author’s tokens, OAuth grants, SSH keys and sessions, enable 2FA and rotate secrets. Then look for backdoors built to survive rotation: the stealer can rewrite an AWS role’s trust policy to open it to any AWS account and add federated identity credentials with the prefix wfx-ci- to Azure AD applications, so workflows can sign in without a stored secret. In CloudTrail, check for sessions named wfx-* followed by CreateAccessKey or UpdateAssumeRolePolicy.

A CI pipeline is where code, cloud trust and secrets meet, which makes a developer’s account an infrastructure account. Rotating a secret does not help once the trust policy behind it has been rewritten; the persistent asset is the trust, the same pattern as in Story 2. Aikido found that accounts hit in an October wave were about 1,000 times more likely than other active accounts to be used this week, though it does not attribute November to the same actor. Hypothesis: stolen credentials keep circulating between groups.

Read more on: Aikido Security Analysis · The Hacker News

If this week tells us anything, it’s this:

All five incidents hinged on access that kept working after its purpose had changed. The acquired system still had a role, the cancelled platform’s trust policy was still live, the AI key still had a billing account behind it, the management console still reached every endpoint and the CI token still reached the cloud. No new attack class was needed; the attackers used permissions that no process ever expires. The structural exposure is access without an owner and an expiry date.

For boards and CISOs the useful exercise is a short inventory. For every trust relationship, API key, integration, management platform and inherited system, who owns it, when does it expire and what would show its misuse? Where the answer to the first two questions is nobody, the third one rarely gets asked. Offboarding a supplier or integrating an acquisition is security work as much as administrative work.

If you would like a second pair of eyes on which inherited systems, integrations or management platforms in your environment still hold access they no longer need, you can reach us on our contact page.