SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations…

Why it is Yellow

• CVSS 7.5 high
• Remotely exploitable without logging in

References

• https://github.com/socfortress/CoPilot/commit/d22f80f9086ef5e68baa3a9414bff7d7621a14a8
• https://github.com/socfortress/CoPilot/pull/942
• https://github.com/socfortress/CoPilot/security/advisories/GHSA-c6jc-rh4j-wg88
• https://github.com/socfortress/CoPilot/tree/v0.1.77

Original description

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.