Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A 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. Details In the countDepth function, we have the following code that calculates the depth of a used fragment: which 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. The 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. So, for example, sending the following query with a max depth of 6: The first use of Test fragment does not exceed the defined limit, and this depth will be cached. In the second use, the fragment is reused in a greater depth, but the countDepth function…
Recommended action: Upgrade to 2.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: However, the node can be one of: FieldNode, FragmentDefinitionNode, InlineFragmentNode, OperationDefinitionNode, FragmentSpreadNode. For example, consider sending the following query: 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 This ensures that the node is explicitly a FieldNode. PoC Max depth: 6 Impact This issue affects applications using the GraphQL Armor Depth Limit plugin with ignoreIntrospection enabled. Fix This is fixed in PR#823
Recommended action: Upgrade to 2.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.