Kimai EUVD-2026-66222

SAML authentication must be explicitly enabled in Kimai - this is a non-default configuration, so deployments using only local password or LDAP authentication are entirely unaffected. Beyond that, exploitation requires one of two further conditions: (1) admin-level control over an IdP that is configured as a trusted SSO provider for the target Kimai instance, sufficient to set or influence the RelayState value in IdP-initiated flows, or (2) the ability to intercept and modify the SAMLResponse ACS POST in transit (requiring a man-in-the-middle position or access to SAML signing keys/certificates). User interaction is required - a legitimate Kimai user must complete the full SAML authentication flow. The vulnerability enables phishing outcomes only (credential or session token theft); it does not allow remote code execution, privilege escalation, or direct host compromise. The combination of non-default SAML configuration plus IdP-level access substantially limits the realistic attacker population.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P with all impact metrics at N) assigns zero impact scores, which reflects that the Kimai host itself is not directly compromised. Real-world risk is driven by the phishing vector: post-SSO credential or session token theft is a meaningful threat in organizations with SAML-enabled Kimai deployments, but the effective attack surface is sharply narrowed by two hard prerequisites - SAML must be deliberately enabled, and the attacker must hold admin-level control over the connected IdP or possess the SAML private keys to modify assertions in transit. The GHSA advisory explicitly states these conditions, making this unsuitable for broad opportunistic exploitation. No EPSS score was provided, limiting probabilistic comparison; absence from CISA KEV indicates no confirmed active exploitation. The CVSS 4.0 AC:L rating appears optimistic given the non-default configuration requirement and IdP access barrier - AC:H better reflects realistic conditions. Overall, this is a genuine vulnerability worth patching immediately given the trivial fix cost, but it does not represent an urgent priority for teams that have not deployed Kimai with SAML, nor for those that can confirm their IdP infrastructure is tightly controlled.

An attacker who has obtained admin access to a SAML IdP configured for Kimai constructs an IdP-initiated SSO URL that sets RelayState to an attacker-controlled phishing site (e.g., https://attacker.example/fake-kimai-login). A legitimate Kimai user who follows the SSO link completes authentication at the IdP, after which Kimai's ACS handler issues a 302 redirect to the attacker's URL - where a convincing credential-harvesting page captures the user's password or post-SSO session token. No public exploit code has been identified at time of analysis, but the attack path is code-confirmed via Kimai's own unit test (SamlAuthenticationSuccessHandlerTest::testRelayState) and the reproduction steps are fully documented in GHSA-3jp4-mhh4-gcgr.