Description

deepstream is a server that allows clients and backend services to sync data, send messages and make rpcs at scale. From 10.1.0 until 10.1.1, src/services/permission/valve/rules-map.ts omits RECORD_ACTION.PATCH_MULTI from RULES_MAP. When an authenticated user sends a PATCH_MULTI record operation while permission.type is config, getRulesForMessage returns a null rule specification and ConfigPermission.canPerformAction treats the missing specification as an unconditional allow instead of applying RULE_TYPES.WRITE. Any authenticated user can therefore modify arbitrary protected records, corrupt application state, or cause service disruption; deployments using the default permission type none already allow all operations and are not additionally affected. This issue is fixed in version 10.1.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-21T17:17:38.510Z",
  "pubdate": "2026-09-21T17:17:38.510Z",
  "executiveSummary": "The vulnerability involves an improper authorization check within the Deepstream server, specifically affecting versions 10.1.0 through 10.1.1. The flaw resides in the handling of the RECORD_ACTION.PATCH_MULTI operation when the permission system is configured as 'config'. Due to an omission in the RULES_MAP within the src/services/permission/valve/rules-map.ts file, the system fails to retrieve a valid rule specification for this specific action.\nConsequently, the ConfigPermission.canPerformAction function incorrectly defaults to an unconditional allow state rather than enforcing the required RULE_TYPES.WRITE permissions. This allows any authenticated user to bypass configured security constraints and execute unauthorized modifications on protected records. The security impact is severe, as it grants attackers the ability to corrupt application state, perform unauthorized data manipulation, or trigger service disruptions. Exploitation requires the attacker to be authenticated, but does not necessitate additional administrative privileges if the environment is configured with the 'config' permission type. Systems already configured with the 'none' permission type are not further impacted as they are inherently permissive.",
  "technicalDetails": "The root cause of this vulnerability is a logic flaw located in src/services/permission/valve/rules-map.ts, which maps record operations to their corresponding permission definitions. In the affected versions (10.1.0 to 10.1.1), the constant RULES_MAP explicitly omits the entry for RECORD_ACTION.PATCH_MULTI. This omission causes a breakage in the permission resolution logic during the server's request handling cycle.\nWhen an authenticated client transmits a PATCH_MULTI request while the permission system is set to type 'config', the system invokes getRulesForMessage to determine the governing security policy. Because the action is missing from the map, the function returns a null rule specification. The downstream logic in ConfigPermission.canPerformAction encounters this null value and, due to insecure default handling, treats the missing specification as an unconditional 'allow'.\nThe attack flow proceeds as follows: 1) An authenticated user crafts a PATCH_MULTI request directed at a protected record that should otherwise be restricted by the configured permission policies. 2) The server's permission module queries the RULES_MAP to identify the authorization requirements. 3) The lookup returns null for the PATCH_MULTI action. 4) The server's validation logic incorrectly defaults to grant access, bypassing the intended RULE_TYPES.WRITE check that would typically ensure the user has appropriate privileges to modify the record. 5) The server processes the unauthorized update request, applying the state change to the backend service. This post-exploitation impact allows for arbitrary record modification, data integrity compromise, and potential service-wide instability if critical system records are targeted. This vulnerability is restricted to authenticated users but bypasses all granular permission controls, effectively escalating the privileges of any standard user to that of an authorized record editor for the affected actions."
}