AiSOC v12.0.0 fixes a critical flaw in action controlthat could allow unauthenticated response operations in default installations. The issue involved a service that manages actions such as computer isolation and IP address blocking.
According to the project's official security bulletin, versions 8.0.0 through 11.2.0 were affected when using the recommended Docker Compose installation. The combination of an empty value for the access token and enabled development mode allowed unauthenticated calls to reach the relevant APIs.
This default overrides the control of actions in facilities where the relevant regulations remain empty. The extent of exposure depended on where the container was operating and which systems could communicate with it; therefore, public access from the internet was not necessarily required.
The gap in action checking was not caused by an error in connecting to a specific provider. The authentication function returned without checking when AISOC_ACTIONS_SERVICE_TOKEN and AISOC_DEV_MODE. The default Compose configuration left the second parameter enabled, while the initial configuration tool did not generate the required access token.
The gap in action control
The service allowed calls without an authorization header to routes through which available interfaces could be enumerated or response actions could be taken. These include system isolation, account deactivation, IP address blocking, process termination, and script execution. The project update rates the vulnerability as critical, with a CVSS score of 9.5.
The exploit did not necessarily require the API to be connected to the public internet. An attacker or an already compromised service that could communicate with the actions service on the Docker network could attempt unauthenticated calls. The default port mapping to 127.0.0.1 did not prevent communication between containers.
However, the ability to send a command does not mean that every installation allowed for real impact on external systems. The project notes that without provider credentials available, some actions returned a simulated result. The actual risk depended on whether the caller could reach the service and the credentials or automation paths configured by the administrator.
See also: CVE-2026-101065: Critical flaw in Obot leaves Docker unchecked
Which versions are affected and what changes?
The vulnerability affects AiSOC versions 8.0.0 to 11.2.0, with a fix included in version 12.0.0. With the change, the service returns a 503 error to any operation that might change data when the required secret is missing, instead of continuing without checking. This new behavior fails in a safer manner.
AiSOC version 12.0.0 also includes fixes for the real-time service and for case registration permissions. The announcement recommends upgrading with the make up or make env commands , which now populate the required secrets in an existing configuration file.
The fix strengthens action control and prevents reliance on a silent, insecure default. For custom installations, administrators must verify that secrets have been passed to each service that needs them. Otherwise, protected operations stop responding, as predicted by the new secure behavior.
For installations via Helm, Terraform, or custom Compose files, administrators must set the required values in the corresponding services before upgrading. If they are missing, some features will be intentionally unavailable rather than working without authentication. This may temporarily break automations, but prevents a fallback to the insecure default.
See also: MCP Python SDK: OAuth credentials stolen by malicious servers
What should administrators do?
The SecNews technical team recommends upgrading to version 12.0.0 immediately and verifying that the AISOC_ACTIONS_SERVICE_TOKEN has been created and set to the correct service. Those who cannot upgrade immediately should disable development mode in production environments and prevent access to the API from untrusted services.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
To audit actions, administrators also need to review logs for unexpected calls to dispatch or authorization routes. If the service was accessed by an untrusted container or user, they should review the actions logged and refresh the relevant provider credentials where there are indications of exposure.
The publication of the vulnerability is not in itself an indication that the flaw has been exploited in real attacks. The critical point is the configuration: installations that did not use the vulnerable defaults had a different level of exposure, but the safe option is to apply the fix and re-check network access.
See also: Rig Security: $12 million in funding for agentic AI identity security
