[HN Gopher] Heap Overflow in FFmpeg EXIF
___________________________________________________________________
Heap Overflow in FFmpeg EXIF
Author : retr0reg
Score : 71 points
Date : 2026-01-01 15:31 UTC (7 hours ago)
(HTM) web link (bugs.pwno.io)
(TXT) w3m dump (bugs.pwno.io)
| ComputerGuru wrote:
| Nice find.
|
| (I don't see what this being reported during the Christmas
| holidays has to do with not revealing the disclosure and patch
| timeline, a "note that delays should be attributed to Christmas"
| would have sufficed.)
| rvz wrote:
| > Pwno is a AI cybersecurity startup...
|
| We all know that LLMs were used to find these vulnerabilities,
| specifically on high impact projects. That's fine.
|
| However, my only question is who actually provided the patch: The
| maintainers of FFmpeg? The LLM that is being used? Or the
| security researchers themselves after finding the issue?
|
| It seems that these two statements about the issue are in
| conflict:
|
| > We found _and patched 6 memory vulnerabilities_ in FFmpeg in
| two days.
|
| > Dec, 2025: _avcodec /exif maintainer provided patch._
| 9cb14c1ec0 wrote:
| > We all know that LLMs were used to find these vulnerabilities
|
| How do we know that? You seem quite certain.
| hedgehog wrote:
| They pitch their company as finding bugs "with AI". It's not
| hard to point one of the coding agents at a repo URL and have
| it find bugs even in code that's been in the wild for a long
| time, looking at their list that looks likely to be what
| they're doing.
| bgwalter wrote:
| The list is pretty short though for 8 months. ossfuzz has
| found a lot more even with the fuzzers often not covering a
| lot of the code base.
|
| Manually paying _people_ to write fuzzers by hand would
| yield a lot more and be less expensive than data centers
| and burning money, but who wants to pay _people_ in 2026?
| hedgehog wrote:
| I can't speak to what exactly this team is doing but I
| haven't seen any evidence that with-robot finds less bugs
| than without-robot. I do have some experience in this
| area.
| tptacek wrote:
| Bugs are not equivalently findable and different
| techniques surface different bugs. The direct comparison
| you're trying to draw here doesn't hold.
| bgwalter wrote:
| It does not matter what purported categories buffer
| overflows are in when manual fuzzing finds 100 and "AI"
| finds 5.
|
| If Google gave open source projects $100,000 per year for
| a competent QA person, it would cost less than this "AI"
| money straw fire and produce better results. Maybe the QA
| person would also find the 5 "AI" detected bugs.
| tptacek wrote:
| This would make sense if every memory corruption
| vulnerability was equivalently exploitable, which is of
| course not true. I think you'll find Google does in fact
| fuzz ffmpeg, though.
| bgwalter wrote:
| Google gives a pittance even for full ossfuzz
| integration. Which is why many projects just have the
| bare minimum fuzz tests. My original point was that even
| with these bare minimum tests ossfuzz has found way more
| than "AI" has.
| tptacek wrote:
| Another weird assumption you've got here is that fuzzing
| outcomes scale linearly with funding, which, no. Further,
| the field of factory-scale fuzzing and triage is one
| Google security engineers basically invented, so it's
| especially odd to hold Google out as a bad actor here.
|
| At any rate, Google didn't employ "AI" to find this
| vulnerability, and Google fuzzing probably wouldn't have
| outcompeted these researchers for this particular bug
| (totally different methods of bugfinding), so it's really
| hard to find a coherent point you'd be making about
| "fuzzers", "AI", and "Google" here.
| hedgehog wrote:
| My guess is the main "AI" contribution here is to
| automate some of the work around the actual fuzzing.
| Setting up the test environment and harness, reading the
| code + commit history + published vulns for similar
| projects, identifying likely trouble spots, gathering
| seed data, writing scripts to generate more seed data
| reaching the identified trouble spots, adding
| instrumentation to the target to detect conditions ASan
| etc don't, writing PoC code, writing draft patches...
| That's a lot of labor and the coding agents can do a
| mediocre job of all of it for the cost of compute.
| tptacek wrote:
| If it's finding exploitable bugs prior factory-scale
| fuzzing of ffmpeg hasn't, seems like a pretty big win to
| me.
| bgwalter wrote:
| Try writing some software yourself and you'll understand.
| But security "researchers" don't do that of course.
| tptacek wrote:
| I am a professional software developer and have been
| since the 1990s.
| tredre3 wrote:
| PWNO provided a patch but it was rejected for being too
| large[1]. A maintainer fixed it himself[2]. I don't know if
| PWNO used a LLM but it seems clear that the maintainer had a
| preferred specific style in mind so it was likely hand written
| (albeit inspired by the initial patch).
|
| 1. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21258
|
| 2.
| https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/4bfac71ecd96488...
| j1elo wrote:
| I just need to say that "commits" has been translated to
| Spanish as "confirmations" in that website, and it made me
| chuckle.
|
| Is Forgejo using LLM-assisted translations? Or simply somepne
| without any context whatsoever in order to understand the
| word's meaning?
|
| ---- EDIT:
|
| I went on a fun detour to inform myself better, and ended up
| finding [1] where Gitlab had the same discussion. Seems some
| translations have tried to use "confirmation" as translation
| for a git commit.
|
| But really, this is one of those cases where no local word is
| able to appropriately describe such an unique concept oridea.
| I'd love to retroactively chime in and _confirm_ (hah) that
| the english word "Commit" has trascended any translation
| attempts, and absolutely nobody would know what you're
| talking about if you say "confirmation" in an attempt to use
| a spanish term.
|
| So Forgejo authors if you read this: it'd better to do as
| Gitlab did.
|
| [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/215956
| renewiltord wrote:
| Hmm interesting. You can see recent edits to the file here
| https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/e...
|
| This specific issue is fixed here
| https://github.com/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dc...
| jeffbee wrote:
| Well, maybe it does and maybe it doesn't. Since this commit
| neither adds nor fixes any tests, we'll never know.
| helge9210 wrote:
| https://x.com/FFmpeg/status/2006773495066464580
|
| > Seeing as this has made the orange site, let it be known this
| person is a model security researcher.
|
| > The issue was not in any FFmpeg release, and a report was sent
| three days after a new code was added to FFmpeg Git.
|
| > There was no big CVE ADVISORY "MUH SECURITEH" "you need to fix
| this now or you will be hacked and the world will end" associated
| with the report.
| bgwalter wrote:
| This is another drawback of security research, but one that had
| already existed before "AI" with ossfuzz.
|
| You basically cannot commit in public to the main branch and
| audit and test everything 3 months before a release, because
| any error can be picked up, will be publicized and go into the
| official statistics.
| nospice wrote:
| > ... go into the official statistics.
|
| There are no "official" statistics. None of this matters. If
| we judged projects by the number of security holes they had,
| then no one would be using ffmpeg, which had hundreds of
| serious vulns.
|
| Vulnerability research is useful insofar that the bad guys
| are using the same techniques (e.g., the same fuzzing tools),
| so any bugs you squash make it harder for others to attack
| you. If your enemy is a nation state, they might still pack
| your laptop / phone / pager with explosives, but the bar for
| that is higher than popping your phone with a 0-day.
|
| Vulnerability research is demonstrably _not_ useful for
| improving the security of the ecosystem in the long haul.
| That 's where sandboxing, hardening, and good engineering
| hygiene come into play. If you're writing a browser or a
| video decoder in C/C++, you're going to have exploitable
| bugs.
| toast0 wrote:
| > Vulnerability research is demonstrably not useful for
| improving the security of the ecosystem in the long haul.
| That's where sandboxing, hardening, and good engineering
| hygiene come into play. If you're writing a browser or a
| video decoder in C/C++, you're going to have exploitable
| bugs.
|
| IMHO, vulnerability research is the stick that drives the
| ecosystem towards all those things. Reports of
| vulnerabilities in the codec for Rebel Assult videos (or
| whatever) leads one to disable codecs other than those they
| need. Reports of vulnerabilities in playlist support leads
| one to disable playlist support where it's unnecessary and
| run transcodes in a chroot sandbox with no network access.
| Reports of buffer oveflows leads one to prefer
| implementation in memory safe languages where available
| with sufficient performance and also to sandbox when
| possible.
| tptacek wrote:
| I mostly agree, and further would say that this doesn't
| really conflict with the preceding comment.
| GaryBluto wrote:
| Is the FFmpeg Twitter account managed by a developer's teenage
| son? No matter what point that they try convey, it's always
| stated in an obnoxious manner.
| bgwalter wrote:
| Maybe they should hire Mario Nawfal for their announcements:
|
| """ BREAKING: AI FOUND VULNERABILITY IN FFMPEG!
|
| After decades of human struggle, humans no longer call the
| shots.
|
| Pwno decided to take the leap. They did not just find a
| vulnerability---they found a BOMBSHELL! What took developers
| weeks to write, AI analyzed in SECONDS! """
| throawayonthe wrote:
| it's kinda charming
___________________________________________________________________
(page generated 2026-01-01 23:01 UTC)