7 ms·

AI is breaking two vulnerability cultures

430 points by speckx 6mo ago

pwndog999 6mo ago
[dead]
Analemma_ 6mo ago
I'd argue it's actually breaking three vulnerability cultures. In addition to the two Jeff mentions, I think the culture of delaying upgrades and staying on stable versions for as long as possible is going to become increasingly untenable, if everything that's not latest can be trivially scanned and exploited. In the extreme I think there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. There will be much wailing and gnashing of teeth around this, because a lot of tech types really resent having to update constantly, but I don't think people will have a choice. If you have a complicated stack where major or even minor version updates are a huge hassle, I'd start working now to try and clear out the cruft and grease those wheels.
- acranox 6mo ago
  Debian has updated kernel packages out for the stable release. https://security-tracker.debian.org/tracker/CVE-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-43284 I kind of get your point, but they responded pretty quickly here.
  - Analemma_ 6mo ago
    Oh yeah, to be clear: Debian has always been good about quickly shipping patches to kernel vulnerabilities, and they will continue to be so. I was more thinking about whether they will get overwhelmed if every bit of software they package just has a firehose of vulnerabilities on everything which isn't latest.
- muvlon 6mo ago
  That's not really the culture of debian to be honest. Yes they run old major and minor versions, but they do ship patch updates as fast as they can. Even on debian stable, you absolutely are supposed to update all the time. The culture of "just don't touch it" is a different one (but also exists, I've seen it).
- layer8 6mo ago
  > there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. Debian continuously issues security updates for stable versions, ingestable with automatic updates. “Stable” doesn’t mean that vulnerabilities aren’t getting fixed. The argument that could be made is that keeping up with getting vulnerabilities fixed might become such a high workload that fewer releases can be maintained in parallel, and therefore the lifetime and/or overlap of maintained releases would have to be reduced. But the argument for abandoning stable releases altogether doesn’t seem cogent. It goes both ways: Stable code that only receives security updates becomes less vulnerable over time, as the likelihood of new vulnerabilities being introduced is comparatively low. From that point of view, stable software actually has a leg up over continuous (“eternal beta” in the worst case) functional updates.
  - ryandrake 6mo ago
    I can only dream, but this may re-popularize (among the rest of the non-Debian software industry) the general best practice of keeping a "sustaining" branch green, buildable, and with frequent releases, for security fixes. I hate software that forces you to take new features as a condition of obtaining bug and security fixes. We need to keep old "stable" builds around for longer and maintain them better. I know, I know, it is really upsetting to developers to have to backport things to old versions--they wish that all they had to work on was the current branch. But that just causes guys like me to never upgrade because the downside of upgrading (new features) is worse than the upside (security fixes).
- pixl97 6mo ago
  We are now paying for the sins of our fathers (well and mostly ourselves). We've just kept building more complex things with more exposure with no recognition that the day of reckoning was coming. And now we are in an untenable situation. With governments spending billions on AI with the big providers it's likely they've found many of these already.
- tetha 6mo ago
  > In the extreme I think there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. It may actually be the opposite. Debians steady and professional approach on shipping security patches with very little to no functional difference actually enables us to consider and work on automated, autonomous weekly or faster patches of the entire fleet. And once that's in place and trusted, emergency rollouts are very possible and easy. We have other projects that "move fast and break things" and ship whatever they want in whatever versions they want and those will require constant attention to ship any update for a security topic. These projects require constant human attention to work through their shenanigans to keep them up to date.
  - calvinmorrison 6mo ago
    Not only that but debian has for example, debsecan so you can see on any system what CVEs exist and if your packages are patched. ex from my system I ran it and got > CVE-2026-32105 xrdp which i see has a fix in sid but not on bookworm
- giancarlostoro 6mo ago
  Arch Linux to become the only Linux OS left.
- y3ahd0g 6mo ago
  Yep. This is why I am using local AI to edit and build my own copies of Linux kernel, Wayland... everything a distribution would ship really. Not so daunting for me having come of age when compiling a kernel specific to a hardware platform was essential. Custom software that does not fit the usual patterns is not fool proof but it won't be obvious. Monocultures with all their eggs in one basket are even less secure than truly diverse ecosystems though.
rikafurude21 6mo ago
This feels more like an old problem getting reframed as an AI problem. people were already diffing kernel commits and figuring out which ones were security fixes long before llms. if a patch lands publicly, the race has basically already started. also not sure shorter embargoes really help. the orgs that can patch in hours are already fine. everyone else still takes days or weeks. if anything, cheaper exploit generation probably makes coordinated disclosure more important, not less.
- JumpCrisscross 6mo ago
  > people were already diffing kernel commits and figuring out which ones were security fixes With skill, and usually not consistently and systematically. With AI, anyone can do this to any software. > not sure shorter embargoes really help Why 90 days versus 2 years? The author is arguing the factors that set that balance have shifted, given the frequency of simultaneous discovery. The embargo window isn’t an actual window, just an illusion, if the exploit is going to be found by several people outside the embargo anyway. > cheaper exploit generation probably makes coordinated disclosure more important I agree. But it also makes it less viable. If script kiddies can find and exploit zero days, the capacity to co-ordinate breaks down. There was always a guild ethic that drove white-hate (EDIT: hat) culture. If the guild is broken, the ethic has nothing to stand on.
  - gritspants 6mo ago
    I'm here for white-hate culture. You should, you should know better.
  - Hizonner 6mo ago
    > With skill, and usually not consistently and systematically. How do you know? If the people who like to crow about vulnerabilities aren't doing it, it doesn't mean that the people who are actually in a position to exploit them systematically and effectively aren't doing it. Those embargoes have always been dangerous, because they create a false sense of security. But, as you point out... > With AI, anyone can do this to any software. Yep. Even if it hadn't been true before, it's clear that now you just have to assume that everybody relevant will immediately recognize the security impact of any patch that gets published. That includes both bugs fixed and bugs introduced. ... and as the AI gets better, you're going to have to assume that you don't even have to publish a patch. Or source code. Within way less time than it's going to take people to admit it and adjust, any vulnerability in any software available for inspection is going to be instant public knowledge. Or at least public among anybody who matters.
JumpCrisscross 6mo ago
> So many security fixes are coming out now that examining commits is much more attractive: the signal-to-noise ratio is higher Why? > Additionally, having AI evaluate each commit as it passes is increasingly cheap and effective This is the key. With AI, the “people won't notice, with so many changes going past” assumption fails.
xiaoyu2006 6mo ago
The quick test doesn't show a lot - by out straight asking if this is a security patch, it implies and guides AI to have output more probably to agree on this assumption. A confusion matrix is more useful. Nonetheless of course this is not a detailed ai capability testing blog.
- cubefox 6mo ago
  Yeah, ideally we would need the phi coefficient (aka MCC, the binary Pearson correlation), which can be calculated from a confusion matrix of yes/no LLM classifications for all kernel diffs. (Number of true positives, true negatives, false positives, false negatives.)
- jefftk 6mo ago
  [author] I agree it is not much additional evidence! If someone wanted to try running the same test on a series of N commits from that list including this one I'd be very curious to see the answer!
- cormacrelf 6mo ago
  Realistically, if you are scanning each kernel commit to check if they might be patching a security issue, you are going to be asking an LLM "is this security related, if so vaguely how" with low effort and taking "maybe" as a yes before feeding it to a more expensive model. You aren't trying to establish a probability of an ultimately unknowable fact, there is ground truth that you can find by producing an exploit, so you are just trying to pre-filter before spending the money to find it.
papichulo2023 6mo ago
Maybe it is about time for Linux to get a real CD/CI and start using AI extensively. Not just for vulnerabilities, having a nice agents|skills|etc.md definitions would encourage new devs to contribute instead of dealing with an overworked maintener repeating the same thing for n time.
j2kun 6mo ago
> Luckily AI can speed up defenders as well as attackers here, allowing embargoes that would previously have been uselessly short. This is an important facet of the problem space: security risks turning into an arms race for who wants to spend more tokens.
- nicce 6mo ago
  One interesting thing is that this makes closed source code even greater asset for the defenders. Attacker cannot spend tokens for it, but defenders can spend tokens for hardening based on source code, while attacker is stuck with blackbox testing.
  - j2kun 6mo ago
    Decompilation is quite good these days as well
  - watusername 6mo ago
    You would be surprised how adept SOTA models are at reverse engineering with IDA/Ghidra or even plain old objdump. Opus basically knows IDAPython on the back of its hand.
    - nicce 6mo ago
      They can be, but the most interesting parts (backend code, deployment confs) are not usually available. Reversing clients can help to understand a bit, but not with equal level.
      - kardos 6mo ago
        On the other hand, any source code leak could be catastrophic
miki123211 6mo ago
AI will shorten update windows dramatically. 2026 is the worst year to be thinking about dependency cooldowns, we need to think about dependency warmups instead. Soon, there will be no such thing as a safe way to disclose a vulnerability in an open source project. Centralized SaaS will have a major security advantage here.
- woah 6mo ago
  You could have a web of trust where Linux-using organizations each spend $x continuously scanning and patching their own dependencies with AI, and sending each other patches and scans.
  - dakolli 6mo ago
    LLMs aren't capable of doing this, and never will be no matter what Anthropic tries tell you.
    - fragmede 6mo ago
      Mozilla seems to think it can. https://blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/ https://blog.mozilla.org/en/privacy-security/ai-security-zer...
      - dakolli 6mo ago
        Ahh yes, I'm sure agents did this all autonomously without any human in the loop what so ever. They are useless without experts to handle them.
        fragmede 6mo ago
        So then have the Linux-using organizations employ experts to handle them then.
    - a_vanderbilt 6mo ago
      That's the same mindset some people had 3 years ago when they said AI wouldn't be capable of software development. Look where we are now.
FuriouslyAdrift 6mo ago
Reverse engineering vulnerabilities from patches is red team 101...
oytis 6mo ago
The old saying of Tony Hoare about no obvious bugs vs obviously no bugs holds in the age of LLMs more than ever
- fragmede 6mo ago
  > There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." — Tony Hoare for those (like me) who hadn't seen it before.
  - randyrand 6mo ago
    That’s really clever and quite funny!
proteal 6mo ago
It sounds to me like the safe assumption with software is that no matter how solid your stack is, there are vulnerabilities, potentially catastrophic. A question to folks more experienced than me - if my business depends on software, and I know that my software is almost certainly exploitable, how do I posture my business in such a way as to minimize the impacts of exploits like these?
- perlgeek 6mo ago
  When Windows was the predominant desktop OS in the 90s and maybe early 00s (ok, maybe still is), it was so badly insecure that you could be pretty much sure that it would be easy to compromise. That's when firewalls were widely deployed to provide some layer of protection. So you can ask yourself, what is the (possibly metaphorical) firewall in the software you depend on? Is there any way you can decrease attack surface, separate out the most important data in extra-secure (and thus less accessible) systems?
tptacek 6mo ago
This has been a very long time coming and the crackup we're starting to see was predicted long before anyone knew what an LLM is. The catalyst is the shift towards software transparency: both the radically increased adoption of open source and source-available software, and the radically improved capabilities of reversing and decompilation tools. It has been over a decade since any ordinary off-the-shelf closed-source software was meaningfully obscured from serious adversaries. This has been playing out in slow motion ever since BinDiff: you can't patch software without disclosing vulnerabilities. We've been operating in a state of denial about this, because there was some domain expertise involved in becoming a practitioner for whom patches were transparently vulnerability disclosures. But AIs have vaporized the pretense. It is now the case that any time something gets merged into mainline Linux, several different organizations are feeding the diffs through LLM prompts aggressively evaluating whether they fix a vulnerability and generating exploit guidance. That will be the case for most major open source projects (nginx, OpenSSL, Postgres, &c) sooner rather than later. The norms of coordinated disclosure are not calibrated for this environment. They really haven't been for the last decade. I'm weirdly comfortable with this, because I think coordinated disclosure norms have always been blinkered, based on the unquestioned premise that delaying disclosure for the operational convenience of system administrators is a good thing. There are reasons to question that premise! The delay also keeps information out of the hands of system operators who have options other than applying patches.
- grog454 6mo ago
  > It has been over a decade since any ordinary off-the-shelf closed-source software was meaningfully obscured from serious adversaries. Probably goes without saying but the last line of defense is not deploying your software publicly and instead relying on server-client architectures to do anything. Maybe this will be more common as vulnerabilities are more easily detected and exploited. Of course its not always feasible. It has been annoying seeing my (proguard obfuscated) game client binaries decompiled and published on github many times over the last 11 years. Only the undeployed server code has remained private. Interestingly I didn't have a problem with adversaries reverse engineering my network protocols until I was updating them less frequently than weekly. LLM assisted adversaries could probably keep up with that now too.
Animats 6mo ago
We have a huge problem. The US is at war. Much of the world is at war at the cyber attack level right now. The US, the EU, most of the Middle East, Israel, Russia... Major services have been attacked and have gone down for days at a time - Ubuntu, Github, Let's Encrypt, Stryker. Entire hospital systems have had to partially shut down. Now, in the middle of this, AI has made attacks much faster to generate. Faster than the defensive side can respond. Zero-day attacks used to be rare. Now they're normal. It's going to get worse before it gets better. Maybe much worse.
- pier25 6mo ago
  > before it gets better How is it going to get better?
  - jcgrillo 6mo ago
    By holding engineers accountable for the stability and security of their software.
  - jefftk 6mo ago
    I'd speculate that at this point Linux etc are probably having vulnerabilities discovered and patched faster than created.
    - pier25 6mo ago
      It's not only Linux though and many projects don't have the funding to perpetually use something like Mythos.
  - nicce 6mo ago
    Downplaying security has now real coencequences for everyone.
  - Sarky 6mo ago
    Right now we are at a point in time when AI can find bugs for attackers and defenders, but defenders did not fix/find those bugs yet. In time most of the bugs AI can find will be fixed, and things will calm down. Some bugs will be left, but will be too complex to find and weaponise (or rarely). Alin short, attackers have advantage for a brief time now, but ultimately defenders will win. I guess this "fight" might be over before the end of the year.
cryo32 6mo ago
I must admit I'm rather enjoying this particular form of shit show, mostly because it was a predication I made in 2023 in the early days of LLMs. It wasn't really a problem related to LLMs but a glaring hole in the thinking of current computing which is the "frustratingly over-connected" and "over-trust" approach to everything. After reading Liu Cixin's "three body problem" and noting the Dark Forest, I applied that to risk vectors and came to the conclusion that our over-connected nature plus some form of acceleration plus some form of negative impact will fuck us big time. Turns out it did. Thus we should probably start treating our thinking model of computing as a Dark Forest, not a friendly community. That mitigates these risks to some degree.
- 9dev 6mo ago
  If you're into gaming, Cyberpunk 2077 essentially plays in a heavily technologized world, where all compute infrastructure is infested with rogue AI that replicates itself to any technology it can physically get in touch with. The only recourse is a new web, built from first principles, protected by (probably) benevolent AI systems. Every device, every server, is partially occupied by AIs doing their thing on it, virtually networked into a digital universe. I found that a fascinating thought.
  - cryo32 6mo ago
    Have played that end to end. It's a dystopian hell hole.
Havoc 6mo ago
The bugs are bugs description reads pretty insane to me personally but I know linux world has many people valueing principle of it over practical matters. 90d seems long too though. Think ultimately the big AI houses will need to help the core internet infra guys. Running latest and greatest AI over stuff like nginx and friends makes sense for us all collectively I think
Worf 6mo ago
> On the other side you have "bugs are bugs" culture. This is especially common in Linux, where the argument is that if the kernel is doing something it shouldn't then someone somewhere may be able to turn it into an attack. Just fix things as quickly as possible, without drawing attention to them. Often people won't notice, with so many changes going past, and there's still time to get machines patched. The 3rd one is what I practice when giving companies time to fix their issue. Note, I haven't reported anything to FOSS projects, but to several companies I found exploits in. I give them 5 days. If they don't respond at all in the first day, I deduct 1 day - apparently they're either incompetent or don't care. After the 5 days have passed, I make it public. So far they've all fixed the issue on the 3rd or 4th day. If I were to report something to a FOSS project, I'd give them a bit more, say 8-9 days. Enough time for everyone to wake up, review the vuln, patch it and ship it. Enough time for all the downstream projects to also ship the patch. 90 days is ridiculous, especially for companies. If I report something on Friday 23:30 and they reply Monday 15:00 - what were they doing during the weekend? Did they forget their software is used 24/7? I had one company complain quite a bit, threatening to sue. When they realized there was no one to sue (me being anonymous with my report), they fixed it in less than a day. Bottom line - if you're a company offering a product or service, you should have a security team 24/7. If you're a FOSS project - either alert your users to stop using your software or disable the service yourself, if you can. If it's an extremely important life-or-death service you can't shut off - then fix it quickly. What are you doing with life-or-death stuff when you can't react quickly enough? Fuck the 90 days standard - it's what companies want us to do because it's easier on them. If security hasn't been your top priority, you have a few days to make it your top priority. With AI, that makes even more sense now. Bugs won't be able to stay hidden for months. Especially bugs I've reported like IDORs or SQL injections - things everyone tries first. (and I love Linux, but getting an "Oh noes!" from Anubis at kernel.org because I don't have cookies enabled (I do??) really makes me not want to report anything to the Linux kernel in particular. If I ever did find something, I'd just immediately post it as a HN comment or something like that)
- jefftk 6mo ago
  > 90 days is ridiculous, especially for companies It depends on the kind of vulnerability, but sometimes in order to fix a problem, you need to do an enormous amount of software engineering. Which needs to be done to a very high standard, because the expectation is that people will push security patches more or less immediately to production. Of course, this only works if no one else is likely to discover the vulnerability in the meantime!
0xbadcafebee 6mo ago
We need automated patch and release cycles. So far we've relied on incredibly slow manual processes to accept reports, investigate, verify, patch, and prepare releases. Releasing a fix often takes months. This is way too slow when attackers can just churn out new exploits in hours. We need to iterate on value chain bottlenecks to lower Mean Time To Patch. We should be able to turn around a bug report to a patched product ready for QA testing in 1 hour. Standardize/open source it, have the whole software supply chain use it (ex. Linux kernel -> distros -> products that use distros -> users). With AI there's no reason we can't do this, we're just slow.
- jfk13 6mo ago
  Sounds like you're expecting the AI-based tools that are finding bugs to also provide fixes. I've been dealing with a bunch of AI-generated (or at least -assisted) vulnerability reports lately. In many cases the reports include proposed patches to fix the issues. It's been..... interesting. In many cases, the analysis provided in the report has been accurate and helpful. In some cases, the proposed patches have also been good, and we've accepted them with minimal or no changes. In other cases, despite finding a valid issue, and even providing a good analysis of the problem, the AI tool's suggested patch has been, quite simply, wrong. Careful review from somebody who really _understands_ the code -- and the wider context in which it is operating -- is still absolutely necessary. That's not always going to happen in an hour.
  - 0xbadcafebee 6mo ago
    Yes, that's why I specified "patched product ready for QA testing". It speeds up the development cycle by making a first pass and ensuring it basically works before passing it to a developer for manual review and a QA tester to ensure the fix doesn't break anything else. Both dev and QA are still in the feedback loop and can make changes until it's ready for release
- Gigachad 6mo ago
  On the other hand, automated fast rollouts leads to a crowdstrike type situation where you brick all the computers of the world immediately. Imo we are going to have to rely on more layers of security. Systems that are designed to be secure even in the presence of individual vulnerabilities. This has already been happening for a while on mobile platforms and game consoles. Even physical hardware designed to keep particular secrets /keys even from the kernel.
Amber-chen 6mo ago
[flagged]
freeqaz 6mo ago
This is exactly what happened with Log4Shell. Day -X + 1: Engineer at Alibaba finds the vuln and tells Apache. Patch is pushed to git while new release is coordinated. Day -X: A black hat sees commits fixing the bug. Attacks start happening. Day 0: Memes start circulating in Minecraft communities of people crashing servers. Some logs are shared on Twitter, especially in China, of people getting pwned. Day 0 + ~4 hours: My friend DMs me a meme on Twitter. I look up to find the CVE. Doesn't exist. My friend and I reproduce the exploit and write up a blog post about it. (We name it Log4Shell to differentiate it from a different, older log4j RCE vuln) Day ~1: Media starts picking it up. Apache is forced to release patches faster in response. CVE is actually published to properly allow security scanners to identify it. Today: AI makes this happen faster and more consistently. Patches probably should be kept private until a coordinated disclosure happens post-testing and CVE being published? Hard to say what the right move is, but this is gonna be happening a lot over the next 1-3 years. Lots of companies are going to be getting cooked until AI helps us patch faster than attackers can exploit these fresh 0-days.
- mlac 6mo ago
  I’m with you until that last sentence, which I’ve been thinking about as “… until AI code testing, vulnerability scanning, and developer support tools help to limit the number of 0-days and vulnerabilities making it into production”. So prevention will be more important than ai-assisted rapid containment or patching, though both of those capabilities will be necessary as part of defense in depth. And some sort of AI-enabled security analysis across the organization’s architecture that is done as part of testing ahead of new software entering production to ID potential vulnerabilities caused by configuration changes or upgrades that modify how systems interact with each other. I’ve been trying to guess the timeframe for seeing improved secure development, but I’m hoping it’s a bit closer to 6 months - 1 year given the speed of AI adoption and AI progression. May be closer to 3 years as you stated. In the meantime, is there more to be done than this (not in order)? - Patch COTS software - re-evaluate the scoring for previous vulnerabilities - set up up containment measures capabilities for systems that can’t be patched / high risk vendors - use frontier model vuln scanning and patching for home grown systems that may have more 0-days than COTS depending on the organization’s capability - limit the number of vendors / simplifying the tech stack. I’d be happy to hear how others are thinking about this.
129x_space 6mo ago
[flagged]
dmurray 6mo ago
Obviously the solution is for Linux to move to a closed-source development model. Security researchers should report their findings to a committee that includes some big companies (IBM and Oracle seem like trustworthy choices here, but ideally we should find a way to get Microsoft included). Those companies would apply the security patches and distribute binary builds of Linux to their customers. Users fortunate enough to have a business relationship with those companies would be protected immediately. The source would still be published after 90 days for educational purposes and for anyone who doesn't appreciate the security benefits of this approach. "But even if you could convince people to collaborate like this for the greater good, the GPL makes it legally impossible", you say. Ah, but the GPL only says you have to make the source available for a minimal monetary cost, it doesn't impose a time limit. Traditionally, responding to source code requests with a snail-mailed CD is good enough. No judge in the US is going to rule that a short administrative delay in sending out those CDs - in the name of everyone's security, after all, and 90 days is nothing to the judicial system - violates a nebulous licensing agreement from a different era.
- raincole 6mo ago
  I like how after so many years, people finally start recognizing that obscurity is a part of security. Not the whole security, obviously, but a part of it.
  - skinfaxi 6mo ago
    The comment you replied to read like satire to me.
  - scheeseman486 6mo ago
    Just like there's LLM-automated vulnerability fuzzing, there's LLM-automated decompilation. Compilation is no longer a meaningful way to obscure code.
- slim 6mo ago
  There are already closed source operating systems you can use instead of linux. No need to enshittify linux
23fedner 6mo ago
[dead]
wisty 6mo ago
A 3rd culture - the "security though obscurity" culture where some random little library might be a potential weak link, but will anyone really bother to hack it? Not as worrysome in a philosophical way (since it's not a serious culture) but it's a real issue. And just wait for a nation state to start astroturing helpful little libraries at scale ...
shouvik12 6mo ago
[flagged]
deleted 6mo ago
[deleted]
ElenaDaibunny 6mo ago
[flagged]
renzom13 6mo ago
[flagged]
pvtmert 6mo ago
solution is simple: commits get shared privately. distros can build on these private patches. after some point those can be made public (ie commited at upstream)
- randyrand 6mo ago
  Source needs to be closed too practically speaking. But I bet AI is pretty good at analyzing binary too. Fix your bugs!
noashavit 6mo ago
Perimeter defense is outdated. AI changes the attack surface from network edges to the data pipeline itself. We need to securing the prompt, the model, and the data.
amusingimpala75 6mo ago
Since the exploit can be mitigated by simply blacklisting the AF_ALG module, why didn’t they release an advisory to disable the problematic module (which AFAIU is hardly used), and then only later, say after a week, release the patch for it? At least then you would have the immediate ability for a mitigation without giving away exactly how to exploit the bug.
adamvendel 6mo ago
[dead]
RevEng 6mo ago
One issue with the author's suggestion that AI makes it faster for defenders: the issue was never time to fix, but time to distribute. My employer is working on a fairly early and small AI platform. Performance issues and other bugs are found regularly. I can usually track it down and have it fixed within an hour. But it's not so easy to distribute that fix. New releases need to be made and there are other changes going into them. The while release needs to be tested (hopefully). We have to update our internal deployments and cloud deployments, which needs careful coordination. Our customers' on-premise deployments are even further behind, often several months. It takes an hour to fix a bug but months for that fix to reach end users. AI doesn't make that faster.

430 points by speckx 6mo ago

[dead]

I'd argue it's actually breaking three vulnerability cultures. In addition to the two Jeff mentions, I think the culture of delaying upgrades and staying on stable versions for as long as possible is going to become increasingly untenable, if everything that's not latest can be trivially scanned and exploited. In the extreme I think there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. There will be much wailing and gnashing of teeth around this, because a lot of tech types really resent having to update constantly, but I don't think people will have a choice. If you have a complicated stack where major or even minor version updates are a huge hassle, I'd start working now to try and clear out the cruft and grease those wheels.

acranox 6mo ago
Debian has updated kernel packages out for the stable release. https://security-tracker.debian.org/tracker/CVE-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-43284 I kind of get your point, but they responded pretty quickly here.
- Analemma_ 6mo ago
  Oh yeah, to be clear: Debian has always been good about quickly shipping patches to kernel vulnerabilities, and they will continue to be so. I was more thinking about whether they will get overwhelmed if every bit of software they package just has a firehose of vulnerabilities on everything which isn't latest.
muvlon 6mo ago
That's not really the culture of debian to be honest. Yes they run old major and minor versions, but they do ship patch updates as fast as they can. Even on debian stable, you absolutely are supposed to update all the time. The culture of "just don't touch it" is a different one (but also exists, I've seen it).
layer8 6mo ago
> there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. Debian continuously issues security updates for stable versions, ingestable with automatic updates. “Stable” doesn’t mean that vulnerabilities aren’t getting fixed. The argument that could be made is that keeping up with getting vulnerabilities fixed might become such a high workload that fewer releases can be maintained in parallel, and therefore the lifetime and/or overlap of maintained releases would have to be reduced. But the argument for abandoning stable releases altogether doesn’t seem cogent. It goes both ways: Stable code that only receives security updates becomes less vulnerable over time, as the likelihood of new vulnerabilities being introduced is comparatively low. From that point of view, stable software actually has a leg up over continuous (“eternal beta” in the worst case) functional updates.
- ryandrake 6mo ago
  I can only dream, but this may re-popularize (among the rest of the non-Debian software industry) the general best practice of keeping a "sustaining" branch green, buildable, and with frequent releases, for security fixes. I hate software that forces you to take new features as a condition of obtaining bug and security fixes. We need to keep old "stable" builds around for longer and maintain them better. I know, I know, it is really upsetting to developers to have to backport things to old versions--they wish that all they had to work on was the current branch. But that just causes guys like me to never upgrade because the downside of upgrading (new features) is worse than the upside (security fixes).
pixl97 6mo ago
We are now paying for the sins of our fathers (well and mostly ourselves). We've just kept building more complex things with more exposure with no recognition that the day of reckoning was coming. And now we are in an untenable situation. With governments spending billions on AI with the big providers it's likely they've found many of these already.
tetha 6mo ago
> In the extreme I think there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. It may actually be the opposite. Debians steady and professional approach on shipping security patches with very little to no functional difference actually enables us to consider and work on automated, autonomous weekly or faster patches of the entire fleet. And once that's in place and trusted, emergency rollouts are very possible and easy. We have other projects that "move fast and break things" and ship whatever they want in whatever versions they want and those will require constant attention to ship any update for a security topic. These projects require constant human attention to work through their shenanigans to keep them up to date.
- calvinmorrison 6mo ago
  Not only that but debian has for example, debsecan so you can see on any system what CVEs exist and if your packages are patched. ex from my system I ran it and got > CVE-2026-32105 xrdp which i see has a fix in sid but not on bookworm
giancarlostoro 6mo ago
Arch Linux to become the only Linux OS left.
y3ahd0g 6mo ago
Yep. This is why I am using local AI to edit and build my own copies of Linux kernel, Wayland... everything a distribution would ship really. Not so daunting for me having come of age when compiling a kernel specific to a hardware platform was essential. Custom software that does not fit the usual patterns is not fool proof but it won't be obvious. Monocultures with all their eggs in one basket are even less secure than truly diverse ecosystems though.

rikafurude21 6mo ago

This feels more like an old problem getting reframed as an AI problem. people were already diffing kernel commits and figuring out which ones were security fixes long before llms. if a patch lands publicly, the race has basically already started. also not sure shorter embargoes really help. the orgs that can patch in hours are already fine. everyone else still takes days or weeks. if anything, cheaper exploit generation probably makes coordinated disclosure more important, not less.

JumpCrisscross 6mo ago
> people were already diffing kernel commits and figuring out which ones were security fixes With skill, and usually not consistently and systematically. With AI, anyone can do this to any software. > not sure shorter embargoes really help Why 90 days versus 2 years? The author is arguing the factors that set that balance have shifted, given the frequency of simultaneous discovery. The embargo window isn’t an actual window, just an illusion, if the exploit is going to be found by several people outside the embargo anyway. > cheaper exploit generation probably makes coordinated disclosure more important I agree. But it also makes it less viable. If script kiddies can find and exploit zero days, the capacity to co-ordinate breaks down. There was always a guild ethic that drove white-hate (EDIT: hat) culture. If the guild is broken, the ethic has nothing to stand on.
- gritspants 6mo ago
  I'm here for white-hate culture. You should, you should know better.
- Hizonner 6mo ago
  > With skill, and usually not consistently and systematically. How do you know? If the people who like to crow about vulnerabilities aren't doing it, it doesn't mean that the people who are actually in a position to exploit them systematically and effectively aren't doing it. Those embargoes have always been dangerous, because they create a false sense of security. But, as you point out... > With AI, anyone can do this to any software. Yep. Even if it hadn't been true before, it's clear that now you just have to assume that everybody relevant will immediately recognize the security impact of any patch that gets published. That includes both bugs fixed and bugs introduced. ... and as the AI gets better, you're going to have to assume that you don't even have to publish a patch. Or source code. Within way less time than it's going to take people to admit it and adjust, any vulnerability in any software available for inspection is going to be instant public knowledge. Or at least public among anybody who matters.

JumpCrisscross 6mo ago

> So many security fixes are coming out now that examining commits is much more attractive: the signal-to-noise ratio is higher Why? > Additionally, having AI evaluate each commit as it passes is increasingly cheap and effective This is the key. With AI, the “people won't notice, with so many changes going past” assumption fails.

xiaoyu2006 6mo ago

The quick test doesn't show a lot - by out straight asking if this is a security patch, it implies and guides AI to have output more probably to agree on this assumption. A confusion matrix is more useful. Nonetheless of course this is not a detailed ai capability testing blog.

cubefox 6mo ago
Yeah, ideally we would need the phi coefficient (aka MCC, the binary Pearson correlation), which can be calculated from a confusion matrix of yes/no LLM classifications for all kernel diffs. (Number of true positives, true negatives, false positives, false negatives.)
jefftk 6mo ago
[author] I agree it is not much additional evidence! If someone wanted to try running the same test on a series of N commits from that list including this one I'd be very curious to see the answer!
cormacrelf 6mo ago
Realistically, if you are scanning each kernel commit to check if they might be patching a security issue, you are going to be asking an LLM "is this security related, if so vaguely how" with low effort and taking "maybe" as a yes before feeding it to a more expensive model. You aren't trying to establish a probability of an ultimately unknowable fact, there is ground truth that you can find by producing an exploit, so you are just trying to pre-filter before spending the money to find it.

papichulo2023 6mo ago

Maybe it is about time for Linux to get a real CD/CI and start using AI extensively. Not just for vulnerabilities, having a nice agents|skills|etc.md definitions would encourage new devs to contribute instead of dealing with an overworked maintener repeating the same thing for n time.

j2kun 6mo ago

> Luckily AI can speed up defenders as well as attackers here, allowing embargoes that would previously have been uselessly short. This is an important facet of the problem space: security risks turning into an arms race for who wants to spend more tokens.

nicce 6mo ago
One interesting thing is that this makes closed source code even greater asset for the defenders. Attacker cannot spend tokens for it, but defenders can spend tokens for hardening based on source code, while attacker is stuck with blackbox testing.
- j2kun 6mo ago
  Decompilation is quite good these days as well
- watusername 6mo ago
  You would be surprised how adept SOTA models are at reverse engineering with IDA/Ghidra or even plain old objdump. Opus basically knows IDAPython on the back of its hand.
  - nicce 6mo ago
    They can be, but the most interesting parts (backend code, deployment confs) are not usually available. Reversing clients can help to understand a bit, but not with equal level.
    - kardos 6mo ago
      On the other hand, any source code leak could be catastrophic

miki123211 6mo ago

AI will shorten update windows dramatically. 2026 is the worst year to be thinking about dependency cooldowns, we need to think about dependency warmups instead. Soon, there will be no such thing as a safe way to disclose a vulnerability in an open source project. Centralized SaaS will have a major security advantage here.

woah 6mo ago
You could have a web of trust where Linux-using organizations each spend $x continuously scanning and patching their own dependencies with AI, and sending each other patches and scans.
- dakolli 6mo ago
  LLMs aren't capable of doing this, and never will be no matter what Anthropic tries tell you.
  - fragmede 6mo ago
    Mozilla seems to think it can. https://blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/ https://blog.mozilla.org/en/privacy-security/ai-security-zer...
    - dakolli 6mo ago
      Ahh yes, I'm sure agents did this all autonomously without any human in the loop what so ever. They are useless without experts to handle them.
      - fragmede 6mo ago
        So then have the Linux-using organizations employ experts to handle them then.
  - a_vanderbilt 6mo ago
    That's the same mindset some people had 3 years ago when they said AI wouldn't be capable of software development. Look where we are now.

FuriouslyAdrift 6mo ago

Reverse engineering vulnerabilities from patches is red team 101...

oytis 6mo ago

The old saying of Tony Hoare about no obvious bugs vs obviously no bugs holds in the age of LLMs more than ever

fragmede 6mo ago
> There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." — Tony Hoare for those (like me) who hadn't seen it before.
- randyrand 6mo ago
  That’s really clever and quite funny!

proteal 6mo ago

It sounds to me like the safe assumption with software is that no matter how solid your stack is, there are vulnerabilities, potentially catastrophic. A question to folks more experienced than me - if my business depends on software, and I know that my software is almost certainly exploitable, how do I posture my business in such a way as to minimize the impacts of exploits like these?

perlgeek 6mo ago
When Windows was the predominant desktop OS in the 90s and maybe early 00s (ok, maybe still is), it was so badly insecure that you could be pretty much sure that it would be easy to compromise. That's when firewalls were widely deployed to provide some layer of protection. So you can ask yourself, what is the (possibly metaphorical) firewall in the software you depend on? Is there any way you can decrease attack surface, separate out the most important data in extra-secure (and thus less accessible) systems?

tptacek 6mo ago

This has been a very long time coming and the crackup we're starting to see was predicted long before anyone knew what an LLM is. The catalyst is the shift towards software transparency: both the radically increased adoption of open source and source-available software, and the radically improved capabilities of reversing and decompilation tools. It has been over a decade since any ordinary off-the-shelf closed-source software was meaningfully obscured from serious adversaries. This has been playing out in slow motion ever since BinDiff: you can't patch software without disclosing vulnerabilities. We've been operating in a state of denial about this, because there was some domain expertise involved in becoming a practitioner for whom patches were transparently vulnerability disclosures. But AIs have vaporized the pretense. It is now the case that any time something gets merged into mainline Linux, several different organizations are feeding the diffs through LLM prompts aggressively evaluating whether they fix a vulnerability and generating exploit guidance. That will be the case for most major open source projects (nginx, OpenSSL, Postgres, &c) sooner rather than later. The norms of coordinated disclosure are not calibrated for this environment. They really haven't been for the last decade. I'm weirdly comfortable with this, because I think coordinated disclosure norms have always been blinkered, based on the unquestioned premise that delaying disclosure for the operational convenience of system administrators is a good thing. There are reasons to question that premise! The delay also keeps information out of the hands of system operators who have options other than applying patches.

grog454 6mo ago
> It has been over a decade since any ordinary off-the-shelf closed-source software was meaningfully obscured from serious adversaries. Probably goes without saying but the last line of defense is not deploying your software publicly and instead relying on server-client architectures to do anything. Maybe this will be more common as vulnerabilities are more easily detected and exploited. Of course its not always feasible. It has been annoying seeing my (proguard obfuscated) game client binaries decompiled and published on github many times over the last 11 years. Only the undeployed server code has remained private. Interestingly I didn't have a problem with adversaries reverse engineering my network protocols until I was updating them less frequently than weekly. LLM assisted adversaries could probably keep up with that now too.

Animats 6mo ago

We have a huge problem. The US is at war. Much of the world is at war at the cyber attack level right now. The US, the EU, most of the Middle East, Israel, Russia... Major services have been attacked and have gone down for days at a time - Ubuntu, Github, Let's Encrypt, Stryker. Entire hospital systems have had to partially shut down. Now, in the middle of this, AI has made attacks much faster to generate. Faster than the defensive side can respond. Zero-day attacks used to be rare. Now they're normal. It's going to get worse before it gets better. Maybe much worse.

pier25 6mo ago
> before it gets better How is it going to get better?
- jcgrillo 6mo ago
  By holding engineers accountable for the stability and security of their software.
- jefftk 6mo ago
  I'd speculate that at this point Linux etc are probably having vulnerabilities discovered and patched faster than created.
  - pier25 6mo ago
    It's not only Linux though and many projects don't have the funding to perpetually use something like Mythos.
- nicce 6mo ago
  Downplaying security has now real coencequences for everyone.
- Sarky 6mo ago
  Right now we are at a point in time when AI can find bugs for attackers and defenders, but defenders did not fix/find those bugs yet. In time most of the bugs AI can find will be fixed, and things will calm down. Some bugs will be left, but will be too complex to find and weaponise (or rarely). Alin short, attackers have advantage for a brief time now, but ultimately defenders will win. I guess this "fight" might be over before the end of the year.

cryo32 6mo ago

I must admit I'm rather enjoying this particular form of shit show, mostly because it was a predication I made in 2023 in the early days of LLMs. It wasn't really a problem related to LLMs but a glaring hole in the thinking of current computing which is the "frustratingly over-connected" and "over-trust" approach to everything. After reading Liu Cixin's "three body problem" and noting the Dark Forest, I applied that to risk vectors and came to the conclusion that our over-connected nature plus some form of acceleration plus some form of negative impact will fuck us big time. Turns out it did. Thus we should probably start treating our thinking model of computing as a Dark Forest, not a friendly community. That mitigates these risks to some degree.

9dev 6mo ago
If you're into gaming, Cyberpunk 2077 essentially plays in a heavily technologized world, where all compute infrastructure is infested with rogue AI that replicates itself to any technology it can physically get in touch with. The only recourse is a new web, built from first principles, protected by (probably) benevolent AI systems. Every device, every server, is partially occupied by AIs doing their thing on it, virtually networked into a digital universe. I found that a fascinating thought.
- cryo32 6mo ago
  Have played that end to end. It's a dystopian hell hole.

Havoc 6mo ago

The bugs are bugs description reads pretty insane to me personally but I know linux world has many people valueing principle of it over practical matters. 90d seems long too though. Think ultimately the big AI houses will need to help the core internet infra guys. Running latest and greatest AI over stuff like nginx and friends makes sense for us all collectively I think

Worf 6mo ago

> On the other side you have "bugs are bugs" culture. This is especially common in Linux, where the argument is that if the kernel is doing something it shouldn't then someone somewhere may be able to turn it into an attack. Just fix things as quickly as possible, without drawing attention to them. Often people won't notice, with so many changes going past, and there's still time to get machines patched. The 3rd one is what I practice when giving companies time to fix their issue. Note, I haven't reported anything to FOSS projects, but to several companies I found exploits in. I give them 5 days. If they don't respond at all in the first day, I deduct 1 day - apparently they're either incompetent or don't care. After the 5 days have passed, I make it public. So far they've all fixed the issue on the 3rd or 4th day. If I were to report something to a FOSS project, I'd give them a bit more, say 8-9 days. Enough time for everyone to wake up, review the vuln, patch it and ship it. Enough time for all the downstream projects to also ship the patch. 90 days is ridiculous, especially for companies. If I report something on Friday 23:30 and they reply Monday 15:00 - what were they doing during the weekend? Did they forget their software is used 24/7? I had one company complain quite a bit, threatening to sue. When they realized there was no one to sue (me being anonymous with my report), they fixed it in less than a day. Bottom line - if you're a company offering a product or service, you should have a security team 24/7. If you're a FOSS project - either alert your users to stop using your software or disable the service yourself, if you can. If it's an extremely important life-or-death service you can't shut off - then fix it quickly. What are you doing with life-or-death stuff when you can't react quickly enough? Fuck the 90 days standard - it's what companies want us to do because it's easier on them. If security hasn't been your top priority, you have a few days to make it your top priority. With AI, that makes even more sense now. Bugs won't be able to stay hidden for months. Especially bugs I've reported like IDORs or SQL injections - things everyone tries first. (and I love Linux, but getting an "Oh noes!" from Anubis at kernel.org because I don't have cookies enabled (I do??) really makes me not want to report anything to the Linux kernel in particular. If I ever did find something, I'd just immediately post it as a HN comment or something like that)

jefftk 6mo ago
> 90 days is ridiculous, especially for companies It depends on the kind of vulnerability, but sometimes in order to fix a problem, you need to do an enormous amount of software engineering. Which needs to be done to a very high standard, because the expectation is that people will push security patches more or less immediately to production. Of course, this only works if no one else is likely to discover the vulnerability in the meantime!

0xbadcafebee 6mo ago

We need automated patch and release cycles. So far we've relied on incredibly slow manual processes to accept reports, investigate, verify, patch, and prepare releases. Releasing a fix often takes months. This is way too slow when attackers can just churn out new exploits in hours. We need to iterate on value chain bottlenecks to lower Mean Time To Patch. We should be able to turn around a bug report to a patched product ready for QA testing in 1 hour. Standardize/open source it, have the whole software supply chain use it (ex. Linux kernel -> distros -> products that use distros -> users). With AI there's no reason we can't do this, we're just slow.

jfk13 6mo ago
Sounds like you're expecting the AI-based tools that are finding bugs to also provide fixes. I've been dealing with a bunch of AI-generated (or at least -assisted) vulnerability reports lately. In many cases the reports include proposed patches to fix the issues. It's been..... interesting. In many cases, the analysis provided in the report has been accurate and helpful. In some cases, the proposed patches have also been good, and we've accepted them with minimal or no changes. In other cases, despite finding a valid issue, and even providing a good analysis of the problem, the AI tool's suggested patch has been, quite simply, wrong. Careful review from somebody who really _understands_ the code -- and the wider context in which it is operating -- is still absolutely necessary. That's not always going to happen in an hour.
- 0xbadcafebee 6mo ago
  Yes, that's why I specified "patched product ready for QA testing". It speeds up the development cycle by making a first pass and ensuring it basically works before passing it to a developer for manual review and a QA tester to ensure the fix doesn't break anything else. Both dev and QA are still in the feedback loop and can make changes until it's ready for release
Gigachad 6mo ago
On the other hand, automated fast rollouts leads to a crowdstrike type situation where you brick all the computers of the world immediately. Imo we are going to have to rely on more layers of security. Systems that are designed to be secure even in the presence of individual vulnerabilities. This has already been happening for a while on mobile platforms and game consoles. Even physical hardware designed to keep particular secrets /keys even from the kernel.

Amber-chen 6mo ago

[flagged]

freeqaz 6mo ago

This is exactly what happened with Log4Shell. Day -X + 1: Engineer at Alibaba finds the vuln and tells Apache. Patch is pushed to git while new release is coordinated. Day -X: A black hat sees commits fixing the bug. Attacks start happening. Day 0: Memes start circulating in Minecraft communities of people crashing servers. Some logs are shared on Twitter, especially in China, of people getting pwned. Day 0 + ~4 hours: My friend DMs me a meme on Twitter. I look up to find the CVE. Doesn't exist. My friend and I reproduce the exploit and write up a blog post about it. (We name it Log4Shell to differentiate it from a different, older log4j RCE vuln) Day ~1: Media starts picking it up. Apache is forced to release patches faster in response. CVE is actually published to properly allow security scanners to identify it. Today: AI makes this happen faster and more consistently. Patches probably should be kept private until a coordinated disclosure happens post-testing and CVE being published? Hard to say what the right move is, but this is gonna be happening a lot over the next 1-3 years. Lots of companies are going to be getting cooked until AI helps us patch faster than attackers can exploit these fresh 0-days.

mlac 6mo ago
I’m with you until that last sentence, which I’ve been thinking about as “… until AI code testing, vulnerability scanning, and developer support tools help to limit the number of 0-days and vulnerabilities making it into production”. So prevention will be more important than ai-assisted rapid containment or patching, though both of those capabilities will be necessary as part of defense in depth. And some sort of AI-enabled security analysis across the organization’s architecture that is done as part of testing ahead of new software entering production to ID potential vulnerabilities caused by configuration changes or upgrades that modify how systems interact with each other. I’ve been trying to guess the timeframe for seeing improved secure development, but I’m hoping it’s a bit closer to 6 months - 1 year given the speed of AI adoption and AI progression. May be closer to 3 years as you stated. In the meantime, is there more to be done than this (not in order)? - Patch COTS software - re-evaluate the scoring for previous vulnerabilities - set up up containment measures capabilities for systems that can’t be patched / high risk vendors - use frontier model vuln scanning and patching for home grown systems that may have more 0-days than COTS depending on the organization’s capability - limit the number of vendors / simplifying the tech stack. I’d be happy to hear how others are thinking about this.

129x_space 6mo ago

[flagged]

dmurray 6mo ago

Obviously the solution is for Linux to move to a closed-source development model. Security researchers should report their findings to a committee that includes some big companies (IBM and Oracle seem like trustworthy choices here, but ideally we should find a way to get Microsoft included). Those companies would apply the security patches and distribute binary builds of Linux to their customers. Users fortunate enough to have a business relationship with those companies would be protected immediately. The source would still be published after 90 days for educational purposes and for anyone who doesn't appreciate the security benefits of this approach. "But even if you could convince people to collaborate like this for the greater good, the GPL makes it legally impossible", you say. Ah, but the GPL only says you have to make the source available for a minimal monetary cost, it doesn't impose a time limit. Traditionally, responding to source code requests with a snail-mailed CD is good enough. No judge in the US is going to rule that a short administrative delay in sending out those CDs - in the name of everyone's security, after all, and 90 days is nothing to the judicial system - violates a nebulous licensing agreement from a different era.

raincole 6mo ago
I like how after so many years, people finally start recognizing that obscurity is a part of security. Not the whole security, obviously, but a part of it.
- skinfaxi 6mo ago
  The comment you replied to read like satire to me.
- scheeseman486 6mo ago
  Just like there's LLM-automated vulnerability fuzzing, there's LLM-automated decompilation. Compilation is no longer a meaningful way to obscure code.
slim 6mo ago
There are already closed source operating systems you can use instead of linux. No need to enshittify linux

23fedner 6mo ago

[dead]

wisty 6mo ago

A 3rd culture - the "security though obscurity" culture where some random little library might be a potential weak link, but will anyone really bother to hack it? Not as worrysome in a philosophical way (since it's not a serious culture) but it's a real issue. And just wait for a nation state to start astroturing helpful little libraries at scale ...

shouvik12 6mo ago

[flagged]

deleted 6mo ago

[deleted]

ElenaDaibunny 6mo ago

[flagged]

renzom13 6mo ago

[flagged]

pvtmert 6mo ago

solution is simple: commits get shared privately. distros can build on these private patches. after some point those can be made public (ie commited at upstream)

randyrand 6mo ago
Source needs to be closed too practically speaking. But I bet AI is pretty good at analyzing binary too. Fix your bugs!

noashavit 6mo ago

Perimeter defense is outdated. AI changes the attack surface from network edges to the data pipeline itself. We need to securing the prompt, the model, and the data.

amusingimpala75 6mo ago

Since the exploit can be mitigated by simply blacklisting the AF_ALG module, why didn’t they release an advisory to disable the problematic module (which AFAIU is hardly used), and then only later, say after a week, release the patch for it? At least then you would have the immediate ability for a mitigation without giving away exactly how to exploit the bug.

adamvendel 6mo ago

[dead]

RevEng 6mo ago

One issue with the author's suggestion that AI makes it faster for defenders: the issue was never time to fix, but time to distribute. My employer is working on a fairly early and small AI platform. Performance issues and other bugs are found regularly. I can usually track it down and have it fixed within an hour. But it's not so easy to distribute that fix. New releases need to be made and there are other changes going into them. The while release needs to be tested (hopefully). We have to update our internal deployments and cloud deployments, which needs careful coordination. Our customers' on-premise deployments are even further behind, often several months. It takes an hour to fix a bug but months for that fix to reach end users. AI doesn't make that faster.