Binance confirms $6.3 billion theft and 4 more

What people are saying

A widely shared security blog post said Anthropic was compromised and that an extension used by tens of millions of developers was delivering a remote access trojan through a reverse Secure Shell (SSH) backdoor. The same researcher's Mastodon thread said the attacker gained reverse SSH access to Anthropic customer environments at scale. Practitioners then argued over the claim on Hacker News, Lobsters and Reddit.

What holds up

The core event is real. Cursor's security notice, as summarized by Penligent, puts the affected population at no more than 5,000 users and says the malicious build was not developed by Anthropic.

Phorion, which found the backdoor, says the build was on the Cursor Marketplace and drops a persistent SSH backdoor across macOS, Linux and Windows. In our reading, it also cautions that its findings do not by themselves show that Anthropic's official release or distribution infrastructure was compromised.

According to Rescana, Cursor says it found no other tampered extensions and worked with the hosting provider to take the attacker's server offline. Cursor also says the SSH-enabling step needs administrator rights that the extension lacks on most macOS and Windows machines.

The blog post's author argues the malicious build was uploaded as Anthropic's verified account. How it got there is not established. Our verdict: partly confirmed.

Inside the threads

On Hacker News, one camp dismissed the headline, with one commenter calling it "just a regular Anti-AI clickbait post." Another camp, in a second Hacker News thread, noted that version 2.1.313 was missing from the official VS Code marketplace and from the Claude Code GitHub changelog. A Lobsters commenter suspected Claude Code's continuous integration (CI) pipeline was compromised. On r/cybersecurity, commenters said a sensible update cooldown setting would have protected most users. A Hacker News commenter added that VS Code's auto-update delay does not apply to extensions from trusted publishers. An r/sysadmin commenter tied the incident to a recent cryptocurrency exchange breach, which we treat as speculation.

Our take

This is a contained incident with an uncomfortable unanswered question. The "Anthropic hacked" framing is ahead of the evidence, but so is any claim that Anthropic's publishing path was untouched. In our reading, what is underrated is that updating the extension does not clean the machine, so exposed developers may still have a planted key and persistence in place. We also think auto-update for developer tooling deserves the same change control as production dependencies. Extensions run with the developer's full access, and that access usually includes repositories and cloud credentials.

What to do

• For exposed machines, follow Cursor's official remediation steps, remove the planted SSH key and persistence, and decide whether to rebuild.
• Rotate credentials reachable from affected accounts from a trusted machine, starting with source repositories, cloud resources and release pipelines.
• Set a cooldown or approval step for extension updates across developer tools.

What people are saying

In Reddit's r/sysadmin, one commenter said they had already switched off the feature everywhere, and others pushed for risk analysis first. In r/cybersecurity, commenters asked why vendor ratings run from 5.9 to 9.8. On Hacker News, a commenter offered the counterpoint that most servers do not create multipath TCP (MPTCP) listeners by default.

What holds up

The National Vulnerability Database (NVD) entry carries a CVSS 3.1 base score of 9.8, critical. The flaw is a race condition in IPv4 TCP connection setup that can make the kernel use memory it has already freed. The record says IPv6 is not affected by the first issue.

As of October 29, Ubuntu and Red Hat Enterprise Linux (RHEL) had not released a fixed kernel, and neither gives a release date. Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixes for at least some kernels.

Distribution scores are lower. Red Hat, Amazon, Oracle and SUSE rate it between 5.9 and 8.1. Red Hat's CVE page says no confidentiality or integrity impact has been demonstrated.

The remote root claim comes from Anthropic. The company said its artificial intelligence (AI) model wrote an exploit that lets an unauthenticated remote attacker run commands as root on servers with an MPTCP listener. Neither the CVE record nor the kernel fix mentions MPTCP. A write-up from Penligent notes that neither disabling MPTCP nor filtering traffic corrects the underlying memory error.

Our verdict is partly confirmed. The flaw, its upstream 9.8 score and the pending Ubuntu and RHEL fixes are established. Remote root on every Linux server is not.

Inside the threads

The sysadmin thread split between people who patch or switch features off at once and people who insist on risk analysis first. One commenter in the second camp said a high score "doesn't mean it's a 10 in your environment." Hacker News commenters added that Go servers may be attempting MPTCP by default. That matches a Go Security Team statement that Go 1.24 and later request it for listening sockets. Other commenters questioned whether disabling MPTCP is a real stopgap, noting that the fix focuses on TCP options rather than on multipath. One r/cybersecurity commenter argued that internet-based remote code execution against a random server is very unlikely. We treat that as informed speculation. Others vented about Debian shipping a fix weeks before Ubuntu, and about vulnerability teams that are already burned out.

Our take

We think the 9.8 accurately describes how bad this bug could be, but it is a poor guide to patch order. Claims that every Linux host is one connection away from root today are overblown. In our reading, the reassurance about MPTCP is also too comfortable: exposure follows your software stack, including Go services, not only your kernel settings. The underrated part is the patch gap between distributions, which leaves RHEL and Ubuntu fleets waiting with no date. Disabling MPTCP where it is unused is a reasonable temporary step, but it is not remediation, and tickets should stay open. We also think the AI-written exploit matters more as a trend than for this CVE.

What to do

• Inventory internet-facing Linux hosts and any services that create MPTCP listeners, including Go builds on 1.24 or later. Patch those first when vendor kernels arrive.
• Where MPTCP is unused, consider disabling it through change control as temporary exposure reduction. Document the change so it can be reverted.
• Track the advisory for your exact distribution and kernel flavor. After the reboot, confirm the fixed kernel is the one actually running.

What people are saying

Researchers at Remedio published a writeup saying they found a way to take over the computer an IT support technician works from, "by launching the attack from the very machine they connect in to help." They say they showed it running a program of their choosing on the technician's computer, with the client fully up to date. A Reddit r/netsec thread picked it up, and the comments turned quickly to whether anyone should run TeamViewer at all.

What holds up

The flaw is real and patched. TeamViewer's security bulletin lists an integer overflow in remote-control screen decompression that leads to a heap-based buffer overflow, tracked as CVE-2026-111585. The vendor says it may let a malicious remote host cause a denial of service or, depending on the platform, run code with the privileges of the viewer process. It affects the Full Client, Portable and Remote Control App before version 15.83, and it requires a user to open a session to an attacker-controlled or compromised host.

In our reading, that description matches Remedio's account, in which the attacker is the host and the victim is the viewer.

The identifier in the chatter is wrong. The National Vulnerability Database record for CVE-2026-11585 describes an SQL injection in CodeAstro Student Attendance Management System 1.0. Verdict: partly confirmed. The event is established by the vendor, but the CVE number spreading with it points to an unrelated bug.

The same bulletin also fixes an out-of-bounds write in the screen-image decoder of the Linux and macOS clients, which can also be triggered through a crafted session recording file, and a local privilege escalation on macOS.

Inside the threads

One camp argued that remote access tools deserve extra scrutiny because of the trust they already hold. One commenter noted they are often installed org-wide with elevated privileges and unattended access. A second camp said they had abandoned the product, with one claiming it has "a crazy exploit every year/every other year." Another complained that it runs in the background even when it is not needed. Others pointed to VPNs and bastion hosts as alternatives, and one claimed a VNC server is far safer. That claim is opinion, and we saw nothing in the thread to support it. Some comments joked about turning the bug against tech support scammers.

Our take

We think the direction of this attack is the underrated part. Most remote-access risk planning assumes the attacker reaches in. Here the technician reaches out, and the exposed machine is the helpdesk workstation, which in many organizations holds the broadest access. Support staff routinely connect to machines they do not control, including customers, contractors and possibly compromised endpoints. The "just uninstall it" camp oversimplifies the problem, since any viewer that decodes a remote screen is parsing untrusted input. The wrong CVE number is a practical problem: teams that search scanners or tickets for it will find a school app, not their exposure.

What to do

• In our reading, track this by the vendor's identifiers (CVE-2026-111585, CVE-2026-92372, CVE-2026-92374), not CVE-2026-11585.
• Prioritize helpdesk and support workstations, and treat sessions to unmanaged or untrusted machines as higher risk until those workstations are patched.
• Find unmanaged TeamViewer installs that your patch tooling does not cover.

What people are saying

A research write-up from Ohey reports that on 29 October 2026 the DebugBear monitoring script Polymarket loaded was replaced with a wallet drainer. On X, one post said the script got swapped for a wallet drainer for about 65 minutes and affected anyone who was logged in. Another post said Polymarket halted trading after a compromise and tied it to a separate breach at OpenCode.

What holds up

The write-up says the DebugBear real-user monitoring (RUM) script loaded by Polymarket was replaced with a wallet drainer. It says the drainer ran in logged-in sessions between 16:54 UTC, when the script's origin went down, and 17:59 UTC, when Polymarket removed the script. In its account, the recipient wallet took in 28,636,284.45 POL and positions from 33 accounts in 52 minutes, and it had forwarded everything by 18:38 UTC.

Hudson Rock's InfoStealers site independently downloaded the file, and two downloads returned the same 15,187-byte payload. Ohey reports that Polymarket had already built a release without the script at 17:59:20 UTC.

According to Ohey, DebugBear posted that it was impacted by an ongoing security incident and told RUM customers to remove its embed code. Ohey also reports that the Polymarket Traders account said one of its third-party providers was compromised, that it referred the matter to law enforcement and that anyone affected will be made whole.

The scale is not settled. Hudson Rock says a screenshot shows more than $2 million in holdings at the payload's fallback recipient address. It adds that the balance is not a verified total of stolen funds. Ohey's timeline also cites a trace posted on X of 2.724M pUSD from 721 wallets, far more than 33 accounts. Hudson Rock says the number of affected users, aggregate losses and the initial compromise mechanism remain unresolved.

In our reading, the core claim is partly confirmed. The swap and the removal are established. The losses and the entry point are not.

Inside the threads

The Reddit discussion on r/blueteamsec was short and admiring of the attacker's craft. One commenter said the attacker had clearly studied how Polymarket's frontend works. The same commenter said the attack stayed inside the CSP except for DebugBear's reporting endpoint, and that whoever built it "knew exactly what they were doing." On X, the OpenCode comparison treated two unrelated incidents as a trend. We think that is speculation, since no link between them has been shown.

Our take

We think the lesson is about trust in vendor code, not about crypto. The write-up says every host the drainer called, apart from DebugBear's, was on Polymarket's Content Security Policy. In our view, that shows an allow-list cannot help once a trusted vendor's own domain serves hostile code. The underrated detail is that a performance tool, which few teams treat as sensitive, ran inside authenticated sessions. Polymarket's quick removal and reimbursement pledge look like the right response. The headline loss figures are overblown until someone verifies them. For listed companies, an incident like this can raise a materiality question fast.

What to do

• Inventory every third-party script that loads on authenticated or payment pages, and remove any that do not need to run there.
• Ask monitoring and analytics vendors how they protect their content delivery origin, and how fast they will notify you if it is compromised.
• Rehearse a one-step script removal in production, so your team can pull a vendor embed within minutes.