SOCFortress CoPilot EUVD-2026-113993

Requires an authenticated portal account at the lowest role (customer_user) to write stored markup via POST /api/incidents/db_operations/alert/comment; the create route authorizes admin, analyst, and customer_user. The payload executes because AlertComment.vue binds comment.comment to v-html after only a newline-to-<br> transform, with no HTML escaping and no DOMPurify/sanitize-html dependency in either frontend or customer-portal; the same unsanitized v-html pattern affects SocCaseNote.vue, SocCaseItem.vue, SocCaseAssetsItem.vue, SocAlertAssetsItem.vue, and HealthcheckItem.vue, so poisoned comment, case, asset, or health-check fields all trigger. Full privileged account takeover additionally requires that a privileged user (analyst or administrator) views the poisoned alert or case, and depends on the tokens being stored in JavaScript-readable storage (auth.ts) and sent as bearer headers (httpClient.ts) rather than HttpOnly cookies. Limiting factors: an attacker needs a valid portal login, a higher-privilege victim must view the content for escalation, and the issue is confined to affected snapshots preceding 0.1.70 (health-check sink) and 0.1.76 (comment and other SOC sinks).

This is a genuine high-priority issue, not a CVSS-inflated one. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) is corroborated by the vuln.today decision label of act_now and by a reporter-confirmed, reproduced proof-of-concept in the GHSA advisory. The combination is the dangerous part: a stored XSS reachable by the lowest-privilege portal role (customer_user) that fires in the browser of whoever views the poisoned alert or case, chained with tokens (both access and refresh) held in JavaScript-readable storage (CWE-922) and sent as bearer headers rather than HttpOnly cookies. That chain converts a low-privilege input flaw into cross-tenant privileged account takeover of a security product. Signals largely agree rather than conflict. Note the gaps: no EPSS score and no CISA KEV entry are present in the input, so there is no quantitative exploitation-probability signal and no evidence of observed in-the-wild exploitation - the urgency rests on the act_now label and the confirmed working PoC, not on KEV. The PR:L in the vector means exploitation is authenticated (an attacker needs a valid, even lowest-tier, portal account); full privileged takeover additionally depends on a privileged user (analyst/admin) later viewing the poisoned content. These are realistic in a multi-tenant SOC portal but are real preconditions, not a drive-by.

An attacker holding a low-privilege customer_user portal account submits a comment containing an HTML/JavaScript payload through POST /api/incidents/db_operations/alert/comment; the backend stores it verbatim. When a SOC analyst or administrator opens that alert, the comment is rendered via v-html without sanitization and the script runs on the application origin, reading the viewer's access and refresh tokens from JavaScript-readable storage and exfiltrating them. A public, reporter-confirmed working proof-of-concept exists - demonstrated live against the published ghcr.io/socfortress/copilot-backend image, popping document.domain from a stored comment - and the vector is network-reachable with low attack complexity (AV:N/AC:L).