Heap Overflow in FFmpeg EXIF
bugs.pwno.io
Heap Overflow in FFmpeg EXIF
1–10 of 36 posts
Re: Heap Overflow in FFmpeg EXIF
#2Nice 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.)
Re: Heap Overflow in FFmpeg EXIF
#3> 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.
Re: Heap Overflow in FFmpeg EXIF
#4Hmm 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...
Re: Heap Overflow in FFmpeg EXIF
#5> 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 pa…
> We all know that LLMs were used to find these vulnerabilities
How do we know that? You seem quite certain.
Re: Heap Overflow in FFmpeg EXIF
#6> 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 pa…
> We all know that LLMs were used to find these vulnerabilities How do we know that? You seem quite certain.
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.
Re: Heap Overflow in FFmpeg EXIF
#7> 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 pa…
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...
Re: Heap Overflow in FFmpeg EXIF
#8Earlier quoted context omitted.
> We all know that LLMs were used to find these vulnerabilities How do we know that? You seem quite certain.
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.
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?
Re: Heap Overflow in FFmpeg EXIF
#9https://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.
Re: Heap Overflow in FFmpeg EXIF
#10https://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.
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.