CVE-2022-1438: Persistent XSS in Keycloak — User Impersonation
The story of my first CVE — how, during a routine penetration test, I discovered a Persistent XSS vulnerability in the Keycloak Admin Console that made it into the MITRE database and earned an official advisory from Red Hat.
CVE-2022-1438 — Persistent Cross-Site Scripting in Keycloak / Red Hat Single Sign-On
Keycloak is an open-source authentication and identity management server developed by Red Hat. It forms the foundation of the Red Hat Single Sign-On (RH-SSO) product and is used by thousands of organizations worldwide to manage user access, identity federation and Single Sign-On.
Discovery context
In December 2021, working as a pentester at SISOFT S.C., I was carrying out a penetration test for a client whose application used the Keycloak 15.0.2 framework as its central authentication system. During a routine examination of the admin panel, I identified a Persistent XSS vulnerability in the user-creation module of the Admin Console.
This was my first discovery to receive a CVE number — a milestone that is special for every pentester. Not because the vulnerability was particularly sophisticated, but because it proved that even in mature, widely used open-source projects, basic validation flaws can be overlooked.
Vulnerability details
| CVE ID | CVE-2022-1438 |
|---|---|
| Type | CWE-79: Stored Cross-Site Scripting |
| Product | Keycloak / Red Hat Single Sign-On (RH-SSO) |
| Tested version | Keycloak 15.0.2 |
| Component | Admin Console — User Impersonation |
| CVSS 3.1 (NIST) | 4.8 MEDIUM |
| CVSS 3.1 (Red Hat) | 6.4 MEDIUM |
| CVSS Vector (NIST) | AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N |
| CVSS Vector (Red Hat) | AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H |
| Fix | Red Hat Single Sign-On 7.6.2 (RHSA-2023:1043) |
Technical analysis
Root cause
The username field in the user-creation module of the Keycloak Admin Console was validated only on the front-end. By intercepting the HTTP request (for example with Burp Suite), the validation could be bypassed entirely, allowing an XSS payload to be planted in the username.
HTML entities were not sanitized during the user impersonation process — a feature that lets an administrator log in as another user for troubleshooting purposes. When the system displayed a message about the impersonation attempt during an existing session, the username (containing the payload) was rendered without escaping.
Key observation: Validation performed only on the client side (front-end) is one of the most common security anti-patterns. Every pentester knows that client-side validation is merely a convenience for the user — it is never a security mechanism. Data must always be validated on the server side.
Payload
A simple, classic XSS payload using the <img> tag with an onerror attribute. It was enough to confirm the vulnerability — more advanced payloads could have carried out session theft, data tampering or lateral movement within the admin panel.
Proof of Concept — the "You are already authenticated as different user" message renders the XSS payload. The alert displays the KEYCLOAK_SESSION value, confirming that the administrator's session can be stolen
Reproduction steps
- Create a new user in the Keycloak administration section
- Intercept the request that creates the user (e.g. with Burp Suite) and modify the
usernamefield by inserting the XSS payload - Log in as the newly created user (with the payload in the name)
- Return to the Admin Console — select a different user (not the one with the payload)
- Modify the selected user — for example, set a new temporary password
- Use the "Impersonate" option on the modified user
- Enter the new credentials when prompted to authenticate
- The system displays the message: "You are already authenticated as different user '[user + payload]' in this session. Please sign out first."
- The JavaScript payload executes immediately
Impact
Although the vulnerability requires administrative privileges to create a user with the payload (hence the MEDIUM CVSS rating), its real-world impact is significant in the context of multi-administrator environments and insider-threat scenarios:
Privilege escalation
An administrator with limited privileges could exploit the vulnerability to hijack a super-admin's session during impersonation, gaining access to the full realm configuration.
Session theft
Capturing an administrator's session tokens would allow unauthorized access to the identity management panel for all of the organization's users.
Broader reach
The "You are already authenticated as different user" message is not the only place that renders the username — every page displaying a username without sanitization can be an attack vector.
Scale of impact
Keycloak/RH-SSO is a central authentication system — compromising the admin panel means potential access to every application in the federation.
Disclosure Timeline
| Date | Event |
|---|---|
| 2021-12-04 | Vulnerability reported to [email protected] with a full report, screenshots and a Burp Suite project |
| 2021-12-13 | Entry created in Red Hat Bugzilla (Bug #2031904) |
| 2022 | CVE-2022-1438 number assigned by Red Hat |
| 2023-03-01 | Fix released in Red Hat Single Sign-On 7.6.2 (RHSA-2023:1043, 1044, 1045, 1047, 1049) |
| 2023-09-20 | CVE-2022-1438 published in the NVD database (NIST) |
A note on the timeline: More than 14 months passed between the report and the release of the patch, and full publication in the NVD came almost 2 years after the report. Such long response times are unfortunately not the exception in large open-source projects — yet another reason why responsible disclosure requires patience and professionalism.
The fix
Red Hat released a fix as part of the Red Hat Single Sign-On 7.6.2 update (Keycloak 18.0.6), published on March 1, 2023. The update covered multiple platforms:
- RHSA-2023:1043 — Red Hat Single Sign-On 7.6.2 on RHEL 7
- RHSA-2023:1044 — Red Hat Single Sign-On 7.6.2 on RHEL 8
- RHSA-2023:1045 — Red Hat Single Sign-On 7.6.2 on RHEL 9
- RHSA-2023:1047 — RHEL-8 Middleware Containers
- RHSA-2023:1049 — Red Hat Single Sign-On 7.6.2
The fix consisted of adding HTML entity sanitization to the impersonation process, so that usernames are escaped before being rendered in administrative views.
Conclusions and lessons
CVE-2022-1438 was my first official CVE and taught me several valuable lessons that I still apply in my day-to-day work as a pentester:
1. Never skip server-side validation
Front-end validation is a UX convenience, not a security mechanism. In the case of Keycloak, intercepting a single HTTP request was enough to bypass all validation of the username field. Every form, every field, every API endpoint must validate data on the server side.
2. Test every field, not just the obvious ones
The username field seems "safe" — after all, it's just a username, right? But in a system where that name is rendered in many contexts (user lists, messages, logs), a lack of sanitization in even one of them creates an attack vector.
3. Administrative features need testing too
There is a temptation to skip the admin panel during pentesting, assuming that "only trusted users have access to it anyway." That's a mistake. Insider-threat scenarios, admin account compromise and multi-tenancy all require that admin panels be secured just as well as public endpoints.
4. Responsible disclosure requires patience
14 months passed between the report and the patch. From the report to full publication in the NVD — almost 2 years. That is the norm in large projects. Don't be discouraged by the lack of an immediate response — every reported CVE is a real security improvement for thousands of organizations.
Key takeaway: Even "simple" XSS vulnerabilities in the admin panels of mature open-source projects can receive a CVE number and an official security advisory. Systematic testing, attention to detail and patience throughout the disclosure process are the foundations of a pentester's work.
References
- NVD: CVE-2022-1438
- Red Hat CVE: access.redhat.com/security/cve/CVE-2022-1438
- Red Hat Bugzilla: Bug #2031904
- Advisory: RHSA-2023:1043
Looking for vulnerabilities in your application?
Professional penetration testing of web applications, APIs and infrastructure. I find vulnerabilities before attackers do — from simple XSS to complex chain attacks.
Book a free consultation