SOCFortress CoPilot EUVD-2026-113399

Requires (1) a valid customer_user portal account - the lowest-privilege role - which can reach the upload/list/download/delete siblings of /case-report-template because they are all scoped to admin/analyst/customer_user, and the global template store has no customer_code scoping; and (2) a privileged admin or analyst to subsequently call POST /api/incidents/report/generate-report-docx or /generate-report-pdf against a case using the poisoned template (this satisfies UI:R and makes it a stored second-order injection, not direct self-service RCE). Limiting factors: the attacker cannot detonate the payload alone - a privileged user's routine report generation is the trigger - and valid low-privilege credentials are needed. Aggravating factors in the reported deployment: no content validation (filename-only MIME check), no Jinja2 sandbox or autoescape on either render path, the backend process runs as root, and wkhtmltopdf runs without --disable-local-file-access, adding local-file read and SSRF.

This is a genuine high-priority issue, not an inflated CVSS score. The signals converge: the vuln.today decision label is act_now, the vendor has shipped a fix (0.1.76), and the GHSA advisory contains a proof-of-concept the reporter states was confirmed live against the official ghcr.io/socfortress/copilot-backend:latest image, achieving uid=0(root) command execution. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H = 9.0) is internally consistent with the mechanism: network-reachable upload endpoint, low complexity, PR:L because the attacker needs only the lowest-privilege customer_user portal role, UI:R because a privileged admin/analyst must generate the report to detonate the stored payload, and S:C because execution escapes the application's authorization scope to run as root across all tenants. No EPSS score and no CISA KEV status are provided in the input, so widespread-exploitation probability cannot be quantified and active in-the-wild exploitation is NOT confirmed. The tension to flag: this is a stored/second-order injection requiring a privileged user's routine action plus valid low-privilege credentials, so despite the critical impact it is not a point-and-click remote-unauthenticated RCE - realistic risk is highest in multi-tenant deployments where untrusted customer_user accounts coexist with admins who generate reports.

A customer_user authorized only for one tenant deletes the organization's default case-report template and re-uploads a malicious .html or .docx under the same name containing a Jinja2 gadget (e.g. {{ lipsum.__globals__["os"].popen(...) }}); the filename-only MIME check passes. When an admin or analyst later runs the routine POST /generate-report-pdf or /generate-report-docx, the non-sandboxed Jinja2 engine evaluates the payload as Python on the backend. A working PoC confirmed live in the GHSA advisory demonstrates arbitrary command execution as root, and the wkhtmltopdf path additionally allows local-file reads and SSRF to internal services.