CVE-2026-128065: Authorization Bypass via Unapplied RBAC Overrides in @grpc/grpc-js-xds

The @grpc/grpc-js-xds package implements xDS (Discovery Service) client and server functionality for the pure-JavaScript Node.js gRPC implementation (@grpc/grpc-js). In modern service mesh architectures, xDS servers receive dynamic configuration updates—including Listener Discovery Service (LDS) and Route Discovery Service (RDS) resources—from a centralized control plane such as Istio or Envoy-based management servers. Among these features, XdsServer supports experimental Role-Based Access Control (RBAC) via HTTP filters to enforce fine-grained access policies on incoming gRPC calls.

In accordance with the Envoy xDS specification, HTTP filters are configured at the top-level HttpConnectionManager within a Listener resource, while more granular overrides can be defined per VirtualHost or per Route using the typed_per_filter_config map. This hierarchical design allows administrators to specify a baseline security policy at the listener level and selectively tighten or relax restrictions for specific domains or gRPC methods.

CVE-2026-128065 (tracked as GHSA-gg5j-6742-v827) is an Incorrect Authorization vulnerability (CWE-863) affecting @grpc/grpc-js-xds versions 1.14.0 and 1.14.1. Due to three compounding implementation defects in how XdsServer registers, keys, and parses per-route filter configurations, all RBACPerRoute overrides specified within VirtualHost and Route resources are silently discarded.

Because the server still sends positive acknowledgments (ACKs) for the RDS and LDS updates back to the xDS control plane, operators receive no indication that the security policies failed to apply. When a deployment configures a permissive top-level RBAC policy (such as ALLOW all) and relies on route-level or virtual-host-level DENY or restricted ALLOW overrides to protect sensitive RPC methods, incoming requests bypass the intended restrictions and execute with unauthorized privileges.

The authorization bypass stems from three distinct logic defects in @grpc/grpc-js-xds across packages/grpc-js-xds/src/http-filter/rbac-filter.ts and packages/grpc-js-xds/src/server.ts. Each defect independently prevents RBAC override policies from taking effect during request routing.

The first defect is a protobuf type URL registration mismatch in rbac-filter.ts. When parseOverrideFilterConfig() in http-filter.ts processes an entry from typed_per_filter_config, it queries the internal FILTER_REGISTRY using the protobuf @type URL embedded in the configuration message. While top-level Envoy RBAC filters use the type URL type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC, route and virtual host overrides use a distinct protobuf message type: type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute. During module initialization, setup() in rbac-filter.ts registered the RBAC filter parser solely under the top-level RBAC type URL and omitted RBAC_FILTER_OVERRIDE_URL. Consequently, every invocation of parseOverrideFilterConfig() for an RBACPerRoute resource failed the registry lookup and returned null.

The second defect is a map key mismatch within the FilterChainEntry class in packages/grpc-js-xds/src/server.ts. When initializing top-level HTTP filters for a listener filter chain, the server creates a per-filter map (filterOverrideConfigMap) to store route-specific override configurations and registers it inside this.overrideConfigMaps. However, the vulnerable code indexed this.overrideConfigMaps using filterConfig.typeUrl (the protobuf type URL) rather than filter.name (the HTTP filter instance name). Per the Envoy xDS specification, the typed_per_filter_config dictionary in Route and VirtualHost messages is keyed by the filter instance name (e.g., "rbac"). When the route processor subsequently attempted to store parsed overrides via this.overrideConfigMaps.get(filterName), the lookup missed and the configuration was dropped.

The third defect is the complete omission of VirtualHost per-filter configuration parsing in server.ts. While FilterChainEntry iterated over route.typed_per_filter_config for individual routes, it contained no logic to inspect virtualHost.typed_per_filter_config. Any RBAC overrides applied at the VirtualHost level were never parsed or inherited by the child routes belonging to that virtual host.

> [!NOTE] > Because all three failures occur silently during asynchronous xDS resource ingestion without throwing exceptions or triggering NACK responses, the control plane assumes the security policy is active while XdsServer falls back exclusively to the top-level filter configuration.

Commit b8f3ced4d4699338dd33dc0f7b1d68d689a31d0e addresses all three root causes across rbac-filter.ts and server.ts. In packages/grpc-js-xds/src/http-filter/rbac-filter.ts, the setup() function was updated to register both the base filter type URL and the override filter type URL (RBAC_FILTER_OVERRIDE_URL) in the HTTP filter registry.

File: packages/grpc-js-xds/src/http-filter/rbac-filter.ts
@@ -171,5 +171,10 @@ export function setup() {
       parseOverrideFilterConfig: parseOverrideRbacConfig,
       createServerFilter: createRbacServerFilter
     });
+    // Register the RBACPerRoute protobuf type URL so parseOverrideFilterConfig resolves it
+    registerHttpFilter(RBAC_FILTER_OVERRIDE_URL, {
+      parseTopLevelFilterConfig: parseTopLevelRbacConfig,
+      parseOverrideFilterConfig: parseOverrideRbacConfig,
+      createServerFilter: createRbacServerFilter
+    });
   }
 }

In packages/grpc-js-xds/src/server.ts, the patch modifies FilterChainEntry in two places. First, when initializing the filter chain interceptors, this.overrideConfigMaps is updated to use filter.name as the map key instead of filterConfig.typeUrl, aligning the internal storage structure with the keys provided in xDS typed_per_filter_config maps.

File: packages/grpc-js-xds/src/server.ts
@@ -170,7 +170,7 @@ class FilterChainEntry {
       const filterConfig = parseTopLevelFilterConfig(filter.typed_config!, false);
       if (filterConfig) {
         const filterOverrideConfigMap = new Map<string, HttpFilterConfig>();
-        this.overrideConfigMaps.set(filterConfig.typeUrl, filterOverrideConfigMap);
+        this.overrideConfigMaps.set(filter.name, filterOverrideConfigMap);
         const filterInterceptor = createServerHttpFilter(filterConfig, filterOverrideConfigMap);
         if (filterInterceptor) {
           httpFilterInterceptors.push(filterInterceptor);

Second, the route configuration ingestion loop in FilterChainEntry was restructured to parse virtualHost.typed_per_filter_config into a temporary virtualHostOverrideConfigs map before iterating over child routes. For each route and each registered filter name, the server now assigns the VirtualHost override as the baseline and supersedes it if a more specific override exists in route.typed_per_filter_config.

File: packages/grpc-js-xds/src/server.ts
@@ -227,6 +227,14 @@ class FilterChainEntry {
         domains: virtualHost.domains,
         routes: []
       };
+      // Parse VirtualHost-level per-filter overrides keyed by filter name
+      const virtualHostOverrideConfigs = new Map<string, HttpFilterConfig>()
+      for (const [filterName, overrideConfig] of Object.entries(virtualHost.typed_per_filter_config)) {
+        const parsedConfig = parseOverrideFilterConfig(overrideConfig);
+        if (parsedConfig) {
+          virtualHostOverrideConfigs.set(filterName, parsedConfig);
+        }
+      }
       for (const [routeIndex, route] of virtualHost.routes.entries()) {
         const routeEntry: RouteEntry = {
           id: `virtualhost=${virtualHostIndex} route=${routeIndex}`,
@@ -238,10 +246,19 @@ class FilterChainEntry {
           this.logConfigurationError('For domains matching [' + virtualHostEntry.domains + '] requests will be rejected for routes matching ' + routeEntry.matcher.toString());
         }
         virtualHostEntry.routes.push(routeEntry);
-        for (const [filterName, overrideConfig] of Object.entries(route.typed_per_filter_config)) {
-          const parsedConfig = parseOverrideFilterConfig(overrideConfig);
-          if (parsedConfig) {
-            this.overrideConfigMaps.get(filterName)?.set(routeEntry.id, parsedConfig);
+        for (const filterName of this.overrideConfigMaps.keys()) {
+          // Inherit the VirtualHost override by default
+          let routeOverrideConfig = virtualHostOverrideConfigs.get(filterName);
+          if (filterName in route.typed_per_filter_config) {
+            const parsedConfig = parseOverrideFilterConfig(route.typed_per_filter_config[filterName]);
+            if (parsedConfig) {
+              /* Route-level override takes precedence over VirtualHost override */
+              routeOverrideConfig = parsedConfig;
+            }
+          }
+          if (routeOverrideConfig) {
+            this.overrideConfigMaps.get(filterName)!.set(routeEntry.id, routeOverrideConfig);
           }
         }
       }

The fix is complete with respect to VirtualHost and Route resources in @grpc/grpc-js-xds. By iterating directly over this.overrideConfigMaps.keys(), the patched implementation ensures that only active filters configured in the filter chain are evaluated, and that route-specific rules properly override virtual-host-level rules according to the Envoy xDS specification.

Exploiting CVE-2026-128065 does not require crafting malformed network packets or subverting the xDS control plane. Instead, the vulnerability manifests passively whenever a target deployment uses @grpc/grpc-js-xds (versions 1.14.0 or 1.14.1) with experimental server RBAC enabled and relies on RBACPerRoute overrides to restrict access to specific gRPC services or methods.

To trigger the unauthorized access, an attacker only needs network connectivity to the exposed XdsServer port and the ability to invoke gRPC methods that are nominally restricted by a VirtualHost or Route override policy. No special authentication credentials or headers are required if the top-level HTTP filter is configured with a wildcard principal (principals: [{any: true}]) and an ALLOW action.

The official regression test suite (packages/grpc-js-xds/test/test-rbac-filter.ts) included in the patch demonstrates the exact configuration structure that triggers the bypass. In this scenario, the top-level RBAC filter permits all traffic, while a VirtualHost or Route resource defines an RBACPerRoute override with a DENY action for all principals:

// Top-level HTTP Filter Configuration: Permissive baseline policy
const rbacFilter: AnyExtension & RBAC = {
  '@type': 'type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC',
  rules: {
    action: 'ALLOW',
    policies: {
      local: {
        principals: [{any: true}],
        permissions: [{any: true}]
      }
    }
  }
};
 
// Per-Route / VirtualHost Override Configuration: Restrictive DENY policy
const overrideConfig: AnyExtension & RBACPerRoute = {
  '@type': 'type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute',
  rbac: {
    rules: {
      action: 'DENY',
      policies: {
        local: {
          principals: [{any: true}],
          permissions: [{any: true}]
        }
      }
    }
  }
};
 
// RouteConfiguration delivered via RDS/LDS
const routeConfiguration: RouteConfiguration = {
  virtual_hosts: [{
    domains: ['*'],
    routes: [{
      match: { prefix: '' },
      action: 'non_forwarding_action',
      non_forwarding_action: {},
      typed_per_filter_config: { rbac: overrideConfig }
    }]
  }]
};

When a gRPC client sends a unary or streaming RPC matching prefix: '' to an unpatched server running this configuration, XdsServer matches the route (virtualhost=0 route=0) and invokes the RBAC filter interceptor. The interceptor checks filterOverrideConfigMap.get('virtualhost=0 route=0'), receives undefined because the override failed to register during RDS ingestion, and evaluates the request against rbacFilter. The call succeeds with gRPC status 0 (OK) instead of being rejected with status 7 (PERMISSION_DENIED).

The primary security impact of CVE-2026-128065 is an authorization bypass (CWE-863) that permits unauthenticated or under-privileged clients to invoke restricted gRPC endpoints. In microservice environments managed by an xDS control plane, administrators frequently define a baseline listener configuration shared across multiple services and apply route-specific RBAC policies to isolate administrative endpoints, internal health checks, or privileged data mutation methods.

When affected versions of @grpc/grpc-js-xds are deployed in this manner, any client capable of reaching the gRPC listener can invoke routes that were explicitly configured with DENY rules or narrower principal requirements in RBACPerRoute. The concrete impact depends on the functionality exposed by the unprotected gRPC methods, ranging from unauthorized disclosure of application data (Confidentiality: Low) to unauthorized state modification (Integrity: Low).

The vulnerability is scored at CVSS v4.0 Base Score 6.9 (Medium) with the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. The Attack Vector is Network (AV:N) with Low Attack Complexity (AC:L) and No Attack Requirements (AT:N), reflecting that standard gRPC requests over the network directly bypass the unapplied filter rules without requiring race conditions or environmental manipulation.

Privilege Required (PR:N) and User Interaction (UI:N) are both None, as the bypass occurs during automated policy evaluation prior to method execution. Scope is limited to the vulnerable gRPC server (SC:N/SI:N/SA:N), and availability is unaffected (VA:N) because the flaw does not cause resource exhaustion or process termination.

Development and operations teams using @grpc/grpc-js-xds to host xDS-enabled gRPC servers in Node.js should upgrade to version 1.14.2 or later immediately. Version 1.14.2 incorporates commit b8f3ced4d4699338dd33dc0f7b1d68d689a31d0e, which registers the RBACPerRoute type URL, keys override maps by filter instance name, and enforces the proper inheritance hierarchy between VirtualHost and Route configurations.

Update the dependency specification in package.json and regenerate the lockfile:

{
  "dependencies": {
    "@grpc/grpc-js-xds": "^1.14.2"
  }
}

If an immediate library upgrade is not operationally feasible, administrators must modify their xDS control plane policies to avoid relying on typed_per_filter_config within VirtualHost or Route resources for access control. Instead, consolidate all authorization rules directly into the top-level envoy.extensions.filters.http.rbac.v3.RBAC filter configuration attached to the Listener's HttpConnectionManager.

Within the top-level RBAC filter, route-specific restrictions can be expressed using Envoy Permission rules that match on HTTP :path headers (corresponding to /package.Service/Method in gRPC) combined with Principal definitions. Alternatively, enforce method-level authentication and authorization directly within the Node.js application layer using native @grpc/grpc-js server interceptors until @grpc/grpc-js-xds can be patched.