CVE-2026-103242 in Red Hat
Summary
by MITRE • 09/30/2026
A heap-based buffer overflow flaw was found in rpm. RPMTAG_FILESIGNATURES in a crafted, unsigned RPM package's main header is declared with the wrong header type, causing hex2binv() to allocate a one-byte buffer and then write the tag's attacker-controlled, hex-decoded content — of attacker-chosen length — past the end of that allocation. This is reachable via rpm2cpio, rpm2archive, and rpm -qlvp on an untrusted package.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in the RPM Package Manager represents a critical heap-based buffer overflow rooted in improper input validation and type handling within the header parsing logic. Specifically, the flaw resides in how the system processes RPMTAG_FILESIGNATURES when encountered in crafted, unsigned RPM packages. The core technical issue arises because this specific tag is declared with an incorrect header type during the initial parsing phase. This misclassification leads to a miscalculation of the required buffer size for subsequent processing steps. When the hex2binv function is invoked to decode the hexadecimal-encoded signature data contained within the main header, it relies on the erroneous length information derived from the wrong header type. Consequently, the function allocates an insufficiently sized one-byte buffer instead of a buffer large enough to hold the actual decoded content.
This allocation error creates a direct path for memory corruption when the attacker provides hex-decoded content of their chosen length. Since the allocated space is only one byte but the write operation attempts to store data based on the full, potentially much larger, size of the input string, the function writes past the end of the heap-allocated buffer. This out-of-bounds write allows an attacker to overwrite adjacent memory structures on the heap. Such corruption can lead to arbitrary code execution if the overwritten memory contains critical pointers or control flow data that are subsequently dereferenced by the application. The vulnerability is particularly dangerous because it does not require authentication, making it a remote attack vector for any user who processes untrusted RPM packages using specific tools.
The operational impact of this flaw extends across multiple components of the RPM ecosystem. An attacker can exploit this condition through rpm2cpio, which converts RPM archives to cpio format; rpm2archive, used for creating archive files from RPMs; and directly via the rpm command with flags such as -qlvp when inspecting an untrusted package. In each case, the processing of the malformed header triggers the buffer overflow before any significant security checks or signature verifications can occur. This means that simply viewing metadata or attempting to extract contents from a maliciously crafted RPM file is sufficient to trigger the vulnerability. The ability to execute arbitrary code with the privileges of the user running these tools poses a severe risk, potentially leading to full system compromise if those users have elevated permissions or if the overflow allows for privilege escalation techniques to be applied against other vulnerable components on the host system.
From a classification perspective, this vulnerability aligns closely with CWE-120, which describes buffer copy without checking size limits, specifically manifesting as a heap-based buffer overflow. The attack vector leverages improper input validation (CWE-20) and incorrect type handling during data interpretation. In terms of the MITRE ATT&CK framework, this vulnerability facilitates initial access or execution through technique T1203, exploitation for client-side code execution, particularly when users are tricked into opening malicious RPM files via rpm2cpio or similar utilities. It also relates to T1496, Resource Hijacking, if the overflow is used to destabilize system resources, though the primary threat remains arbitrary code execution.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The most effective solution is for vendors to release an updated version of RPM that corrects the header type declaration for RPMTAG_FILESIGNATURES and ensures that hex2binv performs rigorous bounds checking before allocating memory or writing data. Administrators should restrict the use of rpm tools on untrusted packages until patches are applied, avoiding commands like rpm -qlvp on files obtained from unknown sources. Additionally, implementing strict input validation at all stages of package ingestion is crucial. Security teams should monitor for updates to RPM and apply them promptly across all systems that process software packages. Deploying intrusion detection signatures that identify anomalous memory access patterns or malformed header structures can also provide an additional layer of defense against exploitation attempts in environments where immediate patching may not be feasible.