CVE-2026-61728 in CoPilot
Summary
by MITRE • 10/30/2026
SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. In affected snapshots preceding the respective 0.1.70 and 0.1.76 sink repairs, portal users, including `customer_user`, can submit stored markup through `POST /api/incidents/db_operations/alert/comment`. In `customer-portal/src/components/alerts/AlertDetails/AlertComment.vue`, `commentHtml` replaces newlines in `comment.comment` but passes the result to `v-html` without escaping or sanitizing HTML. When another user views the poisoned alert, stored script executes on the application origin; the same unsanitized rendering pattern affects server-stored SOC case, asset and health-check fields in `SocCaseNote.vue`, `SocCaseItem.vue`, `SocCaseAssetsItem.vue`, `SocAlertAssetsItem.vue` and `HealthcheckItem.vue`. The authentication store in `customer-portal/src/stores/auth.ts` persists both access and refresh tokens in JavaScript-readable storage, and `customer-portal/src/api/httpClient.ts` uses bearer headers rather than HttpOnly cookies. An injected script can steal both tokens, impersonate the viewer and obtain fresh tokens through `/auth/refresh`. If an analyst or administrator views the poisoned alert or case, this enables persistent privileged account takeover, cross-tenant data access, incident modification or deletion, and detection/response subversion. The health-check sink repair is first contained in version 0.1.70, while the comment and other SOC sink repairs are first contained in version 0.1.76. Version 0.1.76 is the provisional first release containing all observed repairs; grouped versus split CVE scope requires curator adjudication.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
SOCFortress CoPilot, a security operations platform designed to provide centralized visibility into security events, contains critical vulnerabilities in versions preceding 0.1.70 and 0.1.76 that allow for stored cross-site scripting and session hijacking. The primary technical flaw resides within the frontend rendering logic of several Vue.js components, specifically AlertComment.vue, SocCaseNote.vue, SocCaseItem.vue, SocCaseAssetsItem.vue, SocAlertAssetsItem.vue, and HealthcheckItem.vue. These components accept user-supplied input through API endpoints such as POST /api/incidents/db_operations/alert/comment or similar case management interfaces. Instead of sanitizing the incoming HTML content, the application performs a basic newline replacement on comment.comment before passing the resulting string directly to Vue’s v-html directive. This mechanism bypasses standard browser security models by allowing arbitrary JavaScript execution within the context of the SOCFortress origin whenever another user views the poisoned alert or case note.
The operational impact of this vulnerability is severe, facilitating persistent privileged account takeover and cross-tenant data access. An attacker can inject malicious scripts that execute in the victim’s browser session, effectively impersonating legitimate analysts or administrators. This capability enables the modification or deletion of critical incident records, subversion of detection and response workflows, and unauthorized access to sensitive security telemetry. The vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation as a common cause of cross-site scripting flaws. Furthermore, from an adversary perspective, this technique corresponds to the ATT&CK tactic of Collection via Browser Redirect or Scripting, allowing attackers to harvest session data and manipulate security operations without direct network intrusion.
Compounding the risk is the insecure handling of authentication tokens within the client-side application state management system. The auth.ts store persists both access and refresh tokens in JavaScript-readable storage rather than utilizing HttpOnly cookies. Additionally, the httpClient module transmits these credentials using Bearer headers instead of secure cookie attributes. This architectural decision means that any script injected via the aforementioned XSS vulnerability can directly read the stored tokens from memory or local storage. Once obtained, an attacker can use the access token to immediately impersonate the victim and utilize the refresh token to obtain new valid sessions through the /auth/refresh endpoint, ensuring persistent unauthorized access even after session timeouts. This aspect of the flaw relates closely to CWE-524 regarding the exposure of sensitive information in client-side storage.
Mitigation requires immediate upgrading to version 0.1.76 or later, which contains provisional repairs for all observed sinks including comments, SOC cases, assets, and health checks. For organizations unable to upgrade immediately, implementing a Content Security Policy with strict script-src directives can help mitigate the execution of injected scripts by restricting sources from which JavaScript may be loaded. Additionally, developers should refactor the authentication store to use HttpOnly cookies for token storage and ensure that all user-supplied HTML content is sanitized using a robust library such as DOMPurify before being rendered via v-html or similar mechanisms. Regular security audits focusing on input validation and output encoding practices are essential to prevent recurrence of these types of vulnerabilities in future releases.