The following is a list of vulnerabilities that we believe would've been avoided if the project in question had used libpathrs for file operations. For more information about the "strict" and "classic" path safety terms, see my FOSDEM 2026 talk on the topic.
This is not intended to speak ill of other projects (almost all languages provide substandard APIs for doing VFS operations and this is not an issue most people consider), but is instead intended to provide a justification for why this library exists and provides C APIs to maximise adoption.
If you know of any other issues that libpathrs would've protected against, feel free to open a PR!
These bugs were related to classic symlink traversal or similar time-of-check-time-of-use bugs. Most Unix programs are at risk of having bugs of this nature, and so we anticipate this list is much longer than given here.
- docker/docker#5656 (2014)
- CVE-2017-1002101
- CVE-2018-15664
- CVE-2019-16884
- CVE-2019-19921
- CVE-2021-30465
- CVE-2023-27561
- CVE-2023-28642
- CVE-2024-1753
- CVE-2024-45310
- CVE-2024-0132
- CVE-2024-0133
- CVE-2024-9676
- CVE-2024-12086, CVE-2024-12087, and CVE-2024-12088
- CVE-2024-12747
- CVE-2025-31133
- CVE-2025-52565
- CVE-2026-33711
- CVE-2026-33897
- CVE-2026-33945
- CVE-2026-39860
- CVE-2026-29518 and CVE-2026-43619
- RedSun and BlueHammer (2026) -- These vulnerabilities were in Windows (which libpathrs does not yet support) and usage of libpathrs itself would not have avoided the issue, but being forced to write file-handle-based code (which libpathrs does) would've avoided it.
These bugs are more specific than "classic" path safety, and usually involve a
privileged process operating on pseudofilesystems like /proc in a context
where an attacker may be able to modify the mount table of the process. This is
primarily a container-runtime-specific issue and most people probably consider
protecting against this to be a paranoid level of hardening.