- MPTCP is not a requirement, it is a generic use-after-free.
- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.
- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.
- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.
And it takes around an hour to do this in lab setting locally:
> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution
If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.
Over the past few months I've started to install newer ubuntu kernels using the mainline PPA. However, it goes long periods of time without getting updates, so it's not really a satisfactory solution. In one case I just built the kernel myself.
LTS doesn't work if you want immediate fixes like the current environment requires.
Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?
If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?
Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.
I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.
Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.
Yes, we (Proxmox) included the fix for this in 7.0.14-25, which was initially packaged two weeks ago.
It went through internal QA and to the test soon after that, then a few days later to the no-subscription repository and as of yesterday morning CET it was cleared for the enterprise one, so it's available on all repos of all Products we got in their current supported releases.
For kernel updates we where even more conservative in the past, but with the current churn on often quite relevant fixes picked up the pace a bit on moving them along, trying still to balance rolling out fixes fast(er) while not doing that so fast that tricky (hardware/setup specific) regressions don't get caught.
edit: As this makes the rounds we also released a PSA for it now [0] to make our status here easier to find.
I've been compiling a list of cybersecurity RSS feeds to build a small automation (with oversight from Hermes agent) to ping me (ntfy.sh or just Telegram) when a CVE requires my intervention (matching them to a list of services I run for clients and myself.)
My list (of feeds) is still small, but this CVE did not show up, do any of you have any tips for RSS feeds to use for this purpose?
Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
It's okay guys, the authors simply don't know how to write good C. A real C programmer would not have shipped such a basic use-after-free bug. Rust is just a crutch.
At least if you’re on Amazon Web Services behind a load balancer you probably aren’t really that impacted enough to spend Halloween patching.
> AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, TLS Listeners on Network Load Balancer, Cloud Front, API Gateway
> Customers using the above services do not receive TCP connections from untrusted sources directly when following best practices. AWS is applying updates to the underlying infrastructure of these services and no immediate customer action is required if you are using these services. We still recommend customers update their self-managed instances behind these services within the next 30 days.
I blocked packets arriving externally on my firewall with ip-options a couple of days ago. Firewall rule has zero hits, and I've got a very open ISP (andrews+arnold), if I want I can host SMTP, DNS, whatever
My FreeBSD loadbalancers block packets with IP Options with default config. It’s not rocket science, no matter how Cloud providers are trying to tell us.
>the kernel handed those saved options from the request socket to the new connection without copying them, then freed them immediately when the connection went away, while another CPU could still be reading them to build a handshake reply.
If this requires a multi-core system to exploit, it's good news for most of the consumer routers that will never get updates. Saved by cheap single-core hardware.
You would be surprised. A lot of cheap consumer routers are have two or four ARM cores. The bigger issue is that they are typically running a kernel from the stone age (< 6.0.0). Sometimes a still-supported LTS kernel like 5.10 or 5.15, but then they stopped at an old patch level.
Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?
Finally a usecase for mptcp on linux. Been waiting and trying off and on for years to get it to do something, but now it can give a nice remote root shell. Well, not to me, I just get to patch devices.
Can anyone explain how use after free results in a practical exploit?
I ask because I’ve been dabbling in rooting various closed devices at home. I’m finding AI fantastic at finding vulnerabilities statically (from firmware upgrade binaries), but when you then ask it to use it to get root or code execution it just goes in circles.
In the end it usually ends up there’s no exploit it can find, because it can’t actually influence the affected memory in a useful way. This is especially so if that memory is in the heap. On the stack it’s a lot more predictable (especially with OOB writes).
You need to do some https://en.wikipedia.org/wiki/Heap_feng_shui. If you can reasonably reliably trigger some other operation that allocated the freed memory for another purpose, you have something like a type confusion vulnerability.
If it’s freed it can be reallocated, so then you have pointers to the same area of memory used for completely different data structures, and this can go very wrong
I get the principle - what I struggle to find is concrete examples of how it can practically be used.
How do you know which pointer (as I say, especially if it’s in the heap)? And I know it can go wrong - but how do you do more than just crash the kernel?
In OOB writes in a stack variable it’s completely clear to me. For other situations I’d love to find real and clearly explained exploits of past UAF or OOB vulnerabilities.
Getting the right thing allocated in the right place to exploit a UAF is usually very very tricky. For a defender we just need to know it's probably possible and therefore we patch the bug, but the attacker still has a difficult job to do even already knowing a UAF bug.
The simplest thing you could try to do is allocate several more of the same type of object and hope one of them lands at the same memory address. For example if you can UAF a web app's user session and keep it open for a long time period (not true in the TCP bug), you might try to wait until an admin happens to log in with their session at the same address, then use their admin session.
Or you can allocate a lot of something else objects and hope a certain field overlaps, like a function pointer if you can write to it. Like suppose you can get some kind of authentication callback pointer to overlap where your packet sequence number was, maybe you can send a certain number of packets to make it point to the return instruction and skip the authentication.
A web search for "exploit chain uaf" found me a few real-world and a few tutorial examples, though I don't know which are good.
At a high level, though: once you've gotten a new object allocated where the old one was, you now have two different views of the same bit of memory. You use valid operations on one view to put the other one into a corrupted state. For example: in a unixlike kernel, maybe one view has a field containing a function pointer (for method dispatch, essentially). You read that field using the other view, use it to deduce something about the target's memory layout, write a new value to the pointer, then use the field via the first view to cause execution to jump to a location you control.
One example is that you might be able to read what was written there. Here that may mean you could read another process’s packet(s). Imagine they were sending unencrypted passwords, perhaps because it’s in a trusted LAN connection.
It goes around in circles because a UAF alone isn't enough in a lot of cases, sometimes you also need a chain (an info leak, read/write primitive etc), a way to defeat ASLR and so on depending on what you are working on and target mitigations. Not all UAFs can be used for RCEs, some can be used only for DoS or for nothing really.
been doing exactly this lately with camera firmware and yeah the circles thing is real, but im pretty sure its a feedback loop problem, not a model problem
the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.
the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work
on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect
My home firewall runs Ubuntu. It doesn't accept (new) incoming packets from the internet. I don't have any IoT devices except printers, whose packets the firewall rejects, and has done since I bought them. Do I need to do anything apart from wait for the patch to become available?
> Anthropic says Claude wrote the exploit "after initial prompting," that it runs "arbitrary commands as root, without any credentials or user interaction" on servers with a multipath TCP listener, and that in its proof of concept "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution."
This is wild. I'm a firmware nerd, not a backend nerd, what percentage of TCP/IP servers are 'multipath'?
Also, since IPv6 isn't affected, wouldn't it be funny if this is what it took to get everyone to switch.
My understanding is that an app explicitly needs to open a "multipath" socket. Go 1.24 does that by default, so does Caddy, these would be the big ones.
Anthropic only exploited multipath TCP, but the bug is deeper and also affects TCP connections, but it looks like this path is harder to exploit, and it's unclear if anybody managed to.
Thanks. Expanding exploits is something LLMs seem pretty good at so I’d expect people to manage a more general exploit soon if not already. Hopefully it’ll be patched before that happens.
OpenWrt doesn't open ports by default so I think the impact is minimal, unless this can breach nftables as well. CGNAT also mitigates this as a side effect.
If you have services open on the IPv4 net however, close them immediately as a precaution.
A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html
In addition to aggregating, it can also be useful in cases where one link is much slower or higher latency. For example, if you're sitting in your driveway trying to get directions in maps while your phone is still on your very weak wifi network, it's a better user experience to have it to attempt the request using both radios concurrently so that it can fallback to cellular without waiting for a timeout/connection error if you're too far for wifi to actually work well.
2027 is going to be the year of two to three major CVEs per day.
The discourse on this is weird, sounds at times as if these are “because of AI.” These are mostly pre-existing bugs, some very old, and they’ve been lurking. If they all get found we exit the other side more secure and reliable.
I went on a security kick early this year, locking down everything as much as I could. Build your systems with the assumption that you WILL get hacked. Limit blast radius. Be prepared.
The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!
I tried to find a mitigation using a ufw filter that rejects IPv4 packets with too large headers but it didn't work. It broke something essential and I had to switch it off again. I'd be interested in hearing about a temporary mitigation using firewall rules.
It might be bit of an effort to get Fil-C compiling the Linux kernel. As I understand it, it would amount to running garbage collector in the kernel, so some care would probably need to be taken to ensure it doesn't stop things at the wrong time, e.g. interrupts.
- MPTCP is not a requirement, it is a generic use-after-free.
- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.
- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.
- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.
That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.
> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution
source: https://www.anthropic.com/research/discovering-vulnerabiliti...
LTS doesn't work if you want immediate fixes like the current environment requires.
If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?
Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.
Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".
https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...
It went through internal QA and to the test soon after that, then a few days later to the no-subscription repository and as of yesterday morning CET it was cleared for the enterprise one, so it's available on all repos of all Products we got in their current supported releases.
For kernel updates we where even more conservative in the past, but with the current churn on often quite relevant fixes picked up the pace a bit on moving them along, trying still to balance rolling out fixes fast(er) while not doing that so fast that tricky (hardware/setup specific) regressions don't get caught.
edit: As this makes the rounds we also released a PSA for it now [0] to make our status here easier to find.
[0]: https://forum.proxmox.com/threads/proxmox-virtual-environmen...
My list (of feeds) is still small, but this CVE did not show up, do any of you have any tips for RSS feeds to use for this purpose?
https://ubuntu.com/security/CVE-2026-98432
https://access.redhat.com/security/cve/cve-2026-98432
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
> AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, TLS Listeners on Network Load Balancer, Cloud Front, API Gateway
> Customers using the above services do not receive TCP connections from untrusted sources directly when following best practices. AWS is applying updates to the underlying infrastructure of these services and no immediate customer action is required if you are using these services. We still recommend customers update their self-managed instances behind these services within the next 30 days.
[0]: https://aws.amazon.com/security/security-bulletins/2026-160-...
Another reason NixOS will continue to grow :)
If this requires a multi-core system to exploit, it's good news for most of the consumer routers that will never get updates. Saved by cheap single-core hardware.
Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?
[1] https://community.ui.com/releases/dd0283dc-bf71-4140-ae1d-c1...
An entire ecosystem of malware crawling and cohabiting in them.
I ask because I’ve been dabbling in rooting various closed devices at home. I’m finding AI fantastic at finding vulnerabilities statically (from firmware upgrade binaries), but when you then ask it to use it to get root or code execution it just goes in circles.
In the end it usually ends up there’s no exploit it can find, because it can’t actually influence the affected memory in a useful way. This is especially so if that memory is in the heap. On the stack it’s a lot more predictable (especially with OOB writes).
How do you know which pointer (as I say, especially if it’s in the heap)? And I know it can go wrong - but how do you do more than just crash the kernel?
In OOB writes in a stack variable it’s completely clear to me. For other situations I’d love to find real and clearly explained exploits of past UAF or OOB vulnerabilities.
The simplest thing you could try to do is allocate several more of the same type of object and hope one of them lands at the same memory address. For example if you can UAF a web app's user session and keep it open for a long time period (not true in the TCP bug), you might try to wait until an admin happens to log in with their session at the same address, then use their admin session.
Or you can allocate a lot of something else objects and hope a certain field overlaps, like a function pointer if you can write to it. Like suppose you can get some kind of authentication callback pointer to overlap where your packet sequence number was, maybe you can send a certain number of packets to make it point to the return instruction and skip the authentication.
At a high level, though: once you've gotten a new object allocated where the old one was, you now have two different views of the same bit of memory. You use valid operations on one view to put the other one into a corrupted state. For example: in a unixlike kernel, maybe one view has a field containing a function pointer (for method dispatch, essentially). You read that field using the other view, use it to deduce something about the target's memory layout, write a new value to the pointer, then use the field via the first view to cause execution to jump to a location you control.
the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.
the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work
on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect
This is wild. I'm a firmware nerd, not a backend nerd, what percentage of TCP/IP servers are 'multipath'?
Also, since IPv6 isn't affected, wouldn't it be funny if this is what it took to get everyone to switch.
no idea, but at least Tailscale and Caddy were opening MPTCP sockets on servers I checked.
Every Ubuntu version in the last decade is currently vulnerable.
https://ubuntu.com/security/CVE-2026-98432
Patches not yet available. That makes this a big deal.
This article says that this isn’t app level but is level and can be exploited before requests reach apps.
I was talking about the Anthropic blog post, only Go/Caddy enable multipath TCP listeners by default.
Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection.
It reads like it was LLM generated though so who knows. There is at least a simple mitigation for Golang apps if that is the only concern.
Anthropic only exploited multipath TCP, but the bug is deeper and also affects TCP connections, but it looks like this path is harder to exploit, and it's unclear if anybody managed to.
If you have services open on the IPv4 net however, close them immediately as a precaution.
https://www.reddit.com/r/openwrt/comments/1xka85h/is_the_ope...
They say 25.12-SNAPSHOT has it fixed
I see. https://nvd.nist.gov/vuln/detail/cve-2026-98432 affected versions format is the culprit. Entirely unusable. We do have versions, branch names and tags for a reason.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
[1] https://docs.kernel.org/networking/mptcp.html#sockets-api
The discourse on this is weird, sounds at times as if these are “because of AI.” These are mostly pre-existing bugs, some very old, and they’ve been lurking. If they all get found we exit the other side more secure and reliable.
The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!
I agree, but as yet we have no idea how much pain we have to pass through to get to the other side.
Watch your Linux systems for kernel updates. Reboot!