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

### What Was Reported

A researcher found that curl’s IPFS and IPNS URL handling could be tricked into requesting a path outside the gateway namespace configured by the user.

The issue affected curl versions beginning with 8.5.0, including version 8.22.0 and the then-current development code. It involved specially crafted URLs containing URL-encoded slash characters and directory traversal sequences such as `%2f..%2f`.

### How the Issue Worked

When curl processes an IPFS or IPNS URL, it converts that URL into a request to an HTTP gateway. The intended result is a URL under a configured gateway path, such as:

/private/gateway/ipfs/ /file

The problematic input encoded the slashes in a traversal sequence. Curl performed some path cleanup before decoding those encoded slashes. As a result, the traversal markers became active only later in the URL-processing pipeline.

The final URL parser then removed the `..` components, allowing the request to move above the intended gateway and IPFS namespace. In the researcher’s test, a URL intended to access IPFS content was transformed into a request for:

### Demonstrated Impact

The researcher configured a local test gateway under `/private/gateway` and supplied curl with an Authorization header. A crafted IPFS URL caused curl to request `/admin/config` on the same server while retaining the authentication header.

This means that, in a particular application design, an attacker who can control an IPFS or IPNS URL could potentially cause the application to make an authenticated request to another path on the gateway’s host. If that path exposed sensitive information, the response could be returned to the attacker.

The issue does not allow changing the destination hostname or port. It also does not automatically expose an IPFS node’s administrative interface. The impact depends on an application using curl to fetch untrusted IPFS/IPNS URLs through an authenticated gateway that has other sensitive routes on the same origin.

### Conditions Required for Exploitation

Successful exploitation required several conditions:

An application had to accept an attacker-controlled IPFS or IPNS URL.

The application had to use curl to retrieve that URL.

The curl request had to go through an authenticated HTTP gateway.

The gateway had to expose another sensitive route on the same host and port.

The gateway or reverse proxy had to return the response to the requesting application or user.

Without these conditions, the issue would generally result only in curl sending an unexpected path to the gateway.

Curl’s security team classified the report as **Informative**, rather than as a security vulnerability in curl itself.

The team’s reasoning was that an HTTP gateway receives arbitrary paths from clients and is responsible for enforcing its own access controls. If the gateway returns sensitive data for an unexpected path, that behavior is primarily considered a gateway or server-side security problem.

However, curl’s maintainer agreed that the URL rewrite behavior was unintended and should be corrected. The researcher subsequently submitted a proposed fix in pull request [#22944](

### Security Takeaway

The report highlights the risks of performing URL decoding and path normalization in the wrong order. Encoded separators can become structural path characters after an initial security check has already taken place.

Applications that fetch user-controlled IPFS or IPNS URLs should not rely solely on curl or the gateway to enforce isolation. They should validate schemes and paths, restrict requests to approved gateway namespaces, avoid forwarding sensitive credentials unnecessarily, and ensure that private administrative routes are not accessible through the same origin as public gateway content.

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

### What Was Reported

A researcher found that curl’s IPFS and IPNS URL handling could be tricked into requesting a path outside the gateway namespace configured by the user.

The issue affected curl versions beginning with 8.5.0, including version 8.22.0 and the then-current development code. It involved specially crafted URLs containing URL-encoded slash characters and directory traversal sequences such as `%2f..%2f`.

### How the Issue Worked

When curl processes an IPFS or IPNS URL, it converts that URL into a request to an HTTP gateway. The intended result is a URL under a configured gateway path, such as:

/private/gateway/ipfs/ /file

The problematic input encoded the slashes in a traversal sequence. Curl performed some path cleanup before decoding those encoded slashes. As a result, the traversal markers became active only later in the URL-processing pipeline.

The final URL parser then removed the `..` components, allowing the request to move above the intended gateway and IPFS namespace. In the researcher’s test, a URL intended to access IPFS content was transformed into a request for:

### Demonstrated Impact

The researcher configured a local test gateway under `/private/gateway` and supplied curl with an Authorization header. A crafted IPFS URL caused curl to request `/admin/config` on the same server while retaining the authentication header.

This means that, in a particular application design, an attacker who can control an IPFS or IPNS URL could potentially cause the application to make an authenticated request to another path on the gateway’s host. If that path exposed sensitive information, the response could be returned to the attacker.

The issue does not allow changing the destination hostname or port. It also does not automatically expose an IPFS node’s administrative interface. The impact depends on an application using curl to fetch untrusted IPFS/IPNS URLs through an authenticated gateway that has other sensitive routes on the same origin.

### Conditions Required for Exploitation

Successful exploitation required several conditions:

An application had to accept an attacker-controlled IPFS or IPNS URL.

The application had to use curl to retrieve that URL.

The curl request had to go through an authenticated HTTP gateway.

The gateway had to expose another sensitive route on the same host and port.

The gateway or reverse proxy had to return the response to the requesting application or user.

Without these conditions, the issue would generally result only in curl sending an unexpected path to the gateway.

Curl’s security team classified the report as **Informative**, rather than as a security vulnerability in curl itself.

The team’s reasoning was that an HTTP gateway receives arbitrary paths from clients and is responsible for enforcing its own access controls. If the gateway returns sensitive data for an unexpected path, that behavior is primarily considered a gateway or server-side security problem.

However, curl’s maintainer agreed that the URL rewrite behavior was unintended and should be corrected. The researcher subsequently submitted a proposed fix in pull request [#22944](

### Security Takeaway

The report highlights the risks of performing URL decoding and path normalization in the wrong order. Encoded separators can become structural path characters after an initial security check has already taken place.

Applications that fetch user-controlled IPFS or IPNS URLs should not rely solely on curl or the gateway to enforce isolation. They should validate schemes and paths, restrict requests to approved gateway namespaces, avoid forwarding sensitive credentials unnecessarily, and ensure that private administrative routes are not accessible through the same origin as public gateway content.

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.