VLC Media Player hit by two critical security flaws: heap corruption and memory disclosure putting millions at risk

Two newly disclosed vulnerabilities in VLC Media Player could let attackers corrupt heap memory or pull sensitive data off a victim’s machine through malicious PNG files and rogue RTSP streams. Here’s how they work and what to do about them.

The vulnerabilities at a glance

VideoLAN’s VLC Media Player, installed on an estimated 3.5 billion devices worldwide, has been hit with two security vulnerabilities that researchers are urging users to take seriously. Tracked as CVE-2026-56711 (CVSS v4: 8.6, High) and CVE-2026-73324 (CVSS v4: 6.9, Medium), both flaws affect every VLC release from version 3.0.0 through 3.0.23 and were publicly disclosed on September 9, 2026.

The vulnerabilities were found and reported by Fabian Wahle, a security researcher at Hap Security. His technical analysis lays out a pair of classic memory-safety bugs, the kind that keep turning up in widely deployed C codebases despite decades of industry awareness. The first flaw enables a heap-based out-of-bounds write through a crafted PNG image. The second leaks adjacent heap memory to a malicious RTSP server via an improperly null-terminated string buffer.

VLC processes untrusted media files and network streams as a core function, and both vulnerabilities can be triggered through relatively low-effort social engineering: opening a malicious image file, clicking a poisoned playlist entry, or connecting to a rogue streaming server.

CVE-2026-56711: integer overflow leads to heap corruption via malicious PNG

The more dangerous of the two vulnerabilities, CVE-2026-56711, resides in VLC’s internal picture-buffer allocation logic, specifically the AllocatePicture function in src/misc/picture.c. This is the code path responsible for calculating how much heap memory VLC needs to reserve before a decoded image frame can be written into it.

The root cause: 32-bit arithmetic where 64-bit was needed

When VLC decodes an image, it must allocate a contiguous buffer large enough to hold the pixel data across every color plane. The allocation size is computed by iterating over each plane and accumulating the product of i_pitch (bytes per row) and i_lines (number of rows) into a running total. Both i_pitch and i_lines are declared as signed 32-bit integers (int) in VLC’s include/vlc_picture.h header structure, so the multiplication runs in 32-bit signed arithmetic.

If an attacker supplies image dimensions large enough (width and height values in the tens of thousands or higher), the product can exceed the maximum value of a signed 32-bit integer (2,147,483,647). When that happens, the result wraps around to a much smaller positive value, or even a negative one, depending on the overflow magnitude. That wrapped value is then promoted into the larger size_t variable used for the actual malloc call.

The result: VLC allocates a tiny heap buffer, maybe a few kilobytes, while the image decoder downstream expects to write megabytes of scanline data into it.

Why existing validation fails to catch it

Wahle’s analysis points to a subtle but important detail: VLC does include checks meant to prevent absurdly large allocations, but they operate at the wrong abstraction layer. One validation routine does its arithmetic in 64-bit, which would correctly catch an oversized image, but it runs after the vulnerable 32-bit multiplication has already wrapped. The size comparison that follows checks the already-corrupted value instead of the true mathematical product. The guard rails exist; they’re just positioned after the point of failure.

The exploitation vector: a crafted PNG IHDR header

To trigger the vulnerability, an attacker constructs a PNG file whose IHDR chunk (the mandatory header declaring width, height, bit depth, and color type) contains extremely large dimension values. VLC’s image demultiplexer checks that the file’s actual byte size is roughly consistent, but it doesn’t constrain the declared IHDR dimensions against a maximum safe threshold before passing them into the allocation and decode pipeline.

When VLC’s PNG decoder starts processing scanlines based on those oversized dimensions, it writes pixel data well past the boundaries of the undersized heap buffer. Since the attacker controls both the declared dimensions and the actual pixel data in the PNG’s IDAT chunks, they control both how far the write goes and what gets written.

Impact assessment: crash, corruption, or code execution

Heap out-of-bounds writes are among the most dangerous classes of memory corruption bugs. At minimum, exploitation crashes VLC with a segmentation fault or heap corruption abort. In a worst case, depending on the target platform’s memory layout and the presence of exploit mitigations like ASLR, stack canaries, Control Flow Guard (Windows), or RELRO (Linux), an attacker who precisely controls the overflow content and length may achieve arbitrary code execution within the VLC process.

The attack needs no non-default configuration. Opening the malicious PNG directly in VLC, or loading it through a playlist file (.m3u, .xspf, etc.) that references the image, is enough to reach the vulnerable code path. The CVSS v4 score of 8.6 reflects the high impact on confidentiality, integrity, and availability, tempered by the need for user interaction.

CWE classifications: CWE-190 (Integer Overflow or Wraparound) and CWE-787 (Out-of-bounds Write).

CVE-2026-73324: RTSP session header leaks heap memory to malicious servers

The second vulnerability, CVE-2026-73324, affects VLC’s RealRTSP access module (modules/access/rtsp/access.c and modules/access/rtsp/rtsp.c), which handles the Real-Time Streaming Protocol used for live media delivery. The module is compiled and enabled by default in official VideoLAN builds, though some Linux distribution packages disable it at build time.

The bug: strncpy without null termination

The flaw lives in the RtspReadLine function, which reads a line from an RTSP server’s TCP response and copies it into a fixed-size 4,096-byte buffer using strncpy. strncpy has a well-known quirk: if the source string is equal to or longer than the specified maximum copy length, it doesn’t append a null terminator (\0) to the destination buffer.

When a malicious RTSP server sends a Session header line that’s exactly 4,096 bytes or longer, strncpy fills the entire buffer with server-controlled data but leaves it unterminated. VLC then passes this buffer to strdup in modules/access/rtsp/rtsp.c, which expects a properly null-terminated C string. Since there’s no null byte at position 4,096, strdup keeps reading through adjacent heap memory until it happens to hit a zero byte, potentially hundreds or thousands of bytes past the intended buffer.

From memory read to active data exfiltration

This is where CVE-2026-73324 turns from a theoretical information leak into a practical exfiltration channel. VLC stores the result of that strdup call as the RTSP session identifier, and it sends this session ID back in the Session header on every subsequent request to the same server. Since the session ID now contains raw heap memory from the VLC process, potentially including pointers, heap metadata, fragments of previously decoded media, or other runtime data, the attacker’s server receives that data passively with every follow-up request.

The attacker can keep the RTSP session open and keep receiving heap contents for as long as the connection persists, turning a single out-of-bounds read into a sustained data-disclosure channel.

Triggering the vulnerability

Exploitation requires the victim to connect to a malicious RTSP server. The most practical delivery mechanism is a playlist file (.m3u, .pls, .xspf) containing a rtsp:// or realrtsp:// URL pointing to the attacker’s infrastructure. When the user opens the playlist in VLC, the client automatically starts the RTSP handshake and processes the malicious Session header.

The CVSS v4 score of 6.9 reflects the medium severity: the impact is mainly on confidentiality rather than integrity or availability, and exploitation needs both a malicious server and user interaction. Still, in environments where VLC accesses streaming sources of uncertain origin (corporate media monitoring, IPTV setups, automated playback systems), the practical risk isn’t trivial.

CWE classifications: CWE-125 (Out-of-bounds Read) and CWE-170 (Improper Null Termination).

As of this writing, VideoLAN hasn’t released a patched build for either vulnerability. Users and administrators should watch the official VideoLAN security advisories page, the project’s GitLab repository, and their Linux distribution’s security channels for updated packages.

Putting the risk in context: who should worry most?

Both vulnerabilities need some user interaction. An attacker can’t remotely exploit a VLC installation without the victim opening a malicious file, playlist, or stream, which cuts down the odds of mass automated exploitation compared to a wormable network service vulnerability.

That said, a few real-world scenarios raise the risk considerably. Media professionals and journalists who routinely receive video files, images, and streaming links from unverified sources face higher-than-average exposure to crafted PNGs or poisoned playlists delivered by email, messaging platforms, or file-sharing services. Enterprise and broadcast environments that use VLC to monitor IP camera feeds, IPTV streams, or live event coverage over RTSP could connect to a compromised or spoofed RTSP server and trigger CVE-2026-73324 without anyone clicking a suspicious link. Automated or kiosk deployments of VLC, such as digital signage, public displays, or embedded systems, may process media from network shares or streaming endpoints with little human oversight, which weakens the “user must open the file” mitigation.

Linux distribution variance also matters here: CVE-2026-73324 exposure isn’t uniform. Official VideoLAN builds ship with the RealRTSP module enabled, but some Debian, Ubuntu, or Fedora packages compile VLC without it. If RTSP exposure is a concern, check your specific build configuration.

Why these bugs persist in modern codebases

For readers with a software engineering or security research background, it’s worth asking why these two vulnerability classes, integer overflow in allocation size calculation and missing null termination in string handling, keep showing up in a project as mature and widely audited as VLC.

The AllocatePicture integer overflow is a textbook type-width mismatch in C. The picture_plane_t structure uses int for pitch and line count, a design decision that made sense when image resolutions were measured in the hundreds of pixels. Modern PNG files can declare dimensions up to 2³¹−1 per the format spec, and nothing in the PNG standard stops a file from claiming absurd dimensions. The 32-bit multiplication was never updated to 64-bit as display resolutions and image formats grew, and the validation checks added later run at a different precision than the vulnerable arithmetic.

The strncpy null-termination issue in RtspReadLine is similarly well known in C security circles. strncpy was designed for fixed-width field copying in legacy data structures, not safe C-string handling. The C11 standard introduced strncpy_s, and the safer strlcpy (available on BSD and macOS, and in some Linux libcs), specifically to address this class of bug. VLC’s RTSP module still relies on raw strncpy without an explicit null-termination step, a pattern that static analysis tools like Coverity, CodeQL, and Clang’s -Wstringop-truncation are built to catch but that can slip through in a codebase with millions of lines and a long maintenance history.

Neither bug is exotic. Fuzzing campaigns, automated static analysis in CI pipelines, and memory-safe language adoption all exist to catch defects like these, and their presence in VLC is a reminder of how much residual memory-safety risk even a mature, security-conscious C project can carry.

What users and administrators should do right now

Until VideoLAN ships a patched release, or your distribution backports the fix, the following steps will meaningfully cut your exposure.

For individual users:

• Don’t open PNG image files, media playlists, or RTSP/RealRTSP links from untrusted or unexpected sources, including files received via email, messaging apps, social media DMs, or unfamiliar websites. If a contact sends you a media file unexpectedly, verify through a separate channel before opening it in VLC.
• Avoid connecting VLC to RTSP streams from unknown or unverified servers. If you use VLC for IPTV or IP camera viewing, confirm the stream URLs point to trusted, expected infrastructure.
• Keep VLC updated, and install a patched build the moment one ships. Enable automatic updates where available.
• Consider temporarily disabling the RealRTSP module if you don’t use RTSP streaming. On some builds this can be done through VLC’s preferences under Input/Codecs > Access Modules, or by removing or renaming the relevant plugin file. This removes the CVE-2026-73324 attack surface entirely.

For enterprise and organizational IT teams:

• Restrict VLC execution in high-security environments where users process untrusted media. Application whitelisting, sandboxing (Windows Sandbox, Flatpak/AppArmor profiles on Linux), or running VLC in a container can limit the blast radius of a successful exploit.
• Block outbound RTSP connections (TCP port 554 by default) to untrusted network destinations at the firewall or proxy level, particularly where VLC is used for playback but RTSP isn’t a business requirement.
• Deploy EDR rules to flag VLC processes showing anomalous behavior: unexpected child process spawning, unusual network connections after opening a media file, or heap corruption indicators in crash dumps.
• Audit playlist-based delivery mechanisms. If your organization distributes playlists by email, shared drives, or internal portals, make sure those sources are integrity-checked and that VLC instances aren’t configured to auto-open playlist files from network locations.
• Monitor VideoLAN’s GitLab security advisories and your distribution’s security mailing lists (Debian Security, Ubuntu Security Notices, Red Hat Product Security) for patch availability, and apply updates within your standard patch-management SLA.

VLC’s security track record

VLC has been a target for security researchers and attackers for over two decades, thanks to its massive install base and its handling of dozens of complex media codecs and container formats. The project has addressed hundreds of CVEs over the years, from buffer overflows in codec demuxers to use-after-free bugs in subtitle rendering.

The 3.0.x branch, codenamed “Vetinari,” has been VLC’s stable release line since 2018 and carries a substantial patch history. The 4.0 rewrite, in development for several years, introduces a modernized architecture with improved memory handling, but its release timeline has seen repeated delays. Until 4.0 reaches general availability, the 3.0.x codebase remains the production standard, and vulnerabilities like CVE-2026-56711 and CVE-2026-73324 are a reminder that even mature, well-maintained C projects carry residual memory-safety risk.

It’s also important to note that VideoLAN operates with a relatively small core development team compared to commercial vendors of similar reach, so patch cadence can run slower than users might expect from a corporate-backed product. That puts more responsibility on end users and administrators to apply interim mitigations and watch for patch announcements.

Final assessment

CVE-2026-56711 and CVE-2026-73324 aren’t the most exotic vulnerabilities you’ll read about this year, but they’re practically exploitable, well-understood memory-safety bugs in one of the most widely installed media applications on the planet, and they deserve prompt attention. The integer overflow in the picture allocation path is especially concerning: a single malicious PNG file, trivially small, easily distributed, and indistinguishable from a legitimate image at the file-system level, can trigger heap corruption with potential code-execution consequences.

The RTSP information disclosure, while lower severity, opens an active exfiltration channel that goes beyond a simple crash, and its delivery through playlist files makes it a viable component of targeted phishing campaigns.

The need for user interaction is a real mitigating factor, and it keeps these from being wormable or zero-click threats. But social engineering remains the primary way attackers get an initial foothold, so “the user has to open a file” is a thinner defense than a lot of organizations assume.

Patch as soon as updates are available. Until then, treat every unexpected media file, playlist, and stream link as potentially hostile.

This article will be updated if and when VideoLAN releases a patched build or additional technical details emerge. For the latest advisories, check the official VideoLAN website and your operating system vendor’s security bulletins. If you found this analysis useful, share it with your team or IT department, especially anyone responsible for media playback infrastructure, digital signage, or environments where VLC processes content from external sources.