SOCFortress CoPilot: Unauthenticated Exposure of ScoutSuite Reports and Uploaded GCP Service-Account Key via Static Mount
Affects CoPilot versions before 0.1.77 that run GCP ScoutSuite scans with an uploaded service-account key. Fixed in 0.1.77.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 0.1.77
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
Anyone with network access to a SOCFortress CoPilot server can anonymously retrieve cloud security scan reports and results, which reveal cloud identities, resource inventories, and misconfigurations across AWS, Azure, and GCP. During GCP scans, the uploaded Google service-account key is also briefly saved to that publicly reachable location, so an unauthenticated attacker could obtain it and use the account's cloud permissions.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. In affected deployments, the unauthenticated `/scoutsuite-report` `StaticFiles` mount in `backend/copilot.py` exposes the `scoutsuite-report` directory even though normal /api routes require JWT authentication. Generated HTML reports and `scoutsuite-results/scoutsuite_results_<name>.js` files disclose AWS, Azure and GCP IAM principals, resource inventories, misconfigurations and findings. Report names derive from caller-selected names with predictable defaults. During an admin- or analyst-initiated GCP scan, `backend/app/integrations/scoutsuite/routes/scoutsuite.py` saves the uploaded Google service-account JSON key into that same web-served directory. In `backend/app/integrations/scoutsuite/services/scoutsuite.py`, `generate_gcp_report_background` removes the key only after the scan finishes. Any anonymous client that can reach the host and request the file path can therefore retrieve the private key during the scan and use the service account's cloud permissions, as well as read retained cloud-security reports. Credential isolation is released in version 0.1.77; a release fully remediating the report-disclosure component has not been established.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- socfortress CoPilot
fixed in 0.1.77
References 4
GitHub · socfortress/CoPilot
Questions about CVE-2026-61730
What does this mean?
The application serves the ScoutSuite report directory with no login. During a GCP scan, the uploaded Google service-account private key is saved into that directory, so the key and the cloud-security reports can be read without authentication.Source: github.com, github.com
Am I affected, and how do I check?
Versions before 0.1.77 are affected, but only in setups that run a GCP ScoutSuite scan with an uploaded service-account key. To check, compare the installed CoPilot version with 0.1.77 and confirm whether GCP scans with uploaded keys are used.Source: github.com, github.com
What should I do about it?
Upgrade CoPilot to 0.1.77 or later.Source: github.com, github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Is the fix complete?
The fix writes the uploaded key to a private tempfile.mkdtemp() directory instead of the web-served directory. The fix is marked partial, and the checked facts do not say which part of the problem remains unfixed.Source: github.com, github.com