Summary
An unauthenticated path traversal vulnerability in Group-Office's compress.php endpoint allows remote attackers to read files outside the intended cache directory. The issue becomes risky when user-controlled path input is appended to a filesystem path without effective canonicalization and containment checks.
An unauthenticated path traversal vulnerability in Group-Office's compress.php endpoint allows remote attackers to read files outside the intended cache directory. The issue becomes risky when user-controlled path input is appended to a filesystem path without effective canonicalization and containment checks.
Affected context
The vulnerability occurs in Group-Office deployments using the affected compress.php functionality. The endpoint accepts a file parameter and uses it to construct a path for file retrieval; risk exists when traversal sequences are not rejected and the resulting path is not constrained to an approved directory. No authenticated session may be required to reach the affected request path.
The vulnerability occurs in Group-Office deployments using the affected compress.php functionality. The endpoint accepts a file parameter and uses it to construct a path for file retrieval; risk exists when traversal sequences are not rejected and the resulting path is not constrained to an approved directory. No authenticated session may be required to reach the affected request path.
Exploit preconditions
- Attack surface: The publicly reachable
compress.phpHTTP endpoint - Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Server-side processing of the user-controlled
fileparameter - Why exploitation is possible: Input is incorporated into a filesystem path without sufficient traversal prevention and directory-boundary validation
- Attack surface: The publicly reachable
compress.phpHTTP endpoint - Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Server-side processing of the user-controlled
fileparameter - Why exploitation is possible: Input is incorporated into a filesystem path without sufficient traversal prevention and directory-boundary validation
Why this happens
The underlying bug is improper limitation of a pathname to a restricted directory, which maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The application treats externally supplied path components as trusted filesystem locations and passes the resulting path to a file-reading operation without reliably normalizing it and verifying that it remains within the intended base directory.
The underlying bug is improper limitation of a pathname to a restricted directory, which maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The application treats externally supplied path components as trusted filesystem locations and passes the resulting path to a file-reading operation without reliably normalizing it and verifying that it remains within the intended base directory.
Potential impact
- Attackers may read sensitive operating-system or application files.
- Exposed files could disclose credentials, configuration values, or session-related data.
- Retrieved information could support further compromise of the application or host.
- The vulnerability could increase the impact of other weaknesses through information disclosure.
- Attackers may read sensitive operating-system or application files.
- Exposed files could disclose credentials, configuration values, or session-related data.
- Retrieved information could support further compromise of the application or host.
- The vulnerability could increase the impact of other weaknesses through information disclosure.
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied path values and enforcing filesystem boundaries.
Common defensive patterns include:
- Resolve candidate paths against a fixed base directory and verify the canonical result remains inside that directory.
- Prefer server-side identifiers or an allowlisted set of files over client-supplied filesystem paths.
- Reject traversal syntax and invalid path forms as an additional defense, rather than relying on filtering alone.
- Use filesystem APIs that separate resource identifiers from raw path construction.
- Run the application with only the filesystem permissions required for its function.
- Avoid exposing sensitive files through web-accessible endpoints and apply authentication or authorization where appropriate.
Mitigation generally focuses on reducing trust in user-supplied path values and enforcing filesystem boundaries.
Common defensive patterns include:
- Resolve candidate paths against a fixed base directory and verify the canonical result remains inside that directory.
- Prefer server-side identifiers or an allowlisted set of files over client-supplied filesystem paths.
- Reject traversal syntax and invalid path forms as an additional defense, rather than relying on filtering alone.
- Use filesystem APIs that separate resource identifiers from raw path construction.
- Run the application with only the filesystem permissions required for its function.
- Avoid exposing sensitive files through web-accessible endpoints and apply authentication or authorization where appropriate.
How teams detect issues like this
Detection approaches can include:
- Static analysis rules for concatenating request parameters with filesystem paths or passing them to file-reading APIs.
- Code review checks for missing canonicalization, directory-boundary validation, and allowlists.
- Dynamic testing with traversal variants to verify that requests cannot escape the approved resource directory.
- Web-server and application-log monitoring for repeated traversal indicators and unusual file retrieval responses.
- Policy enforcement requiring security review for endpoints that map HTTP parameters to local files.
Automated application-security and code-review tools may help identify these patterns, but findings should be validated against deployment-specific path handling.
Detection approaches can include:
- Static analysis rules for concatenating request parameters with filesystem paths or passing them to file-reading APIs.
- Code review checks for missing canonicalization, directory-boundary validation, and allowlists.
- Dynamic testing with traversal variants to verify that requests cannot escape the approved resource directory.
- Web-server and application-log monitoring for repeated traversal indicators and unusual file retrieval responses.
- Policy enforcement requiring security review for endpoints that map HTTP parameters to local files.
Automated application-security and code-review tools may help identify these patterns, but findings should be validated against deployment-specific path handling.
Sources
| Source | Link |
|---|---|
| cxsecurity. | cxsecurity.com/ |
| github. | github.com/ |
| group-office. | group-office.com/ |
| vulncheck. | vulncheck.com/ |
