Maybe a government doesn't want them to do that.

Mosty probably: not. Traffic passes throught the ASIC, usually it is not processed on CPU or custom code. Unlike typical web servers, that reduces the attack surface as there aren't software parsers (a common place where vulnerabilities hide). Additionally the OS may have additional protection measures, such as signing each binary, signing the booting image and limiting which syscalls can be done by any binary.

Is it a cause of concern? Yes. Will you get hacked? Most likely not.

Most consumer routers run ancient stacks with all kinds of weird proprietary vendor patches that are tied to a specific kernel version. Looking at you Qualcomm!

However they generally also drop all traffic by default so from the WAN side they look like a black hole. I guess that's "safe" enough for most consumers.

For fun, take a look at the open PRs in the OpenWRT repos. Those people are doing some amazing work but it's also frustrating to see them struggle with things that _could_ be easy if the vendor made some slightly better choices.

I would strongly prefer something like OpenWRT though. Call me paranoid but after the last few weeks I'm increasingly less comfortable with connecting my devices to a blackbox.

This is one of the biggest benefits of using OpenWRT. They update the entire stack like every other month or so you’re never on an ancient kernel or utils.

This is why I use a fanless PC as my internal router. I have complete control and get timely kernel updates from a responsible distro.

Ubiquity routers and APs do. Also schedulable backups.

Granted they are pro-sumer devices, not strictly consumer.

Google Wifi used to be good about that. I even got a notification for when my AP was being EOL'd and would no longer receive automatic firmware updates. I don't know if Google is still on the ball there. The Nest acquisition was confusing. Have the Google Wifi and Nest Wifi teams been merged?

But FWIW I run my AP in bridge mode. Wifi drivers and chip firmware seem to be riddled with exploits. I don't want my router & firewall on the same system as the AP.

even more concerning would be the ones who run closed source os but never update.

at least with an open source os there are more paths forward.

A lot of them run BSD, not linux, which wasn't affected

Nah I wouldn't worry about I'm sure they're fine

most of the routers are patched by ISPs directly. also: they are usually not x86 architecture - so not all exploits are possible.

Same for Flock cameras, running a 2017 kernel.

I've seen another poster successfully updating their Kernel from Ubuntu's "proposed" branch which already has the fix. God knows why they don't merge it into stable.

> I've also not seen anyone else make this claim.

That's what I call Steve Jobs style PR / Marketing you deflect the problem by making another problem to make it seem like you're fully aware. "You're holding the phone wrong"

> I have not seen an exploit in the wild.

How would you see one? Have you deployed your own army of honeypots that are actively logging and looking for corrupt IP options packets? If you're not already looking for it, I think it's very likely that most people who get hacked will have no way of knowing how it happened, so we can't consider those incidents as being a result of this particular bug.

Are you actually monitoring for this specifically or just trying to use a sample size of 1 group of servers to prove something?

Yeah, there's definitely more to the story about exploitability that Anthropic isn't telling us. RHEL didn't release a patch until yesterday either.

According to wikipedia[1]:

> A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it.

Apparently the meaning has evolved over the years.

[1] https://en.wikipedia.org/wiki/Zero-day_vulnerability

The volunteer and staff that made up Freenode moved to libera.chat, which is the defacto freenode replacement, if anyone wanna know.

Yeah, I thought we stopped posting freenode links here on HN a while ago. Kinda surprised about this one (especially since it is covered in detail elsewhere as well)

Yeah attackers might not want to bother spending tokens on some niche OS but security thru obscurity only gives you so much

> about having pointless services listening for no good reason

I think you'll find that for most people, plugging the laptop in and having the network immediately available and automatically seeing their local printer is a pretty good reason.

This CVE has nothing to do with leaving random ports open. "Tightening up" will not protect vulnerable servers.

> For example Linux works totally fine without running dhcpcd

how you refresh dhcp lease if there is no service taking care of ? Why you think DHCP is pointless ?

These comments always misunderstand the long tail of the individual end user.

Red Hat claims[1] that's not enough:

> The following nftables table drops incoming IPv4 TCP packets that contain IP options, which reduces exposure to this vulnerability but cannot fully prevent it.

I suppose locally-running malicious programs could send packets to the loopback address or one of its own IPs or something.

[1] https://access.redhat.com/security/vulnerabilities/RHSB-2026...

I know that's one mitigation technique, like disabling mptcp does. But does that fully prevent this exploit?