Direct naar de inhoud
Red Hat

Keycloak wachtwoordreset-lek: accountovername mogelijk

Keycloak wachtwoordreset-lek

Red Hat en het Keycloak-project hebben patches vrijgegeven voor een kritieke kwetsbaarheid in Keycloak die wachtwoordherstel misbruikt om accounts over te nemen. De issue staat bekend als de Keycloak wachtwoordreset-lek (CVE-2026-18963) en krijgt een score van 9,1 op de CVSS-schaal.

Volgens de advisories kan een ongeauthenticeerde aanvaller via een speciaal gemaakte request de flow rond vergeten wachtwoorden zó sturen dat het systeem direct doorgaat naar de fase waarin het wachtwoord wordt aangepast. Daarmee is geen interactie met het slachtoffer nodig en ontbreekt de normale controle via een actie-token uit e-mail.

Wat is de Keycloak wachtwoordreset-lek?

De kwetsbaarheid is gecategoriseerd als een weak password recovery mechanism voor vergeten wachtwoorden (CWE-640). Red Hat beschrijft als kernprobleem een onjuiste state-validatie binnen het authenticatieproces voor reset-credentials.

Concreet: Keycloak verwerkt een verzoek voor wachtwoordherstel via een vaste reeks stappen. De kwetsbaarheid zit in hoe de server de authenticatiesessie en de status (state) beheert in die flow. Een aanvaller kan een request sturen naar het reset-credentials endpoint en daarmee afdwingen dat de sessie overslaat naar de wachtwoordupdate-fase.

Het resultaat: een aanvaller kan een willekeurige account laten resetten, en daarmee het wachtwoord vervangen. Red Hat meldt dat het kan gaan om alle accounts, inclusief administratieve accounts.

Impact: van accountreset tot volledige accountovername

De ernst wordt door Red Hat als Critical beoordeeld omdat misbruik kan plaatsvinden zonder inloggegevens en zonder gebruikersinteractie. Als de exploit succesvol is, krijgt de aanvaller volledige controle doordat het wachtwoord is gewijzigd.

Let op: de bronnen vermelden dat er geen bewijs is gevonden dat de kwetsbaarheid al is uitgebuit, en ook is er tot 24 augustus 2026 geen gevalideerde publieke exploit aangetroffen.

Welke versies zijn geraakt en wat moet je patchen?

De herstelmaatregelen verschillen per distributie en versie. Upstream Keycloak adviseert om te upgraden naar versie 26.7.2 (uitgebracht op 19 augustus 2026).

Voor omgevingen met Red Hat build van Keycloak (RHBK) zijn fixes beschikbaar in de volgende updates:

  • Red Hat build van Keycloak 26.4: niet geraakt voor operator bundle 26.4.15-1 en de bijbehorende rhbk/keycloak-rhel9 beelden.
  • Red Hat build van Keycloak 26.6: niet geraakt voor operator bundle 26.6.6-1 en de bijbehorende keycloak-rhel9 en operator containers.
  • RHBK 26.6 en 26.4: Red Hat noemt ook dat de operator bundles en containerimages in deze streams overeenkomen met de fixed versies.

De advisories verwijzen daarnaast naar vier errata die op 18 augustus 2026 zijn uitgebracht. Die errata behandelen zowel standalone serverpakketten als containerimages voor twee RHBK-streams.

Interessant detail: in de openbare GitHub-advisory worden zowel affected als patched versies als unknown weergegeven, en het CVE-profiel bevat productreferenties voor Red Hat. Eerder stond er meer in het CVE-register, maar later is de productlijst bijgesteld. De status van sommige producten is daarmee niet volledig vastgesteld.

Tijdelijke mitigatie als updaten niet meteen lukt

Kan je niet direct naar een fixed versie? Dan biedt Red Hat een tijdelijke mitigatie. Die komt neer op het uitschakelen van “Forgot password” voor alle realms.

In de Red Hat-beheerconsole vind je de instelling onder: Realm settingsLoginForgot password. Red Hat benadrukt dat je de wijziging voor elke realm moet toepassen.

Hoewel dit geen vervanging is voor patchen, verlaagt het de blootstelling door de betreffende functionaliteit uit te zetten.

Hoe werkt misbruik volgens Red Hat?

Red Hat koppelt de oorzaak aan de manier waarop de reset-credentials flow de state valideert. De aanval draait om het sturen van een speciaal request naar het endpoint voor reset-credentials.

Door een fout in de flow- en state-validatie kan de authenticatiesessie in sommige scenario’s direct doortransitioneren naar de wachtwoordupdate-fase. Daarbij is de actie-token die Keycloak normaal via e-mail zou versturen niet nodig.

Onderzoekers wijzen daarnaast op een bredere consequentie: wie de grens van een systeem overschrijdt, kan uiteindelijk terechtkomen in alles wat achter de authenticatievoorziening zit. In de praktijk betekent dit dat een geslaagde accountovername vaak veel verder gaat dan alleen één gebruiker.

Wat betekent dit voor jouw beveiligingsaanpak?

Een identity and access management (IAM)-lek is zelden “lokaal”. Keycloak vormt vaak de toegangspoort tot apps en diensten. Daarom is het verstandig om dit onderwerp niet alleen als patchmoment te zien, maar ook als signaal voor je bredere security-hygiëne.

Onderzoek bijvoorbeeld hoe je password recovery functioneert, welke realms actief gebruikmaken van vergeten-wachtwoordfunctionaliteit en hoe snel je kritieke IAM-updates kunt uitrollen.

Wil je meer context over beveiliging rond IAM en account-takeover-risico’s in moderne webapplicaties? Lees dan ook eens ons artikel over application security in het AI-tijdperk. Dat stuk gaat in op de bredere verschuiving van aanvalspatronen en de noodzaak om controles end-to-end te beoordelen.

Vergelijkbare recente Keycloak-fixes

CVE-2026-18963 maakte onderdeel uit van de CVE’s die in Keycloak 26.7.2 zijn opgelost. In dezelfde release werd ook CVE-2026-15571 behandeld: een predictable account-linking hash waarmee account takeover mogelijk is via een kwaadaardige OpenID Connect (OIDC) client.

Twee weken eerder (op 5 augustus 2026) verscheen Keycloak 26.7.1 met fixes voor twaalf CVE’s. De genoemde issues betroffen onder andere een SAML identity-provider-initiated broker login die een link-only beperking kon omzeilen en een default dynamic client registration policy die role forgery via user property mappers mogelijk maakte.

Dit laat zien dat het Keycloak-ecosysteem regelmatig wordt aangescherpt. Voor organisaties betekent dat: houd releases bij en plan updates als onderdeel van een vast security-proces.

Praktische checklist voor direct actie

  • Inventariseer welke Keycloak-implementaties je gebruikt (upstream vs Red Hat build, versies en streams).
  • Werk bij naar de fixed versies: upstream 26.7.2 of de bijbehorende RHBK operator bundles en containerimages.
  • Als je niet kunt patchen: zet “Forgot password” uit voor alle realms.
  • Controleer accounts met verhoogde rechten (zoals adminaccounts) en zorg dat wachtwoorden en sessies volgens jullie incident- en beheerbeleid worden beoordeeld.
  • Volg de advisories en release notes voor samenhangende CVE’s in dezelfde versiebundels.

Conclusie

De Keycloak wachtwoordreset-lek (CVE-2026-18963) is een kritieke kwetsbaarheid waarbij een aanvaller zonder authenticatie een wachtwoordreset kan afdwingen en zo accounts kan overnemen. Omdat de flow staat-validatie niet goed doorvertaalt en de e-mailactie-token niet vereist is, kan de impact groot zijn — zelfs voor administratieve accounts.

De boodschap is helder: patch zo snel mogelijk naar de genoemde fixed versies. Lukt dat niet direct, schakel dan “Forgot password” uit voor alle realms totdat je de updates hebt doorgevoerd.

Bron: https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html