GHSA-hmfr-rx46-4jx2 is a medium-severity (CVSS 5.3) vulnerability in @escape.tech/graphql-armor-max-depth. A fix is available for @escape.tech/graphql-armor-max-depth — see the affected versions and patch details below.
GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@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.2npm install @escape.tech/graphql-armor-max-depth@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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-hmfr-rx46-4jx2 can be triaged on real exposure rather than presence alone.
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 Security finds GHSA-hmfr-rx46-4jx2 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.