[HN Gopher] Twenty One Zero-Days in FFmpeg
___________________________________________________________________
Twenty One Zero-Days in FFmpeg
Author : redbell
Score : 184 points
Date : 2026-06-12 22:13 UTC (9 hours ago)
HTML web link (depthfirst.com)
TEXT w3m dump (depthfirst.com)
| bethekidyouwant wrote:
| How does the browser use it ?unless they mean there's a zero day
| in libavcodec
| fpoling wrote:
| Browsers run it in a sandbox process together with allocator
| hardening. Most of the bugs then are just crashed of the
| sandbox
|
| Another option is WASM or WASM-style sandboxes if using another
| process is undesirable.
| johnnythunder wrote:
| One chained sandbox escape away from compromise.
| ttoinou wrote:
| Ahah
|
| But are the compiler+OS that runs the ffmpeg executable
| really a sandbox ?
| fpoling wrote:
| For executables on Linux there are things like bubblewrap
| or firejail. One can also use a restrictive container.
| But those are strictly weaker than browser sandboxes.
|
| The most secure way presently is to use qubes-os that
| allows to use a very hardened VM to run individual
| applications.
| loeg wrote:
| Which is of course better than zero sandbox escapes.
| nemothekid wrote:
| > _The reach of this bug is what makes it serious. Any deployment
| that points FFmpeg at an attacker-influenced RTSP URL is exposed:
| media ingest pipelines fetching user-supplied stream URLs,
| surveillance and CCTV systems pulling RTSP feeds, and transcoding
| services processing remote AV1-over-RTP sources_
|
| Wow this is actually pretty serious - I'm even surprised its
| being published. There are several services where I can imagine
| this is exploitable today.
| akerl_ wrote:
| Some people might suggest it's crucial to publish if you're
| aware of a serious vulnerability, so that people using the
| software in a vulnerable way can take steps to mitigate the
| risk.
| skupig wrote:
| You would also need some sort of ASLR leak to make this
| exploitable
| woodruffw wrote:
| Speaking from firsthand experience: codec and other media
| processing libraries are some of the easiest software to find
| address leaks in.
|
| (There are a number of reasons for this, not least being that
| C makes it very easy to ship partially initialized memory
| over the wire.)
| lostglass wrote:
| Speed and security are not good bedfellows. Combine that
| with really shitty standards and dozens of years of
| development...
|
| Oh, and licensing. Licensing is the real killer. I could
| just write my own mp3 decoder easily (the format not the
| file type) but I'm not gonna risk my company getting sued
| into the ground by doing that.
| woodruffw wrote:
| I don't think this is necessarily true! Constraints can
| be liberating: a language that allows strong encoding of
| invariants makes it easier for the language's compiler to
| optimize.
|
| I agree about long periods of development and difficult
| standards, though.
| TiredOfLife wrote:
| ffmpeg has stated many many times that they don't care about
| bug or security reports
| jacobgold wrote:
| I've been using ffmpeg for a very long time, both personally and
| for services I've built. Fabrice Bellard is a genius, and the
| developers who have taken it so far have made the world
| measurably richer.
|
| But I can't think of a program more worthy of sandboxing when run
| with untrusted input than ffmpeg. It's a huge amount of C dealing
| with the most complicated video and audio codecs, which is
| notoriously impossible to get completely right.
|
| But it's not actually that big of a problem. I run ffmpeg inside
| a VM or gVisor, and the end result is usually a video file that
| I'm perfectly willing to play in my browser, where it gets
| decoded in yet another sandbox because this shit is hard.
| Gehinnn wrote:
| What do you mean "video file that I'm perfectly willing to play
| in my browser". Isn't it safe to assume that no video file can
| escape the browser decoding sandbox?
| thaumasiotes wrote:
| > Isn't it safe to assume that no video file can escape the
| browser decoding sandbox?
|
| Why would that be safe to assume? If that were a reasonable
| assumption, you could just as well assume that it's safe to
| run ffmpeg.
| ttoinou wrote:
| The parent does argues it is safer to sandbox ffmpeg yes
| Denvercoder9 wrote:
| I'm not up-to-speed with the current state of sandboxing in
| browsers, but in principle it's (on modern operating
| systems) not especially hard for them to sandbox the
| decoding into a separate process with basically no
| privileges beyond rendering a video stream. It's a bit
| trickier if we're only considering demuxing and delegating
| decoding to the hardware, but that's a much smaller attack
| surface.
|
| A manually run ffmpeg on the command line does nothing to
| restrict its privileges, and its security model has very
| little interest in doing so, while browsers very much have.
| lostglass wrote:
| Yeah, then you need to stream content in real time
| between multiple processes. And not screw up the
| licensing.
|
| And get hardware acceleration working...
| kjs3 wrote:
| _Isn 't it safe to assume that no video file can escape the
| browser decoding sandbox?_
|
| It's 'safe to assume' it's not. It's emphatically not safe to
| assume any mitigation is perfect.
| cyberax wrote:
| But then you also often need hardware accelerators for
| encoding, so you need to use C again.
| Terr_ wrote:
| I glumly predict that copyright-holding companies wanting DRM,
| "trusted platforms", regulatory capture, etc. will drive some
| of the damage here.
|
| Secure sandboxing tends to mean opportunities to make
| unrestricted copies.
| wavemode wrote:
| > At this point the corrupted free pointer is called, and control
| of the instruction pointer is ours.
|
| Very serious, though in practice it doesn't sound like this bug
| achieves arbitrary RCE on its own (especially in the presence of
| ASLR). You would need there to be some writable and executable
| page of memory lying around.
| skupig wrote:
| The article glosses over this, but it looks like the next
| variable in the struct is conveniently the first parameter to
| the function, so you can run arbitrary code with system() or
| whatever. But, yeah, you would need some other exploit to
| defeat ASLR.
| ttoinou wrote:
| Is the future of defense-against-foreign-agents-on-my-codebase to
| subtly hide prompt injections into one's codebase that would
| defeat agents to find security bugs ?
|
| If the attackers of ffmpeg need to be using such those authors'
| services to find RCE in popular tools to attack, what the ffmpeg
| team needs to defeat attackers is to reduce efficiency of such
| tools depthfirst
| Davidzheng wrote:
| No...
| fizzynut wrote:
| I find difficult to know how serious the issue is, if it is even
| an issue.
|
| LLM constantly confidently giving me this same sounding script
| with a "the root cause" and how it "is simple" while being
| completely incorrect.
| josephg wrote:
| Its 21 issues. And they've been human validated, as far as I
| can tell.
| lostglass wrote:
| Most of them involve very weird and unlikely scenarios and bad
| security practices _or_ access to the ffmpeg binaries and being
| allowed to run arbitrary commands at an elevated permission.
|
| In and of itself there's not a massive issue from what I can
| see, they're entry vectors that can lead to worse situations.
|
| That's not to say they're not serious but if a Russian hacking
| group is using one of them it's in conjunction with other
| exploits or security flaws. Which is common in practice when it
| comes to decoding.
| zerobees wrote:
| Ffmpeg has an _exceptionally_ terrible track record when it comes
| to security. People have been throwing fuzzers at it for as long
| as I remember and coming back with a nearly inexhaustible supply
| of memory corruption bugs. Here 's an effort by one Googler a
| decade ago:
|
| https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
|
| So, while it's a demo of the capabilities of LLMs, this should
| _not_ be at all surprising. Ffmpeg is absolutely not something
| you should be running outside of a sandbox if you 're touching
| any untrusted or user-supplied content. I know that people do,
| and these people are taking unreasonable risks.
| loeg wrote:
| They're also extremely hostile to security researchers who
| report these issues.
| insanitybit wrote:
| https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw.
| ..
|
| Security is the punch line for ffmpeg.
| hootz wrote:
| Oh my god! They are so funny and memeable! _gets RCE 'd_
| grahamjperrin wrote:
| I'm glad to see their sense of humour :-)
|
| https://nitter.net/ffmpeg/status/2039115531744334180
| KPGv2 wrote:
| > Assembly is a human readable version of machine code.
| It's exactly the same.
|
| goddamn, and this is a project that prides itself on
| having had-written assembly in it
| breppp wrote:
| There's certainly assembly that maps directly to the
| machine language bytes, I assume you are talking about
| the version of assembly with the high level loop macros
| rcbdev wrote:
| In some circles, High Level Assembly (HLA) is lovingly
| called "Mainframe Assembly".
| KPGv2 wrote:
| Apr Fools Day really is the shittiest day to be online. For
| one thing, practical jokes/pranks are just gussied-up
| asshole behavior. For another thing, nerds generally SUCK
| at information-delivery pranks, which is what the Internet
| is full of on Apr 1.
| hdgvhicv wrote:
| Back in 2004 when free email services like hotmail were
| limited to 10-15mb, on April 1st the evening standard
| front page headline, which I saw in the office around
| 2pm, was something "Google lunched 1gb email"
|
| I couldn't believe they had fallen for an April fools so
| hard.
| stackghost wrote:
| In their defense, the "rewrite it in rust" crowd can be
| really grating.
| grahamjperrin wrote:
| > ... hostile to security researchers who report these
| issues.
|
| Do you have an example?
| naturalmovement wrote:
| I have numerous examples of security researchers being
| hostile and impossible to work with (but cannot share them
| unfortunately).
| lukaslalinsky wrote:
| I don't have an example, but I know the pattern. You are
| working on your software, security researcher finds a bug,
| it's in your project, for you it's just another bug, but
| for them it's a point on their CV, so they make a theater
| about it, and expect priority in dealing with it. It must
| get tiring if you get many of these.
| duped wrote:
| One dude running an X account is not indicative of a
| community to be honest.
|
| That said, that dude has a point. "Researchers" chasing clout
| with their names attached to CVEs is kind of ridiculous. Half
| these CVEs are missing bounds checks that can be fixed with a
| patch in as much effort as writing up the blog post
| announcing that there was a missing bounds check.
| boomlinde wrote:
| I guess that the perceived problem from a security
| perspective is that they're there, not that they're
| necessarily hard to fix once found.
| lkt wrote:
| The guy running the twitter account is incompetent but the
| actual devs are a lot saner I think.
|
| I agree it reflects poorly on them though
| gerdesj wrote:
| ffmpeg is also rather popular and delivers a lot of
| functionality. Its unlikely that you don't have it installed.
|
| Yes, there are security issues but quite a few are not ffmpeg
| itself related - the input is pretty shabby or at least not
| exactly easy to deal with!
|
| Obviously, they could do with some assistance and I'm sure you
| and I will both dive in with equal zeal.
| naturalmovement wrote:
| If there was a nearly inexhaustible supply of Indian security
| researchers emailing you a nearly inexhaustible supply of LLM
| slop daily, there is a point where you or I would stop caring
| too.
|
| ffmpeg is Free Software. You are also free not to use it.
|
| Oddly enough, despite all these endless grievances, no one has
| come up with a better or more capable tool, certainly not one
| that is freely available.
|
| Evidently no one cares either, because most implementations of
| ffmpeg I've seen typically run it as root "because we have to".
| _Don 't worry we use Docker bro._
| bawolff wrote:
| > nearly inexhaustible supply of LLM slop daily,
|
| Actual well written vulnerability reports are not the same as
| slop.
|
| AI slop is a real problem and annoying. Just because it
| exists does not mean every vulnerability report is AI slop.
|
| Ffmpeg devs are free not to care, but then they cant complain
| when they start to get a bad reputation.
| naturalmovement wrote:
| > AI slop is a real problem and annoying. Just because it
| exists does not mean every vulnerability report is AI slop.
|
| Ok but who is going to sift through it all to triage the
| good bits when you're working on something for free?
|
| > Ffmpeg devs are free not to care, but then they cant
| complain when they start to get a bad reputation
|
| Who gives a shit about reputation when you're the only game
| in town?
|
| There is nothing out there that even attempts to
| approximate an ffmpeg clone. They are the Swiss army knife
| of media encoding and all complainers have produced are
| plastic sporks.
| bawolff wrote:
| > Ok but who is going to sift through it all to triage
| the good bits when you're working on something for free?
|
| Its like anything else in open source. Maintainers will
| do so if they care. Maybe they decide they don't care.
| That is always their decision to make but there are
| consequences for the project. Maybe those consequences
| make sense. Being a maintainer is all about making cost-
| benefit trade offs.
|
| > Who gives a shit about reputation when you're the only
| game in town?
|
| Its up to the maintainers whether they care or not. It
| depends on what they value.
|
| Ultimately if maintainers make decisions that are at odds
| with what their userbase want, someone eventually forks
| and people vote with their feet.
| naturalmovement wrote:
| Security is a bit different.
|
| Today it's an industry driven by unscrupulous clout-
| chasers and a commitment to quantity over quality.
|
| There is a difference between going through patches and
| pull requests vs. the endless stream of LLM-assisted
| bullshit that has started cluttering security inboxes in
| the last few years.
| tptacek wrote:
| Vulnerability researchers don't create the
| vulnerabilities they report. The vulnerabilities exist
| whether or not they're reported by "clout chasers".
| eipi10_hn wrote:
| Yes, and people will sit there and sip tea while waiting
| for "someone"? For how long?
| bawolff wrote:
| > Yes, and people will sit there and sip tea while
| waiting for "someone"? For how long?
|
| Until someone cares enough to do it. This is open source
| software. When it comes to open source, the golden rule
| is you either do the things you care about yourself or
| stfu.
|
| Given the libav fork wasn't all that long ago, it can
| obviously happen to ffmpeg just as much as it can happen
| to any other project.
| nerdsniper wrote:
| Is GStreamer a more secure alternative or does it just get a
| bit less attention than ffmpeg?
| ranger_danger wrote:
| In my experience it's mainly run by very grumpy and
| opinionated Europeans who take pride in having bugs old
| enough to drink.
| WD-42 wrote:
| From what I understand gstreamer is more about building
| complex pipelines and plugins, ffmpeg is better at playing
| some obscure 20 year old video format extremely efficiently
| so you can watch it compiled for a potato.
|
| Different cases really I think both are good.
| hackernudes wrote:
| That's not really true. Ffmpeg is a Swiss army knife for
| anything related to digital multimedia (old and new). It is
| broken into a few libraries but doesn't really have
| plugins.
|
| Gstreamer has a different model, chaining together plugins.
| Lots of overlap, but I think Gstreamer only has real
| traction because some silicon vendors use it.
| wmf wrote:
| Doesn't GStreamer mostly use ffmpeg plugins?
| hugmynutus wrote:
| GStreamer is just a different front end to ffmpeg.
|
| ffmpeg's core functionality (encode, decode, streams, pipes,
| channels) are all implemented in `libav` which gstreamer
| links against.
| harrall wrote:
| GStreamer doesn't use ffmpeg's pipeline at all. It
| implements a much more advanced directed graph with
| disconnect, connection and pad negotiation. You can
| dynamically swap out the entire filter graph during live
| playback with zero disruption. Swap feeds, outputs,
| effects... all at runtime.
|
| ffmpeg and other media frameworks (Windows Media
| Foundation, Apple's AVFramwork) only support static
| pipelines. You can use "switcher" components but the inputs
| are still static.
|
| GStreamer is extremely special. The only thing that comes
| close was Microsoft's DirectShow, which has since been
| replaced with Media Foundation which can't do it. And while
| DirectShow did support it, it was fragile because many 3rd
| party filters did not support dynamic configuration.
|
| GStreamer does use ffmpeg, but it just wraps the core
| encoder/decoder/filter code and discards the
| streams/graph/pipe part of ffmpeg.
| Sesse__ wrote:
| > ffmpeg and other media frameworks (Windows Media
| Foundation, Apple's AVFramwork) only support static
| pipelines.
|
| FFmpeg doesn't do "pipelines". It's a library, not a
| framework.
| derf_ wrote:
| Any multimedia project trying to support a large number of
| formats, whose usage in the wild differs by orders of
| magnitude, is going to have code of varying quality (although
| quality is _not_ strictly correlated with usage: age and
| complexity are also big factors, among others). GStreamer
| puts plugins into different categories (-good, -bad, etc.)
| based on things like the maturity of the code, which helps
| you judge what risks you are taking. With FFmpeg it is harder
| to know which formats are more likely to have issues. Of
| course GStreamer can use FFmpeg, in which case you will also
| have all of FFmpeg 's problems.
|
| In both cases you are best off restricting things to what you
| actually use.
| samiv wrote:
| Gstreamer is a multimedia framework where the user creates
| media DAGs by placing video/audio/multimedia elements such as
| demuxers, decoders etc in a pipeline. The framework then
| takes care of running the media pipeline and handles the data
| buffering etc.
|
| Within the framework there are multitudes of plugin packages
| that contain said elements and many of them are built on top
| of ffmpeg.
| oinoom wrote:
| Funny, John Carmack was just admiring the creator of ffmpeg the
| other day for being a better programmer.
| https://x.com/id_aa_carmack/status/2064095424420487226?s=46
| tptacek wrote:
| One thing has nothing to do with the other.
| wavemode wrote:
| Security vulnerabilities are less about programming ability
| and more about rigor.
| pibaker wrote:
| Famous man whose last impactful work was decades ago and
| spent years on meta's sinking metaverse boat said so, so it
| must be true.
| endofreach wrote:
| So who is someone who's opinion is worth anything to you?
|
| Except yourself, presumably, to me it almost seems nobody
| is perfect.
| pibaker wrote:
| On this subject I'd at minimum expect someone with
| experience in security. Not someone most famously known
| for making toys that run on computers.
| bravoetch wrote:
| I've seen a lot of things written about Carmack over the
| last 30+ years, not one comment this casually dismissive
| until today.
| zerobees wrote:
| I don't think that's fair. There's a lot of talent and grit
| behind ffmpeg. But for better or worse, getting the code to
| do what it's supposed to do requires a different mindset
| than getting it to _not do anything else_ (i.e., to handle
| malicious inputs correctly).
|
| The developers of ffmpeg are very good at the first thing
| and not very good at the second. But few people on this
| planet, if instructed to write a complex video format
| parser in C or assembly, can produce something that's
| secure on the first try. The main failing of the ffmpeg
| team is that they should have spent more time on
| architectural hardening and mitigations. Most other large
| projects of this type do.
| HappMacDonald wrote:
| So all I am hearing is.. Rust
| plaguuuuuu wrote:
| Can't help laughing at a random ad hominem against John
| Carmack of all people, and about his opinion on a guy who
| is already widely regarded as an especially talented
| programmer.
| mjg59 wrote:
| The majority of code in ffmpeg today isn't written by
| Fabrice, but also there's multiple axes that people view
| programming ability on. Some people can write software that
| will do things you couldn't imagine given the constraints.
| Some people can write software that is resilient against all
| malformed input. Sometimes these people are the same people,
| but frequently they're not.
| anon-3988 wrote:
| Doesn't this negate all the amazing muh assembly hacking that
| they do lol
| cubefox wrote:
| > Ffmpeg is absolutely not something you should be running
| outside of a sandbox if you're touching any untrusted or user-
| supplied content.
|
| You would change your opinion quickly if your browser, apps and
| TV suddenly stopped supporting videos due to relying on FFmpeg.
| defrost wrote:
| What prevents running a data stream in, transcoded data out
| sandbox with no access to unlimited resources, system files,
| system stacks, etc.
|
| It's okay for a sandbox to fall over due to bad inputs and
| poor memory security if it can just be restarted and move
| onto other streams.
| ReactiveJelly wrote:
| I think Chromium already does sandbox ffmpeg in the
| renderer process because of their "Rule of Two": https://ch
| romium.googlesource.com/chromium/src/+/HEAD/docs/s...
|
| Thus:
|
| 1. Code which processes untrusted input
|
| 2. Code written in unsafe languages like C or C++
|
| 3. Code that runs without a sandbox
|
| So ffmpeg should be sandboxed, same as the network code and
| GPU process are sandboxed.
| defrost wrote:
| I completely agree, with regard for the GP's point about
| Android TV's with onboard ffmpeg libraries and Addon Apps
| that call on said libraries (or pull in their own) ..
|
| Cheap arse low resource TVs _should_ either include some
| form of sandboxing OR the entire device should be treated
| as a "can fall over" sandbox .. well isolated from any
| household LAN of consequence, etc.
|
| It seems unlikely that BoxStore Brand Android TVs will be
| well designed with an eye to security so <shrug> they're
| an exercise for home net admin masochists and/or an
| opportunity to market sensible easy to use IoT age
| routers that come preconfigured to handle bad-device(s).
| cubefox wrote:
| Am I getting this right, you expect TVs which are running
| Google TV (Android TV is the old name) to be less secure
| than TVs which are running a different operating system?
| I think the opposite is the case, because Google TV is
| developed by Google, which has a lot of experience with
| software security, while other TV operating systems are
| developed by companies which clearly don't have that
| experience.
| defrost wrote:
| There are a _lot_ of "Android like" TVs out there.
| bitwize wrote:
| Time to RIIR, then?
| anonymousiam wrote:
| I haven't seen that acronym before, but my guess is that it's
| "Re-Implement In Rust", right?
| erk__ wrote:
| Usually it's Rewrite it in Rust, but both work I guess
| endofreach wrote:
| Of course. Everybody knows to rather use the obvious
| alternative to ffmpeg!
| teravor wrote:
| while sandboxing ffmpeg directly isn't difficult, unfortunately
| with something like MPV/VLC that uses ffmpeg it's more
| challenging. until recently (virtio gpu native context) it
| wasn't even possible to sandbox a video player without losing
| all hardware acceleration. at least not from the outside, they
| could always try to sequester ffmpeg and seccomp it to hell
| like chromium.
| bayouborne wrote:
| What about VLC's own built-in versions of decoding libraries (I
| think, from the FFmpeg project)? Is there a scenario here where
| we may have to deal with malicious MP4 files?
| jeffbee wrote:
| All media containers are potentially hostile. Any offset,
| extent, or reference has to be considered hostile user-provided
| input.
| omoikane wrote:
| Is there a timeline for each of these bugs? I wonder if these
| bugs had been reported to ffmpeg yet.
| Philpax wrote:
| "No way to prevent this" say users of only language where this
| regularly happens, etc, etc. Several of these bugs do not appear
| to be in hot code and would have been detected by a language with
| saner behaviour.
| izacus wrote:
| Well, get to work then and rewrite, should be quick. Chop-chop!
| da_chicken wrote:
| That's not what "zero-day" means.
| nerdsniper wrote:
| It seems to have lost its meaning after getting popularized
| following Stuxnet coverage.
| da_chicken wrote:
| No, I think it was since Code Red.
|
| I understand why it's poorly understood. It's a snappy term,
| and people assume it means "bad" and nothing else because
| that's all you can get from the context. However, since most
| people also don't know the difference between a vulnerability
| and an exploit, they won't understand the definition of a
| zero-day when they read it.
|
| But I'm still going to complain if a _security vulnerability
| research company_ is using the term incorrectly in their own
| press copy. It makes them look amateurish.
| NooneAtAll3 wrote:
| > the difference between a vulnerability and an exploit
|
| is it the difference between a knife and a stab wound?
| da_chicken wrote:
| No, that's the difference between exploit (knife) and
| either the incident or impact (wound). The vulnerability
| would be a gap in armor.
|
| The vulnerability is _the exposed weakness_.
| Vulnerabilities get fixes, and they exist without anybody
| knowing about them. Vulnerabilities get CVEs assigned to
| them.
|
| The exploit is _the means of attack_. It 's the specific
| actions or calls that let you take advantage of a
| vulnerability. It could be a worm, or botnet scripts, or
| specifically crafted data[0]. A proof of concept is _not_
| an exploit itself, but it demonstrates that the
| vulnerability can be exploited.
|
| An example of a vulnerability might be a gate where the
| gap between the door and the jam are too wide. The
| exploit is a coat hanger used to lift the inside latch
| from outside the gate. That results in unprivileged
| access.
|
| And zero-day specifically compares when the white hats
| (vendors, system owners) and the black hats learn about
| the existence of a vulnerability. If white hats learn
| that a vulnerability exists by being subject to an _in-
| the-wild black hat exploit_ of it, then it 's a true
| zero-day.
|
| [0]: https://xkcd.com/327/
| journal wrote:
| Explain what it means along with your statement. Maybe I have
| the wrong definition too.
| perlgeek wrote:
| (not op)
|
| If a security bug is exploited in the wild, it's an n-day if
| it's been first exploited n days after the publication of the
| bug, and a zero-day if it's been exploited before or on the
| day of the publication.
|
| When a bug is not yet exploited in the wild, it's just a
| discovery of a bug, not a zero-day.
| lschueller wrote:
| Inflated use of the term zero-day, while none of the described
| vulnerabilities is actually a zero-day. But it sounds and clicks
| good.. thank you for the PoC.
| tom_ wrote:
| > A victim only has to run ffmpeg -i rtsp://attacker/stream, the
| most ordinary command imaginable
|
| What about "ls"?
| kodt wrote:
| Infinity - 21 is still infinity
| 0xbadcafebee wrote:
| Even if this isn't as big a deal as this [advertisement for a
| security company] seems, it is a reminder that every application
| you release does have a security hole somewhere, and a script
| kiddie can now find it 5 minutes after release for $2 in credit.
| If you're not red-teaming your code before release, hackers are
| doing it after.
| appleappleapple wrote:
| Help me understand: depthfirst seems to be bigging up their
| "security agent" here, but is it not just prompt engineering +
| writing skill files? What goes into producing a "security agent"
| beyond this? Feels like they're really gussying up a process that
| is ultimately just LLM usage
| guessmyname wrote:
| I think the industry is optimizing for the wrong thing.
| Generating thousands of AI-written bug reports is easy, at least
| with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the
| hard part.
|
| A few months ago I started working on a system that finds
| critical security issues and opens PRs instead of just filing
| reports. The acceptance rate is sitting at roughly 94% so far.
| Most of the failures were due to project-specific kill switches
| or other internal mechanisms that weren't documented, not because
| the vulnerability itself was misidentified.
|
| Developers generally seem to prefer this approach. A bug report
| creates work. A good PR removes work. That sounds obvious, but a
| lot of security products still stop at the report and call it a
| day.
| rcbdev wrote:
| I think I'm missing something here. Apple software has no open
| source code, how are you suggesting fixes?
| tkocmathla wrote:
| What?
|
| https://github.com/apple
| rcbdev wrote:
| I genuinely didn't know about their OSS efforts, thanks!
| Thev00d00 wrote:
| I wouldn't go so far as efforts, so much as legally
| required publication of 3rd party code they use, or open
| wrappers to their proprietary libraries
| Rygian wrote:
| > I think the industry is optimizing for the wrong thing.
|
| Indeed: The industry optimizes for speed, time to market, and
| features, and applies the ostrich model to everything that
| doesn't bring short-time revenue (security considerations,
| accessibility, vendor lock-in, interoperability, ...)
|
| This has been going on for as long as the industry exists, and
| now we start to have the proper tools to assess the damage and
| understand the brittleness of it all.
___________________________________________________________________
(page generated 2026-06-13 08:00 UTC)