---
title: "VLC Media Player Flaws Expose Heap Memory, No Patch Yet"
date: 2026-09-11
author: "Sofia Ramirez"
featured_image: "https://sqmagazine.co.uk/wp-content/uploads/2026/09/vlc-media-player-flaw.jpg"
categories:
  - name: "Cybersecurity"
    url: "/cybersecurity.md"
tags:
  - name: "News"
    url: "/tag/news.md"
---

# VLC Media Player Flaws Expose Heap Memory, No Patch Yet

VulnCheck, a vulnerability intelligence firm, disclosed on 9th September 2026 that VLC media player versions 3.0.0 through 3.0.23 write attacker-controlled data past a heap buffer when they open a crafted PNG file. VideoLAN has not shipped a fixed build.

## What to Know?

- CVE-2026-56711 is a heap out-of-bounds write in VLC’s picture allocation code, rated 8.6 on CVSS v4.
- CVE-2026-73324 is a heap out-of-bounds read in the RealRTSP module that can leak client memory to a hostile server.
- Fabian Wahle of Hap Security is credited with finding both flaws, according to the two VulnCheck advisories.
- VideoLAN’s newest 3.0 release is still 3.0.23, so users have no patched version to install yet.

## How It Happened?

The PNG bug sits in AllocatePicture, inside src/misc/picture.c. That function adds **p->i\_pitch** multiplied by **p->i\_lines** to a running byte total, and because both fields are **32-bit** integers in **include/vlc\_picture.h**, the multiplication wraps before VLC widens the result to **size\_t**.

An attacker only needs to declare huge width and height values in the PNG’s IHDR header. The product wraps to a small number, aligned\_alloc reserves a buffer that’s far too small, and VLC’s PNG decoder then writes scanlines sized to the original dimensions straight past its end.

VLC’s guards miss this. Its overflow check divides with 64-bit arithmetic, but the later limit check tests the already wrapped value, and the image demuxer counts the file’s bytes instead of its declared dimensions. Opening the file directly or through a playlist reaches the bug, with no special settings required.

[VulnCheck’s advisory for CVE-2026-56711](https://www.vulncheck.com/advisories/vlc-media-player-3.0.0-through-3.0.23-heap-out-of-bounds-write-via-integer-overflow-in-picture-allocation) maps it to **CWE-190 and CWE-787**. It describes an attacker-controlled heap write but doesn’t claim a working code execution exploit, and nobody has confirmed exploitation in the wild or a public proof-of-concept.

## A Hostile RTSP Server Can Read Client Memory

[CVE-2026-73324](https://sqmagazine.co.uk/kev-tracker/) scores **6.9** on CVSS v4 and lives in **RtspReadLine**. VLC copies each server response line into a fixed-size buffer with strncpy but never guarantees a terminating null byte. When a server sends a line longer than **4,096 bytes**, VLC later passes that buffer to strdup, which keeps reading neighboring heap memory until it hits a stray zero.

The delivery route turns a read bug into a leak. A malicious server puts the oversized line in the Session header, VLC stores it as the session identifier, and the player echoes those heap bytes back to the server on later requests.

RealRTSP is optional at build time, and some distribution packages leave it out, but official VideoLAN builds include it. The CVE records also list CVSS v3.1 scores of 8.8 and 6.5, so [CVE severity ratings](https://sqmagazine.co.uk/cve-statistics/) for these bugs vary depending on which scoring version a source quotes.

## What’s Next?

Both bugs come down to a safety check that trusted a value after it had already gone wrong. The PNG flaw is the bigger worry for most people because it needs only a file or a playlist, while the RTSP leak needs the player to connect to a server the attacker runs.

VideoLAN hasn’t published a security bulletin, and neither advisory names a fixed version. Until a release ships, don’t open untrusted PNG files or playlists in VLC, and skip RTSP streams from unknown sources. That helps reduce risk but doesn’t remove it. IT teams should also check whether their packaged VLC builds include RealRTSP. Two questions stay open: when VideoLAN will ship a fixed 3.0 build, and how quickly Linux distributions will carry it.