SOCFortress CoPilot EUVD-2026-113995

Two distinct conditions apply. For theft of the GCP service-account key: an admin/analyst-initiated GCP scan must be in progress, because generate_gcp_report_background writes the uploaded key into the web-served scoutsuite-report directory and deletes it only after the scan completes, leaving it readable at /scoutsuite-report/<uploaded-filename> for the scan duration (the endpoint itself describes this as 'a few minutes'). For cloud-posture disclosure: at least one generated ScoutSuite report (HTML and scoutsuite-results/scoutsuite_results_<name>.js) must exist in that directory, and names are guessable from caller-selected names with predictable defaults (aws-report/gcp-report). No authentication, no user interaction, and no special client capability are required - network reachability to the host is the only access prerequisite (AV:N/AC:L/PR:N/UI:N). Limiting factors that reduce realistic exposure: key theft is time-bounded to active scan windows, and report disclosure requires that a scan report has been generated and retained.

All available signals point the same direction and support the input's act_now decision. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H) is internally consistent with the mechanism: an unauthenticated StaticFiles mount serves files to any network client with no privileges or user interaction, and the scope change (S:C) is well justified because a leaked Google service-account key grants access to a separate cloud environment beyond the vulnerable host. The GHSA advisory supplies a live, step-by-step curl proof-of-concept confirmed against the published ghcr.io/socfortress/copilot-backend:latest image, so the issue is demonstrated as real and trivially reproducible, not theoretical. No EPSS probability and no CISA KEV status were provided in the input, and the product is not listed in KEV; absence of those signals does not lower the severity but does suggest this is a targeted/low-volume risk rather than mass-scanned internet-wide exploitation, consistent with the product's limited footprint. This is a genuine high priority for any organization running CoPilot - not a high-CVSS-but-low-real-risk case - because it enables unauthenticated theft of a live cloud credential plus full cloud-posture disclosure. One caveat: the input's integrity rating (I:L) is not explained by the sources, and the credential-theft path is time-bounded to active scan windows, so realistic exposure depends on whether GCP scans are run and whether reports are retained.

An unauthenticated attacker who can reach the CoPilot host requests files under the public /scoutsuite-report mount using predictable report names (defaults aws-report/gcp-report). While an admin- or analyst-initiated GCP scan is running, the attacker downloads the uploaded Google service-account JSON key at /scoutsuite-report/<filename> and uses it to act with the service account's GCP permissions, and separately reads retained AWS/Azure/GCP posture reports as an attack roadmap. A working curl-based proof-of-concept for exactly this is published in the GHSA advisory and confirmed live against the official container image.