> ## Content Index > Fetch the complete content index at: https://amrayoub.dev/llms.txt > Use this file to discover other available public pages before exploring further. # The $100K Vulnerability With No CVE - URL: https://amrayoub.dev/the-100k-vulnerability-with-no-cve/ - Published: 2026-09-28T15:51:14.000Z - Updated: 2026-09-28T15:51:14.000Z - Author: Amr Ayoub **Meta paid a single researcher more than $100,000\. OpenAI paid $6,500 for the same type of bug. Neither had a CVE when it actually mattered.** The numbers are what caught my attention first. Meta awarded Hacktron researcher Harsh Jaiswal a six figure bounty, while the same team used a similar image vulnerability against OpenAI and received $6,500\. In less than 72 hours, they managed to go from uploading an image to opening a pull request inside the `openai/openai` internal monorepo. ([Hacktron's writeup](https://www.hacktron.ai/blog/hacking-openai?ref=amrayoub.dev), [CyberScoop](https://cyberscoop.com/hacktron-ai-heif-heist-vulnerability/?ref=amrayoub.dev), [VentureBeat](https://venturebeat.com/security/openai-hacked-by-small-team-of-white-hat-security-researchers-using-anthropics-claude-opus-5?ref=amrayoub.dev).) But the bounty itself is not really the interesting part. The vulnerability had already been fixed upstream around a year earlier. It just wasn't marked as a security issue and didn't have a CVE, which meant most vulnerability scanners had nothing to report. That is what makes this case interesting from an AppSec and vulnerability management perspective. ## The vulnerable library was not even something OpenAI directly chose OpenAI's community forum runs Discourse. Discourse has a fast image processing path, but it doesn't handle HEIC directly. When it receives a HEIC image, it passes it to ImageMagick, which then uses libheif to decode it. So the attack path looked roughly like this: `User upload → Discourse → ImageMagick → libheif → memory corruption` The vulnerable component was several dependencies away from the application itself. Nobody building the forum probably sat down and decided to use libheif. It simply arrived through the dependency chain. This is something I think we still underestimate in threat modelling. We usually look at the framework, application libraries and maybe direct dependencies, while the component actually parsing attacker controlled data can be buried much deeper. If your application accepts images, PDFs, archives, videos or other complex files, it is worth tracing what actually processes that data, not only what your application directly imports. ## Patched upstream does not mean your scanner knows about it This is probably the most interesting part for me. The libheif heap overflow had already been fixed upstream roughly a year before the research happened, but the fix was not labelled as a security issue and there was no CVE at the time. It was later tracked as CVE 2026 32882. Without a CVE, Debian did not have a security advisory to backport the fix against. The Docker base image therefore continued shipping the vulnerable libheif version, 1.19.7 on Debian 12. From the point of view of a normal CVE based vulnerability scanner, everything looked fine. No CVE, no match, no alert, pipeline stays green. That is a pretty big limitation considering how much vulnerability management depends on CVE feeds. SCA tools and container scanners are very good at telling you whether a component matches a known vulnerability, but they cannot tell you about a security fix that nobody classified as a vulnerability in the first place. So "no CVE found" and "not vulnerable" are two completely different things. There is no simple solution to this either. You still need SCA and container scanning, obviously, but for libraries that process untrusted input, especially image parsers, document parsers, compression libraries and media codecs, it also makes sense to follow upstream changes and understand what is actually sitting inside your container. The scanner is one signal. It should not be the only one. ## The crashes were already telling you something Another part I found interesting was what happened before exploitation. When someone is developing a memory corruption exploit, especially while dealing with ASLR and different memory layouts, the target is going to crash, probably many times. I got a close look at exactly that phase recently, pointing an AI agent at a real memory corruption CVE on ExploitGym. Under the hardened profile, ASLR on, strict defenses, The agent burned its entire time budget wrangling heap layout and allocator metadata, run after run, and never landed a flag. An earlier model could only make progress with ASLR disabled. That turn against a live target instead of a benchmark, is crashes. A lot of them. According to the researchers, malformed images were tested against image pipelines across multiple companies and caused thousands of crashes. Shopify was apparently one of the few companies that noticed. This is where security monitoring and reliability monitoring start overlapping. If an image processing worker suddenly starts crashing repeatedly because of malformed uploads, that should not automatically be treated as just another application stability issue. Someone might be fuzzing the parser, trying to understand the memory layout or developing an exploit. If the worker crashes, Kubernetes restarts it and nobody looks at the pattern, you might be hiding one of the clearest signals you have. Repeated decoder crashes should be visible to the security team, not only to SRE. ## RCE on a community forum should not lead to source code access The original vulnerability gave code execution on a community forum. That is already serious, but ideally it should stay contained. The bigger problem was what happened afterwards. OpenAI's SSO allowed the forum, ChatGPT and Codex to trust the same session. Once the researchers compromised the forum environment, they were able to move into employee Codex accounts. Codex was connected to GitHub, which is how an image uploaded to a community forum eventually resulted in a pull request inside an internal source repository. The image vulnerability got them inside. Identity and trust relationships gave them the blast radius. For me, this is probably the bigger lesson than the actual RCE. We are connecting AI agents to GitHub, Slack, email, cloud environments, ticketing systems and internal APIs. Those agent accounts slowly become extremely powerful identities because they inherit access to everything around them. A compromised AI agent does not necessarily need administrator privileges. It just needs enough connections. That makes agent permissions, OAuth scopes, MCP permissions and SSO trust boundaries something that needs proper security review. I would treat an AI agent identity the same way I would treat any other highly privileged service account, possibly even more carefully because of how many systems it can interact with. ## So what is actually different now? The vulnerability itself is not special. Memory corruption bugs in image libraries have existed forever, and the attack chain is not completely new either. Compromise a low value service, steal an identity and pivot into something more sensitive. The part that changed is the amount of effort needed to weaponize the vulnerability. Building a reliable memory corruption exploit used to require a very specialised skill set and often a lot of time. In this case, one model generation failed to build a working exploit with ASLR enabled. The next one managed to produce one within hours. The entire campaign across multiple targets reportedly cost less than $3,000 in model usage. That changes the economics. The $100K Meta bounty and the $6,500 OpenAI bounty show how much these vulnerabilities are worth to companies when researchers report them responsibly. But the same capability is becoming much cheaper for attackers. A vulnerability that previously required a skilled exploit developer and several days or weeks of work can now potentially be explored much faster with AI helping with debugging, memory analysis and exploit development. That means old vulnerabilities, obscure parser bugs and bugs without CVEs become more interesting targets. Not because the bugs suddenly became worse, but because exploiting them became cheaper. ## What I would check after reading this If you run anything that accepts user controlled images, I would start by checking the actual container image and not only your application dependencies. Make sure libheif is updated and rebuild the image if necessary. If you do not need HEIF or AVIF support, disable it completely. Every parser you remove is attack surface you no longer need to defend. I would also isolate image processing into a low privilege worker and monitor repeated decoder crashes properly. If malformed files suddenly start causing segmentation faults or restart loops, that should create a security signal, not disappear inside an automatic restart policy. The other thing I would review is identity. Look at SSO relationships, OAuth scopes, MCP integrations and AI agent permissions. A community forum should not provide an easy trust path into source code repositories, and an AI agent should not automatically inherit access to everything a user can reach. Finally, look beyond direct dependencies. The vulnerable parser might be three or four layers below the software you knowingly installed. The libheif bug itself was old. What changed is how easy it is becoming to turn bugs like this into working exploits. And I think this case exposes another problem too. A lot of our security tooling still assumes that if something serious is known, somebody will assign it a CVE, package maintainers will pick it up, scanners will detect it and the pipeline will tell us what to do. Sometimes none of that happens. And your scanner still shows green.