Anyone else feel like there’s a rise in cybersecurity fear mongering lately?

Posted by catfrogbigdog@reddit | ExperiencedDevs | View on Reddit | 27 comments

I’ve been working on data/analytics APIs for over a decade. ive gone through SOC2, HIPAA, FedRAMP, you name it, and I’m usually the guy advocating for being more cybersecurity conscience, but lately I feel like I’ve seen more “It’s so over” security stories that ever before that are all way overblown.

This one (CVE-2026-48710 / BadHost) is driving me nuts:

https://arstechnica.com/information-technology/2026/05/millions-of-ai-agents-imperiled-by-critical-vulnerability-in-open-source-package/

Partly because I know Starlette and FastAPI really well (being a data guy and all), so I thought it was really odd to see people saying there’s an “authentication bypass” vulnerability in Starlette when it literally doesn’t have an authentication implementation (you have to bring your own JWT or cookie auth).

Without getting too into the weeds here, the vulnerability allows an attacker to change the URL by manipulating the Host header. Of course this is bad. But, clearly it has nothing to do with how cookies are handled (which is what I thought might have been the issue) and certainly doesn’t have anything to do with the Authorization header (JWT auth), which is how every FastAPI app I’ve worked on has done auth, so there’s really no way to impersonate a user that I’m aware of.

Even looking at the CVE’s title “Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks”

https://app.opencve.io/cve/CVE-2026-48710

It’s even ranked as a 6.5 moderate severity on the CVE itself. It doesn’t even mention “authentication” in the details, but that’s not stopping all these news articles and people on social media fear mongering that this is some catastrophic vulnerability for a large search of Python apps.

Anyways, I’m feeling like I’m going crazy here. Maybe I’m missing something though, so please correct me in the comments if I’m missing something.

[-]

Drayenn@reddit

All i know is i had a meeting this week and we talked about Mythos and AI vulerability exploits in general and how we need to react 15x faster to fix our vulnerabilities.. felt like "fix in 2 days or else" "we'll have to figure out a plan if we get one during the weekend"

[-]

catfrogbigdog@reddit (OP)

Right… I think that’s contributing to this rise in fear mongering.

Not every CVE is exploitable and in my experience most CVEs flagged by scanners aren’t exploitable in our specific app, so increasing turnaround time for shipping patches might just burn your team out more.

[-]

Smallpaul@reddit

This is what has changed. The top models now generate exploit code.

I’ll quote CloudFlare:

“It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:

Exploit chain construction - A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.

Proof generation - Finding a bug and proving it's exploitable are two different things, and Mythos Preview can do both. It writes code that would trigger the suspected bug, compiles that code in a scratch environment, and runs it. If the program does what the model expected, that's the proof. If it doesn't, the model reads the failure, adjusts its hypothesis, and tries again. The loop matters as much as the bugs it finds, because a suspected flaw without a working proof is speculation, and Mythos Preview closes that gap on its own.

Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit.”

[-]

catfrogbigdog@reddit (OP)

That all may well be true, but doesn’t justify fear mongering or misrepresenting the risks of CVEs like the one I mentioned.

[-]

Smallpaul@reddit

The threat landscape actually has changed and we live in a more dangerous world from a cybersecurity point of view.

[-]

codescapes@reddit

Yep, similar experience at my employer. So much hysteria and so little thinking. Pointing to an actual example, like the recent TanStack supply chain attack, shows how using the absolute latest package is itself a meaningful security risk (https://tanstack.com/blog/npm-supply-chain-compromise-postmortem).

You should realistically have a 48h cool off - minimum - this is configurable in various package managers. For security reasons but also because there may be unknown bugs / vulnerabilities you introduce because it's so new. For reference I don't mean 'stay on some old dependency from 4 year ago' nor 'stay on a dependency with a major CVE because it has only been 24h since the fix came out' - just that the default policy should not be *immediate* upgrade. Fast track sure but constantly falling over yourself to get the latest patch version the nanosecond its released is not the right approach.

[-]

---ill-go-last---@reddit

Lol, “lately”..

The raisod d’etre of that entire industry is fear mongering.

[-]

archialone@reddit

No. I've been exposed to it for a while. SasS protection services, dependancies scanners, docker scanners. Endpoint protection. Etc...

Most of it is fear mongering and grifting, with AIM to sell a useless product.

[-]

doyouevencompile@reddit

It’s kind of the same story with “scientists cure cancer” news. Or how people treat every viral infection as if it’s the new Covid. Most people are not familiar with the nuances of things. Most news articles are written for clicks.

There has been quite a few large scale supply chain attacks recently and they have gotten more public attention so it’s an easy click.

iirc arstechina was also sold so it’s no longer a reliable source of technology news.

[-]

Izacus@reddit

Also security researchers have gotten used to bombastic marketing because it gets them more funding, more eyes, more conferences for continued work. Similarly the AI models need to be sold as well.

It's all marketing, all the way down.

[-]

doyouevencompile@reddit

i might be all for better security. Yeah there’s sometimes sensationalism but considering the vast amount of cyberattacks and gaps in security it’s a good thing to have security as a priority.

[-]

catfrogbigdog@reddit (OP)

Yeah fair. Maybe it’s always been this way and I’m just getting fed these stories more these days.

[-]

doyouevencompile@reddit

Understandable. Journalism everywhere has gone downhill and it’s more annoying when it’s in an area you have deeply knowledgeable

[-]

raralala1@reddit

People also forget that there is huge possibility that Covid really is lab created from china, also there is plenty of fear mongering before Covid happen, just want people to start remembering history just google pandemic and find video from 2010-2020 there is huge number of it not just gates fear mongering pandemic fyi.

[-]

billdietrich1@reddit

there’s a rise in cybersecurity fear mongering lately?

The fears are justified. We've had major CVEs such as the BitLocker thing, a flood of vulns and exploits from LLMs, and major data breaches from companies such as Canvas/Instructure.

[-]

xopherus@reddit

I’m sure it all stems from Mythos. Companies everywhere have had conversations about it and what their response will be when it drops and all of a sudden they have hundreds of critical vulns they need to patch or else some hacker is going to pop them and destroy the company.

There have been more supply chain attacks over the last 6mo as well but I don’t think those alone are causing the urgency in the media coverage.

[-]

PinEnvironmental6395@reddit

The Starlette thing is being undersold by its CVSS. Those ratings aren't particularly helpful when it comes to "how bad is this issue in abstract" since they're a computed score based on rough input values. They're really for automated systems to crunch on at this point.

The issue lets an attacket poison the value that's returned by request.url. So when your authentication middleware gets called and asked "hi is this request authenticated and authorized?" it's going to check the requested path as reported by request.url. If your attacker poisons it so that it contains a URL that the middleware doesn't care about, then it'll let the request right on through even if the endpoint that the request is actually about to get routed to should have been authenticated or authorized.

Or in other words, if you read request.url to make authz decisions, and your application exposes endpoints that aren't authenticated (like, say, a /login), then you might as well not have an authorization check at all.

As for hysteria, a big part of it is the AI boogeyman. It's getting particularly bad because now that cyber is in the hype cycle beyond "company X was negligent, point and laugh" senior leadership types are terrified that their shoestring budget infosec team is about to get flambeed by a teenager with a stolen anthropic API key.

[-]

jozefizso@reddit

This is a very well written explanation and indeed there’s a possibility of authentication bypass.

[-]

catfrogbigdog@reddit (OP)

But a standard JWT authentication middleware would ignore the request.url and only check the Authorization header for the user’s token.

And an authentication backend isn’t provided by Starlett but it has a you can implement your own auth with here. You can see in their example middleware it doesn’t touch the request.url and just looks at the Authorization header.

FastAPI takes a different approach with an example implementation of JWT auth here. Again, it’s not dependent on the request.url and uses the Authorization header.

[-]

wildfirestopper@reddit

Yes but I don't think it's unwarranted tbh.

[-]

catfrogbigdog@reddit (OP)

Don’t you think there’s a risk with misrepresenting risks though? It could create a boy who cried wolf effect

[-]

crazylikeajellyfish@reddit

In that story, the whole village came running the first time that the boy cried wolf. In real life, most people don't use a password manager and most JS devs have no idea what packages they've installed. An uptick in attention is the exception to the rule, which is most people not giving a shit.

Also, cryptocurrency and the growing number of developers have made cybercrime more easily lucrative than ever before. We live in a golden age for attackers, gotta do what we can to stem the tide.

[-]

catfrogbigdog@reddit (OP)

Right my whole point is that we’re well past the part of the story where the villagers come running. But we can agree to disagree.

+the order the middlewares are run shouldn’t matter unless you only use the URL for authorization/permissions, but in most situations you’d check what access the user record has before returning any private data.

Think about how a basic GET /api/projects/ route would work. You’d check the Authorization header for a token then authenticate the user and then run SELECT * FROM projects WHERE owner_id=user.id or whatever.

How would malforming the Host header get you another user’s project data?

[-]