Security1 publisher2 min readPublished
GraphQL Java 24.4, 25.1 and 26.1 fix remote DoS flaws in query parsing and validation
Imperva found remote denial-of-service flaws in GraphQL Java's query parsing and validation, fixed in releases 24.4, 25.1 and 26.1. Imperva says the bugs sit ahead of the depth and cost limits most teams rely on, so exposure depends on the library version a stack ships.
The Watch · Security desk
What happened
- Imperva lists Adobe Experience Manager, Atlassian Confluence and the open-source HAPI FHIR healthcare server among affected products that embed the library.
- GraphQL Java is the engine beneath Spring for GraphQL, Netflix DGS and Atlassian's own products.
- The library has more than one million downloads a month and ten years of production use, according to Imperva.
- The flaws are tracked under advisory GHSA-7p4r-9rcc-8vhv, which Imperva describes as still in draft.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Going by Imperva's description, an attacker needs no knowledge of a target's schema or resolvers to aim these queries, so any reachable GraphQL Java endpoint is a candidate.
- decision Teams on Spring for GraphQL or Netflix DGS have to trace which GraphQL Java build their framework release resolves to and move it onto a fixed line.
- constraint Operators of products that bundle the library have to wait for each product vendor to ship a build with the fixed dependency.
- cost Imperva says GraphQL denial of service can surface as excess cost consumption in cloud-billed environments as well as outage, so an attack can land on the operator's bill.
Resolvers run last. A GraphQL Java server tokenises the query, builds a syntax tree from the tokens, and checks that tree against the schema before any resolver touches application data [16]. A request that fails the syntax or schema checks is rejected before execution [15].
Parsing does real work on attacker input. Block strings go through a dedicated normalisation routine that strips leading and trailing blank lines, and numeric literals become BigInteger or BigDecimal objects as the tree is built [10]. Validation checks fields and argument types. It also walks named fragments to confirm that none forms a cycle, directly or transitively [11].
Depth limits, complexity budgets and field caps came out of earlier rounds of GraphQL denial-of-service findings [4]. Apollo added query cost analysis and depth limiting, GitHub meters its public GraphQL API by computed node cost, and GraphQL Java added its own controls [4]. In GraphQL Java 26.0, maxDepth and maxFieldsCount are checked during validation [12]. Imperva puts the attacks it found in the parse and validation half of the pipeline [6]. Imperva wrote that the added controls "can leave blind spots earlier in the pipeline, before the server has even understood the request" [5].
A 26.0 server runs those validation-stage checks and is still one minor release short of the fix [2]. The attacker's payoff is an outage, because these are denial-of-service flaws [1]. One research team found this library defect [1]. The write-up does not say whether the flaws have been exploited in the wild, or which Spring for GraphQL and DGS releases pull in a fixed GraphQL Java. The upstream fix covers three release lines [1].
Imperva says endpoints behind its web application firewall are already protected [14]. That is the vendor's claim about its own product. Every other deployment gets its protection from the library upgrade [8].
What to watch
- GHSA-7p4r-9rcc-8vhv leaving draft with a CVE and published affected-version ranges.
- Atlassian, Adobe and HAPI FHIR releases that bundle a fixed GraphQL Java.
- Spring for GraphQL and Netflix DGS releases that bump their GraphQL Java dependency to 24.4, 25.1 or 26.1.