CVE-2026-103055 in AiSOC
Summary
by MITRE • 09/30/2026
AiSOC versions 7.5.0 before 12.0.0 use a hard-coded constant for JWT verification in the realtime WebSocket and SSE service when the AISOC_REALTIME_JWT_SECRET environment variable is not set. Unauthenticated attackers can forge subscription tickets with arbitrary tenant identifiers to access cross-tenant live alerts, cases, agent events and graph updates through the realtime endpoints.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in AiSOC versions prior to 12.0.0 represents a critical failure in authentication logic within its real-time data streaming services. Specifically, the WebSocket and Server-Sent Events (SSE) implementations rely on JSON Web Tokens for session management and tenant isolation. Under normal operational conditions, these tokens are verified against a secret key provided via the AISOC_REALTIME_JWT_SECRET environment variable. However, when this configuration parameter is omitted or left unset, the application falls back to using a hard-coded constant as the verification key. This design flaw creates a predictable cryptographic basis that can be exploited by attackers who possess knowledge of this default value, effectively bypassing the intended authentication mechanisms for real-time endpoints.
From a technical perspective, this issue stems from improper handling of configuration defaults and insufficient validation of security-critical parameters during initialization. The use of a hard-coded secret is a well-documented anti-pattern that violates fundamental principles of secure software development. By embedding the key directly into the source code or binary rather than allowing it to be configured per deployment instance, the system ensures that every installation using this version shares the same authentication credential. This lack of entropy and uniqueness allows an attacker to generate valid JWTs without any prior access credentials. The flaw is particularly severe because it affects services designed for real-time monitoring, which typically have high privileges and broad data visibility within the security operations center environment.
The operational impact of this vulnerability is significant due to its potential for cross-tenant data exfiltration. An unauthenticated attacker can forge subscription tickets containing arbitrary tenant identifiers. By manipulating these tokens, the attacker gains access to live alerts, incident cases, agent events, and graph updates belonging to other tenants or organizational units within the AiSOC platform. This breach of multi-tenancy isolation means that sensitive security telemetry, which may include indicators of compromise, network topology maps, and internal alert details, can be accessed by unauthorized parties. In a managed service context where multiple customers share the infrastructure, this could lead to widespread data leakage across different organizations, compromising confidentiality and potentially aiding further attacks against specific targets identified through the leaked intelligence.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials, as it involves the use of static authentication information that cannot be changed by the administrator or user. Furthermore, from an offensive security perspective, this flaw facilitates unauthorized access to resources and can be categorized under ATT&CK technique T1078: Valid Accounts, specifically through credential spoofing or token forgery. The ability to inject arbitrary tenant identifiers also touches upon CWE-269: Improper Privilege Management, as it allows users to escalate their scope of visibility beyond what they are authorized for by assuming the identity of other tenants.
To mitigate this risk, organizations running AiSOC versions between 7.5.0 and 12.0.0 must immediately upgrade to version 12.0.0 or later where this hard-coded fallback has been removed or secured. For environments that cannot be upgraded instantly, it is imperative to ensure the AISOC_REALTIME_JWT_SECRET environment variable is set with a strong, randomly generated secret key before starting any AiSOC services. Administrators should audit their deployment configurations to verify that no instances are running without this critical security parameter defined. Additionally, implementing network-level access controls for WebSocket and SSE endpoints can provide an additional layer of defense by restricting direct client connections until proper authentication is established at the application level. Regular security audits and configuration reviews should be conducted to prevent similar misconfigurations in future deployments.