Every CVESearch/Get API key

GHSA-hmfr-rx46-4jx2

GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation

5.3 MediumFix available

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

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
Low

What each source reports

GitHub Advisories Score used5.3

GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation

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

Record
GHSA-hmfr-rx46-4jx2
CVSS 3.0
5.3 MediumCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weakness
CWE-400
Updated
2026-11-02
OSV5.3

GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation

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

Record
GHSA-hmfr-rx46-4jx2
CVSS 3.0
5.3 MediumCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weakness
CWE-400
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
@escape.tech/graphql-armor-max-depth
npm
through 2.4.1
2.4.2
@escape.tech/graphql-armor-max-depth
npm
before 2.4.2
2.4.2

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

GHSA-hmfr-rx46-4jx2 is a medium vulnerability (CVSS 5.3) in @escape.tech/graphql-armor-max-depth, published August 26, 2025. No source lists public exploit code. Fixed in @escape.tech/graphql-armor-max-depth 2.4.2.

References

MoveEnter Open