VLC media player copies an RTSP response line into a fixed buffer without guaranteeing termination and then…

CVE-2026-73324 is a heap out-of-bounds read in VLC media player's RealRTSP module (modules/access/rtsp/access.c and modules/access/rtsp/rtsp.c). The RtspReadLine function copies each server response line into a 4,096-byte buffer using strncpy with the full buffer length, which omits the null terminator when the source line fills or exceeds the destination. The rtsp_get function then passes that unterminated buffer to strdup, which measures length past the allocation boundary, copying adjacent heap bytes until it hits an incidental zero byte. Because the over-read data ends up stored as the RTSP Session identifier, VLC dutifully sends those leaked heap bytes back to the malicious server on every subsequent request. Affected versions are 3.0.0 through 3.0.23 — every current official build. No patch exists as of 2026-09-12.

The vendor's MEDIUM / 6.5 score is directionally correct but slightly generous for most enterprise environments. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) correctly reflects the user-interaction requirement and confidentiality-only impact. However, the attack surface is narrowed further by the fact that it requires a user to open a realrtsp:// URI — a legacy protocol almost no enterprise workflow depends on. The leaked data is unstructured heap content, not targeted credential theft. In practice, this is an opportunistic info-disclosure primitive that is hard to weaponize into anything beyond raw memory bytes, making the real-world severity slightly below the vendor's label.

Why this verdict

• User-interaction gate on a dead protocol: The attack requires a user to click a realrtsp:// URI. RealRTSP (Real Networks' proprietary RTSP variant) has been functionally obsolete for over a decade. The probability of an enterprise user encountering a legitimate — let alone malicious — realrtsp link in a normal workflow is near zero.
• Read-only primitive with uncontrolled output: CWE-125 OOB read yields raw heap bytes. The attacker cannot select which memory regions to read, cannot achieve code execution, and cannot pivot from disclosure to write. Weaponizing random heap content into credential theft requires coincidental heap layout.
• Role multiplier: VLC is a workstation application, not a high-value-role component. VLC does not run on domain controllers, hypervisors, CI/CD servers, backup infrastructure, or network edge appliances in any standard deployment. It runs as a regular-user process on desktops. Blast radius is strictly single-host, single-user — no domain, fleet, or supply-chain escalation path exists. This means no high-value-role floor applies.
• No exploitation evidence or PoC amplifier: EPSS at 0.33%, no KEV listing, no public PoC, no observed campaigns. The trivial PoC bar (just serve a long header) is offset by the low value of the resulting leak.
• Egress filtering friction: Enterprise networks with proxy-only egress or port-restricted firewalls block direct RTSP connections, further reducing the reachable population.

Why not higher?

Upgrading to HIGH would require either a code-execution primitive, active exploitation, or a high-value deployment role. This CVE delivers none of those: it is a read-only heap disclosure on a desktop media player via a legacy protocol, with no PoC in the wild and an EPSS in the bottom 1%. The blast radius is capped at one workstation's heap — there is no lateral movement or privilege escalation path.

Why not lower?

Despite the friction, the vulnerability is real, trivial to trigger once a user clicks the link, and no patch exists. VLC's massive install base means some fraction of enterprise endpoints will have it. The CVSS C:H rating is warranted — the heap leak is genuine and exfiltrated to the attacker. Dropping to LOW would understate the risk for organizations that cannot enforce egress filtering or URI-scheme blocking.

1. Block or unregister the realrtsp:// URI scheme — Remove VLC's handler registration for realrtsp:// on managed endpoints via GPO (Windows) or xdg-mime / Launch Services (Linux/macOS). This kills the attack chain at step 2 with zero operational impact, since no legitimate workflow uses this scheme. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window, but this control is free and should be deployed proactively.
2. Block outbound RTSP (port 554) at the perimeter — If not already blocked, add an egress firewall rule denying TCP/554 outbound. This prevents VLC from reaching attacker-controlled RTSP servers even if the URI handler fires. Most enterprises already block this; verify your rule set.
3. Deploy email gateway rules to strip realrtsp:// URIs — Configure your email security gateway (Proofpoint, Mimecast, Microsoft Defender for O365) to quarantine or defang messages containing realrtsp:// links or .m3u/.xspf attachments referencing them.
4. Pin VLC version and prepare for rapid update — Use your software management tool (SCCM, Intune, Munki) to inventory all VLC 3.0.x installations. When VideoLAN releases 3.0.24 (or a 4.x build with the fix), push it within the 365-day noisgate remediation SLA.

Run on each target host (Linux, macOS, or WSL on Windows) to check the installed VLC version. No special privileges required. Example: bash check_vlc_cve_2026_73324.sh

#!/usr/bin/env bash
# check_vlc_cve_2026_73324.sh
# Checks whether the installed VLC version is vulnerable to CVE-2026-73324
# Affected: VLC 3.0.0 through 3.0.23
# Exit codes: 0 = PATCHED/not installed, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

get_vlc_version() {
  if command -v vlc >/dev/null 2>&1; then
    vlc --version 2>/dev/null | head -1 | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1
  elif command -v flatpak >/dev/null 2>&1 && flatpak list 2>/dev/null | grep -qi vlc; then
    flatpak run org.videolan.VLC --version 2>/dev/null | head -1 | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1
  elif [ -x "/Applications/VLC.app/Contents/MacOS/VLC" ]; then
    /Applications/VLC.app/Contents/MacOS/VLC --version 2>/dev/null | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1
  else
    echo ""
  fi
}

VERSION=$(get_vlc_version)

if [ -z "$VERSION" ]; then
  echo "PATCHED — VLC not found on this host."
  exit 0
fi

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

echo "Detected VLC version: $VERSION"

if [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 0 ] && [ "$PATCH" -ge 0 ] && [ "$PATCH" -le 23 ]; then
  echo "VULNERABLE — VLC $VERSION is in the affected range (3.0.0–3.0.23) for CVE-2026-73324."
  exit 1
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 0 ] && [ "$PATCH" -ge 24 ]; then
  echo "PATCHED — VLC $VERSION is above 3.0.23."
  exit 0
elif [ "$MAJOR" -ge 4 ]; then
  echo "UNKNOWN — VLC $VERSION is a 4.x build; verify RealRTSP module status independently."
  exit 2
else
  echo "PATCHED — VLC $VERSION predates the 3.0.x affected range or is unaffected."
  exit 0
fi

Sources

1. VulnCheck Advisory — VLC RealRTSP OOB Read
2. SecurityOnline — Two VLC Flaws Expose Heap Memory
3. GBHackers — VLC Flaws Let Attackers Corrupt Memory
4. OpenCVE — CVE-2026-73324 Details
5. OSV — CVE-2026-73324
6. OffSeq Threat Radar — CVE-2026-73324
7. CyberPress — VLC Memory Leak Analysis