CVE-2026-104266 in tinytaginfo

Summary

by MITRE • 10/15/2026

tinytag is a Python library for reading audio file metadata. From 2.0.0 until 2.3.0, an M4A file containing a sub-atom with a size of zero inside a ---- atom can cause the metadata parser to stop advancing through the input. The custom-field atom traversal repeatedly processes the malformed location, causing an infinite loop and denying service to a program that reads the crafted file. This issue is fixed in version 2.3.0.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/15/2026

The vulnerability identified within the tinytag Python library affects versions ranging from 2.0.0 through 2.3.0, representing a critical flaw in how the parser handles malformed M4A audio files. Tinytag is widely utilized for extracting metadata such as title, artist, and album information from various audio formats, making it a common dependency in media management applications and automated processing pipelines. The specific weakness lies in the parsing logic responsible for handling custom-field atoms, specifically those designated by the ---- atom type within the M4A container format. When an attacker crafts an M4A file that contains a sub-atom with a size field explicitly set to zero inside this context, it triggers a failure in the standard traversal algorithm designed to iterate through metadata fields.

From a technical perspective, the root cause of this issue is an infinite loop resulting from incorrect boundary checking during atom parsing. The parser attempts to read and process atoms sequentially by advancing its position pointer based on the size specified in each atom header. However, when encountering a sub-atom with a zero byte length inside a ---- atom, the logic fails to properly advance past the malformed entry or detect it as an invalid structure that should terminate processing. Instead of raising an exception or skipping the corrupt data, the parser remains stuck at the same memory location, repeatedly attempting to process the same zero-sized segment. This behavior effectively traps the execution thread in a non-terminating loop, consuming CPU resources indefinitely and preventing any further operations within the application using tinytag.

The operational impact of this vulnerability is primarily focused on availability, manifesting as a denial-of-service condition for any service or script that ingests untrusted audio files. If an automated system processes user-uploaded media without strict validation prior to parsing, a maliciously crafted M4A file can hang the process indefinitely. In web applications where metadata extraction occurs during upload, this could lead to thread exhaustion if multiple such requests are processed concurrently, potentially rendering the service unavailable to legitimate users. While there is no direct indication of code execution or arbitrary memory access in this specific flaw, the resource consumption and potential for application crash constitute a significant security risk that must be addressed before trusting external inputs.

This vulnerability aligns with CWE-835, which describes loops that do not terminate correctly due to missing boundary conditions or incorrect loop control variables. Furthermore, it maps to MITRE ATT&CK technique T1496, Resource Hijacking, where attackers use resources such as CPU time or memory in a way that negatively impacts the availability of systems and services. The exploitation vector is remote if the application accepts file uploads from untrusted sources over a network interface. To mitigate this risk, organizations relying on tinytag must upgrade to version 2.3.0 or later, where the parsing logic has been corrected to handle malformed atoms gracefully by detecting invalid sizes and terminating traversal appropriately. Until an update can be applied, implementing input validation at the application layer to reject files with suspicious atom structures or setting strict timeouts for metadata processing tasks can provide a temporary defensive measure against this denial-of-service vector.

Responsible

GitHub M

Reservation

10/01/2026

Disclosure

10/15/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you know our Splunk app?

Download it now for free!