Summary
A path traversal vulnerability in Dancer2's File route handler can cause requests to access readable files outside the configured public_dir.
When the handler is explicitly enabled and static path filtering is disabled, an unauthenticated request may retrieve any file readable by the worker process, including sensitive application configuration.
Affected context
The vulnerability affects Dancer2 applications using the File route handler in versions where relative path segments are not normalized before file access checks. The risk arises when an application names File in route_handlers and sets static_handler to 0, allowing requests to reach the vulnerable handler. Files outside public_dir may be exposed when they are readable by the application worker.
Exploit preconditions
- Attack surface: HTTP request handling through the Dancer2 File route handler
- Required access: No authentication may be required if the affected route is publicly reachable
- Trigger point: A request path containing relative traversal segments that resolves outside
public_dir - Why exploitation is possible: The handler joins the request path to
public_dirwithout canonicalizing or constraining the resulting path before checking whether it is a readable regular file
Why this happens
The underlying bug is insufficient path canonicalization and boundary validation, mapping to CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The handler accepts attacker-controlled path components, combines them with the intended document root, and validates only the resulting file type and readability. Because relative segments are not collapsed and the final path is not verified to remain within public_dir, the configured directory boundary can be bypassed.
Potential impact
- Sensitive application configuration files could be disclosed
- Database credentials, API keys, or session secrets could be exposed
- Source code or deployment metadata could be retrieved
- Attackers could use disclosed information to target other application or infrastructure components
- Confidential user or operational data could be exposed if readable by the worker process
General mitigation guidance
Mitigation generally focuses on enforcing a trusted directory boundary before serving files.
Common defensive patterns include:
- Canonicalizing requested paths before performing file access
- Rejecting traversal components and encoded equivalents consistently
- Verifying that the canonical resolved path remains beneath the intended public directory
- Serving only explicitly mapped or allowlisted public assets
- Avoiding exposure of configuration, source, credential, and deployment files
- Running the worker process with least-privilege filesystem permissions
- Keeping the vulnerable File route disabled unless it is required and safely constrained
How teams detect issues like this
Organizations can look for path traversal risks through:
- Static analysis of file-serving code for direct joins between request paths and directories
- Code review checks for missing canonicalization and containment validation
- Tests using relative, encoded, and mixed-format path components
- Web-server and application logs containing traversal-like requests or unexpected file responses
- Policy enforcement that restricts public file serving to approved directories or asset maps
- Automated security review tools that identify uncontrolled filesystem paths
