Backdoored Claude Code extension, not an Anthropic hack and 4 more

What people are saying

Northflank, a cloud deployment platform, is being discussed as the latest multi-tenant infrastructure vendor to report a breach. On a Reddit r/cybersecurity thread, commenters said the company had taken down the featured clients on its homepage.

What holds up

Northflank's status page lists a security incident and a major outage affecting seven platform components. In our reading, eighteen minutes later, it told them to assume all environment variables had been decrypted and to disable or rotate all keys.

The posted timeline begins with a Wiz threat alert at 11:43 UTC. It shows Northflank requested support from Wiz's incident response team at 13:00 UTC.

In our reading, by the evening of October 30, Northflank said users had reported unauthorized use of artificial intelligence (AI) application programming interface (API) keys stored on the platform. The company said those reports may fit a broader pattern of attacks targeting AI credentials.

Northflank has enabled secret rotation for Postgres and MongoDB and told users to disable public access to addons. Its incident page says audit logs are now enabled for all customers, including free users.

The core claim is confirmed by Northflank itself. The root cause, the number of affected customers and the homepage change are not established by the company.

Inside the threads

One Hacker News commenter counted six attacks on multi-tenant service vendors since September, listing PingCAP/TiDB, Fireworks AI, Zeabur, OpenCode Console, Railway and Northflank. Some commenters predicted enterprises will move back to hyperscalers, and others questioned whether hyperscalers are more secure. Several criticized Northflank for having kept audit logs behind a paid plan. One Reddit commenter said attackers used their Gemini key after their environment variables were accessed. Commenters on both sites raised the risk of a chain reaction through Northflank's customers, and one Reddit commenter said Sentry had published a note on whether its customer data was affected. A post on X called it a "similar distillation attack," a cause Northflank has not stated.

Our take

We think the instruction to treat every stored secret as decrypted is the part leaders should act on. Whatever the root cause, the customer's exposure is the full set of credentials held by the platform and every system they open. In our reading, the AI key abuse is the visible symptom because it shows up fast on a bill, but database passwords and cloud credentials stored the same way may be used more quietly. The debate about hyperscalers versus smaller platforms is overblown as a lesson from one incident. The underrated question is which of your vendors hold your secrets in their own platforms, as the Sentry exchange shows. Our take: audit logging and rotation tooling should be checked before you sign a deployment contract, not enabled during an incident.

What to do

• If any team uses Northflank, revoke and reissue every secret stored there with its issuing provider, then review AI provider usage and billing logs.
• Ask critical vendors whether they run on Northflank or similar platforms and whether your credentials were stored there.
• Set spending caps, short lifetimes and narrow scopes on AI and cloud API keys held by any hosted platform.
• Confirm that audit logs and automated secret rotation are available on every platform that stores production credentials.

What people are saying

A Hacker News thread spread the claim that Scribd, the document-sharing site, has been breached. One commenter said the notice arrived only recently: "I only received this same email a few hours ago, Oct 30." Another quoted a notice saying an intruder may have accessed the email address, the last four digits of a credit card, the card issuer and the expiry date.

What holds up

The core claim is confirmed. Scribd's help center states that an unauthorized third party gained access to its systems. The company says the intruder used that access to reach other internal systems and accessed certain user information.

Scribd says most accounts involved basic account information, while a smaller number involved more sensitive information. It says it has notified law enforcement and the relevant data protection authorities. It says notices are going out in phases from Epiq, its notification provider. It asks users to reset passwords for Scribd, Slideshare, Everand and Fable.

The company has not stated the number of affected accounts, how the intruder got in, or what "more sensitive" covers. The payment-card details rest on an email a commenter quoted, not on the company page.

Inside the threads

In our reading, a large share of the thread was hostility toward Scribd's paywalled business model rather than discussion of the incident. Several commenters faulted the disclosure. One commenter asked why companies rarely name the specific system that was breached. A reply said companies tend to disclose the bare minimum the law requires. Another commenter pointed to a 2013 thread titled "Scribd hacked" about leaked emails and hashed passwords. On encryption at rest, a practitioner noted that it does not help once the application itself is compromised: "If an adversary breaches the application, they get the data." One commenter linked the breach to a compromise of the Cursor integrated development environment. Nothing in the thread supports that link, and we treat it as speculation.

Our take

We think the account data is the smaller risk for most organizations. The larger exposure is what employees have uploaded to Scribd and Slideshare over the years. A researcher's 2025 Medium post described finding passports among public uploads. That is a separate issue from this breach, but in our reading it shows how sensitive files end up on these platforms. Phased notices from a third-party provider give phishers a convenient template, and we expect lookalike messages. The talk about root cause is overblown until Scribd says more. The reuse of corporate email addresses and passwords on consumer sites is underrated.

What to do

• Search these platforms for documents carrying your organization's name or markings, and revisit your policy on public document-sharing sites.
• If corporate cards were saved on these accounts, ask finance to watch for card fraud.

What people are saying

A Binary Security write-up on Azure Logic Apps is circulating under the title "Azure's Weakest Link, Five Full Cross-Tenant Compromises." Its summary claims that API Connections let anyone fully compromise any other connection worldwide, with full access to the connected backend. In our reading, the post drew 58 comments in a Hacker News thread.

What holds up

The researcher's post describes flaws in API Connections, which are part of Azure Logic Apps. It says the exposure covered other tenants' Key Vaults and Azure SQL databases, plus externally connected services such as Jira or Salesforce. The researcher says the findings earned $200,000 in total.

Microsoft's Security Response Center (MSRC) uploaded the researcher's BlueHat Asia 2026 talk on October 29. Its description says the work uncovered three cross-tenant vulnerabilities tied to a shared architectural root cause. That count differs from the five in the headline now spreading.

The post says the first report was marked fixed a couple of weeks after submission. The researcher judged that the fix restricted allowed paths rather than the underlying token issue. In our reading, he then found undocumented functions that he says had the same weakness.

Whether every variant is now closed, and whether anyone abused these paths before the fixes, is not established. Our verdict: partly confirmed. The core flaws are real and Microsoft has aired them, but the count and current status are not settled.

Inside the threads

One commenter used the thread to raise a separate complaint: that the callback in Microsoft's admin consent flow can be forged by someone who knows another customer's tenant ID. That claim is unrelated to this research and unverified. Another commenter asked why enterprises still choose Azure given its record of cross-tenant leaks. Replies pointed to bundling with existing Microsoft licenses and to the old line, "No one ever got fired for buying Microsoft." A commenter whose employer contracts Binary Security vouched for the firm. Another claimed Microsoft's second fix broke the earlier one, and a separate commenter guessed the flaws had been live since the feature launched.

Our take

We think the lesson is the pattern, not the count. In our reading, a fix that blocks one input path while the shared credential model stays the same invites variants, and the researcher's account shows exactly that. Tenant isolation is Microsoft's job, and customers cannot patch it. What customers do control is blast radius. The post notes that whoever sets up a connection can scope its tokens or keys to minimal backend privileges, and that OAuth connections carry the token of the person who created them.

What to do

• Inventory Logic Apps API Connections across subscriptions and record which identity or key each one uses.
• Rebuild connections that run on personal or admin OAuth tokens using scoped service identities with minimal backend rights.
• Ask your Microsoft account team to confirm in writing that all reported variants are remediated; treat it under your third-party risk process.
• Review Key Vault and Azure SQL access logs for access through API Connections you cannot explain, and rotate secrets where you find gaps.

What people are saying

Akamai-owned cloud host Linode posted a security advisory on its status page, and a Hacker News discussion quickly filled with readers trying to work out whether it meant a breach. Other commenters folded the notice into a wider fear that AI-powered attacks are now reaching infrastructure and software-as-a-service providers.

What holds up

The advisory is real and comes from the vendor. Linode's incident page says Akamai is aware of the recently published remote code execution flaw CVE-2026-98432 and is investigating and taking mitigation actions. The first post went up on Oct. 30, 2026, at 18:10 UTC.

The latest update, posted Oct. 31 at 01:55 UTC, says Linode is deploying mitigations for the underlying known attack vector while it analyzes any other possible impact. It strongly advises customers to apply OS updates from their upstream provider as soon as those become available. It also says Linode has no evidence of the vulnerability being exploited on the Akamai Compute platform.

Akamai's corporate status page carries the same advisory and says the company is continuing to investigate. Our verdict is confirmed: this is a vendor notice about a vulnerability under active mitigation. In our reading, it is not a disclosed compromise of Linode's control plane or customer data.

Inside the threads

The first camp was simply confused. Several commenters read the notice as nothing having happened yet, while one said Linode treating a patch cycle as an incident was probably the right call. One customer said they noticed it only after spending an hour troubleshooting slow servers, a link to the advisory that nobody established. On mitigation, a commenter said no patches were available yet, and another suggested not using MPTCP while warning the flaw might be exploitable without it. A second camp argued that basic hygiene still works: "Its really not that hard to secure your servers." The practical tip of the thread was a pointer to Google's open source OSV-Scanner as a base for self-hosted vulnerability alerts.

Our take

We think the headline reaction overshoots. A status-page entry with a CVE number is not a breach notice, and Linode explicitly says it has seen no exploitation. The more useful signal is the split in duties. Akamai's shared security model says it controls the physical hosts up to the hypervisor, while customers are responsible for keeping their own installed software patched. That means the provider's mitigation covers its layer, and your guest operating systems remain your problem. We would treat this as a patch-readiness test and a check on how your third-party risk process consumes vendor status pages.

What to do

• Inventory workloads on Linode and Akamai Compute, and subscribe the right on-call channel to both status pages.
• Ask your platform team whether disabling MPTCP is a safe interim control where it is not in use, and confirm against vendor guidance as it appears.
• Hold off on tenant-wide credential rotation unless Linode reports exploitation or data exposure.