CVE-2025-9809: Critical Out-of-Bounds Write in libretro-common

CVE-2025-9809 is a critical (9.8, CVSS 3.1) out-of-bounds write in libretro-common's cdfs_open_cue_track, triggered by a crafted .cue file with an over-long path. The upstream issue was closed as fixed by pull request 226 in April 2026. Update any copy you bundle.

What's affected

The record lists libretro libretro-common, "latest" at the time of the report, on all platforms. It names no version numbers. libretro-common is a shared C library, so the real exposure is every program that bundles or links a copy of its cdfs code and opens .cue files from untrusted sources.

The description says a file path inside a .cue file that is longer than PATH_MAX_LENGTH is copied with memcpy into a fixed-size buffer. The record scores it 9.8 critical with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no privileges, no user interaction. A .cue file is a local file format, so how "remote" this is in practice depends on whether your program accepts such files from outside, for example by download.

Fixed versions: the upstream issue page we fetched shows the issue closed as completed by pull request 226 on 7 April 2026. We could not confirm a tagged release number, because libretro-common is normally consumed as source rather than versioned packages. Check which commit your copy is on and whether it includes that change.

The record does not mark this as exploited, and the CVE is not in the CISA Known Exploited Vulnerabilities catalog. The issue text describes a crafted file as enough to trigger the overflow; we are not repeating details of it here.

How to check if you're exposed

Find every place a copy of the file exists in your source trees and build dependencies.

find . -type f -name cdfs.c 2>/dev/null
grep -rn "current_track_path" --include=cdfs.c .

If you find a copy, read the code around the line the issue points to. The vulnerable pattern copies a length taken from the source string rather than the size of the destination buffer. If the copy is not bounded by the destination size, or the buffer is not null terminated afterwards, your copy predates the fix.

If you consume libretro-common through another project, such as an emulator frontend or a core, look at that project's changelog for an update that pulls in the upstream change.

What to do now

1. Inventory every project and image that includes libretro-common, including vendored copies and git submodules.
2. Update each copy to a commit that includes pull request 226, or to a release of the downstream project that says it does.
3. Until then, do not open .cue files from sources you do not trust, and do not offer file loading to unauthenticated users on a server.
4. Build with stack protection and address space randomisation enabled, which raise the cost of turning an overflow into code execution.
5. Add a check to your build that fails if a bounded copy is replaced by an unbounded one in vendored code.
6. Record the change in your software bill of materials so the next scan is accurate.

Why it matters

The class is CWE-787, out-of-bounds write. Copying a string into a fixed buffer using the length of the source, not the size of the destination, is one of the oldest memory safety mistakes in C. The issue's own suggested fix is to limit the copy to the buffer size minus one and ensure null termination.

Libraries like this are the hard case for vulnerability management. The code was copied into other projects, so there is no single package to bump. A scanner that only reads package manifests will miss vendored copies, which is why an inventory of source level dependencies matters.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• libretro-common issue 222
• cdfs.c source file
• Gold vulnerability page
• Free in-browser dependency scan

Last reviewed: 18 October 2026.