This one is quite serious and the type of vulnerability is once again, a C style memory corruption and a race condition combined; leading to an RCE.
At this point, we seriously need to discuss whether if the major projects still written in C such as Linux, Chromium and even git can even handle the stream of now near infinite bugs being discovered with AI.
Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.
These sort of vulnerabilities are far to common in those projects and in the future, it will be extremely unsafe for even experts to continue using C or C++ in any way.
I bet there's a half-life to bugs though. Bugs might be infinite over the lifespan of a project, but the rate that they are produced goes down with our ability to detect them.
A lot are being found _now_ in projects written in C because the backlog of bugs to find is mostly written in C. We haven't yet gotten to the point when we're detecting most bugs before they're released, but we will.
Unless someone vibecodes a new OS and convinces everyone to use it, we're stuck with what we got. Reaching feature parity with Linux and then debugging it to the point where it'd be usable is a gargantuan undertaking.
DHH and team are writing Omarchy components in Rust when possible. I was playing on that in my now downvoted comment.
Obviously Omarchy's kernel, Wayland, and the Hyprland compositor are not Rust and work just fine. If you've seen any of DDH's public speaking, he's willing to burn tokens to Rust all the things, don't tempt him! That was the joke, people.
I am pleasantly surprised to be daily driving Omarchy with minimal friction, by the way. For a relatively new Linux OS, this is no small feat.
> Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.
Are they? Distributions are rating this at a lower severity presumably because it can’t be easily exploited.
Would dropping these specialized ipv4 syn packets with extra header size beyond 20 bytes with the firewall (iptables/nftables/etc) be low enough in the order of things to mitigate the attack? Like, iptables -A INPUT -p tcp --syn -m u32 --u32 "0>>24&0xF=6:15" -j DROP ?
I fail to understand / find the gist of this article.
Article describes the technical aspects of the bug, how it got handled by different vendors...AI position on it...
But, one would always ask themselves, why did the author write this article? That part hasn't been clear to me even after going through much of the article.
I believe the author of this article is in fact most likely a large matrix multiplication and that it is possible that no human even initiated the computation of said multiplication directly. I assume it's not hard to set up some monitor for new CVEs to try and slop out an article as quickly as possible to get as revenue
GoogleGroups (slight tangent) Go programs enable MPTCP by default, exposing them to Linux CVE-2026-98432 (9 points, 3 hours ago, 4 comments) https://news.ycombinator.com/item?id=50298526
It would have been about 50x less annoying if whoever was driving the LLM had simply told it to make a clickable index/headers in markdown and divide it into sections and subsections by logical topic.
Pattern worth flagging: this is the second kernel UAF in a packet-handling subsystem to hit the news this cycle — the recent PHP2Shell chain used an XFRM ESP-in-TCP UAF to escalate from www-data to root. Both bugs sit on the "mark-then-free" side of the race (SOCK_DEAD-bit-equivalent patterns).
On patch validation specifically: the right smoke test is a reproducer that FAILS without the mark being set, not "no crash in syzkaller for N hours." Those are different quality bars, and the article doesn't address which one this patch cleared.
Given these types of security bugs that are being found left and right, I reckon there's going to be an uptick in hiring of software engineers to fix them.
There is a push for that, but the fixes (often as little as a one line Dockerfile change in some cases) still have to be tested and verified by a real engineer.
Otherwise everywhere would have patched already with AI.
"Haven't had enough yet of very junior engineers pasting wall-of-text from chatgpt at you in Slack? Come on down to the CVE announcement emporium, where we have a special treat for you today..."
The overlaid HTML popup on that page for "Try The World's First Agentic AI Hacker." tool is cancerous and annoying. This should really be a link to a more reputable link for the CVE in question.
It doesn't appear until you've read the page for maybe 10-15 seconds, so if you're not seeing it, just wait.
It even managed to get past ublock origin, since there's no specific rule for it yet.
48 comments
[ 0.59 ms ] story [ 35.9 ms ] threadAt this point, we seriously need to discuss whether if the major projects still written in C such as Linux, Chromium and even git can even handle the stream of now near infinite bugs being discovered with AI.
Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.
These sort of vulnerabilities are far to common in those projects and in the future, it will be extremely unsafe for even experts to continue using C or C++ in any way.
Edit: also thanks for using RCE correctly, it seems to be any kind of code execution these days is considered "RCE".. boo.
A lot are being found _now_ in projects written in C because the backlog of bugs to find is mostly written in C. We haven't yet gotten to the point when we're detecting most bugs before they're released, but we will.
Obviously Omarchy's kernel, Wayland, and the Hyprland compositor are not Rust and work just fine. If you've seen any of DDH's public speaking, he's willing to burn tokens to Rust all the things, don't tempt him! That was the joke, people.
I am pleasantly surprised to be daily driving Omarchy with minimal friction, by the way. For a relatively new Linux OS, this is no small feat.
Are they? Distributions are rating this at a lower severity presumably because it can’t be easily exploited.
Not sure why the article doesn't mention it, but you can specifically check for MPTCP listeners using `ss -M`.
> ListenConfig now uses MPTCP by default on systems where it is supported (currently on Linux only).
This seems to imply basically any golang server built since February 2025 is going to be at least attempting to use it.
Luckily though, it seems dialer lets you override this https://cs.opensource.google/go/go/+/refs/tags/go1.27.3:src/...
Want a big name? RedHat.
I was vulnerable myself by using Caddy (although MPTCP is not a prerequisite).
Article describes the technical aspects of the bug, how it got handled by different vendors...AI position on it...
But, one would always ask themselves, why did the author write this article? That part hasn't been clear to me even after going through much of the article.
Ubuntu (34 points, 16 hours ago, 3 comments) https://news.ycombinator.com/item?id=50287647
CVE.org (2 points, 7 hours ago) https://news.ycombinator.com/item?id=50295879
GoogleGroups (slight tangent) Go programs enable MPTCP by default, exposing them to Linux CVE-2026-98432 (9 points, 3 hours ago, 4 comments) https://news.ycombinator.com/item?id=50298526
On patch validation specifically: the right smoke test is a reproducer that FAILS without the mark being set, not "no crash in syzkaller for N hours." Those are different quality bars, and the article doesn't address which one this patch cleared.
Otherwise everywhere would have patched already with AI.
You're essentially saying that swallowing a pill is trivial, so therefore pharmaceutical engineering is.
I’m saying patching is easy because the pill is delivered to you.
Everyone using LLMs needs to stop shipping their first draft.
"I have made this letter longer than usual, only because I have not had the time to make it shorter"
("Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte").
Also Balzac:
* https://quoteinvestigator.com/2012/04/28/shorter-letter/
It doesn't appear until you've read the page for maybe 10-15 seconds, so if you're not seeing it, just wait.
It even managed to get past ublock origin, since there's no specific rule for it yet.
None of this can ever affect seL4[0] nor a system built on it, due to its architecture.
0. https://sel4.systems/