Critical Command Injection in AiSOC Python Actions Service - CVE-2026-103056

Authentication bypass in AiSOC 7.5.0 through 11.x lets unauthenticated remote attackers subscribe to realtime WebSocket/SSE channels belonging to any tenant, exposing live alerts, cases, agent events, and graph updates. The realtime edge verifies subscription tickets with a hard-coded HS256 key committed to the repository, and per the patch commit that constant was the effective key in every shipped deployment because no docker-compose or make manifest ever passed AISOC_REALTIME_JWT_SECRET to either the API or the realtime service. Version 12.0.0 removes the fallback entirely and generates a real secret, so only deployments that explicitly set the variable are unaffected; no public exploit code identified at time of analysis, and the assessed impact is confidentiality-only against a very small deployment footprint.

Authorization bypass in the MSSP (multi-tenant) module of AiSOC 10.0.0 through before 12.0.0 allows any authenticated user who already owns at least one portfolio to submit arbitrary tenant UUIDs to the add_tenants_to_portfolio endpoint and pull unclaimed tenants into their own portfolio without those tenants' consent. Once a victim tenant is claimed, the attacker can read its security alerts, incidents, and posture metrics, giving high confidentiality impact with limited integrity impact but no availability loss (assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). Exploitation requires a valid account with portfolio ownership in an MSSP-enabled deployment and only works against tenants not already managed by another organisation; single-tenant installations are unaffected, and no public exploit code was identified at time of analysis.

Missing authentication on AiSOC's realtime service internal fan-out routes allows any caller that can reach the realtime port (adjacent-network access, no credentials, no user interaction) to inject spoofed agent events and unauthorized device notifications for arbitrary tenant IDs into the platform's WebSocket and Redis SSE broadcast channels, corrupting the integrity of what analysts see in AiSOC 5.1.0 through 11.x. The flaw is present by default: the guard protecting POST /internal/agent-event and POST /internal/push treated an unset REALTIME_INTERNAL_TOKEN as authorized, and no shipped manifest ever passed that variable, so authentication was effectively absent in every default deployment of affected versions. Impact is integrity-only with no data disclosure or denial of service, the affected deployment base is small, and exploitation is largely constrained to networks where the target's internal realtime service is reachable; no public exploit identified at time of analysis, and a vendor fix exists in v12.0.0.

Missing authentication on AiSOC's response-action API endpoints lets adjacent-network attackers reach the actions service without credentials in versions 9.0.0 through 11.x when the shipped defaults are in use - AISOC_DEV_MODE enabled and AISOC_ACTIONS_SERVICE_TOKEN left empty. In that state the authorization guard in services/actions/app/security/authz.py exempts itself, so every mutating route answers unauthenticated, allowing an attacker to enumerate response-action integrations, submit and approve actions as arbitrary principals, and trigger host-isolation or account-disable containment actions through the platform's own vendor credentials. Exploitation is deployment-gated rather than universal: it requires network reachability to the actions-service port (adjacent/internal), and no public exploit code was identified at time of analysis. Vendor patching is available in AiSOC v12.0.0.