Evidence used
- No CISA KEV confirmation is currently recorded.
- The selected CVSS metric records a network-reachable, unauthenticated path with no user interaction.
- EPSS is 0.83% for the current model date.
BlackTreeCVE Intelligencetypelevel · grackle
Official source article: GitHub GHSA-G56X-7J6W-G8R8 ↗. Check the applicable product and release in the original source.
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Patch availableGrackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.
Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.
The product does not properly control the allocation and maintenance of a limited resource.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may disrupt the affected service.
Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.
The product does not properly control the allocation and maintenance of a limited resource.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may disrupt the affected service.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-400: Uncontrolled Resource Consumption. The product does not properly control the allocation and maintenance of a limited resource.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 22 Dec 2023 · Last source change 2 Aug 2024, 22:16 UTC · CWE-400 · Uncontrolled Resource Consumption
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.