GHSA-89VX-JH4Q-VG3W

Vulnerability from github – Published: 2026-09-22 19:56 – Updated: 2026-09-22 19:56
VLAI
Summary
deepstream: PATCH_MULTI action bypasses Valve permission system allowing unauthorized record writes
Details

Summary

The RECORD_ACTION.PATCH_MULTI action is not registered in the Valve permission system's RULES_MAP (src/services/permission/valve/rules-map.ts). When ConfigPermission.canPerformAction() is called for a PATCH_MULTI message, getRulesForMessage() returns null because the action is missing from the map. This triggers an unconditional allow (callback(..., null, true)), completely bypassing all configured Valve permission rules.

Any authenticated user — regardless of their configured permissions — can write arbitrary data to any record using the PATCH_MULTI action.

Root Cause

In src/services/permission/valve/rules-map.ts lines 38-54, the RULES_MAP[TOPIC.RECORD].actions dictionary maps record actions to permission rule types. The actions registered include: SUBSCRIBE, SUBSCRIBEANDHEAD, SUBSCRIBEANDREAD, READ, HEAD, LISTEN, CREATE, UPDATE, PATCH, NOTIFY, DELETE, ERASE. However, RECORD_ACTION.PATCH_MULTI is absent from this map.

When getRulesForMessage() at line 86-99 encounters an action not in the map, it returns null. In config-permission.ts at line 88-93, when ruleSpecification === null, the callback is invoked with true (allow) unconditionally.

Attack Chain

  1. Attacker authenticates with any valid credentials (even a minimal-privilege user)
  2. Attacker sends a WebSocket message: {topic: RECORD, action: PATCH_MULTI, name: "admin/secret-record", parsedData: [{path: "role", data: "admin"}]}
  3. message-processor.ts:68 invokes permission check
  4. config-permission.ts:89 → getRulesForMessage() returns null for PATCH_MULTI
  5. config-permission.ts:92 → unconditional ALLOW
  6. Record transition applies the operations — arbitrary record is modified

Impact

  • Complete Valve permission bypass for record writes — all configured permission rules are irrelevant
  • Any authenticated user can overwrite any record, including admin-only records
  • Mass record overwrites can destroy application state, corrupt sessions, cause service outage
  • Only exploitable when permission.type is set to config (Valve) — the recommended production configuration per deepstream documentation
  • Default permission type none (OpenPermission) allows everything already, so default deployments are unaffected
Proof of Concept
// Connect as a minimal-privilege user
const { DeepstreamClient } = require('@deepstream/client');
const client = new DeepstreamClient('localhost:6020');
await client.login({ username: 'restricted-user', password: 'password' });

// This should be blocked by Valve permissions but isn't:
// Send raw PATCH_MULTI message to bypass all permission rules
const connection = client.getConnection();
connection.sendMessage({
  topic: 0x52, // TOPIC.RECORD
  action: 0x50, // RECORD_ACTION.PATCH_MULTI (check actual enum value)
  name: 'admin/protected-record',
  parsedData: [
    { path: 'permissions', data: 'admin' },
    { path: 'secret', data: 'overwritten' }
  ]
});

Suggested Fix

Add PATCH_MULTI to the RULES_MAP in src/services/permission/valve/rules-map.ts:

[RECORD_ACTION.PATCH_MULTI]: RULE_TYPES.WRITE,

This maps PATCH_MULTI operations to the same WRITE permission rule that governs UPDATE and PATCH.

Affected Versions

All versions that include PATCH_MULTI support with the Valve (ConfigPermission) permission system. The PATCH_MULTI action was added in commit 82ffa8119d8f4a8242ac5c3507469a22de746b65 but was never registered in RULES_MAP.

Credit

Vulnerability discovered by Zhixi "Jace" Sun of ASM/VI at TikTok.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@deepstream/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "10.1.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T19:56:34Z",
    "nvd_published_at": "2026-09-21T17:17:38Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `RECORD_ACTION.PATCH_MULTI` action is not registered in the Valve permission system\u0027s `RULES_MAP` (`src/services/permission/valve/rules-map.ts`). When `ConfigPermission.canPerformAction()` is called for a PATCH_MULTI message, `getRulesForMessage()` returns `null` because the action is missing from the map. This triggers an unconditional allow (`callback(..., null, true)`), completely bypassing all configured Valve permission rules.\n\nAny authenticated user \u2014 regardless of their configured permissions \u2014 can write arbitrary data to any record using the PATCH_MULTI action.\n\n## Root Cause\n\nIn `src/services/permission/valve/rules-map.ts` lines 38-54, the `RULES_MAP[TOPIC.RECORD].actions` dictionary maps record actions to permission rule types. The actions registered include: SUBSCRIBE, SUBSCRIBEANDHEAD, SUBSCRIBEANDREAD, READ, HEAD, LISTEN, CREATE, UPDATE, PATCH, NOTIFY, DELETE, ERASE. However, `RECORD_ACTION.PATCH_MULTI` is **absent** from this map.\n\nWhen `getRulesForMessage()` at line 86-99 encounters an action not in the map, it returns `null`. In `config-permission.ts` at line 88-93, when `ruleSpecification === null`, the callback is invoked with `true` (allow) unconditionally.\n\n## Attack Chain\n\n1. Attacker authenticates with any valid credentials (even a minimal-privilege user)\n2. Attacker sends a WebSocket message: `{topic: RECORD, action: PATCH_MULTI, name: \"admin/secret-record\", parsedData: [{path: \"role\", data: \"admin\"}]}`\n3. `message-processor.ts:68` invokes permission check\n4. `config-permission.ts:89` \u2192 `getRulesForMessage()` returns `null` for PATCH_MULTI\n5. `config-permission.ts:92` \u2192 unconditional ALLOW\n6. Record transition applies the operations \u2014 arbitrary record is modified\n\n## Impact\n\n- **Complete Valve permission bypass for record writes** \u2014 all configured permission rules are irrelevant\n- Any authenticated user can overwrite any record, including admin-only records\n- Mass record overwrites can destroy application state, corrupt sessions, cause service outage\n- Only exploitable when `permission.type` is set to `config` (Valve) \u2014 the recommended production configuration per deepstream documentation\n- Default permission type `none` (OpenPermission) allows everything already, so default deployments are unaffected\n\n\u003cdetails\u003e\u003csummary\u003eProof of Concept\u003c/summary\u003e\n\n```javascript\n// Connect as a minimal-privilege user\nconst { DeepstreamClient } = require(\u0027@deepstream/client\u0027);\nconst client = new DeepstreamClient(\u0027localhost:6020\u0027);\nawait client.login({ username: \u0027restricted-user\u0027, password: \u0027password\u0027 });\n\n// This should be blocked by Valve permissions but isn\u0027t:\n// Send raw PATCH_MULTI message to bypass all permission rules\nconst connection = client.getConnection();\nconnection.sendMessage({\n  topic: 0x52, // TOPIC.RECORD\n  action: 0x50, // RECORD_ACTION.PATCH_MULTI (check actual enum value)\n  name: \u0027admin/protected-record\u0027,\n  parsedData: [\n    { path: \u0027permissions\u0027, data: \u0027admin\u0027 },\n    { path: \u0027secret\u0027, data: \u0027overwritten\u0027 }\n  ]\n});\n```\n\u003c/details\u003e\n\n## Suggested Fix\n\nAdd `PATCH_MULTI` to the RULES_MAP in `src/services/permission/valve/rules-map.ts`:\n\n```typescript\n[RECORD_ACTION.PATCH_MULTI]: RULE_TYPES.WRITE,\n```\n\nThis maps PATCH_MULTI operations to the same WRITE permission rule that governs UPDATE and PATCH.\n\n## Affected Versions\n\nAll versions that include PATCH_MULTI support with the Valve (ConfigPermission) permission system. The PATCH_MULTI action was added in commit `82ffa8119d8f4a8242ac5c3507469a22de746b65` but was never registered in RULES_MAP.\n\n## Credit\n\nVulnerability discovered by Zhixi \"Jace\" Sun of ASM/VI at TikTok.",
  "id": "GHSA-89vx-jh4q-vg3w",
  "modified": "2026-09-22T19:56:34Z",
  "published": "2026-09-22T19:56:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/deepstreamIO/deepstream.io/security/advisories/GHSA-89vx-jh4q-vg3w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/deepstreamIO/deepstream.io/commit/1c2adde6581c53ef47e204364bc740bc3c2e2e2a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/deepstreamIO/deepstream.io"
    },
    {
      "type": "WEB",
      "url": "https://github.com/deepstreamIO/deepstream.io/releases/tag/v10.1.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "deepstream: PATCH_MULTI action bypasses Valve permission system allowing unauthorized record writes"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…