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 proxy tracking firm Synthient tied the activity to Windows 11 installations of Infatica, whose founder previously ran King Servers, the hosting company used by Russian state hackers to attack election systems in Arizona and Illinois in 2016. Most of the activity happens between 5pm and midnight, suggesting a person’s device rather than a guest network. Synthient’s founder Ben Brundage told Krebs that some resellers charge as little as 60 cents a gigabyte, so “for less than a dollar you can gain access into some of the most confidential and trusted networks.”

Being an exit node doesn’t automatically mean the internal network is exposed, but past research has shown that poorly secured proxy SDKs can be used to reach other devices on the local network. If you have an off-brand Android TV box which seemed like a suspiciously good deal, it might be time to retire it, or at least move it to its own isolated network.

Never gonna print you up

Over a week in August, Yannick Dixken took apart the firmware on his Prusa MK4S, and came away with 14 findings covering roughly 23 individual bugs, ending in code execution on the printer’s main controller over the network. Prusa has fixed all of them in Buddy firmware 7.0.0, which covers fifteen printer models across the CORE One, XL, MK4, MK3.5/3.9, and MINI lines. If you have one, update it.

The worst bug is in the code that handles commands from Prusa Connect, Prusa’s cloud (or self-hosted) printer management service. A file path from Connect is copied into a shared 512-byte buffer, with the filename written right after it, and the only thing enforcing the 104-byte path limit is an “assert()” call. Asserts are debugging checks which are typically compiled out of release builds, so in the shipping firmware a long path overflows the buffer onto a pointer used to dispatch printer commands. The firmware also had no stack canaries, a common compiler protection against exactly this kind of overflow. To exploit it, an attacker has to control or intercept the Connect endpoint the printer talks to; Dixken tested with TLS turned off, so a real attack would need to defeat or downgrade TLS as well. Other findings include crafted USB filenames which also take control of the processor, and encrypted Connect downloads with no integrity checking.

Dixken used Claude Opus and a fuzzer, along with a Cortex-M emulator running the real signed firmware, and credits the tools with making this kind of thoroughness cheap. He also has kind words for Prusa, which answered within a day, reproduced the bugs, and coordinated disclosure, unlike a previous vendor which answered him with a law firm. As he puts it, “Only one of those two responses makes the next researcher pick up the phone.” Not everything has gone smoothly: Prusa held back the 7.0.0 source code until the disclosure, to give owners time to update, which has kicked off a heated discussion about the GPL obligations of firmware derived from Marlin.

GitLab regex bug hits Alpine

It’s been a rough week for Alpine. Two weeks ago we mentioned CVE-2026-97229, a CVSS 10.0 bug in GitLab’s handling of regular expressions in CI configurations. Alpine Linux has published an incident report describing how an attacker tried to exploit it against Alpine’s own GitLab instance on October 20 and 21, a week after the fix was released.

Alpine had accidentally upgraded to the version just before the fix. Worse, when they upgraded to a fixed version on October 22, they were still vulnerable: the actual bug is in Onigmo, the regular expression engine built into Ruby, and GitLab’s fix is a patch to the copy of Ruby that ships in GitLab’s own packages. Alpine runs GitLab on a standard Ruby, so the update did nothing until upstream Ruby shipped its own fix on October 23. The attacker crashed GitLab worker processes eight times, got partway through the exploit four times, and even downloaded Alpine’s GitLab container image, presumably to tune the exploit for their exact build.

Alpine found no evidence the attack succeeded, but couldn’t rule it out, so it rebuilt the server from scratch, reset every password, and verified every commit and package against its 45 build servers. Package signing keys were never stored on the GitLab server. It’s a good, transparent write-up, and the lesson applies to anyone running GitLab from source or a custom container: upgrading GitLab isn’t enough, you also need Ruby 3.3.13, 3.4.12, 4.0.9, or later.

Follow-ups: PHP2Shell and eMudhra

Last week we noted that, despite all the chaos around the broken PHP2Shell embargo, nobody had been able to show a reliable exploit. Wordfence’s latest update says that, as of October 28, it still isn’t aware of any WordPress site compromised through PHP2Shell, despite logging about 77,600 attack requests from more than 2,000 IP addresses. That doesn’t mean nothing has happened: security firm Dream reported an attacker using a customized PHP2Shell exploit plus a Linux kernel privilege escalation to take over 24 internet-facing firewalls, Palo Alto Networks reports active exploitation targeting PAN-OS management interfaces, and Morphisec reported code execution on a Windows IIS server. Working exploits apparently need to be tuned to each target, and as we keep seeing, “hard to exploit” buys time, not safety. If practical exploitation requires tight timing, expect attackers to focus on products which embed PHP on hardware with predictable timing (like Palo Alto and other solutions-in-a-box) more than random servers, but you’re still not safe if you haven’t updated!

The trivially recoverable eMudhra certificate authority keys have also found a new use. Alexandro Sanchez has shown that they can be used to bypass Android’s Factory Reset Protection, the anti-theft feature which requires the previous owner’s Google account after a phone is wiped, so a stolen phone can’t simply be reset and resold. Using one of the compromised intermediate certificates to impersonate Google’s servers during the setup wizard, Sanchez injects a response that marks the phone as already set up, then combines that with an older vulnerability to wipe the FRP lock; he’s keeping the full chain private. The compromised intermediates have been revoked and blocked by the major browsers, but they don’t expire until 2028 or 2040, and anything which doesn’t check revocation or get a trust store update will keep trusting them. Apparently that includes at least part of the Android setup process.

APT redirects and resumed downloads

Debian has released a security update for APT, the package manager used by Debian, Ubuntu, Raspberry Pi OS, and many others. Max Justicz found that if an HTTP redirect makes two different package downloads end up at the same URI, APT can merge them, and a flaw in how it resumes interrupted downloads lets an attacker in the middle of the connection replace a package after it has been verified. The result is arbitrary code execution as root.

Many APT mirrors still use plain HTTP, which is normally fine: the package lists are cryptographically signed and every package is checked against them, so tampering in transit should be caught. Bugs like this break that assumption. Justicz also found the last big APT redirect bug, CVE-2019-3462, back in 2019. Update APT, and consider switching your mirrors to HTTPS if they support it.

Secure USB sticks, or not

Security researcher Xusheng Li of Vector 35 found that Lenovo’s ThinkPlus FU100 fingerprint USB stick, sold as an AES-256 encrypted drive, is in fact a plain SD card in a fancy case, Tom’s Hardware reports. The fingerprint reader only turns the USB connection on; nothing is encrypted. Lenovo’s TSD303 SSD did encrypt its data, but sent the correct password back over USB in plain text so the software could compare it. Lenovo says the products were sold only in China, that it fixed them and published CVE-2025-13453, CVE-2025-13454, and CVE-2025-13455 in January, and that owners can contact support for a replacement.

In a follow-up covered in his slides, Li used OpenAI’s Codex with his company’s reverse engineering tools to look at other vendors’ “secure” USB products, finding fixed keys built into software from Netac, KakaSoft, and Nexcopy in minutes, and two hidden backdoor accounts in another product. His summary is hard to improve on: “‘Hardware security’ can be pure marketing.”

Secure, “secure”, or just a standard USB drive, you still need to know where your USB stick of data is. Politico reports that the UK’s oversight body for surveillance found GCHQ, Britain’s signals intelligence agency, can’t account for “thousands” of USB sticks, hard drives, and memory cards which may hold intercepted communications. The Investigatory Powers Commissioner said GCHQ “still cannot tell me what has happened to removable media that may hold sensitive data, years after I first raised it with them.” Hopefully they at least bought the kind which actually encrypts.