CVE-2026-13574 LLVM Heap Buffer Overflow in Bitcode Handler

Technical summary

The vulnerability resides in llvm/lib/IR/IntrinsicInst.cpp within the GCRelocateInst::getBasePtr function, which handles bitcode file processing. The flaw is a heap-based buffer overflow triggered through specific manipulation of intrinsic instruction data. An authenticated local user can craft inputs that cause memory corruption, resulting in application termination or potential code execution in certain configurations. The CWE classifications (CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, and CWE-122: Heap-based Buffer Overflow) confirm the nature of the memory safety issue.

Business impact

Organizations using LLVM for compilation, static analysis, or JIT compilation pipelines face localized denial of service risk. If an attacker gains local shell access, they could crash compiler processes or development toolchains, disrupting build pipelines and CI/CD systems. However, the low CVSS score (3.3) and requirement for local authentication means impact is typically limited to insider threats or multi-stage attacks where an attacker already has foothold access.

Affected systems

LLVM llvm-project versions up to and including 22.1.6 are affected. The vulnerability is triggered through the bitcode file handler component, which is used when LLVM processes bitcode input. No specific downstream vendors or products were formally listed in the advisory data, but any software or service that embeds or calls LLVM's bitcode processing—such as compilers, runtime environments, or security analysis tools—should be considered potentially affected.

Exploitability

Exploitation requires local system access and valid user credentials; remote exploitation is not possible. An attacker must be able to supply malformed bitcode input to trigger the buffer overflow in GCRelocateInst::getBasePtr. Public disclosure has occurred, but the LLVM project has questioned whether the reported behavior genuinely qualifies as a security vulnerability, asserting it is outside documented security boundaries. This dispute suggests either the attack surface is constrained to non-security-critical use cases or the condition is difficult to trigger reliably.

Remediation

Update LLVM to a patched version beyond 22.1.6. The LLVM project recommends reviewing their advisory for specific patched releases. Organizations should verify compatibility and regression testing for their specific use cases before deploying updates, particularly if LLVM is embedded in production systems. Until patching is possible, restrict local shell access and monitor bitcode file ingestion for anomalies.

Patch guidance

Verify the LLVM project's official advisory for patched version numbers and availability timeline. Update should target the next stable release after 22.1.6. Review your build system and runtime environment to identify all locations where LLVM components are used, including toolchain integrations and embedded compilers. Test patched versions in a pre-production environment to confirm no regressions affect your bitcode processing workflows before rolling out to production systems.

Detection guidance

Monitor local system access logs for users attempting to invoke LLVM compiler or bitcode processing tools with unusual or malformed input files. Application crashes or segmentation faults in LLVM processes consuming untrusted bitcode may signal exploitation attempts. Enable core dumps and analyze stack traces to confirm GCRelocateInst::getBasePtr as the crash location. For development and CI/CD environments, instrument build processes to log and alert on unexpected tool termination or resource consumption spikes during compilation.

Why prioritize this

Despite public disclosure, this vulnerability merits lower immediate priority due to its low CVSS score, requirement for local authentication, and denial-of-service-only impact. However, it should not be ignored: organizations running LLVM in multi-tenant or shared development environments where untrusted users can submit bitcode should escalate patching timelines. Additionally, if LLVM is part of a security-sensitive pipeline (e.g., formal verification, security analysis tools), the denial of service itself becomes a business continuity concern.

Risk score, explained

The CVSS 3.1 score of 3.3 (LOW) reflects: local attack vector (AV:L), low attack complexity (AC:L), requirement for user-level privileges (PR:L), no user interaction needed (UI:N), unchanged scope (S:U), and availability impact only (A:L). No confidentiality or integrity damage is possible. The score accurately captures the limited blast radius; widespread automated exploitation or unauthenticated attacks are not feasible.

Frequently asked questions