Summary
A path traversal vulnerability in SOCFortress CoPilot allows an authorized administrator or analyst to influence the destination of a generated GCP ScoutSuite report through a multipart filename. Under affected configurations, this may write accepted JSON content outside the intended report directory and overwrite host files, potentially disrupting application operation.
A path traversal vulnerability in SOCFortress CoPilot allows an authorized administrator or analyst to influence the destination of a generated GCP ScoutSuite report through a multipart filename. Under affected configurations, this may write accepted JSON content outside the intended report directory and overwrite host files, potentially disrupting application operation.
Affected context
The issue occurs in the ScoutSuite GCP report-generation route when the backend passes a caller-controlled multipart filename to a file-writing service. The service combines that filename with the intended report directory without sanitizing traversal components or verifying that the resolved destination remains within the permitted directory. Exploitation depends on the route being reachable and the submitted content satisfying the endpoint's GCPScoutSuiteJSON validation.
The issue occurs in the ScoutSuite GCP report-generation route when the backend passes a caller-controlled multipart filename to a file-writing service. The service combines that filename with the intended report directory without sanitizing traversal components or verifying that the resolved destination remains within the permitted directory. Exploitation depends on the route being reachable and the submitted content satisfying the endpoint's GCPScoutSuiteJSON validation.
Exploit preconditions
- Attack surface:
POST /api/scoutsuite/generate-gcp-report - Required access: An authenticated account with administrator or analyst privileges
- Trigger point: Processing and saving the uploaded report through the ScoutSuite integration
- Required input: A crafted multipart filename and JSON content accepted as
GCPScoutSuiteJSON - Why exploitation is possible: The filename influences the filesystem destination, while the writer lacks canonical-path containment validation
- Environmental dependency: The resulting permissions and impact depend on the backend account, filesystem protections, and writable application paths
- Attack surface:
POST /api/scoutsuite/generate-gcp-report - Required access: An authenticated account with administrator or analyst privileges
- Trigger point: Processing and saving the uploaded report through the ScoutSuite integration
- Required input: A crafted multipart filename and JSON content accepted as
GCPScoutSuiteJSON - Why exploitation is possible: The filename influences the filesystem destination, while the writer lacks canonical-path containment validation
- Environmental dependency: The resulting permissions and impact depend on the backend account, filesystem protections, and writable application paths
Why this happens
The underlying bug is a failure to treat multipart filenames as untrusted path data. Combining a caller-controlled filename with a trusted directory using os.path.join does not prevent traversal when the filename contains path components or causes the resolved path to escape the intended location. Without filename normalization, destination allowlisting, and resolved-path containment checks, an attacker can influence where validated content is written. This maps primarily to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, with related concerns involving external control of file names and unrestricted file upload handling.
The underlying bug is a failure to treat multipart filenames as untrusted path data. Combining a caller-controlled filename with a trusted directory using os.path.join does not prevent traversal when the filename contains path components or causes the resolved path to escape the intended location. Without filename normalization, destination allowlisting, and resolved-path containment checks, an attacker can influence where validated content is written. This maps primarily to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, with related concerns involving external control of file names and unrestricted file upload handling.
Potential impact
- Host files may be overwritten with content accepted by the report-validation logic
- The application may become unavailable or malfunction because source or configuration files are altered
- Root-owned files may be modified when the backend runs with excessive privileges
- Application integrity and deployment reliability could be affected
- Broader compromise may be possible in environments where overwritten files are later executed or trusted, but this is not established by the demonstrated primitive alone
- Host files may be overwritten with content accepted by the report-validation logic
- The application may become unavailable or malfunction because source or configuration files are altered
- Root-owned files may be modified when the backend runs with excessive privileges
- Application integrity and deployment reliability could be affected
- Broader compromise may be possible in environments where overwritten files are later executed or trusted, but this is not established by the demonstrated primitive alone
General mitigation guidance
Mitigation generally focuses on removing caller control over filesystem destinations and reducing the privileges available to the service.
Common defensive patterns include:
- Generate server-side report names rather than using client-supplied filenames
- Treat multipart filenames as display metadata only, not as filesystem paths
- Resolve candidate paths and enforce strict containment within an approved directory
- Reject path separators, traversal components, absolute paths, and unexpected filename formats
- Use dedicated writable directories that are isolated from application source and configuration paths
- Apply least-privilege service identities and avoid running the backend as root
- Keep report validation and file storage policies independent of client-controlled path data
- Consider atomic writes and controlled file permissions to limit overwrite effects
Mitigation generally focuses on removing caller control over filesystem destinations and reducing the privileges available to the service.
Common defensive patterns include:
- Generate server-side report names rather than using client-supplied filenames
- Treat multipart filenames as display metadata only, not as filesystem paths
- Resolve candidate paths and enforce strict containment within an approved directory
- Reject path separators, traversal components, absolute paths, and unexpected filename formats
- Use dedicated writable directories that are isolated from application source and configuration paths
- Apply least-privilege service identities and avoid running the backend as root
- Keep report validation and file storage policies independent of client-controlled path data
- Consider atomic writes and controlled file permissions to limit overwrite effects
How teams detect issues like this
Detection can combine source analysis, runtime monitoring, and policy enforcement:
- Search for filesystem APIs that concatenate or join user-controlled filenames with trusted directories
- Flag uses of multipart
filenamevalues that reach open, write, rename, copy, or save operations without canonicalization - Review whether resolved paths are checked against an approved directory boundary
- Add code-review checks for server-generated filenames and isolated upload/report directories
- Monitor file writes outside expected report locations, especially writes to application source or configuration directories
- Enforce static-analysis and secure-upload policies in CI pipelines
- Log authenticated route usage, destination paths, and write failures without exposing sensitive content
Detection can combine source analysis, runtime monitoring, and policy enforcement:
- Search for filesystem APIs that concatenate or join user-controlled filenames with trusted directories
- Flag uses of multipart
filenamevalues that reach open, write, rename, copy, or save operations without canonicalization - Review whether resolved paths are checked against an approved directory boundary
- Add code-review checks for server-generated filenames and isolated upload/report directories
- Monitor file writes outside expected report locations, especially writes to application source or configuration directories
- Enforce static-analysis and secure-upload policies in CI pipelines
- Log authenticated route usage, destination paths, and write failures without exposing sensitive content
