Description

CefSharp provides .NET bindings for the Chromium Embedded Framework for Windows Forms and Windows Presentation Foundation applications. Prior to version 148.0.90, CefSharp/SchemeHandler/FolderSchemeHandlerFactory.cs used filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) to decide whether a decoded and canonicalized request path remained inside rootFolder. That raw prefix test did not enforce a directory boundary, so a request such as ..%2fwww2/secret.txt could escape a configured www directory into a sibling www2 directory whose path shared the same string prefix. Applications that register FolderSchemeHandlerFactory for a custom scheme or an HTTP or HTTPS scheme can therefore serve local files outside the intended root when an attacker can cause the embedded browser to request the crafted URL. The issue affects both Unix-style paths such as /tmp/app/www2 and Windows paths such as C:\app\www2, and the fix appends a directory separator to the normalized root before comparison while rejecting null bytes and alternate data stream syntax. This issue is fixed in version 148.0.90.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-18T22:16:52.280Z",
  "pubdate": "2026-08-18T22:16:52.280Z",
  "executiveSummary": "A path traversal vulnerability exists in CefSharp prior to version 148.0.90, specifically within the folder scheme handling implementation. The vulnerability stems from improper validation of request paths against the designated root directory.\nAn unauthenticated attacker can exploit this flaw by supplying a crafted URL containing directory traversal sequences and URL-encoded characters, such as ..%2fwww2/secret.txt, to bypass intended directory restrictions.\nSuccessful exploitation allows the embedded browser to read local files residing outside the configured web root, potentially exposing sensitive system or application data to unauthorized users.\nThe issue impacts applications utilizing Windows Forms or Windows Presentation Foundation that register FolderSchemeHandlerFactory for custom, HTTP, or HTTPS schemes.\nRisk implications include unauthorized file disclosure across both Unix-style and Windows file systems, requiring remediation through software updates or strict path sanitization controls.",
  "technicalDetails": "The vulnerability resides in the CefSharp/SchemeHandler/FolderSchemeHandlerFactory.cs component of CefSharp prior to version 148.0.90.\nThe root cause of the flaw is the reliance on a raw string prefix check via filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) to determine whether a decoded and canonicalized request path remains contained within the designated rootFolder.\nBecause the check is performed as a raw string comparison without enforcing a directory boundary, a prefix collision occurs when a sibling directory shares the same starting string as the root folder (for example, /tmp/app/www versus /tmp/app/www2, or C:\\app\\www versus C:\\app\\www2).\nAn attacker triggers the vulnerability by causing the embedded browser to request a maliciously crafted URL containing directory traversal sequences and URL encoding, such as ..%2fwww2/secret.txt.\nThe attack flow proceeds as follows: First, the attacker crafts a request utilizing traversal sequences designed to escape the intended directory. Second, the embedded browser submits the request to the application utilizing FolderSchemeHandlerFactory. Third, the vulnerable component processes the path and evaluates the string prefix against rootFolder using the flawed StartsWith logic. Fourth, because the string shares the correct prefix despite crossing a directory boundary, the validation check incorrectly evaluates to true. Finally, the application serves the requested local file from outside the intended root directory.\nThe vulnerability affects both Unix-style paths and Windows paths. The conditions for exploitation require the application to register FolderSchemeHandlerFactory for a custom scheme or an HTTP/HTTPS scheme, and the attacker must be able to cause the embedded browser to request the crafted URL.\nPost-exploitation impact includes the unauthorized disclosure of sensitive local files accessible to the application security context, which may include configuration files, source code, or system data."
}