VLC Media Player Hit by Two Memory Corruption Flaws Exploitable via Malicious PNG and Rogue RealRTSP Server
VLC media player contains two memory corruption vulnerabilities that can be triggered without any special configuration or plugins.
The more severe flaw, CVE-2026-56711, received an 8.6 CVSS 4.0 score. It is caused by an integer overflow during buffer-size calculation for PNG images. An attacker can supply an image with abnormally large width and height values, forcing VLC to allocate an undersized memory region and then write data beyond its boundaries. The vulnerability activates when a malicious PNG is opened directly or referenced inside a playlist.
The second issue, CVE-2026-73324, carries a 6.9 CVSS score and affects the RealRTSP module. A malicious server can return a response string longer than 4096 bytes that lacks a terminating null character. As a result, VLC continues reading memory past the intended buffer, potentially disclosing adjacent data to the attacker-controlled server.
Both vulnerabilities impact official VideoLAN builds of VLC versions 3.0.0 through 3.0.23. Some Linux distributions may ship the player without the RealRTSP module enabled. Until patched versions are released, users should refrain from opening images or playlists from untrusted sources and avoid connecting to unknown RealRTSP streams.
Related articles
Fuzzy Logic in Cybersecurity: Reducing Vulnerability Queue by 7.5 Times with CVSS, EPSS and FSTEC Comparison
An information security specialist has developed a fuzzy logic system that prioritizes vulnerabilities far more effectively than traditional scoring methods. The approach uses linguistic variables and membership functions to handle the inherent uncertainty in exploitability and impact assessments. By integrating EPSS probability data with CVSS impact scores and vulnerability age, the model reduces the actionable backlog by a factor of 7.5. The implementation relies on the Mamdani inference algorithm and trapezoidal membership functions to produce smooth, human-interpretable urgency ratings. Detailed coverage checks and rule-base validation ensure no gaps exist in the decision space. Real-world testing on CVE-2025-49113 in Roundcube Webmail demonstrated practical advantages over rigid threshold logic. The method is positioned as a practical enhancement rather than a replacement for existing standards.
September Windows 11 Security Update KB5124008 Breaks Always On VPN Certificate Authentication
The September security update KB5124008 for Windows 11 has introduced a regression that disables Always On VPN connections using certificate-based authentication. The issue affects devices running Windows 11 versions 24H2 and 25H2 that connect to Remote Routing and Access Service (RRAS) and Network Policy Server (NPS) instances on Windows Server 2019. VPN profiles deployed via Microsoft Intune are impacted, with the failure occurring during the certificate negotiation phase of the IPsec connection. Users confirm the problem is reproducible: the VPN works before the patch, stops after installation, and resumes after patch removal and reboot. Microsoft has not yet acknowledged the regression or released a fix, leaving administrators to pause deployment through WSUS or Intune and open support cases with client and NPS logs. A potential workaround involves switching profiles to EAP-TLS, though its reliability remains unconfirmed.
API Token Lifecycle: From Issuance to Revocation and Secure Management
The article provides a comprehensive examination of the full API token lifecycle in browser-based applications, emphasizing that signatures alone cannot prevent token theft. It details risks introduced at issuance, storage, transmission, and revocation stages, including improper OAuth grant types and long-lived tokens. Key recommendations include short-lived access tokens, atomic refresh token rotation, and the use of Authorization Code Flow with PKCE for public clients. Storage advice strongly discourages localStorage and sessionStorage in favor of HttpOnly cookies or a Backend-for-Frontend pattern that keeps real tokens on the server. The piece also covers CSRF protections, rate limiting on authorization endpoints, and the advantages of signed client assertions over static secrets. Overall, it stresses that token security depends on the entire lifecycle architecture rather than cryptographic strength alone.
PKCE Becomes Mandatory for OAuth Public Clients as RFC 9700 and OAuth 2.1 Close Authorization Code Interception Risks
PKCE, or Proof Key for Code Exchange, was introduced in RFC 7636 to prevent code interception attacks in OAuth 2.0 flows used by mobile and single-page applications. The mechanism generates a code_verifier and derives a code_challenge using S256 hashing to bind the authorization code to the original client session. Without PKCE, malicious apps on the same device can hijack custom URI schemes like myapp://callback and exchange stolen codes for access tokens. RFC 9700, published in January 2025, now mandates PKCE for public clients and recommends it for confidential ones while requiring S256 over the weaker plain method. The upcoming OAuth 2.1 draft further embeds PKCE into the core authorization code flow and removes implicit and resource owner password credentials grants. Major providers including Auth0, Okta, and Microsoft Entra ID show varying default support, highlighting the need for explicit S256 implementation. The standard also protects against code injection attacks even when client secrets are present.