Executive Summary

On 10 February 2026 CVE-2026-1529 was published: a logic flaw in Keycloak’s invitation/registration token validation allows, in certain configurations, unauthorized account creation - effectively bypassing invite-only registration flows. Within hours the community responded; notably, f3ds cr3w produced a clean, reliable PoC and pushed reproducible artifacts to GitHub within 24 hours after discovery.

This post gives a compact, technical writeup: root cause, impact, how the PoC verifies the issue (conceptually), recommended mitigations, and links to the public advisory and PoC repository so operators can quickly validate and remediate.

Affected Products / Versions

Operators should consult the official Keycloak release notes and the GHSA entry for the canonical affected-version list and recommended upgrades.

Impact

  • Unauthorized account creation in invite-only Realms.
  • Bypass of invitation workflows used to gate self-service onboarding or private tenants.
  • Downstream risk: attacker-created accounts can be used to enroll in services, request roles, or escalate privileges depending on local RBAC/policies.

Severity depends on deployment: single-tenant test systems may be low-risk, while multi-tenant or automated provisioning environments can be severely impacted.

Technical Details (summary)

At a high level the bug is a validation logic error in the invitation/registration flow. Key points:

  • Tokens are not checked strongly enough for context binding - client id, realm, and expected flow are not always enforced.
  • Token metadata checks (audience, issuer, expiry) are incomplete in the vulnerable code path.
  • Under some async state transitions a replay or context-switch allows a crafted request to be accepted as a valid registration.

Those three failures combined allow an attacker to reuse or repurpose a token (or craft a request that looks like a legitimate token-backed registration) and complete account creation despite the invite-only guard.

For reproducible test cases and request examples see the referenced PoC repository; operators should only run PoCs in isolated test environments.

Defensive Code Examples (safe, non-exploit)

Below are short, defensive snippets you can adopt to harden invitation-token handling. These examples focus on proper JWT verification, strict audience/issuer checks, and binding tokens to the expected organization and client.

Python (PyJWT) - verify signature and claims:

import jwt
from jwt import InvalidTokenError

PUBLIC_KEY = open('keycloak_public.pem').read()

def verify_invite_token(token, expected_org_id, expected_aud):
		try:
				payload = jwt.decode(token, PUBLIC_KEY, algorithms=['RS256'], audience=expected_aud)
		except InvalidTokenError as e:
				raise RuntimeError('invalid token') from e

		# Enforce strict binding
		if payload.get('org_id') != expected_org_id:
				raise RuntimeError('org_id mismatch')
		if payload.get('email') is None:
				raise RuntimeError('missing email')

		return payload

# usage: verify_invite_token(token, 'org-1234', 'invite-client')

Node.js (express) - middleware example:

const jwt = require('jsonwebtoken');
const fs = require('fs');

const publicKey = fs.readFileSync('./keycloak_public.pem');

function verifyInvite(req, res, next) {
	const token = req.body.invite_token;
	try {
		const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'], audience: 'invite-client' });
		if (payload.org_id !== req.expectedOrg) return res.status(403).end();
		next();
	} catch (err) {
		return res.status(401).json({ error: 'invalid_token' });
	}
}

Logging & detection suggestion (conceptual): instrument registration handlers to log token kid, alg, aud, iss, org_id and the requester IP. Alert on:

  • tokens where signature verification fails but request proceeds
  • tokens with unexpected alg (e.g., none)
  • org_id values not mapped to the invoking client or realm
  • spikes in registration attempts using tokens from the same kid

Example Sigma rule (conceptual): detect registration attempts with invalid token verification:

title: Suspicious Keycloak Registration Token Failure
id: a1d2e3f4-5678-90ab-cdef-1234567890ab
description: Detect registration attempts where token signature validation failed but request completed
logsource:
	product: webserver
	service: keycloak
detection:
	selection:
		event.action: registration
		token.validation: failed
	condition: selection
level: high

Additional References (collected)

In addition to the GHSA and the community PoC repo, the advisory links to vendor and ecosystem resources that are useful for operators:

If you operate Keycloak in enterprise distributions (Red Hat, vendor forks), consult the vendor errata for platform-specific patches and CVE tracking.

f3ds cr3w and other researchers moved fast: within hours a clean PoC appeared and a public repo was pushed containing test fixtures and reproduction steps. That rapid, usable disclosure is important - it lets operators validate and patch quickly. Credit where it’s due: f3ds cr3w’s PoC was among the earliest reliable reproductions.

Responsible note: this post intentionally omits executable exploit code. Use the PoC repo only in isolated labs or with permission on systems you own.

Conceptual verification steps (for lab use):

  1. Deploy a Keycloak test instance and enable invite-only registration for a Realm.
  2. Obtain a legitimate invitation token via the admin UI or API.
  3. Send a crafted registration request that reuses or alters token context as indicated by the PoC (client/realm headers, parameters).
  4. Observe successful account creation where it should have been rejected.

PoC (lab-only): safe test setup & run

Warning: only run PoCs in an isolated lab you control. Never target third-party or production systems.

The community repo contains a ready-to-run PoC tool (keycloak-exploit.py) used to reproduce the issue in controlled environments. The steps below explain how to set up a disposable Keycloak lab and run the PoC for validation - the instructions purposefully avoid describing how to craft malicious tokens.

1) Start a disposable Keycloak instance (example using Docker):

# run a local Keycloak (example image/tag may vary)
docker run --rm -p 8080:8080 quay.io/keycloak/keycloak:21.1.1 start-dev

2) Configure a test realm and enable invite-only registration via the admin console (create a test client and the invitation flow). Use non-production credentials.

3) Clone the PoC repo and install dependencies:

git clone https://github.com/ninjazan420/CVE-2026-1529-PoC-keycloak-unauthorized-registration-via-improper-invitation-token-validation
cd CVE-2026-1529-POC
python -m venv .venv && .venv/bin/pip install -r requirements.txt

4) Run the PoC against your local instance (lab only). The PoC automates detection and, optionally, demonstration runs - it may generate tokens for test use according to its config. Use -d for debug and -c to point at a custom config file.

python keycloak-exploit.py http://localhost:8080

Notes: - The PoC tool includes options to pass a custom invitation token (-t) or a target organization id (-o) - these are useful for testing specific scenarios in your lab. - Inspect config/default_config.json in the PoC repo to understand defaults for generated accounts, token algorithms, and timeouts. - If you only want to validate vulnerability presence without creating users, run the tool’s detection/health-check modes or review its --help output.

5) After testing, destroy the lab (stop Docker) and delete any generated accounts and reports.

If you prefer not to run the PoC, you can verify the issue at a conceptual level by observing token-handling paths and ensuring strict signature+claim checks as shown in the defensive examples above.

Mitigations & Recommendations

Short-term operators actions:

  • Patch: Apply vendor-supplied fixes or upgrade to the patched Keycloak versions per the GHSA.
  • Validate tokens: Ensure invitation tokens are strictly bound to client/realm/flow, check audience/issuer/expiry and enforce replay protection.
  • Audit accounts: Review accounts created since disclosure for suspicious creation patterns and disable or flag as necessary.
  • Logging: Capture full request/response traces for registration flows for forensics.
  • Compensating controls: Throttle registrations, add WAF signatures to detect anomalous registration traffic, and require additional verifications (email verification, manual review) temporarily.

Incident response checklist:

  1. Patch affected instances.
  2. Audit recently created users and remove or quarantine suspicious accounts.
  3. Rotate any tokens or secrets that could be abused.
  4. Notify stakeholders with a concise timeline and IOCs for detection.

Timeline (short)

  • 2026-02-09: initial finder/vendor disclosure reported (see GHSA).
  • 2026-02-10: GHSA advisory posted.
  • 2026-02-10: first PoC (f3ds cr3w push) published - enabling fast validation by operators.

f3ds cr3w’s rapid PoC reduced time-to-verification for operators; that speed matters for incident response.

References