CVE-2024-31852: LLVM before 18.1.3 generates code
Source CVE Database V5
Not known to be exploited · CVSS 5.9 Medium.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.9% chance of exploitation in 30 days – higher than 62% 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:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 5 Apr 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 26 Oct 2026.
What to do
AI-suggested
To mitigate CVE-2024-31852, organizations should upgrade LLVM to version 18.1.3 or later, where the issue is resolved. Comprehensive testing and fuzzing of ARM-targeted binaries should be enhanced to detect miscompilations that could cause crashes. Incorporate static and dynamic analysis tools to identify control flow anomalies in compiled code. Avoid deploying binaries compiled with vulnerable LLVM versions in production environments, especially for critical systems. For legacy systems where recompilation is not immediately feasible, implement runtime monitoring to detect abnormal crashes and enable rapid incident response. Developers should review build pipelines to ensure no outdated LLVM versions are used inadvertently. Additionally, consider employing compiler verification tools or alternative compilers for ARM targets as a temporary measure. Maintain awareness of LLVM updates and security advisories to promptly address similar future issues.
Description
LLVM before 18.1.3 generates code in which the LR register can be overwritten without data being saved to the stack, and thus there can sometimes be an exploitable error in the flow of control. This affects the ARM backend and can be demonstrated with Clang. NOTE: the vendor perspective is "we don't have strong objections for a CVE to be created ... It does seem that the likelihood of this miscompile enabling an exploit remains very low, because the miscompile resulting in this JOP gadget is such that the function is most likely to crash on most valid inputs to the function. So, if this function is covered by any testing, the miscompile is most likely to be discovered before the binary is shipped to production."