_Keycloak_ is a widely-used open-source identity and access management solution, trusted by developers for securing applications. In June 2024, a new critical vulnerability—CVE-2024-4028—was disclosed. This flaw opens the door for privileged attackers to execute stored cross-site scripting (XSS) attacks by injecting a malicious payload when creating Resource and Permission items via the admin console.
In this post, I explain what this vulnerability is, how it can be exploited, and what you can do to protect your Keycloak installation.
What Exactly Is CVE-2024-4028?
Keycloak’s admin console allows privileged users (like admins or certain roles with permissions) to manage resources and fine-tune permissions. Due to improper handling and sanitization of user-supplied input, a privileged attacker can embed arbitrary JavaScript code in the name or description fields while creating a Resource or Permission.
This code gets stored in the Keycloak database and is executed every time another admin (or the same attacker) views the affected resource or permission in the admin console—a classic stored XSS scenario.
Key facts
- Affected versions: Keycloak before v24..4 (check vendor’s advisory)
Attack Vector: Admin console (privileged account required)
- Impact: Execution of malicious scripts in another admin’s browser, potentially hijacking sessions, stealing tokens, or escalating privileges
Attack Scenario
1. Attacker logs into the Keycloak admin console with elevated privileges (e.g., realm admin, or a custom role with permission management).
2. Creates a Resource or Permission item with a malicious JavaScript payload in one of the input fields like "Name", "Description", etc.
3. Another admin (or the attacker later) opens the Resource/Permission view in the Keycloak admin console.
Let’s say the attacker uses the following classic XSS payload in the Name field
<script>alert('XSS via Keycloak!')</script>
`html
`
4. Save the resource/permission.
Any admin who now opens this entry will trigger the XSS:
!XSS Popping in Keycloak Admin Console
Note: For real-world attacks, attackers can use more harmful payloads (e.g., exfiltrating JWTs, sending HTTP requests with admins' credentials, etc.).
Why Is This Dangerous?
- Privileges required are high, but in many organizations, admin rights are distributed (for delegation, multitenancy, etc.).
- Impact is critical because the attacker can pivot from one admin account to others, or even all users if they automate the process.
- Existing browser-based protections like CSP might not be enforced properly within internal admin consoles.
Official Advisory
- Keycloak Security Advisory: GHSA-xxxx-xxxx-xxxx _(replace with actual advisory link once public)_
- Keycloak Release: v24..4 Release Notes
Patch Details
- Affected field inputs are now sanitized on server side and encoded on output, preventing script injection.
`bash
docker pull quay.io/keycloak/keycloak:24..4
`
- For local/server: download from Keycloak Downloads
- Do not rely only on browser-based protections! Always sanitize user input, even from trusted roles.
Detection & Hunting
- Review existing resources and permissions for suspicious scripts in the name/description fields.
Example SQL to look for <script> in your Keycloak database
SELECT * FROM RESOURCE WHERE NAME LIKE '%<script%';
SELECT * FROM PERMISSION WHERE DESCRIPTION LIKE '%<script%';
References
- Keycloak Security Advisories
- CVE-2024-4028 Details at NVD _(will be updated as published)_
- OWASP XSS Cheat Sheet
- Keycloak Releases
Conclusion
CVE-2024-4028 highlights how even administrative interfaces can become a vector for serious attacks if user input is not sanitized, and why it's critical to always patch and audit trust boundaries—including internal tools. If you run Keycloak, upgrade at once and check your audit trails. Stay safe, and keep your IAM secure!
_If you’ve found this article useful, please share and subscribe for more practical security insights!_
Timeline
Published on: 02/18/2025 18:15:25 UTC
Last modified on: 03/15/2025 04:12:08 UTC