Someone left a trap inside a picture frame, but you still have to pick it up and hang it on your wall
CVE-2026-56711 is a classic integer-overflow-to-heap-overflow in VLC media player's AllocatePicture function (src/misc/picture.c). The i_pitch * i_lines multiplication for each image plane uses 32-bit int arithmetic; a crafted PNG with absurdly large IHDR dimensions wraps the product before it's widened to size_t, producing a tiny allocation. The PNG decoder then writes full scanlines past the buffer boundary, giving an attacker a controlled heap out-of-bounds write — the gold standard for memory corruption primitives. Affected versions are 3.0.0 through 3.0.23. The fix is VLC 3.0.24, which widens the multiply to 64-bit before accumulating. Credit goes to Fabian Wahle of Hap Security.
The vendor's CVSS 3.1 score of 8.8 HIGH is technically accurate per the vector (network-adjacent, no auth, user interaction, full CIA impact), but it materially overstates the operational risk for enterprise defenders. VLC is a *workstation media player*, not a server, identity provider, or network appliance. The attack requires a user to actively open a malicious PNG — identical in delivery cost to any spear-phishing payload. There is no public PoC, no in-the-wild exploitation, and an EPSS of 0.3% placing it in the bottom quartile. Modern EDR and email-gateway sandboxing would intercept most realistic delivery chains. For an enterprise managing 10,000 endpoints, this belongs in the normal patching cadence, not the emergency column.
4 steps from start to impact.
Craft malicious PNG
i_pitch * i_lines for at least one plane wraps past 2^32, producing a small positive 32-bit result. The two existing overflow guards in VLC — a 64-bit division check and a comparison against PICTURE_SW_SIZE_MAX — both inspect the already-wrapped value and pass. No specialized tooling beyond a hex editor or Python script is needed.- Knowledge of the VLC AllocatePicture integer-width bug
- Ability to craft a valid PNG with oversized IHDR dimensions
- No public PoC or weaponized tool exists as of 2026-09-12
- Attacker must reverse-engineer the exact dimension pairs that survive libpng header validation while also triggering the wrap
Deliver payload to victim
- Victim must have VLC 3.0.0–3.0.23 installed
- VLC must be invoked to open the PNG (not just any image viewer)
- Enterprise email gateways strip or sandbox uncommon image attachments
- Most OS defaults open PNG files in a native viewer, not VLC
- Web proxy / CASB policies may block direct media downloads
Trigger integer overflow and heap write
AllocatePicture computes the undersized buffer and calls malloc. The decoder then writes full-resolution scanlines into the too-small heap allocation, overwriting adjacent heap metadata and objects. This gives the attacker a controlled out-of-bounds write primitive.- VLC successfully opens and begins decoding the PNG
- ASLR/heap layout must be predictable enough for reliable exploitation
- Modern glibc and Windows heap hardening (LFH, segment heap) make heap metadata corruption unreliable without an info-leak companion bug
- ASLR on 64-bit systems significantly raises the bar for code execution vs. a simple crash
Achieve code execution as user
- Successful heap-layout manipulation past OS mitigations
- No EDR intervention during post-exploitation
- Execution is limited to the current user's privilege level — no SYSTEM/root escalation inherent to the bug
- EDR agents detect post-exploitation behavior (credential access, lateral movement) even if the initial corruption succeeds
The supporting signals.
| In-the-wild exploitation | None observed. Not listed in CISA KEV. No vendor, CERT, or threat-intel reports of active campaigns as of 2026-09-12. |
|---|---|
| Proof-of-concept | No public PoC. No exploit code found on GitHub, ExploitDB, or Metasploit. General CVE-2026 PoC aggregator repos do not index this CVE. |
| EPSS | 0.00299 (0.3%) — bottom quartile; probability of exploitation in the next 30 days is very low. |
| KEV status | Not listed. No CISA KEV entry as of 2026-09-12. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — User interaction required (UI:R) is the key modifier; scope is unchanged, meaning impact is confined to the VLC process context. |
| Affected versions | VLC media player 3.0.0 through 3.0.23 (all platforms: Windows, macOS, Linux, *BSD). |
| Fixed version | VLC 3.0.24 — widens the i_pitch * i_lines multiply to 64-bit arithmetic before accumulating into i_bytes. |
| Exposure data | VLC is a client-side desktop application with no listening network ports in default configuration. Shodan/Censys/GreyNoise exposure: N/A — no server-side attack surface exists. |
| Disclosure date | 2026-09-09, coordinated disclosure by Fabian Wahle of Hap Security. |
| Researcher / org | Fabian Wahle, Hap Security. Also credited for companion CVE (heap info-leak) disclosed in the same batch. |
noisgate verdict.
VLC is a workstation media player occupying no high-value infrastructure role; blast radius is limited to a single user session on a single endpoint. The single most decisive downgrade factor is the workstation-only blast radius combined with mandatory user interaction — exploitation requires social engineering a user into opening a crafted PNG specifically with VLC, producing impact equivalent to a generic phishing payload.
Why this verdict
- User interaction required: The entire chain begins with social engineering — a user must open a crafted PNG *with VLC specifically*, not just any image viewer. This is functionally identical to a malicious-document delivery, which enterprises already have layered defenses for (email gateway, EDR, user training).
- No PoC, no exploitation, bottom-quartile EPSS: With an EPSS of 0.3%, no public exploit code, and no observed campaigns, the near-term weaponization probability is very low. Converting the heap overflow to reliable RCE past modern OS mitigations (ASLR, heap hardening) requires significant exploit-development effort.
- Role multiplier: VLC is a desktop media player. It is not deployed in any high-value infrastructure role (not a domain controller, hypervisor, CI/CD runner, backup agent, IdP, or network edge appliance). Virtually 100% of VLC installs occupy the *low-value workstation* role. Successful exploitation yields user-level code execution on a single endpoint — no domain-wide, fleet-wide, or supply-chain escalation is inherent to the bug. The blast radius floor does not elevate the verdict.
- Client-side only, no network exposure: VLC opens no listening ports. There is zero Shodan/Censys/GreyNoise attack surface. The attacker must deliver the payload through a separate channel (email, web, USB) and survive enterprise gateway filtering.
Why not higher?
VLC occupies no high-value infrastructure role in any enterprise — it is exclusively a workstation media player. The attack requires user interaction, there is no public PoC or active exploitation, and EPSS sits at the 0.3% mark. The blast radius is a single user session on a single host. None of the high-value-role floor triggers (identity, hypervisor, backup, CI/CD, network edge) apply.
Why not lower?
The underlying primitive — a controlled heap out-of-bounds write from an integer overflow — is a proven class of exploitable bug. VLC is ubiquitously installed across enterprise endpoints (often without IT knowledge), and the PNG trigger format is trivial to deliver via email or web. If a weaponized exploit does emerge, the time-to-mass-exploitation could be short. Dropping below MEDIUM would undercount the latent risk.
What to do — in priority order.
- Remove or restrict VLC from managed endpoints — If VLC is not a business-required application, uninstall it via SCCM/Intune/Endpoint Central. If required, restrict it to approved users via AppLocker/WDAC allow-listing. This eliminates the attack surface entirely. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
- Reassign PNG file association away from VLC — Ensure the OS default handler for
.pngfiles is the native image viewer (Windows Photos, Preview.app, eog), not VLC. This breaks the most likely accidental-trigger scenario. Deploy via GPO or MDM profile. - Update to VLC 3.0.24 when available — The definitive fix. Push via your software-deployment pipeline within the noisgate 365-day remediation window. Validate with the version-check script below.
- Enable EDR monitoring for anomalous VLC child processes — Create a detection rule for
vlc.exeorvlcspawningcmd.exe,powershell.exe,/bin/sh, or network-connection-initiating processes. This catches post-exploitation regardless of the trigger vulnerability.
- Network-level blocking (firewall, IDS signatures): The payload is a valid PNG file delivered over HTTPS — there is no network signature to match. DPI cannot distinguish a malicious IHDR from a legitimate one without full image parsing.
- WAF rules: VLC is a client-side application with no web-server component. WAF is irrelevant.
- Disabling VLC plugins/codecs: The vulnerability is in the core picture-allocation path (
src/misc/picture.c), not in a removable plugin. Disabling individual demuxers does not help.
Crowdsourced verification payload.
Run on each Windows endpoint (or centrally via SCCM/Intune script deployment) as any user. Example: powershell -ExecutionPolicy Bypass -File Check-CVE-2026-56711.ps1. No admin privileges required.
#Requires -Version 5.1
<# Check-CVE-2026-56711.ps1
Checks whether VLC media player is installed and vulnerable to CVE-2026-56711.
Affected: 3.0.0 – 3.0.23 | Fixed: 3.0.24+
Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
#>
$vlcPaths = @(
"$env:ProgramFiles\VideoLAN\VLC\vlc.exe",
"${env:ProgramFiles(x86)}\VideoLAN\VLC\vlc.exe",
"$env:LOCALAPPDATA\Programs\VideoLAN\VLC\vlc.exe"
)
$found = $false
foreach ($p in $vlcPaths) {
if (Test-Path $p) {
$found = $true
$ver = (Get-Item $p).VersionInfo.ProductVersion
if (-not $ver) { $ver = (Get-Item $p).VersionInfo.FileVersion }
if (-not $ver) {
Write-Output "UNKNOWN - VLC found at $p but version unreadable"
exit 2
}
try {
$parts = $ver.Split('.')
$major = [int]$parts[0]
$minor = [int]$parts[1]
$patch = [int]($parts[2] -replace '[^0-9]','')
} catch {
Write-Output "UNKNOWN - could not parse version '$ver' at $p"
exit 2
}
if ($major -eq 3 -and $minor -eq 0 -and $patch -le 23) {
Write-Output "VULNERABLE - VLC $ver at $p (CVE-2026-56711: affected 3.0.0-3.0.23)"
exit 1
} elseif ($major -gt 3 -or ($major -eq 3 -and $minor -gt 0) -or ($major -eq 3 -and $minor -eq 0 -and $patch -ge 24)) {
Write-Output "PATCHED - VLC $ver at $p (fixed in 3.0.24+)"
exit 0
} else {
Write-Output "PATCHED - VLC $ver at $p (version outside affected 3.0.x range)"
exit 0
}
}
}
if (-not $found) {
Write-Output "PATCHED - VLC media player not installed (not vulnerable)"
exit 0
}If you remember one thing.
vlc.exe spawning shell processes as a durable backstop. There is no active exploitation and no public PoC, so Monday morning this goes on the backlog board, not the war-room whiteboard.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.