Directory traversal in manifest path extraction in github.com/cloudflare/cfrpki

The core of the vulnerability lies within the ExtractPathManifest function, which improperly handles file paths. Specifically, it fails to adequately sanitize input, allowing the inclusion of relative directory traversal sequences (e.g., ../). An attacker could craft a malicious request containing a specially crafted path, such as ../../../../etc/passwd, to access files outside the intended directory. This could expose sensitive configuration data, private keys, or other critical system files. The potential blast radius depends on the permissions of the cfrpki process and the files accessible from its execution context. Successful exploitation could lead to complete system compromise.

Organizations using cfrpki in their certificate management infrastructure, particularly those deploying it in cloud environments or containerized applications, are at risk. Systems with weak file permissions or exposed certificate management endpoints are especially vulnerable.

• go / binary: Inspect cfrpki binary for the vulnerable ExtractPathManifest function. Use strings or objdump to search for the function name and related code. • go / supply-chain: Examine dependencies of Go projects using cfrpki. Use go list -m all to identify versions and check for vulnerable versions. • generic web: Monitor access logs for unusual file requests containing ../ sequences, especially targeting paths related to certificate management.

1. 2022-07-15Disclosure

   disclosure

1. Réservé2021-10-26
2. Publiée2022-07-15
3. Modifiée2026-02-04
4. EPSS mis à jour2026-04-02

The primary mitigation for CVE-2021-3907 is to upgrade to cfrpki version 1.4.4 or later. This version includes a fix that properly sanitizes file paths, preventing directory traversal attacks. If upgrading immediately is not feasible, consider implementing input validation on file paths used by cfrpki to restrict access to authorized directories. While a WAF might offer some protection, it's not a reliable substitute for patching the underlying vulnerability. There are no specific Sigma or YARA rules readily available for this vulnerability, as it's a code-level issue.