GHSA-crq5-92j2-j7wv: Path Traversal
The static content handlers ResourceService and WebjarService URL decode each path segment and then reject only segments that are exactly "", ".", or "..". A percent-encoded separator (%2F) lets an attacker smuggle a ../ segment past that filter and escape the configured base, reading resources that should not be public.
On Windows, a similar attack exists with (%5C).
Impact
Disclosure of classpath or webjar resources outside the configured base.
Preconditions
- Application uses ResourceService (with a non-root base path) or WebjarService - At least one classpath entry is served from a directory (e.g. sbt run, exploded .war) - Backend forwards %2F/%5C without normalizing (e.g., Ember, Blaze)
Fixes
The patch rejects any decoded path segment containing / (%2F) or \ (%5C) with a 400 Bad Request in ResourceService and WebjarService.
FileService was not exploitable, but the same guards are applied for consistency and to remove its reliance on path normalization.
Workarounds
- Deploy as a fat jar, with no filesystem directories on the classpath. - Front the service with a proxy that rejects/normalizes %2F and %5C in the request path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.http4s:http4s-server_2.13to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-server_3to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-server_3to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-server_2.13to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-server_2.12to a version that resolves this vulnerability.Fixed in 0.23.35 - Configuration
Update/enable the guard behavior in ResourceService and WebjarService so that after URL-decoding, any path segment containing '/' (%2F) or '\' (%5C) is rejected with 400 Bad Request.
ResourceService and WebjarService (static content handlers) decoded path segment validation for separator characters = Reject any decoded path segment containing '/' (%2F) or '\' (%5C) with 400 Bad Request - Configuration
Ensure ResourceService and WebjarService URL decode each path segment and then reject segments that are exactly "", ".", or ".."; additionally, apply the patch behavior to reject any decoded segment containing '/' (%2F) or '\' (%5C) with 400 Bad Request.
ResourceService and WebjarService (static content handlers) rejected path segments = Reject only segments exactly "", ".", or ".." after URL-decoding (and apply additional /,%2F and \,%5C segment rejection per patch) - Configuration
Apply the same decoded path segment guards used by ResourceService and WebjarService to FileService (including rejecting exactly "", ".", or ".."), removing reliance on path normalization.
FileService (static content handler) consistency guard for path segment validation = Apply the same guards as ResourceService/WebjarService - Compensating control
Front the service with a proxy that rejects or normalizes %2F and %5C in the request path (so encoded path separators cannot be used to smuggle ../ outside the configured base).
- Compensating control
Deploy as a fat jar with no filesystem directories on the classpath (avoid serving classpath entries from directories).
- Compensating control
If the application does not require it, ensure it is not using ResourceService (with a non-root base path) or WebjarService for static content outside the configured base.
Event History
Frequently Asked Questions
Which deployments are actually exposed to this issue?
Exposure requires use of ResourceService with a non-root base path or WebjarService, plus at least one classpath entry served from a filesystem directory, such as during sbt run or from an exploded WAR. The backend must also forward encoded separators without normalizing them, as Ember and Blaze can do.
What does an attacker need to exploit it?
An unauthenticated network attacker must be able to send a request containing a percent-encoded path separator, such as %2F or, on Windows, %5C. The vulnerable static-content handler must process that request under the affected deployment conditions.
What information can be exposed?
The issue can disclose classpath or webjar resources located outside the configured static-content base. The described impact is disclosure; integrity and availability impact are not identified.
What can be done if the patch cannot be applied immediately?
Deploy the application as a fat JAR with no filesystem directories on the classpath, or place it behind a proxy that rejects or normalizes %2F and %5C in request paths. These mitigations address the encoded-separator condition used for traversal.
Is FileService affected?
FileService was not exploitable according to the advisory. It received the same guards for consistency and to avoid relying on path normalization.