Two newly disclosed VLC Media Player vulnerabilities show how a file that appears to be ordinary media can reach dangerous low-level parsing code. One flaw can corrupt heap memory when VLC processes a crafted PNG image; the other can disclose adjacent heap data when the player connects to an attacker-controlled RTSP service.

The issues affect VLC versions 3.0.0 through 3.0.23 and require user interaction, such as opening a malicious image, media file or playlist. They were reported by Fabian Wahle of Hap Security and disclosed on September 9. Users and administrators should track VideoLAN and their operating-system distributor for patched packages.

Integer overflow can produce an undersized buffer

CVE-2026-56711 is the more severe of the two, with a CVSS score of 8.6. It combines an integer-overflow condition with an out-of-bounds write in VLC’s picture-buffer allocation logic. The affected calculation determines how much memory is needed for decoded image planes using width- and line-related values stored as signed integers.

A malicious PNG can declare extremely large dimensions in its IHDR header. During a 32-bit multiplication, the required size may wrap around to a much smaller value. VLC can then allocate a buffer that is insufficient for the image the decoder believes it is processing. When scanlines are written according to the attacker-supplied dimensions, data extends beyond the allocated heap region.

Some validation exists, but it does not neutralize the unsafe calculation. One check uses wider arithmetic in a division operation, while another examines the result only after it has already wrapped. Consequently, a crafted file can pass the checks yet still reach the dangerous write.

The immediate outcome may be a crash, but heap corruption can sometimes be developed into code execution depending on the platform, allocator behavior and exploit mitigations. That possibility is why malformed-media bugs merit attention even when opening a file is required.

RTSP handling can disclose client memory

CVE-2026-73324, rated 6.9, affects VLC’s RTSP access module. A hostile server can return an oversized Session header of at least 4,096 bytes. The player copies the line into a fixed-size buffer with a function that may omit the terminating null byte when the input fills the destination.

Later code treats that buffer as a normal C string and continues reading until it happens to encounter a zero byte in memory. VLC then reuses the session identifier in subsequent requests. This sequence may send bytes located after the intended buffer back to the malicious server, exposing fragments of process memory.

An attacker could deliver the endpoint through a playlist containing a realrtsp URL. Exposure varies because some Linux distributors may build VLC without the optional module, although official VideoLAN builds enable it. Inventory should therefore include both the VLC version and the features compiled into deployed packages.

Reducing risk before updates arrive

• Do not open unsolicited PNGs, playlists or media archives, even when they appear to come from a familiar contact.
• Block or restrict untrusted RTSP connections in environments where streaming is not required.
• Use application controls or sandboxing for media processing on sensitive workstations.
• Monitor for crashes and unusual child processes following VLC activity.

Organizations that use VLC for automated transcoding, preview generation or content review should be particularly cautious. In those workflows, untrusted files may be opened without the traditional warning moment of a person double-clicking an attachment.

Media parsers remain a useful attack surface

VLC supports a wide range of codecs, containers and network protocols, creating a large parsing surface exposed to complex, attacker-controlled input. These two flaws arise in different components but share a familiar memory-safety theme: assumptions about sizes and string termination fail at an input boundary.

Until fixed releases are deployed, treating unfamiliar media as active content is the safest posture. Endpoint protections may catch later exploit behavior, but limiting exposure to the vulnerable parsers provides a more direct defense.