AiSOC CVE-2026-103053

Requires the default Docker Compose deployment of AiSOC 9.0.0 through pre-12.0.0 where AISOC_DEV_MODE is enabled (the default) AND AISOC_ACTIONS_SERVICE_TOKEN is empty (also the shipped default, because the variable was never generated by 'make up' despite compose declaring it must match on the api and actions services). Under those conditions the authorization guard exempts itself and every mutating response-action route answers unauthenticated. The attacker must be able to reach the actions-service network port (adjacent/internal per AV:A), which limits internet-facing exposure. Exploitation is closed once the token is generated (v12.0.0 makes 'make up' create it so the guard fails closed and mutating routes return 503 without it), so upgrading or manually setting AISOC_ACTIONS_SERVICE_TOKEN remediates.

This is a genuine but deployment-gated authentication bypass (CWE-306) rather than a high-CVSS-but-low-risk paper cut. The vendor CVSS 4.0 base of 5.3 (AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N) understates the real-world consequence: an unauthenticated attacker who reaches the actions-service port can submit and approve response actions on behalf of arbitrary principals and dispatch containment actions (host isolation, account disable) using the platform's stored vendor credentials (e.g. CrowdStrike RTR). The impact is not merely 'low integrity' - it is unauthorized operation of a security-orchestration control plane against downstream managed endpoints. No EPSS, KEV, SSVC, or public POC data was supplied: exploitation status is 'no public exploit identified at time of analysis' despite a VulnCheck advisory and a vendor GitHub Security Advisory (GHSA-g4h7-p63q-r8r4). The one signal that tempers priority is that the flaw only manifests in the DEFAULT Docker Compose deployment (AISOC_DEV_MODE enabled and AISOC_ACTIONS_SERVICE_TOKEN empty) - which per the commit was every install, because the token variable was never generated even though compose claimed it 'must match', and the guard exempted itself when the token was empty and dev mode was set. So while a special condition is named, it was the shipped default, making default installs of 9.0.0-11.x live-vulnerable until upgraded. Conflict to note: vendor scored AV:A (adjacent) and low impact; I assess the impact materially higher given containment-action abuse against real hosts.

An attacker who can reach the AiSOC actions-service HTTP port on the deployment's network (default Docker Compose, dev mode on, actions token never generated) sends unauthenticated requests to the response-action API, enumerates configured integrations, then submits and self-approves a containment action. The service executes it with the tenant's stored vendor credentials - isolating an arbitrary endpoint or disabling an account. No public exploit code was identified, but the guard's fail-open behavior is documented in the fix commit and requires no authentication.