Two vulnerabilities published on 9 September affect every VLC media player build in the 3.0 line, from 3.0.0 through 3.0.23, and neither record names a version where the problem is fixed. The more serious of the pair can end with code running under the VLC process after somebody opens a booby-trapped file.
VLC is one of the most widely installed desktop applications in the world. That is most of the story here: a flaw that needs a user to open a file is a weak flaw on a server and a strong one on a machine where opening files somebody sent you is the entire purpose of the software.
One needs a file, one needs a server
CVE-2026-56711 is described in its National Vulnerability Database entry as a memory-safety flaw reachable when the player processes crafted media. Memory safety here means the program can be pushed into reading or writing outside the slice of memory it was handed, which is the class of mistake that ends either in a crash or, with enough care, in attacker-chosen code. Exploitation requires user interaction, and the outcome may be anything from the application terminating to code execution with the privileges of the VLC process. It carries a CVSS v3.1 base score of 7.0 and a CVSS v4.0 score of 7.3, high on both scales, and the v3.1 vector treats it as needing local access and a difficult set of conditions rather than a drive-by.
CVE-2026-73324 is the quieter one. It affects certain builds only, is reachable when the player processes media from a network source an attacker controls, and may disclose a limited and layout-dependent amount of VLC process memory. Whether a given install is exposed depends on how the build was configured. It is scored 5.3 under CVSS v4.0 and 4.3 under v3.1, medium in both.
The version range has no exit
Both records were published through VulnCheck, the authority that assigned the identifiers, and the only reference either one carries is the VideoLAN source repository. Peru's national digital security centre flagged the pair in its 12 September bulletin, which is one of the few write-ups anywhere outside the CVE records themselves.
What none of that gives a defender is a build number to move to. The affected range ends at 3.0.23, so there is no fixed release named anywhere in the public record, and the usual advice stops mid-sentence. It is an uncomfortable position, though not an unfamiliar one, and closer than anyone would like to what faces the owners of video encoders with a root flaw and no vendor left to fix it.
Until a fixed build appears
The exposure is bounded by how the player gets used, because both flaws need the user to press play: a file in the first case, a stream from a server an attacker controls in the second. Do not open media that arrived unsolicited, be wary of playlists that pull from remote sources, and treat a streaming URL from a forum, a search result or a message the way you would treat an executable from the same place. On managed fleets the practical controls are application allowlisting and constraining what VLC is permitted to touch, since a version bump is not currently on offer.
Watch the VideoLAN project and the two CVE records for a fixed build, because those records are the only place one would be written down. A flaw in a media player rarely makes anybody's emergency list, which is exactly why the unpatched copy is still there a year later.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.