Bug 2252197 (CVE-2023-6394) - CVE-2023-6394 quarkus: GraphQL operations over WebSockets bypass
Summary: CVE-2023-6394 quarkus: GraphQL operations over WebSockets bypass
Status: NEW
Alias: CVE-2023-6394
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Product Security
QA Contact:
Depends On:
Blocks: 2250889
TreeView+ depends on / blocked
Reported: 2023-11-30 04:07 UTC by Chess Hazlett
Modified: 2024-05-03 18:49 UTC (History)
23 users (show)

Fixed In Version: quarkus 3.6.0
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in Quarkus. This issue occurs when receiving a request over websocket with no role-based permission specified on the GraphQL operation, Quarkus processes the request without authentication despite the endpoint being secured. This can allow an attacker to access information and functionality outside of normal granted API permissions.
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Chess Hazlett 2023-11-30 04:07:09 UTC
I've tried it and when I have the /graphql endpoint secured, then calling it over a websocket is possible without providing an auth header, because the websocket handler is placed before the authorization checks.

It seems to be exploitable only when you don't specify any role-based permissions (@RolesAllowed) on the GraphQL operation, because if you do, then Quarkus attempts to check the role of the user, which fails  with a NullPointerException (because the security identity is null and  Quarkus tries to check whether it has a role). When the policy says just that the user has to be authenticated, the request goes through. If there's any checking of the user metadata, the request fails with NPE. But all in all, it looks pretty bad to me, because websockets are always enabled (maybe we should also add an option to disable them)

Note You need to log in before you can comment on or make changes to this bug.