GHSA-733v-p3h5-qpq7
MEDIUMGraphQL Armor Cost-Limit Plugin Bypass via Introspection Query Obfuscation
Blast Radius
@escape.tech/graphql-armor-cost-limitReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A query cost restriction using the cost-limit can be bypassed if ignoreIntrospection is enabled (which is the default configuration) by naming your query/fragment __schema.
Details
At the start of the computeComplexity function, we have the following check for ignoreIntrospection option:
if (this.config.ignoreIntrospection && 'name' in node && node.name?.value === '__schema') {
return 0;
}
However, the node can be FieldNode | FragmentDefinitionNode | InlineFragmentNode | OperationDefinitionNode | FragmentSpreadNode
So, for example, sending the following query
query hello {
books {
title
}
}
would create an OperationDefinitionNode with node.name.value == 'hello'
The proper way to handle this would be to check for the __schema field, which would create a FieldNode.
The fix is
if (
this.config.ignoreIntrospection &&
'name' in node &&
node.name?.value === '__schema' &&
node.kind === Kind.FIELD
) {
return 0;
}
to assert that the node must be a FieldNode
PoC
query {
...__schema
}
fragment __schema on Query {
books {
title
author
}
}
query __schema {
books {
title
author
}
}
Impact
Applications using GraphQL Armor Cost Limit plugin with ignoreIntrospection enabled.
Fix:
Fixed on 772. A quick patch would be to set ignoreIntrospection to false.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @escape.tech/graphql-armor-cost-limit | 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-cost-limit. 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-cost-limit to 2.4.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-733v-p3h5-qpq7 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-733v-p3h5-qpq7 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-733v-p3h5-qpq7. 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-733v-p3h5-qpq7 in your dependencies?
O3 detects GHSA-733v-p3h5-qpq7 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.