HackerOne Bug Bounty Disclosure: encoded-slash-traversal-in-the-ipfs-ipns-url-rewrite-escapes-the-configured-gateway-namespace

Report title Encoded slash traversal in the IPFS/IPNS URL rewrite escapes the configured gateway namespace

Report link

Date submitted 2026-09-14T20:11:32.634Z

A researcher found an unexpected path-handling problem in curl’s IPFS and IPNS URL support. Certain URL paths containing encoded slashes and directory-traversal sequences such as `%2f..%2f` could be decoded late in curl’s processing. This allowed the resulting request path to escape the gateway namespace that curl normally builds for IPFS content.

When curl is configured to use an authenticated private IPFS gateway, the crafted URL could cause curl to send a request to another path on the same gateway. In the researcher’s test, a request intended for an IPFS resource was transformed into a request for `/admin/config`, while still including the gateway’s `Authorization` header.

If the gateway or reverse proxy exposed sensitive routes on the same host, the response could potentially be returned to the application or user that invoked curl. The issue did not allow changing the destination host or port, and it depended on the gateway incorrectly allowing access to the escaped path.

The reported input used an IPFS URL similar to:

ipfs:// /%2f..%2f..%2f..%2f..%2fadmin/config

The encoded slashes were initially treated as ordinary characters. After curl performed its earlier path processing, the encoded separators were decoded and the `..` components were interpreted as directory traversal. The final HTTP request therefore reached `/admin/config` instead of remaining under the configured gateway path.

### Scope and Limitations

The issue affected curl’s IPFS/IPNS URL rewrite logic, introduced in curl 8.5.0 and present in the tested 8.22.0 release. Exploitation required an application to accept an attacker-controlled IPFS or IPNS URL and fetch it through an authenticated gateway.

This was not a general server-side vulnerability in every IPFS gateway. A gateway should independently validate and restrict incoming paths. The curl behavior nevertheless produced an unintended request outside the expected IPFS or IPNS namespace.

### Response from curl

curl’s security team agreed that the behavior should be corrected, but did not classify it as a curl security vulnerability. The team considered the gateway’s failure to protect sensitive routes the primary security issue, while acknowledging that curl was generating an unexpected request.

The researcher submitted a proposed fix through pull request [curl/curl#22944]( The HackerOne report was subsequently closed as **Informative** and disclosed publicly.

### Recommended Protection

Applications should avoid passing untrusted IPFS or IPNS URLs directly to authenticated gateways without validation. Gateways and reverse proxies should reject directory-traversal sequences after decoding the URL, enforce strict namespace boundaries, and ensure that administrative endpoints are not reachable through the content gateway.

Users should also apply the relevant curl update once the fix is included in an official release.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

HackerOne report summary

Programme

Profile

Report title Encoded slash traversal in the IPFS/IPNS URL rewrite escapes the configured gateway namespace

Report link

Date submitted 2026-09-14T20:11:32.634Z

A researcher found an unexpected path-handling problem in curl’s IPFS and IPNS URL support. Certain URL paths containing encoded slashes and directory-traversal sequences such as `%2f..%2f` could be decoded late in curl’s processing. This allowed the resulting request path to escape the gateway namespace that curl normally builds for IPFS content.

When curl is configured to use an authenticated private IPFS gateway, the crafted URL could cause curl to send a request to another path on the same gateway. In the researcher’s test, a request intended for an IPFS resource was transformed into a request for `/admin/config`, while still including the gateway’s `Authorization` header.

If the gateway or reverse proxy exposed sensitive routes on the same host, the response could potentially be returned to the application or user that invoked curl. The issue did not allow changing the destination host or port, and it depended on the gateway incorrectly allowing access to the escaped path.

The reported input used an IPFS URL similar to:

ipfs:// /%2f..%2f..%2f..%2f..%2fadmin/config

The encoded slashes were initially treated as ordinary characters. After curl performed its earlier path processing, the encoded separators were decoded and the `..` components were interpreted as directory traversal. The final HTTP request therefore reached `/admin/config` instead of remaining under the configured gateway path.

### Scope and Limitations

The issue affected curl’s IPFS/IPNS URL rewrite logic, introduced in curl 8.5.0 and present in the tested 8.22.0 release. Exploitation required an application to accept an attacker-controlled IPFS or IPNS URL and fetch it through an authenticated gateway.

This was not a general server-side vulnerability in every IPFS gateway. A gateway should independently validate and restrict incoming paths. The curl behavior nevertheless produced an unintended request outside the expected IPFS or IPNS namespace.

### Response from curl

curl’s security team agreed that the behavior should be corrected, but did not classify it as a curl security vulnerability. The team considered the gateway’s failure to protect sensitive routes the primary security issue, while acknowledging that curl was generating an unexpected request.

The researcher submitted a proposed fix through pull request [curl/curl#22944]( The HackerOne report was subsequently closed as **Informative** and disclosed publicly.

### Recommended Protection

Applications should avoid passing untrusted IPFS or IPNS URLs directly to authenticated gateways without validation. Gateways and reverse proxies should reject directory-traversal sequences after decoding the URL, enforce strict namespace boundaries, and ensure that administrative endpoints are not reachable through the content gateway.

Users should also apply the relevant curl update once the fix is included in an official release.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.