Bug bounty

Public

Keycloak Bug Bounty Program

Keycloak is an open-source Identity and Access Management (IAM) solution providing Single Sign-On (SSO), identity brokering, and user federation. It supports standard protocols like OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0. As a CNCF incubating project, Keycloak runs on a lightweight Quarkus stack, making it fast, efficient, and ideal for containerized environments.

Reward

Bounty

Hall of fame

€100

Low

€500

Medium

€1,000

High

€2,000

Critical

€5,000

Program

Avg reward

€1,000

Max reward

€1,000

Scopes

Supported languages

English

Hacktivity

Reports

1st response

< 1 day

Reports last 24h

Reports last week

Reports this month

Program description

Program activity

About our project

Keycloak centralizes IAM, decoupling applications from user storage, authentication, and authorization. It manages the entire auth flow—federating with LDAP, Active Directory, or social logins—and issues secure JWTs to applications. This consolidation allows administrators to enforce universal security policies, such as MFA and fine-grained authorization, from a single control plane instead of embedding them in dozens of microservices.

As a CNCF project, Keycloak is purpose-built for securing cloud-native microservices. It is designed to run in containers and be managed by Kubernetes Operators. Its Quarkus-based architecture provides the low memory footprint and fast startup essential for horizontal scaling. In this stack, Keycloak acts as the security backbone, issuing tokens that are validated by API gateways or service meshes to secure all requests within the cluster.

About the scope

Submissions must target the latest stable release of in-scope components. Issues specific only to older versions, release candidates, or nightly builds are out of scope unless confirmed reproducible on the latest stable release.

Only vulnerabilities within Supported features are in scope. Any issues identified in features explicitly marked as Preview, Experimental, or Deprecated in the official documentation or release notes are considered out of scope.

In Scope

For the list of specific components and their latest stable versions covered by this program, always refer to the official Keycloak Downloads page: https://www.keycloak.org/downloads. The scope of this program is limited to the three following assets :

Keycloak Server: The latest stable release of the Keycloak server (Quarkus distribution), whether downloaded as a ZIP/TAR.GZ or used via the official container image.
Keycloak Operator: The latest stable release of the Keycloak Operator for Kubernetes and OpenShift.
JavaScript Client Adapter: The latest stable release of the official JavaScript adapter.

Out of scope

This programs will only consider reports about the latest stable versions, which means that the following is considered out of the scope of this program :

Unsupported or deprecated versions
Archived releases
Nightly builds
Release candidates (RCs)
Demonstration and Non-Production Code
All "Quickstarts" and any other example code.
Test code and testing tools.

Regarding client libraries and adapters, the following will be considered as out of scope :

Client adapter aside from the official JavaScript adapter, most notably the Node.js adapter
Client Libraries
All Java-based "Client Libraries" are considered out of scope, this encompass:
- Admin Client
- Authorization Client
- Policy Enforcer
- Common Module

In addition to the above, some additional generic exclusions also apply :

Third party licences and dependencies, for these any issue must be reported to the corresponding project/maintainers and not to our program
Any issue pertaining to underlying infrastructure, including bugs in any other container runtime or orchestration platform (Kubernetes, OpenShift, Docker, Podman)
Reports should focus on the Keycloak Operator code itself, not the platform it runs on
Vulnerabilities in third-party dependencies within container images, including CVEs or flaws in operating system packages (RPMs, DEBs), system libraries (like glibc, openssl), or base container images (like UBI, Alpine) used by the Keycloak Server or Operator images as reports should target vulnerabilities in the Keycloak application code, not pre-existing flaws in its bundled dependencies
Documentation, blog posts, and website issues (e.g., typos, broken links)
Non-security-related bugs/issues

Furthermore, reports about behaviours that relies on leveraging a legitimate access as an administrator won't be considered for reward. Being administrator of a Keycloak realm grants extended rights which could be abused as for any application. Due to our threat model and context of use we won't consider reports that leverage legitimate administrator access under the assumption that the administrator may have malicious intent and could abuse his level of rights.

Documentation

This section provides links to the official Keycloak documentation for in-scope components. Security researchers should use these resources to understand the intended architecture, configuration, and protocol flows.

Server Administration Guide: This is the most critical resource. Pay close attention to sections on security, realms, users, and tokens.
Securing Applications and Services Guide: This explains the protocol flows (OIDC, OAuth 2.0, SAML) from the server's perspective.
Server Developer Guide: Useful for understanding how to build custom extensions (Providers).
Operator Documentation: This is the main documentation hub for the Operator.
JavaScript Adapter Guide: This guide details all initialization options and functions.
Keycloak repository : includes the code for Keycloak Server, Keycloak Operator and the JavaScript adapter.

Program rules

About report's content

To qualify for a reward, your report must include:

A clear description of the vulnerability.
Details about the vulnerable component, endpoint, parameters, and conditions required to trigger the bug.
The Keycloak version(s) affected.
Clear, step-by-step instructions to reproduce the vulnerability, including necessary setup and relevant HTTP requests.
Recommendations for fixing the vulnerability.

A detailed template is provided during submission – you must use it. Reports that fail to meet these requirements or significantly deviate from the template may be ineligible for rewards or closed without action. Spamming, submitting intentionally low-quality reports, or repeated submission of invalid issues may result in temporary or permanent suspension from the program.

Testing Policy, Responsible Disclosure

Please adhere to the following rules while performing research on this program:

Denial of service (DoS) attacks on our applications, servers, networks or infrastructure are strictly forbidden
All reports must be validated manually, submission from automated tools won't be considered and may lead to sanctions (code analysis tools, AI, …)
Targeting other users' instances is forbidden, only test against your own
DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.
Same with secrets, keys and credentials
No vulnerability disclosure, full, partial or otherwise, is allowed without prior agreement from us
Please avoid submitting security issues on our repositories before reporting it to this program, your report might be considered as a duplicate if a related submission already exists on our repositories
The following topics won’t be considered as a valid finding eligible for reward nonetheless, you’re welcome to suggest improvements about it through our repositories but not our bug bounty program :
- Code improvements/code quality issues without security impact
- Insecure default/basic configurations
- Mistakes or lack of precision in our documentation

Reward Eligibility

We are happy to thank everyone who submits valid reports which help us improve the security, however only those that meet the following eligibility requirements may receive a monetary reward:

You must be the first reporter of a vulnerability
You must not break any of the testing policy rules listed above
You must not be a former or current employee nor a maintainer of our project or one of its contractors
The vulnerability must be a qualifying vulnerability
The report must contain the following elements:
- Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and the company, and remediation advice on fixing the vulnerability
- Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
- Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc
Identical vulnerabilities present in different versions will be considered as a single issue/will warrant a single reward
Multiple vulnerabilities caused by one underlying issue will be considered as a single issue/will warrant a single reward

Reward amounts are based on:

Reward grid of the report's scope
CVSS scoring and actual business impact of the vulnerability upon performing risk analysis

Reward

Asset value	CVSS Low	CVSS Medium	CVSS High	CVSS Critical
Medium	€500	€1,000	€2,000	€5,000

Systemic issues

1st report100%

2nd report100%

3rd report75%

4th report50%

5th report25%

6th+ report10%

We appreciate all valid reports submitted to our program that enhance our security. However, please note that if a similar issue (see definition in 'More info') has already been reported, by you or any other hunter, the reward will be decreasing according to these percentages.

Scopes

Scope	Type	Asset value
Keycloak Server	Open Source	Medium
Low €500 Medium €1,000 High €2,000 Critical €5,000
Keycloak Operator	Open Source	Medium
Low €500 Medium €1,000 High €2,000 Critical €5,000
JavaScript Client Adapter	Open Source	Medium
Low €500 Medium €1,000 High €2,000 Critical €5,000

Out of scopes

Any asset that is not explicitly included in our program's scope

Any third parties’ or Community’s assets that are not explicitly included (e.g. forks, libraries or packages)

Any depreciated versions and other versions than the current stable/official version are considered out of scope except if specified otherwise in the program’s rules

Any local implementation of the project/implementation belonging to third parties

Vulnerability types

Qualifying vulnerabilities

SQL Injection (SQLi)

Cross-Site Scripting (XSS)

Remote Code Execution (RCE)

Insecure Direct Object Reference (IDOR)

Horizontal and vertical privilege escalation

Authentication bypass & broken authentication

Business Logic Errors vulnerability with real security impact

Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)

Cross-Origin Resource Sharing (CORS) with real security impact

Cross-site Request Forgery (CSRF) with real security impact

Open Redirect

Cryptographic flaws (e.g. using insecure crypto primitives, insufficient randomness, incorrect handling of keys, …)

Race conditions

Missing validations of untrusted inputs (e.g. injection of unescaped markup in output, following untrusted symlinks, …)

Undefined behavior leading to a security vulnerability (e.g. integer overflow)

Denial of Service (DoS): Regular Expression DoS (ReDoS) in validation fields & resource exhaustion (e.g., via caching, API abuse, or unbounded computations)

Exposed secrets, credentials or sensitive information from an in-scope asset and affecting at least one of our scopes

Non-qualifying vulnerabilities

Tabnabbing

Content/Text injections without security impact (e.g., injecting text into non-HTML contexts)

Clickjacking/UI redressing on non-sensitive pages or where no sensitive action can be performed

Recently disclosed CVEs (less than 30 days since patch release)

CVEs reported without a working Proof of Concept (PoC) or clear exploitation steps

Open ports or services without a demonstrated, exploitable vulnerability and PoC

Social engineering of staff or contractors

Presence of autocomplete attribute on web forms

Vulnerabilities affecting outdated or unsupported browsers or platforms

Self-XSS or XSS that cannot be used to impact other users (e.g., requires unlikely user interaction within their own session)

Any hypothetical flaw or best practice recommendation without a demonstrated, exploitable vulnerability and PoC

Basic SSL/TLS configuration issues (e.g., weak cipher suites, expired certificates) unless they lead to a demonstrable exploit beyond passive eavesdropping

Reports with attack scenarios requiring Man-in-the-Middle (MITM) attacks or physical access to the victim's device or network

Missing security-related HTTP headers (e.g., Strict-Transport-Security, Content-Security-Policy, X-Frame-Options) which do not lead directly to an exploitable vulnerability and PoC

Low severity Cross-Site Request Forgery (CSRF) on actions without significant security impact (e.g., Unauthenticated actions like login/logout attempts, non-state-changing actions)

Disclosure of non-sensitive information (e.g., basic software versions, generic error messages, directory listings on non-critical paths) unless it facilitates a higher-impact attack

Stack traces, path disclosures unless they leak sensitive information (secrets, PII, internal network structure) or contribute directly to another vulnerability

CSV injection without demonstrating execution or significant data manipulation

Malicious file upload that does not result in execution (RCE), XSS, SSRF, or overwriting critical system files (e.g., uploading an inert .exe or EICAR test file)

User enumeration (e.g., confirming existence of email, alias): confirming user existence is often intentional for usability or unavoidable. Effective mitigations (MFA, brute-force protection) exist elsewhere. Given the high report volume, it is better to explicitly mention it.

Weak password policies configured by an administrator (e.g., allowing short passwords) - Note: Bugs in the enforcement mechanism are in scope.

Ability to spam users (email / SMS / direct messages flooding) - Note: If spamming leads to DoS of the notification system, it might qualify under DoS.

Exploits that rely on non-standard, experimental, or undocumented configurations distant from normal use cases or official recommendations

Exploits that rely on a configuration explicitly documented as insecure or voluntarily downgraded by the administrator against security recommendations

Stolen secrets, credentials or information gathered from a third-party asset that we have no control over

Exposed secrets, credentials or information on an out of scope asset

Issues relying on legitimate access as a user with administrator rights

Reports of leaks and exposed credentials

In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program’s scope and policy. To summarize our policy, you may refer to the below table:

Type of leak

Source of leak is in-scope

Source of leak belongs to the Organization and is out-of-scope

Source of leak does not belong to the Organization and is out-of-scope

Impact is in-scope (e.g. valid credentials on an in-scope asset)

Eligible

Not eligible

Impact is out-of-scope (e.g. valid credentials for an out-of-scope asset)

Not eligible

Hunters collaboration

When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.

For more information, see help center.
Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.

To submit a vulnerability report, you need to login with your hunter account.