GHSA-hmfr-rx46-4jx2
MEDIUMGraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@escape.tech/graphql-armor-max-depthnpmDescription
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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @escape.tech/graphql-armor-max-depth | all versions | 2.4.2 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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.
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
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.