CVE-2026-103054 in AiSOC
Summary
by MITRE • 09/30/2026
AiSOC versions before 12.0.0 contain an authorization bypass vulnerability in the MSSP module that allows authenticated users to add arbitrary tenants to portfolios they own. Attackers can submit tenant UUIDs via the add_tenants_to_portfolio endpoint to claim unclaimed tenants and read their security alerts, incidents, and posture metrics without consent.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The AiSOC platform prior to version 12.0.0 contains a critical authorization bypass vulnerability within its Multi-Service Provider (MSSP) module that fundamentally undermines the principle of least privilege and tenant isolation. This flaw allows authenticated users, who are already granted access to specific portfolios they own, to manipulate system state by adding arbitrary tenants to those portfolios without proper administrative consent or verification mechanisms. The core technical failure lies in the insufficient validation of ownership relationships during the execution of the add_tenants_to_portfolio endpoint. Instead of verifying that the target tenant is explicitly associated with the requesting user’s organization or has granted permission for such inclusion, the application accepts any valid Universal Unique Identifier (UUID) representing a tenant and immediately grants access to its data within the context of the attacker-controlled portfolio. This lack of server-side authorization checks enables an authenticated actor to escalate their privileges effectively by gaining unauthorized visibility into security operations belonging to other entities or unrelated tenants in the system.
The operational impact of this vulnerability is severe, as it compromises the confidentiality and integrity of sensitive security telemetry data across multiple organizations sharing the AiSOC infrastructure. By successfully exploiting this flaw, an attacker can claim unclaimed tenant UUIDs and subsequently read critical security alerts, incident reports, and posture metrics associated with those tenants. This exposure reveals detailed insights into the victim organization’s network architecture, detected threats, vulnerability status, and compliance posture. Such information is highly valuable for further reconnaissance or targeted attacks against the compromised organizations. Furthermore, because MSSP modules are designed to manage multiple clients from a single interface, this breach can lead to widespread data leakage affecting numerous distinct entities simultaneously if an attacker identifies valid tenant identifiers through enumeration techniques. The ability to ingest and view security incidents without consent also violates trust agreements between service providers and their customers, potentially leading to significant legal liabilities and reputational damage for the MSSP provider hosting the vulnerable AiSOC instance.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing restrictive policies on authorized users regarding resource access rights. The attack vector involves manipulating API inputs to bypass intended security boundaries, which is characteristic of Broken Object Level Authorization (BOLA) or Insecure Direct Object Reference (IDOR) patterns often documented under CWE-639. In terms of the MITRE ATT&CK framework, this behavior maps directly to T1078 Valid Accounts, as it relies on legitimate authentication credentials to perform unauthorized actions, and potentially T1530 Data from Cloud Storage if the tenant data is considered stored assets accessible via API calls. The exploitation does not require complex privilege escalation techniques beyond initial access but rather exploits logical flaws in how resource ownership and permissions are validated during runtime operations.
Mitigation strategies must focus on implementing robust authorization checks at both the application logic layer and the database query level. Developers should ensure that every request to modify portfolio-tenant relationships includes a strict verification step confirming that the target tenant is either already part of the user’s organization or has explicitly granted permission for such association through a formal consent workflow. Implementing role-based access control (RBAC) with granular permissions can help restrict who may manage tenant assignments within portfolios. Additionally, introducing rate limiting and anomaly detection on API endpoints like add_tenants_to_portfolio can help identify and block automated enumeration attempts targeting random UUIDs. For organizations currently running AiSOC versions before 12.0.0, immediate upgrading to the patched version is essential to resolve this authorization bypass flaw. Until an upgrade is feasible, administrators should monitor logs for unusual patterns of tenant additions or access requests originating from single accounts that do not correspond to expected business activities and consider restricting API exposure through network-level controls if possible.