Skip to main content
VulnerabilityPublished Updated

CVE-2023-46049: NULL Pointer Dereference

Source CVE Database V5

0

Not known to be exploited · CVSS 5.3 Medium.

Data as of 26 Oct 2026, 09:15 UTC

CVSS 3.1 base score
5.3Medium
How severe the flaw is on the 0–10 CVSS scale.
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:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 Mar 2024

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

1. Avoid processing untrusted or unauthenticated pdflatex.fmt or .o files with llvm-lto until a patch is released. 2. Implement input validation and sanitization in build pipelines to detect and reject malformed or suspicious files before they reach llvm-lto. 3. Monitor LLVM project communications and security advisories closely for any forthcoming patches or updates addressing this vulnerability. 4. Use containerization or sandboxing techniques to isolate build environments, limiting the impact of potential crashes on broader systems. 5. Incorporate robust error handling and automated recovery mechanisms in continuous integration workflows to minimize disruption from llvm-lto crashes. 6. Consider temporarily downgrading to a prior LLVM version if feasible and if it does not contain this vulnerability. 7. 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.

References

Community reviews

Loading reviews…