Linux kernel bugs which can be triggered remotely, without any login, are rare. Most kernel vulnerabilities need an attacker to already be running code on the machine. CVE-2026-98432 is one of those: a use-after-free in the IPv4 TCP handshake code, rated CVSS 9.8, which Atlas has written up in detail. It goes all the way back to Linux 4.4.

A use-after-free is exactly what it sounds like: the program releases a chunk of memory, but some other code keeps using it. If an attacker can get their own data placed into that freed memory before it’s used again, they can influence what the kernel does next. In this case, when a server accepts a connection whose SYN packet carries IPv4 header options (a rarely used feature of IPv4), the kernel hands those options from the half-open connection to the full connection without copying them, then frees them while another CPU core may still be reading them. The fix is a four-line change, from “kfree()” to “kfree_rcu()”, which waits until every reader is done before freeing the memory. A lost race simply fails the handshake, so an attacker can keep trying.

The bug was reported by Xinyang Ge at Anthropic, and Anthropic says its Claude model wrote a working proof-of-concept that gets root on “Linux servers with a multipath TCP listener.” Multipath TCP (MPTCP) lets a single connection use several network paths at once, like WiFi and cellular, and you might assume almost nobody runs it on servers. Unfortunately, as Marcus Hutchins points out, Debian kernels enable MPTCP by default, and Go 1.24 and newer open MPTCP listening sockets by default when the kernel allows it, so anything built in Go (including the Caddy web server) is potentially exposed. Hutchins’ scans found about 2.1 million servers reachable over MPTCP on port 443, and he’s already seeing scanning from residential proxies and Russian VPNs which looks like it’s specifically hunting for this bug.

Upstream stable kernels were fixed in mid October, but as of October 31, Ubuntu and Red Hat were both still listed as vulnerable, with fixes in progress. If you can’t patch yet, you can check for MPTCP listeners with “ss -Mlnp”, and disable MPTCP with “sysctl net.mptcp.enabled=0”, but note that this doesn’t affect sockets which are already open, so you’ll need to restart any services using them. Red Hat and AlmaLinux have also published firewall rules which drop TCP packets carrying IPv4 options, which basically no legitimate traffic uses.

We haven’t seen bulk exploitation of this vulnerability yet, which might hint that it’s less trivial to trigger than the severity might indicate, but it’s a great time to get servers up to date. “Not exploited yet” has a nasty habit of turning into “every vulnerable server exploited in a day”.

Meanwhile, on the local side, OpenAI has published the results of pointing an automated pipeline, built on an unreleased “cyber-focused” model, at the kernel. In a run in mid October, it found 2,300 candidate bugs, reproduced 1,700 of them, and produced 948 working local privilege escalation exploits against a stock desktop Linux distribution, for about $1.2 million in API credits, or roughly $1,279 per root exploit. That’s not cheap, but for comparison, Pwn2Own has historically paid $20,000 for a single Linux kernel privilege escalation. Local privilege escalation is the step after an attacker gets a foothold: turning an ordinary user account, a compromised web app, or a sandboxed process into full control of the machine. Coupled with even a basic vulnerability in other code, it can allow an attacker to take full control of the system and hide the compromise much more effectively.

OpenAI says it’s working with the kernel community to report the bugs and submit patches, starting with the most critical, and that during the ten days the scan was running, more than 100 other kernel privilege escalation bugs were patched by other contributors, with about 300 more being discussed publicly. The most sobering line in the report is that, for now, a low-privileged account on an unpatched system “should be considered functionally equivalent to root access for a well-resourced threat actor.” It’s been quite a week for kernel developers, and it’s not going to slow down any time soon.

The flood of AI discovered vulnerabilities seems to continue unabated, and it’s easy to feel under attack from them. Consider, however, how often the open source community has called for companies using open source tools and libraries as core elements of their business to help support those tools and community. There’s still a significant burden placed on the community maintainers when almost 2000 bug reports land in a week, but over $1 million investment in securing Linux isn’t nothing, and the patches at least appear to be reasonably scoped and accurate. I’m pretty sure we’d see an article covering Linus’s response if they weren’t.

The *sshole in musl

Password checking on Unix is simple in principle. Each account has a password hash stored in “/etc/shadow”; when you log in, the system hashes what you typed with the same salt and checks whether the result matches. Accounts which should never accept a password, like a key-only deploy user or root on many cloud images, get a “” instead of a hash, and since “” isn’t a valid hash, nothing can ever match it. That convention goes back to BSD in 1980.

The sshole write-up explains how three reasonable decisions years apart added up to OpenSSH on musl libc (the smaller, lighter C library used by Alpine, OpenWrt, Buildroot, Yocto, and a lot of Docker images) accepting any password between 257 and 1024 characters for those “” accounts. In 2012, musl changed its “crypt()” function to return “” instead of NULL when hashing fails, so careless programs wouldn’t crash. Weeks later, musl capped SHA-512 password hashing at 256 bytes, since very long passwords can tie up the CPU, so anything longer fails. Then in 2016, to fix a timing bug (CVE-2016-6210) which let attackers tell real accounts from fake ones, sshd started hashing the password against another account’s salt when an account has no real hash, just to take the same amount of time. Put it all together: a too-long password makes “crypt()” fail, it returns ““, and “” matches the “*” stored for the locked account.

You’re affected if sshd runs on musl without PAM (Alpine’s default), password logins are enabled (also the default), there’s an account locked with ““, and at least one other account has a real password for sshd to borrow the salt from. Alpine switched root to “” in 2022 after a previous fix for its passwordless Docker root (CVE-2019-5021), and on Alpine’s official AWS and Azure images, the default “alpine” user is locked this way and has passwordless “doas”, so this is root. Systems using glibc, PAM, Dropbear, or OpenBSD aren’t affected.

The researcher found it by building sshd every way they could think of and throwing about 17,600 unusual logins at each build with “agent swarms”; every build agreed except musl without PAM. OpenSSH 10.6p2 fixes it. If you can’t update right away, set “PasswordAuthentication no”, which you probably wanted anyhow… Just make sure you provisioned SSH keys and tested them, first!

Claude Code extension trojanized

On October 29, a malicious version (2.1.313) of Anthropic’s official Claude Code extension for VS Code was distributed through the Cursor editor’s extension marketplace. The malicious version was published under the official extension ID rather than as a lookalike, so anyone with auto-updates turned on simply received it. The Hacker News reports that Cursor says at most 5,000 users installed it during the roughly eleven hours it was available, and that the malicious version was not developed by Anthropic. How the attacker got their code into the marketplace hasn’t been explained.

According to the analysis by OpenSourceMalware, the extension was identical to the real one except for a 66-line loader added to the start of the main JavaScript file. As soon as the extension loads, it adds an attacker-controlled key labeled “svc-telemetry” to “~/.ssh/authorized_keys”, tries to turn on the local SSH server, opens a reverse SSH tunnel back to the attacker, installs persistence (a LaunchAgent disguised as “com.apple.sysmond” on macOS, a crontab entry on Linux, and a scheduled task on Windows), and reports the host name, user, Git email address, and the names of any environment variables that look like credentials.

Phorion found a bug in the macOS version of the attack: the malware checks if Remote Login is turned off by running a command which requires administrator rights, gets an error message back instead of “Off”, and assumes SSH is already running. On Macs without SSH turned on, the tunnel connects but leads nowhere. That’s not something to count on, of course. If you used Claude Code in Cursor around October 29, check your authorized_keys file for the “svc-telemetry” key, look for the persistence entries, and rotate any credentials that machine could access. Version 2.1.314 is the clean replacement.

On a related note about developer tools reaching into each other, a Postman user filed a bug after discovering that opening the Postman desktop app had silently installed a Postman plugin for Claude Code, a startup instruction hook for their coding agents, a remote MCP connection, and the Postman CLI. As they put it, “An API client should not make itself the default workflow in other tools simply because I opened it.” AI coding agents are rapidly becoming one of the most privileged pieces of software on a developer’s machine, and everything with access to their configuration effectively gets to tell them what to do. Since the post, the company behind Postman has updated their website to note that the install will install other tools as well. Feels like the bad days of the early 2000s when every application also brought half a dozen desktop “enhancements” and browser toolbars.

The biggest crypto heist yet

On October 29, attackers stole $6.3 billion in cryptocurrency from Binance, the world’s largest cryptocurrency exchange, which by a wide margin makes it the largest crypto theft ever. According to the AP, the FBI has attributed the attack to TraderTraitor, the North Korean group behind last year’s $1.5 billion theft from Bybit, and is asking exchanges and blockchain analytics firms to block transactions linked to the stolen funds. Binance says it has enough reserves to cover 90% of the missing assets, and has promised customers will be fully reimbursed.

Binance’s initial findings, reported by the BBC, say the attackers compromised the computers of Binance engineers and gained control of the tools needed to drain its wallets. One engineer was contacted through a legitimate job-hunting platform and invited to fake job interviews with fake company representatives, who built trust by sharing social media accounts with personal photos. The attackers also used a compromised internal AI tool.

Fake job offers have been a favorite North Korean tactic for years, because “please run this coding test” or “please install our interview software” is a very natural way to get malware onto a developer’s machine. If a recruiter you’ve never heard of has an amazing opportunity and just needs you to run something, use a throwaway machine, or better yet, don’t. If this sounds familiar, it’s because Iranian hackers have already been known to pose as recruiters with booby-trapped coding tests, and similar lures are how recent high-profile supply chain compromises were triggered.

Polymarket drained through a performance monitor

Polymarket, the prediction market site, had user wallets drained on October 29 through a script it didn’t write. Ohey has published a detailed analysis showing that the real-user monitoring script Polymarket loaded from DebugBear, a script to monitor users actions in the browser to track behavior and performance of website components, was replaced with a wallet drainer for about an hour. Around 16:54 UTC the script’s normal origin server stopped responding, and shortly after, a different server started answering for DebugBear’s hostnames and serving the malicious version.

The drainer was written specifically for Polymarket. It used Polymarket’s own trading client from the page, signed transfers with each account’s existing signer, and submitted them through Polymarket’s own relayer. Every host it contacted, except for DebugBear, was already on Polymarket’s Content Security Policy (the browser-enforced list of what a page is allowed to load and talk to), so nothing looked out of place. Polymarket removed the script at 17:59 UTC, paused trading, and says affected users will be reimbursed.

That’s about $2.5 million in under an hour.

Any third-party JavaScript a site loads runs with full access to the page, including whatever the logged-in user can do. We’ve seen this before with the Polyfill.io takeover in 2024 and with Magecart credit card skimmers before that. A performance monitoring script is about the last thing anyone would think of as security-critical, which is exactly what makes it a good target.

Poker cheating with remote access malware

Polymarket isn’t the only highly targeted supply chain attack this week. WIRED has a great story about a professional online poker player whose Claude agent, while helping review his play statistics, noticed MeshAgent, a legitimate open-source remote management tool, running on his computer. It had been installed months earlier without his knowledge, and had been capturing his screen during sessions on the Americas Cardroom site. The same opponent had been at his table for 10 of the 11 recorded sessions.

The attacker had compromised two popular multi-tabling tools used by high-stakes players, Jurojin and IntuitiveTables. Jurojin was compromised through its own update system, and the IntuitiveTables developer’s test machine was infected through that Jurojin update, letting the attacker add malicious code before the developer signed the next release. The trojanized software checked the user’s poker usernames against a list of high-stakes targets, and only installed the remote access agent for players on the list; everyone else got a perfectly normal app. Sources estimate the attacker took between $1.5 million and $4 million.

The sites’ responses have varied wildly. CoinPoker banned the player in 2025 and refunded more than $100,000, while players say reports to GGPoker and ACR went unanswered for months. GGPoker has since banned third-party tools and added anomaly detection, while ACR has announced it found no wrongdoing and won’t issue refunds, in the same email announcing a new feature to stop remote tools from capturing card images.

Supermarket freezers, again, again

It’s a three-peat!

Last month we covered refrigeration controllers in hundreds of French supermarkets being hijacked and set to heat instead of cool. On Monday, the Guardian reports, retailers in at least seven more countries (Belgium, Estonia, Ireland, Finland, Luxembourg, the Netherlands, and Sweden) found their refrigerators and freezers heated to as high as 50C (122F) overnight. Affected chains include Ahold Delhaize, Carrefour Belgium, Coop and ICA in Sweden, SuperValu in Ireland, and an Ikea store in Belgium.

The operator of Delhaize’s refrigeration systems said the units’ evaporators were switched into defrost mode, the same defrost-mode trick seen in the US military commissary failures earlier this fall. The head of Sweden’s national cybersecurity centre said the country had “quite a lot of exposed operational technology devices” that needed patching, and Patrick Lamplmair of the security firm Tributech said “thousands of these controllers were still reachable from the internet after the French attack.” Nobody has claimed responsibility, and there have been no ransom demands, which points toward sabotage rather than profit.

If there is any lesson to take from the past two months, it’s that refrigeration controllers, building management systems, and other industrial gear have no business being directly reachable from the Internet. Put them behind a VPN, or at the very least behind a firewall that only allows the monitoring service to connect.

Fake nuclear alerts in Ukraine and Russia

On Sunday night, users of Ukraine’s “Air Alert” app, which millions of people rely on to warn them of incoming missiles and drones, received a series of fake warnings about radiation, chemical threats, and street fighting, followed by a message in Russian claiming all of Ukraine was under nuclear alert. NBC News reports that some public warning sirens and loudspeakers in the Lviv region also broadcast a radiation hazard signal. Hours later, Russia’s emergencies ministry said its own alert app had suffered a “massive cyberattack” and sent fake warnings of nuclear warheads launched at Russia.

Ukrainian president Zelenskyy then confirmed to PBS that the Russian alerts were Ukraine’s retaliation: “We only respond on their attacks.”

Many Ukrainians apparently shrugged the alerts off as an obvious fake, partly because they were in Russian. But emergency alerts only work if people trust them: Hawaii’s accidental missile alert in 2018 showed how much damage a single false alarm can do, and alert systems which can be spoofed teach people to ignore the real ones. It’s nuisance-level hacking with potentially drastic real-world consequences.

Residential proxies, from set-top boxes to the White House

Residential proxy services, which we’ve talked about a lot in the past few months, sell access to other people’s internet connections, so traffic appears to come from an ordinary home or business. If you’re lucky, it’s only being used for ad fraud. If you’re unlucky, it’s redirecting “free” VPN traffic through your home IP, being used to hack companies from a less-suspicious domestic IP address, or sold to a ransomware group to attack systems inside your network. The devices providing those connections are usually running a proxy SDK bundled with some “free” app or game, or are cheap gadgets with the proxy software built in: This week brought examples of both ends of that pipeline.

Google has dismantled the XCPE botnet, more than 1.3 million Android set-top boxes, and says with high confidence that the backdoor was built and operated by the device manufacturer itself, Videostrong Technology. The backdoor ran with system privileges and reinstalled itself from a protected partition if removed. Videostrong sold access to affiliates, loading their modules for ad fraud, residential proxy networks (including Linkfog, AppSalt, and NetNut), and yet more malware, and Google says it saw Videostrong operators capturing screens, injecting keystrokes, and opening reverse shells on devices. Back in August we looked at a teardown of a cheap streaming box which turned out to be pre-infected; this is the business model behind that kind of device. Surprisingly, Videostrong was an official Google manufacturing partner who went through the certification process, making them much more legitimate than many of the cheap devices out there. Google has since banned Videostrong from making certified Android devices, and changed its certification process, the malware was loaded after first boot specifically to slip past Google’s testing.

At the other end, Layer3 Intel reports that its probes through public residential proxy services exited from the White House network (AS2650, registered to the Executive Office of the President) 236 times between October 5 and November 3, from six different addresses, through 28 different proxy services. As Brian Krebs reports, the prox