CVE-2026-110877 in AdPlug
Summary
by MITRE • 10/15/2026
AdPlug through 2.4 contains a heap out-of-bounds read vulnerability in CdmoLoader::load() in src/dmo.cpp that allows attackers to read past a heap allocation by supplying a truncated TwinTeam DMO file. Attackers can supply a 12- or 13-byte file passing dmo_unpacker::decrypt(), opened via CAdPlug::factory, to read bytes beyond packed_module and potentially crash the application.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in AdPlug versions through 2.4 represents a critical heap-based out-of-bounds read flaw located within the CdmoLoader::load function found in src/dmo.cpp. This security issue arises from insufficient boundary checks when processing TwinTeam DMO module files, which are commonly used for tracking music formats in retro computing and gaming communities. The core of the vulnerability lies in the interaction between the file loading mechanism and the decryption routine, specifically involving dmo_unpacker::decrypt(). When a user or automated system supplies a malformed input file that is truncated to exactly twelve or thirteen bytes, the application fails to validate whether the data length aligns with expected buffer sizes before proceeding with memory operations. This lack of validation allows an attacker to trigger a read operation that extends beyond the allocated heap memory region associated with packed_module.
From a technical perspective, this flaw constitutes a classic case of improper input validation leading to out-of-bounds access. The CAdPlug::factory method serves as the entry point for loading these modules, passing control directly to the loader without adequate pre-checks on file integrity or size constraints relative to internal buffer allocations. As dmo_unpacker::decrypt processes the truncated data, it attempts to unpack and decrypt content that does not exist within the bounds of the allocated memory space. Consequently, the application reads arbitrary bytes from adjacent heap regions. This behavior is categorized under CWE-125, which defines out-of-bounds read vulnerabilities where software accesses memory beyond the intended boundary, potentially exposing sensitive information or causing instability depending on what data resides in those adjacent memory locations.
The operational impact of this vulnerability extends beyond simple data exposure. While an attacker might theoretically use this flaw to leak heap contents such as stack canaries, encryption keys, or other process-sensitive data, the most immediate and observable consequence is application stability degradation. The act of reading past allocated boundaries often leads to segmentation faults or general protection violations, resulting in a denial of service condition where the AdPlug-based application crashes unexpectedly. For applications that rely on continuous audio playback during gaming sessions or multimedia presentations, such crashes can disrupt user experience significantly. Furthermore, if this library is integrated into larger software ecosystems without proper sandboxing, the crash could potentially be leveraged as part of a more complex exploitation chain to achieve arbitrary code execution, although direct remote code execution via out-of-bounds reads typically requires additional primitives like heap spraying or specific allocator behaviors that may not always be present.
Mitigation strategies for this vulnerability focus primarily on robust input validation and defensive programming practices within the library itself. Developers must implement strict length checks before invoking dmo_unpacker::decrypt to ensure that the provided file size meets minimum requirements necessary for safe unpacking operations. Additionally, incorporating bounds checking mechanisms during memory access points can prevent reads from extending beyond allocated regions. For end-users and integrators of AdPlug, upgrading to a patched version is the most effective remediation step. Until an official patch is available or if maintaining legacy versions is required, implementing external validation layers that inspect file headers and sizes before passing them to the library can provide a layer of defense against malformed inputs. Monitoring industry standards such as CWE-125 helps in auditing similar code paths for potential weaknesses, ensuring that future development cycles prioritize memory safety checks at every stage of data ingestion.