CVE-2024-36615: n/a
Source CVE Database V5
Not known to be exploited · CVSS 5.9 Medium.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NExploitation evidence
Disclosed: evidence found.
CVE published 29 Nov 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
AI-suggested
To mitigate CVE-2024-36615, organizations should monitor FFmpeg project updates closely and apply patches promptly once released. Until patches are available, consider the following measures: 1) Restrict processing of untrusted VP9 video streams or implement input validation to reduce exposure. 2) Employ runtime thread sanitizers or static analysis tools to detect and fix data races in custom FFmpeg builds. 3) Use containerization or sandboxing to isolate video processing components and limit potential data leakage. 4) Review and enhance synchronization mechanisms in the VP9 decoder code if maintaining custom FFmpeg forks. 5) Maintain strict network controls to limit access to video processing services. 6) Educate developers and security teams about race condition risks and secure multithreading practices. These targeted steps go beyond generic advice by focusing on the specific concurrency issue and operational context of FFmpeg deployments.
Description
FFmpeg n7.0 has a race condition vulnerability in the VP9 decoder. This could lead to a data race if video encoding parameters were being exported, as the side data would be attached in the decoder thread while being read in the output thread.