Authentication Flow Hijack

The gematik Authenticator registers as the handler for the authenticator:// custom URI scheme and accepts a challenge_path parameter that names the Identity Provider (IDP) for an OpenID Connect login. No allowlist restricts which host may act as the IDP, so a crafted deep link can point the Authenticator at an attacker-controlled server. The link can be delivered through a web page, an email, or a QR code.

The parameter is checked only for URL shape, not for domain. Any http/https URL is accepted:

export async function validateChallengePath(challengePath: string) {
  if (!COMMON_USED_REGEXES.URL.test(challengePath)) { /* throw */ }
}

// constants.ts
URL: /(http|https):\/\/(\w+:?\w*@)?(\S+)(:\d+)?(\/|\/([\w#!:.?+=&%@!\-/]))?/,

The Authenticator fetches the OpenID Connect discovery document from that host and decodes it with jsonwebtoken.decode(), which performs no signature verification:

const res = await window.api.httpGet(
  context.state.idpHost + IDP_ENDPOINTS.OPENID_CONFIGURATION, { /* ... */ }
);
context.commit('setOpenIdConfiguration', jsonwebtoken.decode(res.data));

jsonwebtoken.decode() only base64-decodes the token; the library's own documentation warns it must not be used for untrusted messages. The attacker's unsigned document (alg: none) is accepted, and its authorization_endpoint and uri_puk_idp_enc fields are used as-is. The Authenticator then encrypts the smartcard-signed assertion with the attacker's public key and POSTs it to the attacker's endpoint:

const payload = 'signed_challenge=' + state.jweChallenge;
const url = context.state.openIdConfiguration.authorization_endpoint;
const response = await window.api.httpPost(url, payload, { /* ... */ });

The POSTed JWE wraps a JWS holding the card's X.509 AUT certificate (x5c header) and the smartcard signature. Because the attacker owns the encryption key, they decrypt it and recover the signed assertion; this credential capture is demonstrated end-to-end against the mock environment. The challenge JWT carries no environmental binding (no cnf claim, source IP, or TLS session identifier), so the captured assertion can in turn be relayed to the real IDP to complete login as the victim — assessed from the specification and the reference IDP implementation, not tested against production infrastructure.

IDP certificate pinning was present in v4.4.1 but removed in v4.12.0 in favour of the OS trust store, so the attacker's host only needs an ordinary publicly-trusted TLS certificate (for example, Let's Encrypt). The smartcard's private key never leaves the card; the weakness is that the Authenticator does not authenticate the IDP it talks to.