Executive brief
Apollo Server is a GraphQL implementation used by developers to build APIs. When subscriptions are enabled (the default), schema validation rules—including introspection restrictions meant to hide sensitive field and type names—are not applied to the WebSocket subscription endpoint. An attacker can query this endpoint to discover internal schema details, field names, or descriptions that developers intended to keep private, potentially exposing secrets or aiding further attacks.
Technical details
The vulnerability is a validation rule bypass affecting the WebSocket subscription server in Apollo Server. When ApolloServer is instantiated with subscriptions enabled (default behavior) and custom validationRules or the internal NoIntrospection rule configured, those rules are not passed to the SubscriptionServer instance. This allows introspection queries on the WebSocket endpoint even when disabled elsewhere, and permits other user-defined validation rules to be circumvented. The attack requires network access to the WebSocket subscriptions endpoint. The root cause is that validationRules are enforced on the main HTTP pipeline but omitted when invoking SubscriptionServer.create(). The fix ensures validation rules are consistently applied across all transports. Patched in versions 2.14.2 and higher.
Affected products
- Apollo apollo-server 2.0.0 to 2.14.1
- Apollo apollo-server-core 2.0.0 to 2.14.1
- Apollo apollo-server-express 2.0.0 to 2.14.1
- Apollo apollo-server-lambda 2.0.0 to 2.14.1
- Apollo apollo-server-koa 2.0.0 to 2.14.1
- Apollo apollo-server-azure-functions 2.0.0 to 2.14.1
- Apollo apollo-server-cache-memcached 2.0.0 to 2.14.1
- Apollo apollo-server-cloud-functions 2.0.0 to 2.14.1
- Apollo apollo-server-cloudflare 2.0.0 to 2.14.1
- Apollo apollo-server-fastify 2.0.0 to 2.14.1
- Apollo apollo-server-hapi 2.0.0 to 2.14.1
- Apollo apollo-server-micro 2.0.0 to 2.14.1
Timeline
- 2020-06-05: disclosed: Advisory published
- 2020-06-05: patched: Patch released in versions 2.14.2 and higher