CVE-2023-46049: LLVM · NULL Pointer Dereference
Source CVE Database V5
Not known to be exploited · CVSS 5.3 Medium.
Data as of 26 Oct 2026, 12:54 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 52% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NExploitation evidence
Disclosed: evidence found.
CVE published 27 Mar 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
- Avoid processing untrusted or unauthenticated pdflatex.fmt or .o files with llvm-lto until a patch is released.
- Implement input validation and sanitization in build pipelines to detect and reject malformed or suspicious files before they reach llvm-lto.
- Monitor LLVM project communications and security advisories closely for any forthcoming patches or updates addressing this vulnerability.
- Use containerization or sandboxing techniques to isolate build environments, limiting the impact of potential crashes on broader systems.
- Incorporate robust error handling and automated recovery mechanisms in continuous integration workflows to minimize disruption from llvm-lto crashes.
- Consider temporarily downgrading to a prior LLVM version if feasible and if it does not contain this vulnerability.
- Educate development teams about the vulnerability and encourage cautious handling of input files related to llvm-lto processes.
Description
LLVM 15.0.0 has a NULL pointer dereference in the parseOneMetadata() function via a crafted pdflatex.fmt file (or perhaps a crafted .o file) to llvm-lto. NOTE: this is disputed because the relationship between pdflatex.fmt and any LLVM language front end is not explained, and because a crash of the llvm-lto application should be categorized as a usability problem.