Summary
A critical path traversal vulnerability in gvproxy's unauthenticated expose endpoint allows a caller to supply an attacker-controlled socket path. Under conditions where the endpoint can reach host filesystem paths, this may allow deletion of arbitrary files on the host system.
A critical path traversal vulnerability in gvproxy's unauthenticated expose endpoint allows a caller to supply an attacker-controlled socket path. Under conditions where the endpoint can reach host filesystem paths, this may allow deletion of arbitrary files on the host system.
Affected context
The vulnerability occurs in gvproxy, the network forwarder provided by the gvisor-tap-vsock package, when its /services/forwarder/expose endpoint processes caller-supplied socket paths without adequately restricting them to an intended directory or resource set. Deployments are most exposed when the endpoint is reachable by untrusted network clients and the forwarding service has sufficient host filesystem privileges.
The vulnerability occurs in gvproxy, the network forwarder provided by the gvisor-tap-vsock package, when its /services/forwarder/expose endpoint processes caller-supplied socket paths without adequately restricting them to an intended directory or resource set. Deployments are most exposed when the endpoint is reachable by untrusted network clients and the forwarding service has sufficient host filesystem privileges.
Exploit preconditions
- Attack surface: The
/services/forwarder/exposeHTTP endpoint - Required access: Network reachability to the endpoint; authentication may not be required
- Trigger point: Processing a caller-supplied socket path during an expose request
- Why exploitation is possible: Insufficient path validation permits traversal outside the expected socket location, allowing file-removal behavior to target unintended host paths
- Attack surface: The
/services/forwarder/exposeHTTP endpoint - Required access: Network reachability to the endpoint; authentication may not be required
- Trigger point: Processing a caller-supplied socket path during an expose request
- Why exploitation is possible: Insufficient path validation permits traversal outside the expected socket location, allowing file-removal behavior to target unintended host paths
Why this happens
The underlying bug is improper restriction and validation of a user-controlled filesystem path. Path traversal sequences or equivalent path forms can cause the resolved location to escape the intended directory, mapping to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The insecure pattern is accepting a path from an unauthenticated request and using it for filesystem deletion without canonicalization, directory confinement, and an allowlisted resource policy.
The underlying bug is improper restriction and validation of a user-controlled filesystem path. Path traversal sequences or equivalent path forms can cause the resolved location to escape the intended directory, mapping to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The insecure pattern is accepting a path from an unauthenticated request and using it for filesystem deletion without canonicalization, directory confinement, and an allowlisted resource policy.
Potential impact
- Arbitrary files on the host may be deleted
- The gvproxy service could be disrupted or rendered unavailable
- Network forwarding and dependent workloads could be interrupted
- Host or application data could be lost
- Deletion of security-relevant files could weaken system protections
- Arbitrary files on the host may be deleted
- The gvproxy service could be disrupted or rendered unavailable
- Network forwarding and dependent workloads could be interrupted
- Host or application data could be lost
- Deletion of security-relevant files could weaken system protections
General mitigation guidance
Mitigation generally focuses on removing trust in caller-supplied filesystem paths and enforcing a narrow resource policy.
Common defensive patterns include:
- Restricting operations to server-generated socket identifiers rather than raw paths
- Canonicalizing paths and enforcing confinement within a dedicated directory
- Rejecting traversal components, symlink escapes, absolute paths, and unexpected path forms
- Applying strict request authorization and network exposure controls
- Running the forwarder with the minimum filesystem permissions required
- Using dedicated, isolated runtime directories with restrictive ownership and permissions
- Preferably avoiding deletion of arbitrary filesystem objects as part of a network-facing operation
Mitigation generally focuses on removing trust in caller-supplied filesystem paths and enforcing a narrow resource policy.
Common defensive patterns include:
- Restricting operations to server-generated socket identifiers rather than raw paths
- Canonicalizing paths and enforcing confinement within a dedicated directory
- Rejecting traversal components, symlink escapes, absolute paths, and unexpected path forms
- Applying strict request authorization and network exposure controls
- Running the forwarder with the minimum filesystem permissions required
- Using dedicated, isolated runtime directories with restrictive ownership and permissions
- Preferably avoiding deletion of arbitrary filesystem objects as part of a network-facing operation
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying filesystem deletion APIs that receive HTTP request parameters
- Code review checks for missing canonicalization, directory confinement, or allowlist validation
- Tests covering traversal sequences, absolute paths, symbolic links, and encoded path variants
- Web-service policy checks requiring authentication and restricted network exposure for administrative endpoints
- Runtime monitoring for unexpected file-removal events by the gvproxy process
Automated code review and application security tools may help identify untrusted data flows into filesystem operations.
Organizations can look for this class of issue through:
- Static analysis rules identifying filesystem deletion APIs that receive HTTP request parameters
- Code review checks for missing canonicalization, directory confinement, or allowlist validation
- Tests covering traversal sequences, absolute paths, symbolic links, and encoded path variants
- Web-service policy checks requiring authentication and restricted network exposure for administrative endpoints
- Runtime monitoring for unexpected file-removal events by the gvproxy process
Automated code review and application security tools may help identify untrusted data flows into filesystem operations.
Sources
| Source | Link |
|---|---|
| access. | access.redhat.com/ |
| bugzilla. | bugzilla.redhat.com/ |
| github. | github.com/ |
| redhat. | redhat.atlassian.net/ |
