CVE-2026-61739
HighCVSS 7.5Summary
In SOCFortress CoPilot prior to 0.1.77, the Velociraptor Sigma exclusion-management endpoints omit role and tenant authorization, and the exclusion creation endpoint does not properly validate credentials — any invalid, expired or forged Bearer token can create a suppression rule. Additionally, rules with a null customer_code apply across all tenants, and low-privilege users can list, modify, disable or delete exclusions.
Risk Assessment
An attacker can suppress detections platform-wide and hide real incidents, while low-privilege accounts can tamper with detection tuning, weakening the organization's security monitoring.
Recommendation
Update SOCFortress CoPilot to version 0.1.77 or later, and until then restrict access to the Velociraptor Sigma exclusion endpoints and review existing exclusion rules, especially those with a null customer_code.
Other vulnerabilities in SOCFortress CoPilot
See all- CVE-2026-61708High
In SOCFortress CoPilot prior to 0.1.76, the POST /api/agent_data_store/upload endpoint allows customer_user callers to choose bucket_name and object_name without an allowlist, tenant prefix, or ownership check. This enables overwriting objects belonging to any tenant, including sysmon configs, report templates, and case evidence. The issue is fixed in version 0.1.76.
- CVE-2026-61738Critical
In SOCFortress CoPilot prior to 0.1.77, the POST /api/scoutsuite/generate-gcp-report endpoint passes the raw multipart filename to the file writer without sanitization or a resolved-path containment check. A traversal filename therefore writes the supplied JSON outside the intended report directory, including into the application source directory.
- CVE-2026-61730Critical
In SOCFortress CoPilot, the unauthenticated /scoutsuite-report StaticFiles mount exposes the scoutsuite-report directory, disclosing HTML reports and result files containing AWS, Azure and GCP IAM principals, resource inventories and misconfigurations. During a GCP scan, the service-account key is saved into that same web-served directory and removed only after the scan finishes, so an anonymous client can retrieve it.
- CVE-2026-61729Critical
In SOCFortress CoPilot prior to 0.1.76, verify_graylog_header and verify_velociraptor_header authenticate webhooks against the same publicly hardcoded fallback header, also shipped in .env.example. Deployments with unchanged secrets let an anonymous caller bypass JWT authentication, invoke active-response actions and create forged alerts.
- CVE-2026-61728Critical
In SOCFortress CoPilot, portal users including customer_user accounts can submit stored markup via the alert comment endpoint, which is rendered without sanitization using v-html. This enables stored XSS, and because access and refresh tokens are persisted in JavaScript-readable storage, injected script can steal them and impersonate the viewer. The same unsanitized rendering affects other SOC fields (cases, assets, health-checks), with fixes first contained in versions 0.1.70 (health-check) and 0.1.76 (comments and other SOC sinks).
- CVE-2026-61707Critical
In SOCFortress CoPilot prior to 0.1.76, case-report templates uploaded by the lowest-privilege customer_user role are later executed by non-sandboxed Jinja2 engines when an admin or analyst generates a report. Lack of template content validation and cross-tenant scoping allows an attacker to inject malicious Jinja expressions that are evaluated as Python on the backend.
- CVE-2026-42869Critical
In versions prior to 0.1.57, SOCFortress CoPilot contained a hardcoded JWT signing secret, allowing attackers to forge admin-scoped tokens. If JWT_SECRET is not set, all authentication tokens are signed with this publicly known key.
Original NVD description (English source)
SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. Prior to 0.1.77, the Velociraptor Sigma exclusion-management endpoints in `backend/app/incidents/routes/incident_alert.py` omit role and tenant authorization, and `POST /api/incidents/alerts/create/velo-sigma/exclusion` does not validate credentials. Its `return_username_for_logging` dependency in `backend/app/auth/utils.py` calls `decode_token`, which returns ordinary Invalid token or Expired signature strings on failure, and the dependency passes these strings through instead of rejecting the request. A Bearer header is required, but an arbitrary invalid, expired or forged value can create a suppression rule without a valid account. The collection GET at /create/velo-sigma/exclusion lists exclusions; the read, update and delete routes under `/create/velo-sigma/exclusion/{exclusion_id}`, and the `/velo-sigma/exclusion/{exclusion_id}/toggle` route, use `get_current_user` without role checks, permitting any authenticated `customer_user` to manage every exclusion. In `backend/app/incidents/services/velo_sigma.py`, `process_sigma_alert` calls `check_exclusions` and drops matching enabled alerts before incident creation. A null `customer_code` applies a rule across all tenants. Attackers can suppress detections platform-wide through channel, title or field matching, while low-privilege accounts can enumerate detection-tuning data and modify, disable or delete legitimate exclusions. This issue is fixed in version 0.1.77.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS