### Summary `FolderSchemeHandlerFactory` was intended to restrict served files to a configured `rootFolder`, but its path validation used a raw string prefix check. A request could escape to a sibling directory whose full path starts with the root folder path, allowing files outside the configured root to be served. ### Details In affected versions, `FolderSchemeHandlerFactory` canonicalized `rootFolder`, decoded the request path, combined it with the root, and then allowed the file when: ```csharp filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) ``` This does not enforce a directory boundary. For example, `/tmp/app/www2/secret.txt` starts with `/tmp/app/www`, but `www2` is a sibling of `www`, not a child. The same issue applies on Windows, for example `C:\app\www2\secret.txt` starts with `C:\app\www`. The affected code was reviewed at commit `b5fef3bb4bc58798c95170078c41de92cfe9066e`, assembly version `147.0.100`. ### PoC Set `rootFolder` to a directory named `www` and create a sibling directory named `www2`: ```text <temp>/www/index.html <temp>/www2/secret.txt ``` Register `FolderSchemeHandlerFactory` for `<temp>/www`, then request: ```text https://folderschemehandlerfactory.test/..%2fwww2/secret.txt ``` The request path is URL-decoded to `../www2/secret.txt`, combined with `<temp>/www`, and canonicalized to: ```text <temp>/www2/secret.txt ``` Because `<temp>/www2/secret.txt` starts with `<temp>/www` as a string prefix, the affected check passes and `secret.txt` is served from outside `rootFolder`. Expected vulnerable result: HTTP 200 with the contents of `<temp>/www2/secret.txt`. Expected fixed result: 404 or equivalent not-found response because the resolved file is outside `rootFolder`. ### Impact Applications using `FolderSchemeHandlerFactory` for a custom scheme or registered HTTP/HTTPS scheme may expose local files outside the intended served directory. This is most relevant when sensitive sibling directories share the root path prefix, such as `www`/`www2`, `public`/`public_backup`, or `static`/`static-secrets`. An attacker must be able to cause the embedded browser to request URLs handled by the affected scheme registration.
### Summary `FolderSchemeHandlerFactory` was intended to restrict served files to a configured `rootFolder`, but its path validation used a raw string prefix check. A request could escape to a sibling directory whose full path starts with the root folder path, allowing files outside the configured root to be served. ### Details In affected versions, `FolderSchemeHandlerFactory` canonicalized `rootFolder`, decoded the request path, combined it with the root, and then allowed the file when: ```csharp filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) ``` This does not enforce a directory boundary. For example, `/tmp/app/www2/secret.txt` starts with `/tmp/app/www`, but `www2` is a sibling of `www`, not a child. The same issue applies on Windows, for example `C:\app\www2\secret.txt` starts with `C:\app\www`. The affected code was reviewed at commit `b5fef3bb4bc58798c95170078c41de92cfe9066e`, assembly version `147.0.100`. ### PoC Set `rootFolder` to a directory named `www` and create a sibling directory named `www2`: ```text <temp>/www/index.html <temp>/www2/secret.txt ``` Register `FolderSchemeHandlerFactory` for `<temp>/www`, then request: ```text https://folderschemehandlerfactory.test/..%2fwww2/secret.txt ``` The request path is URL-decoded to `../www2/secret.txt`, combined with `<temp>/www`, and canonicalized to: ```text <temp>/www2/secret.txt ``` Because `<temp>/www2/secret.txt` starts with `<temp>/www` as a string prefix, the affected check passes and `secret.txt` is served from outside `rootFolder`. Expected vulnerable result: HTTP 200 with the contents of `<temp>/www2/secret.txt`. Expected fixed result: 404 or equivalent not-found response because the resolved file is outside `rootFolder`. ### Impact Applications using `FolderSchemeHandlerFactory` for a custom scheme or registered HTTP/HTTPS scheme may expose local files outside the intended served directory. This is most relevant when sensitive sibling directories share the root path prefix, such as `www`/`www2`, `public`/`public_backup`, or `static`/`static-secrets`. An attacker must be able to cause the embedded browser to request URLs handled by the affected scheme registration.
Update CefSharp.Common to 148.0.90 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCefSharp.Common: `FolderSchemeHandlerFactory` path boundary check can expose files outside the configured root folder affects CefSharp.Common (nuget). Severity is medium. ### Summary `FolderSchemeHandlerFactory` was intended to restrict served files to a configured `rootFolder`, but its path validation used a raw string prefix check. A request could escape to a sibling directory whose full path starts with the root folder path, allowing files outside the configured root to be served. ### Details In affected versions, `FolderSchemeHandlerFactory` canonicalized `rootFolder`, decoded the request path, combined it with the root, and then allowed the file when: ```csharp filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) ``` This does not enforce a directory boundary. For example, `/tmp/app/www2/secret.txt` starts with `/tmp/app/www`, but `www2` is a sibling of `www`, not a child. The same issue applies on Windows, for example `C:\app\www2\secret.txt` starts with `C:\app\www`. The affected code was reviewed at commit `b5fef3bb4bc58798c95170078c41de92cfe9066e`, assembly version `147.0.100`. ### PoC Set `rootFolder` to a directory named `www` and create a sibling directory named `www2`: ```text <temp>/www/index.html <temp>/www2/secret.txt ``` Register `FolderSchemeHandlerFactory` for `<temp>/www`, then request: ```text https://folderschemehandlerfactory.test/..%2fwww2/secret.txt ``` The request path is URL-decoded to `../www2/secret.txt`, combined with `<temp>/www`, and canonicalized to: ```text <temp>/www2/secret.txt ``` Because `<temp>/www2/secret.txt` starts with `<temp>/www` as a string prefix, the affected check passes and `secret.txt` is served from outside `rootFolder`. Expected vulnerable result: HTTP 200 with the contents of `<temp>/www2/secret.txt`. Expected fixed result: 404 or equivalent not-found response because the resolved file is outside `rootFolder`. ### Impact Applications using `FolderSchemeHandlerFactory` for a custom scheme or registered HTTP/HTTPS scheme may expose local files outside the intended served directory. This is most relevant when sensitive sibling directories share the root path prefix, such as `www`/`www2`, `public`/`public_backup`, or `static`/`static-secrets`. An attacker must be able to cause the embedded browser to request URLs handled by the affected scheme registration.
AI coding agents often install or upgrade packages automatically in nuget. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| CefSharp.Commonnuget | <148.0.90 | 148.0.90 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate CefSharp.Common to 148.0.90 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCefSharp.Common: `FolderSchemeHandlerFactory` path boundary check can expose files outside the configured root folder affects CefSharp.Common (nuget). Severity is medium. ### Summary `FolderSchemeHandlerFactory` was intended to restrict served files to a configured `rootFolder`, but its path validation used a raw string prefix check. A request could escape to a sibling directory whose full path starts with the root folder path, allowing files outside the configured root to be served. ### Details In affected versions, `FolderSchemeHandlerFactory` canonicalized `rootFolder`, decoded the request path, combined it with the root, and then allowed the file when: ```csharp filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) ``` This does not enforce a directory boundary. For example, `/tmp/app/www2/secret.txt` starts with `/tmp/app/www`, but `www2` is a sibling of `www`, not a child. The same issue applies on Windows, for example `C:\app\www2\secret.txt` starts with `C:\app\www`. The affected code was reviewed at commit `b5fef3bb4bc58798c95170078c41de92cfe9066e`, assembly version `147.0.100`. ### PoC Set `rootFolder` to a directory named `www` and create a sibling directory named `www2`: ```text <temp>/www/index.html <temp>/www2/secret.txt ``` Register `FolderSchemeHandlerFactory` for `<temp>/www`, then request: ```text https://folderschemehandlerfactory.test/..%2fwww2/secret.txt ``` The request path is URL-decoded to `../www2/secret.txt`, combined with `<temp>/www`, and canonicalized to: ```text <temp>/www2/secret.txt ``` Because `<temp>/www2/secret.txt` starts with `<temp>/www` as a string prefix, the affected check passes and `secret.txt` is served from outside `rootFolder`. Expected vulnerable result: HTTP 200 with the contents of `<temp>/www2/secret.txt`. Expected fixed result: 404 or equivalent not-found response because the resolved file is outside `rootFolder`. ### Impact Applications using `FolderSchemeHandlerFactory` for a custom scheme or registered HTTP/HTTPS scheme may expose local files outside the intended served directory. This is most relevant when sensitive sibling directories share the root path prefix, such as `www`/`www2`, `public`/`public_backup`, or `static`/`static-secrets`. An attacker must be able to cause the embedded browser to request URLs handled by the affected scheme registration.
AI coding agents often install or upgrade packages automatically in nuget. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| CefSharp.Commonnuget | <148.0.90 | 148.0.90 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard