GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-C96P-56GH-3PVW

Vulnerability from github – Published: 2026-07-05 09:30 – Updated: 2026-07-05 09:30
VLAI
Details

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'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).

The userinfo endpoint must be enabled (default).

The attacker must control or have compromised the upstream OIDC provider.

Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.

Bypass email-based security controls or verification workflows.

Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-14781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-05T07:16:39Z",
    "severity": "MODERATE"
  },
  "details": "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.\nThe 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\u0027s email_verified=true claim is blindly applied to the userinfo email.\nExploitation Conditions:\nThe OIDC identity provider must have trustEmail set to true (non-default).\n\nThe userinfo endpoint must be enabled (default).\n\nThe attacker must control or have compromised the upstream OIDC provider.\n\n\nConcrete Impact:\nMark arbitrary email addresses as verified in the Keycloak database.\n\nBypass email-based security controls or verification workflows.\n\nPotential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.",
  "id": "GHSA-c96p-56gh-3pvw",
  "modified": "2026-07-05T09:30:23Z",
  "published": "2026-07-05T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14781"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-14781"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2497118"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…