CVE-2026-61708 in CoPilot
Summary
by MITRE • 10/30/2026
SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. Prior to 0.1.76, `POST /api/agent_data_store/upload` in `backend/app/data_store/data_store_routes.py` permits `customer_user` callers to choose `bucket_name` and `object_name` without an allowlist, tenant prefix, ownership check or content restriction. The only file check requires a nonempty filename. The operations in `backend/app/data_store/data_store_operations.py` create missing buckets and upsert objects, allowing existing objects belonging to any tenant to be overwritten. Targets include `sysmon-configs/<customer_code>/sysmon_config.xml` distributed to managed Windows endpoints, `copilot-case-report-templates/<name>` rendered server-side, and case evidence or forensic artifacts under `copilot-cases/<case_id>/<file>` and `velociraptor-artifacts/<agent_id>/<flow_id>/<file>`. A lowest-privilege user can tamper with cross-tenant evidence, blind endpoint telemetry, poison report templates for later code execution, plant data or exhaust storage. Sibling list, download and delete routes remain restricted to admin/analyst; the exposed operation is the upload write path. This issue is fixed in version 0.1.76.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in SOCFortress CoPilot prior to version 0.1.76 represents a critical insecure direct object reference combined with insufficient access control within the backend data storage subsystem. The core technical flaw resides in the POST endpoint for agent data store uploads, specifically located at /api/agent_data_store/upload in the file backend/app/data_store/data_store_routes.py. This interface allows any authenticated user classified as a customer_user to specify arbitrary bucket_name and object_name parameters without validation against an allowlist or enforcement of tenant-specific prefixes. The application logic lacks ownership verification mechanisms that would ensure users can only write to resources belonging to their own tenancy context. Furthermore, there are no content restrictions applied to the uploaded files, relying solely on a trivial check for non-empty filenames. This architectural oversight creates a direct path for unauthorized data manipulation across multi-tenant boundaries.
The operational impact of this vulnerability is severe due to the specific functions performed by the affected storage operations defined in backend/app/data_store/data_store_operations.py. These operations automatically create missing buckets and perform upserts on objects, meaning that if an attacker specifies a bucket or object path that does not exist, it will be created under their control, or more critically, existing objects belonging to other tenants can be overwritten. This capability allows for several distinct attack vectors depending on the targeted resource paths. Attackers can tamper with cross-tenant evidence stored in copilot-cases/<case_id>/<file> and velociraptor-artifacts/<agent_id>/flow_id/file>, compromising the integrity of forensic investigations and potentially destroying critical legal or operational data. Additionally, by modifying sysmon-configs/<customer_code>/sysmon_config.xml files distributed to managed Windows endpoints, an attacker can blind endpoint telemetry for other tenants, effectively hiding malicious activities from security monitoring systems.
Beyond immediate data tampering, this vulnerability enables persistent code execution risks through template poisoning. The application renders copilot-case-report-templates/<name> server-side; by uploading a crafted file with the appropriate name to overwrite existing templates, an attacker can inject malicious content that executes when administrators or analysts view case reports. This transforms a storage misconfiguration into a remote code execution vector for lower-privilege users. Other potential impacts include planting false data within the system to confuse analysis efforts and exhausting cloud storage quotas through rapid upload of large files, leading to denial of service conditions. The severity is compounded by the fact that while sibling operations such as list, download, and delete remain restricted to admin or analyst roles via proper access controls, the write path remains wide open to any customer user, creating an asymmetric risk profile where read integrity is protected but write availability and confidentiality are compromised.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-611 Improper Restriction of XML External Entities if template rendering involves parsing untrusted input, though primarily it reflects CWE-597 Use of Wrong Operator in Boolean Context or more accurately CWE-862 Missing Authorization. In terms of the MITRE ATT&CK framework, this behavior maps to T1074 Data Staged for collection and potentially T1036 Masquerading if used to hide artifacts, but most directly relates to T1565 Stored Data Manipulation where an attacker modifies data stored in a system. The exploitation requires no special privileges beyond standard customer user access, making it easily exploitable by any compromised or malicious insider account within the platform.
Mitigation for this vulnerability involves upgrading SOCFortress CoPilot to version 0.1.76 or later, where these checks have been implemented. For organizations unable to immediately patch, defensive measures should include implementing strict server-side validation of bucket and object names against a whitelist of allowed patterns that enforce tenant isolation prefixes. Access control lists must be updated to ensure that write operations verify the authenticated user's ownership of the target resource path before allowing upserts or creations. Additionally, input sanitization for uploaded files is necessary to prevent code execution via template poisoning, ensuring that only expected file types and content structures are accepted by the rendering engine. Regular auditing of storage access logs can also help detect attempts to exploit this flaw prior to remediation.