Resource exhaustion exploit when parsing queries about graphql-js HOT 7 CLOSED

Ran a bisect, discovered the performance degradation was 5caff03 (#3457). Raised #3958

cc: @IvanGoncharov

from graphql-js.

@IvanGoncharov or others on this thread. Can we please organise a release for v16? As per #3967.

I would argue this issue should not be marked complete until consumers can use a fixed version of this security/performance hole, on a stable (non-beta) release channel.

from graphql-js.

👋 Apollo Server maintainer here. Going to follow along on this issue to track updates. For @IvanGoncharov 's sake it would be nice to minimize the reproduction to exclude apollo server (and add certainty that it's a graphql-js problem).

from graphql-js.

@trevor-scheer I'll look at just testing against graphql-js this week and post an update

from graphql-js.

I've added a minimal graphql-js example in the same repo. You can run it using node graphql-js.mjs.

The slow parsing performance is still observed here

// 1000 __typename query = Took 1999.3179998397827 milliseconds
// 2000 __typename query = Took 8064.870334148407 milliseconds

We've also reproduced this in a real world scenario on a API and due to it's impact, I consider it a critical issue.

from graphql-js.

It looks like (nearly) all the time is spent in OverlappingFieldsCanBeMergedRule.

from graphql-js.

Raised #3967 for 16

from graphql-js.