Summary
OpenHop contains a path traversal vulnerability in unauthenticated flow routes that allows attacker-controlled identifiers to escape the configured flow directory. Depending on the route used, an attacker may read accessible YAML files or permanently delete accessible YAML files, potentially exposing secrets or disrupting services.
OpenHop contains a path traversal vulnerability in unauthenticated flow routes that allows attacker-controlled identifiers to escape the configured flow directory. Depending on the route used, an attacker may read accessible YAML files or permanently delete accessible YAML files, potentially exposing secrets or disrupting services.
Affected context
The issue affects OpenHop deployments where the server exposes the flow API routes without authentication and constructs filesystem paths from client-supplied identifiers. Risk is higher when the service is reachable over a network, when Docker binds it to all interfaces, or when permissive CORS allows an untrusted webpage to make requests to a loopback-bound instance.
The issue affects OpenHop deployments where the server exposes the flow API routes without authentication and constructs filesystem paths from client-supplied identifiers. Risk is higher when the service is reachable over a network, when Docker binds it to all interfaces, or when permissive CORS allows an untrusted webpage to make requests to a loopback-bound instance.
Exploit preconditions
- Attack surface: Unauthenticated
GET /api/flows/:idandDELETE /api/flows/:idendpoints - Required access: Network access to the OpenHop server, or browser access to a reachable loopback-bound instance
- Trigger point: A request identifier is decoded and passed to
FlowStore.filePath() - Why exploitation is possible: The identifier is not restricted by an allow-list, and path normalization can resolve it outside the configured flow directory
- Additional exposure factors: Broad CORS behavior and Docker deployments listening on
0.0.0.0may expand the reachable attack surface
- Attack surface: Unauthenticated
GET /api/flows/:idandDELETE /api/flows/:idendpoints - Required access: Network access to the OpenHop server, or browser access to a reachable loopback-bound instance
- Trigger point: A request identifier is decoded and passed to
FlowStore.filePath() - Why exploitation is possible: The identifier is not restricted by an allow-list, and path normalization can resolve it outside the configured flow directory
- Additional exposure factors: Broad CORS behavior and Docker deployments listening on
0.0.0.0may expand the reachable attack surface
Why this happens
The vulnerability results from using a user-controlled route parameter in filesystem path construction without enforcing a constrained identifier format or verifying the resolved path remains within the intended directory. URL decoding followed by path normalization permits traversal components to alter the final filesystem location, which maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The same flaw affects both read and delete operations, creating confidentiality and availability risks.
The vulnerability results from using a user-controlled route parameter in filesystem path construction without enforcing a constrained identifier format or verifying the resolved path remains within the intended directory. URL decoding followed by path normalization permits traversal components to alter the final filesystem location, which maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The same flaw affects both read and delete operations, creating confidentiality and availability risks.
Potential impact
- An attacker may read accessible YAML files outside the configured flow directory
- Sensitive configuration data or secrets may be disclosed
- An attacker may permanently delete accessible
.yamlfiles - Dependent services may be disrupted by removal of required flow definitions
- Browser-based attacks may succeed against exposed local instances when cross-origin requests are permitted
- An attacker may read accessible YAML files outside the configured flow directory
- Sensitive configuration data or secrets may be disclosed
- An attacker may permanently delete accessible
.yamlfiles - Dependent services may be disrupted by removal of required flow definitions
- Browser-based attacks may succeed against exposed local instances when cross-origin requests are permitted
General mitigation guidance
Mitigation typically focuses on reducing trust in route parameters and enforcing filesystem boundaries.
Common defensive patterns include:
- Accepting only opaque, allow-listed flow identifiers rather than filesystem-like paths
- Resolving candidate paths and verifying they remain within the intended directory before any file operation
- Rejecting encoded traversal sequences and unexpected separators at the validation boundary
- Applying authentication and authorization to read and delete routes
- Restricting CORS to explicitly trusted origins instead of reflecting arbitrary origins
- Binding services only to required interfaces and limiting container network exposure
- Running the process with least-privilege filesystem permissions
- Separating sensitive configuration files from directories reachable by application flow operations
Mitigation typically focuses on reducing trust in route parameters and enforcing filesystem boundaries.
Common defensive patterns include:
- Accepting only opaque, allow-listed flow identifiers rather than filesystem-like paths
- Resolving candidate paths and verifying they remain within the intended directory before any file operation
- Rejecting encoded traversal sequences and unexpected separators at the validation boundary
- Applying authentication and authorization to read and delete routes
- Restricting CORS to explicitly trusted origins instead of reflecting arbitrary origins
- Binding services only to required interfaces and limiting container network exposure
- Running the process with least-privilege filesystem permissions
- Separating sensitive configuration files from directories reachable by application flow operations
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis rules identifying request parameters passed into path-joining or file-operation APIs
- Code review checks for missing identifier allow-lists and canonical-path boundary validation
- Tests using encoded separators, traversal markers, and nested path segments to verify rejection
- Runtime monitoring for abnormal access or deletion attempts involving paths outside the configured data directory
- Policy checks requiring authentication for destructive endpoints and restricting CORS origins
- Automated security review tools that flag tainted data flows from HTTP routes into filesystem APIs
Organizations can detect this class of issue through:
- Static analysis rules identifying request parameters passed into path-joining or file-operation APIs
- Code review checks for missing identifier allow-lists and canonical-path boundary validation
- Tests using encoded separators, traversal markers, and nested path segments to verify rejection
- Runtime monitoring for abnormal access or deletion attempts involving paths outside the configured data directory
- Policy checks requiring authentication for destructive endpoints and restricting CORS origins
- Automated security review tools that flag tainted data flows from HTTP routes into filesystem APIs
