https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 07:41:42 +0000 https://cve.radiocsirt.org/vuln/cnvd-2026-27675 cnvd-2026-27675 https://cve.radiocsirt.org/vuln/cnvd-2026-27675 https://cve.radiocsirt.org/vuln/euvd-2026-333306 EUVD-2026-333306 https://cve.radiocsirt.org/vuln/euvd-2026-333306 https://cve.radiocsirt.org/vuln/fkie_cve-2026-14781 <p>A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token&#39;s email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default).</p> <p>The userinfo endpoint must be enabled (default).</p> <p>The attacker must control or have compromised the upstream OIDC provider.</p> <p>Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.</p> <p>Bypass email-based security controls or verification workflows.</p> <p>Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.</p> <p>A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token&#39;s email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default).</p> <p>The userinfo endpoint must be enabled (default).</p> <p>The attacker must control or have compromised the upstream OIDC provider.</p> <p>Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.</p> <p>Bypass email-based security controls or verification workflows.</p> <p>Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-14781 https://cve.radiocsirt.org/vuln/ghsa-c96p-56gh-3pvw <p>A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token&#39;s email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default).</p> <p>The userinfo endpoint must be enabled (default).</p> <p>The attacker must control or have compromised the upstream OIDC provider.</p> <p>Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.</p> <p>Bypass email-based security controls or verification workflows.</p> <p>Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.</p> <p>A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token&#39;s email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default).</p> <p>The userinfo endpoint must be enabled (default).</p> <p>The attacker must control or have compromised the upstream OIDC provider.</p> <p>Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.</p> <p>Bypass email-based security controls or verification workflows.</p> <p>Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.</p> https://cve.radiocsirt.org/vuln/ghsa-c96p-56gh-3pvw https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2198 <p>Ein Angreifer kann mehrere Schwachstellen in Keycloak ausnutzen, um Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder erweiterte Berechtigungen zu erlangen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Keycloak ausnutzen, um Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder erweiterte Berechtigungen zu erlangen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2198