CVE-2026-61707 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, in the reported deployment, case-report templates uploaded by `customer_user`, the lowest-privilege portal role, are later executed by non-sandboxed Jinja2 engines when an admin or analyst generates a report. The `/case-report-template/upload` route in `backend/app/incidents/routes/db_operations.py` validates only the filename-derived MIME type, not the template content. Templates share a global store without customer_code scoping, and `customer_user` can also list, download and delete them, allowing an attacker to replace a legitimate default template under the same name. In `backend/app/incidents/services/reports.py`, `render_document_with_context` uses `DocxTemplate` without a sandbox; in `backend/app/incidents/services/reports_pdf.py`, `render_html_template` uses a non-sandboxed `Environment` without autoescaping. Normal privileged requests to `POST /api/incidents/report/generate-report-docx` or `/generate-report-pdf` therefore evaluate attacker-controlled Jinja expressions as Python on the backend. The reported deployment executes commands as root, exposing all tenants' incident and SIEM data and stored connector credentials. The HTML/PDF wkhtmltopdf renderer additionally permits local-file reads and requests to internal services. This issue is fixed in version 0.1.76.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability described constitutes a critical server-side template injection flaw within the SOCFortress CoPilot security operations platform, specifically affecting versions prior to 0.1.76. The core technical deficiency lies in the insecure handling of user-uploaded case-report templates by backend services responsible for generating reports. While the application implements role-based access control where customer users hold the lowest privilege level, it fails to enforce strict isolation or sanitization when these low-privilege inputs are processed by higher-privileged administrative functions. The vulnerability stems from a combination of insufficient input validation and the use of non-sandboxed template rendering engines that allow arbitrary code execution on the server side.
The attack vector begins at the file upload endpoint located in backend/app/incidents/routes/db_operations.py, specifically the /case-report-template/upload route. This endpoint performs only superficial validation by checking the MIME type derived from the filename rather than inspecting the actual content of the uploaded template files. Consequently, an attacker can bypass these checks and inject malicious Jinja2 code into a template file. Furthermore, the application architecture lacks proper multi-tenancy isolation for this resource; templates are stored in a global store without customer_code scoping. This design flaw allows any authenticated user to list, download, or delete existing templates. An adversary can exploit this by identifying a legitimate default template used by administrators and replacing it with their own malicious version under the same filename, thereby ensuring that when an admin generates a report using that template name, the injected code is executed.
The execution of the payload occurs within two distinct service modules: backend/app/incidents/services/reports.py and backend/app/incidents/services/reports_pdf.py. In the former, the render_document_with_context function utilizes DocxTemplate without any sandboxing mechanisms to restrict access to dangerous Python objects or methods. Similarly, in the latter, the render_html_template function employs a Jinja2 Environment that lacks autoescaping features and operates outside of a secure sandbox context. When an administrator or analyst triggers report generation via POST requests to /api/incidents/report/generate-report-docx or /generate-report-pdf, the backend processes these non-sandboxed templates. This allows attacker-controlled Jinja expressions to be evaluated directly as Python code on the server, leading to Remote Code Execution with the privileges of the application process.
The operational impact of this vulnerability is severe due to the execution context and architectural design of the SOCFortress deployment. In many reported instances, the backend services execute commands as the root user, which amplifies the risk significantly. Successful exploitation grants an attacker full control over the underlying operating system, enabling them to exfiltrate sensitive data from all tenants within the platform. This includes incident records, Security Information and Event Management (SIEM) logs, and stored connector credentials that provide access to external security tools and cloud environments. Additionally, the HTML and PDF rendering process utilizes wkhtmltopdf, which introduces secondary risks such as local file read capabilities and server-side request forgery against internal services, further expanding the attack surface for lateral movement within the network infrastructure.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) due to the execution of attacker-supplied code via template injection. It also maps to CWE-732 Incorrect Permission Assignment for Critical Resource regarding the lack of tenant isolation in the global template store and CWE-611 Improper Restriction of XML External Entity Reference if interpreted broadly, though primarily it is a Code Injection issue. In terms of MITRE ATT&CK tactics, this represents Initial Access via Exploitation of Remote Services followed by Execution through Command and Scripting Interpreter, potentially leading to Credential Access and Collection depending on the data accessed post-exploitation.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix is upgrading SOCFortress CoPilot to version 0.1.76 or later, where these template handling flaws have been addressed. For deployments that cannot immediately upgrade, administrators should restrict access to the /case-report-template/upload endpoint to only high-privilege roles and disable public listing of templates. Implementing strict multi-tenancy by scoping all uploaded resources with customer identifiers is essential to prevent cross-tenant contamination. Furthermore, template rendering engines must be configured in sandboxed modes that prohibit access to sensitive Python objects, file system operations, and network requests. Enabling autoescaping for HTML outputs and validating MIME types based on content signatures rather than filenames will further reduce the risk of similar injection attacks.