Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-hmfr-rx46-4jx2

MEDIUM

GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation

Published
Aug 26, 2025
Updated
Aug 26, 2025
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

@escape.tech/graphql-armor-max-depthnpm
306Kdownloads / week

Description

Summary

A query depth restriction using the max-depth property can be bypassed if ignoreIntrospection is enabled (which is the default configuration) by naming your query/fragment __schema.

Details

At the start of the countDepth function, we have the following check for the ignoreIntrospection option:

    if (this.config.ignoreIntrospection && 'name' in node && node.name?.value === '__schema') {
        return 0;
    }

However, the node can be one of: FieldNode, FragmentDefinitionNode, InlineFragmentNode, OperationDefinitionNode, FragmentSpreadNode.

For example, consider sending the following query:

query hello {
  books {
    title
  }
}

This would create an OperationDefinitionNode where node.name.value == 'hello'

The proper way to handle this is to check explicitly for the __schema field, which corresponds to a FieldNode.

The fix is

    if (
      this.config.ignoreIntrospection &&
      'name' in node &&
      node.name?.value === '__schema' &&
      node.kind === Kind.FIELD
    ) {
      return 0;
    }

This ensures that the node is explicitly a FieldNode.

PoC

Max depth: 6

query {
  books {
    author {
      books {
        author {
          ...__schema
        }
      }
    }
  }
}
fragment __schema on Author {
  books {
    title
  }
}

Impact

This issue affects applications using the GraphQL Armor Depth Limit plugin with ignoreIntrospection enabled.

Fix

This is fixed in PR#823

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@escape.tech/graphql-armor-max-depthall versions2.4.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @escape.tech/graphql-armor-max-depth. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update @escape.tech/graphql-armor-max-depth to 2.4.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hmfr-rx46-4jx2 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-hmfr-rx46-4jx2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-hmfr-rx46-4jx2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary A query depth restriction using the `max-depth` property can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`. ### Details At the start of the `countDepth` function, we have the following check for the `ignoreIntrospection` option: ```typescript if (this.config.ignoreIntrospection && 'name' in node && node.name?.value === '__schema') { return 0; } ``` However, the `node` can be one of: `FieldNode`, `FragmentDefinitionNode`, `InlineFragmentNode`, `OperationDefinitionNode`, `FragmentSpread
O3 Security · Impact-Aware SCA

Is GHSA-hmfr-rx46-4jx2 in your dependencies?

O3 detects GHSA-hmfr-rx46-4jx2 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.