{"id":"GHSA-224p-v68g-5g8f","aliases":[],"status":"published","title":"GraphQL Armor Max-Depth Plugin Bypass via fragment caching","description":"### Summary\nA query depth restriction using the max-depth can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`.\n\n### Details\nIn the `countDepth` function, we have the following code that calculates the depth of a used fragment:\n\n```typescript\n    } else if (node.kind == Kind.FRAGMENT_SPREAD) {\n      if (this.visitedFragments.has(node.name.value)) {\n        return this.visitedFragments.get(node.name.value) ?? 0;\n      } else {\n        this.visitedFragments.set(node.name.value, -1);\n      }\n      const fragment = this.context.getFragment(node.name.value);\n      if (fragment) {\n        let fragmentDepth;\n        if (this.config.flattenFragments) {\n          fragmentDepth = this.countDepth(fragment, parentDepth);\n        } else {\n          fragmentDepth = this.countDepth(fragment, parentDepth + 1);\n        }\n        depth = Math.max(depth, fragmentDepth);\n        if (this.visitedFragments.get(node.name.value) === -1) {\n          this.visitedFragments.set(node.name.value, fragmentDepth);\n        }\n      }\n    }\n```\n\nwhich will calculate the depth of the fragment used in the current node, store the value in `this.visitedFragments` and re-use it in the future to avoid re-calculating the depth for the same fragment.\n\nThe issue arises when the same fragment is used multiple times, **at different depths**. The current caching takes into account the depth of the first occurrence, which means if the fragment is re-used later in a higher depth, this cached value is not updated.\n\nSo, for example, sending the following query with a max depth of `6`:\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\nThe first use of `Test` fragment does not exceed the defined limit, and this depth will be cached.\n\nIn the second use, the fragment is reused in a greater depth, but the `countDepth` function will still use the depth cached, without accounting for the increased depth.\n\n### PoC\n\nMax depth: `6`\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\n### Impact\n\nThis issue affects applications using the GraphQL Armor Depth Limit plugin.\n\n### Fix\n\nThis is fixed in [PR#824](https://github.com/Escape-Technologies/graphql-armor/pull/824). We now store only the additional depth contributed by the fragment and add it to the parent depth where the fragment is used (`parentDepth`).","severity":{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400"],"published":"2025-08-26T18:45:55Z","modified":"2025-08-26T18:45:55Z","fixes":[{"ecosystem":"npm","package":"@escape.tech/graphql-armor-max-depth","fixed_in":["2.4.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@escape.tech/graphql-armor-max-depth","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.4.1"},{"fixed":"2.4.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@escape.tech/graphql-armor-max-depth","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.4.2"}]}]}],"references":[{"url":"https://github.com/Escape-Technologies/graphql-armor/security/advisories/GHSA-224p-v68g-5g8f","tags":["web"]},{"url":"https://github.com/Escape-Technologies/graphql-armor/pull/824","tags":["web"]},{"url":"https://github.com/Escape-Technologies/graphql-armor/commit/998986109f8c2313bd61325ddfe7f5dcd48f9232","tags":["web"]},{"url":"https://github.com/advisories/GHSA-224p-v68g-5g8f"},{"url":"https://github.com/Escape-Technologies/graphql-armor","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-224p-v68g-5g8f","title":"GraphQL Armor Max-Depth Plugin Bypass via fragment caching","description":"### Summary\nA query depth restriction using the max-depth can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`.\n\n### Details\nIn the `countDepth` function, we have the following code that calculates the depth of a used fragment:\n\n```typescript\n    } else if (node.kind == Kind.FRAGMENT_SPREAD) {\n      if (this.visitedFragments.has(node.name.value)) {\n        return this.visitedFragments.get(node.name.value) ?? 0;\n      } else {\n        this.visitedFragments.set(node.name.value, -1);\n      }\n      const fragment = this.context.getFragment(node.name.value);\n      if (fragment) {\n        let fragmentDepth;\n        if (this.config.flattenFragments) {\n          fragmentDepth = this.countDepth(fragment, parentDepth);\n        } else {\n          fragmentDepth = this.countDepth(fragment, parentDepth + 1);\n        }\n        depth = Math.max(depth, fragmentDepth);\n        if (this.visitedFragments.get(node.name.value) === -1) {\n          this.visitedFragments.set(node.name.value, fragmentDepth);\n        }\n      }\n    }\n```\n\nwhich will calculate the depth of the fragment used in the current node, store the value in `this.visitedFragments` and re-use it in the future to avoid re-calculating the depth for the same fragment.\n\nThe issue arises when the same fragment is used multiple times, **at different depths**. The current caching takes into account the depth of the first occurrence, which means if the fragment is re-used later in a higher depth, this cached value is not updated.\n\nSo, for example, sending the following query with a max depth of `6`:\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\nThe first use of `Test` fragment does not exceed the defined limit, and this depth will be cached.\n\nIn the second use, the fragment is reused in a greater depth, but the `countDepth` function will still use the depth cached, without accounting for the increased depth.\n\n### PoC\n\nMax depth: `6`\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\n### Impact\n\nThis issue affects applications using the GraphQL Armor Depth Limit plugin.\n\n### Fix\n\nThis is fixed in [PR#824](https://github.com/Escape-Technologies/graphql-armor/pull/824). We now store only the additional depth contributed by the fragment and add it to the parent depth where the fragment is used (`parentDepth`).","status":"published","published":"2025-08-26T18:45:55Z","modified":"2025-08-26T18:45:55Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:38:54.795089Z"}],"osv":[{"id":"GHSA-224p-v68g-5g8f","title":"GraphQL Armor Max-Depth Plugin Bypass via fragment caching","description":"### Summary\nA query depth restriction using the max-depth can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`.\n\n### Details\nIn the `countDepth` function, we have the following code that calculates the depth of a used fragment:\n\n```typescript\n    } else if (node.kind == Kind.FRAGMENT_SPREAD) {\n      if (this.visitedFragments.has(node.name.value)) {\n        return this.visitedFragments.get(node.name.value) ?? 0;\n      } else {\n        this.visitedFragments.set(node.name.value, -1);\n      }\n      const fragment = this.context.getFragment(node.name.value);\n      if (fragment) {\n        let fragmentDepth;\n        if (this.config.flattenFragments) {\n          fragmentDepth = this.countDepth(fragment, parentDepth);\n        } else {\n          fragmentDepth = this.countDepth(fragment, parentDepth + 1);\n        }\n        depth = Math.max(depth, fragmentDepth);\n        if (this.visitedFragments.get(node.name.value) === -1) {\n          this.visitedFragments.set(node.name.value, fragmentDepth);\n        }\n      }\n    }\n```\n\nwhich will calculate the depth of the fragment used in the current node, store the value in `this.visitedFragments` and re-use it in the future to avoid re-calculating the depth for the same fragment.\n\nThe issue arises when the same fragment is used multiple times, **at different depths**. The current caching takes into account the depth of the first occurrence, which means if the fragment is re-used later in a higher depth, this cached value is not updated.\n\nSo, for example, sending the following query with a max depth of `6`:\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\nThe first use of `Test` fragment does not exceed the defined limit, and this depth will be cached.\n\nIn the second use, the fragment is reused in a greater depth, but the `countDepth` function will still use the depth cached, without accounting for the increased depth.\n\n### PoC\n\nMax depth: `6`\n\n```graphql\nquery {\n  books {\n    author {\n      ...Test\n    }\n  }\n  books {\n    author {\n      books {\n        author {\n          ...Test\n        }\n      }\n    }\n  }\n}\nfragment Test on Author {\n  books {\n    title\n  }\n}\n```\n\n### Impact\n\nThis issue affects applications using the GraphQL Armor Depth Limit plugin.\n\n### Fix\n\nThis is fixed in [PR#824](https://github.com/Escape-Technologies/graphql-armor/pull/824). We now store only the additional depth contributed by the fragment and add it to the parent depth where the fragment is used (`parentDepth`).","status":"published","published":"2025-08-26T18:45:55Z","modified":"2025-08-26T18:45:55Z","cvss":[{"version":"3.0","score":5.3,"vector":"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}
