The Quarkus WebAuthn module publishes default REST endpoints for registering and logging users in, while allowing developers to provide custom REST endpoints for those. When developers provide custom REST endpoints, the default endpoints remain accessible, potentially allowing attackers to obtain a login cookie that has no corresponding user in the Quarkus application, or depending on how the application is written, could correspond to an existing user that has no relation with the current attacker, allowing anyone to log in as an existing user by just knowing that user's user name.

To exploit, a Quarkus application must use the Quarkus WebAuthn module, and provide custom endpoints for login and registration, leaving the default endpoints open and half-working (because they call user code in WebAuthnUserProvider.create/update that will probably be a no-op since the developers will focus on their custom endpoints).
Doing a POST /q/webauthn/callback with a WebAuthn login or registration payload will obtain a login cookie, causing all code annotated with @Authenticated to accept calls, with a SecurityIdentity that has a user name as provided by the user. That SecurityIdentity by default will have no roles, but the Quarkus application can add roles if the user exists, depending on how it's written.