fix: return 400 instead of 500 for malformed Content-Type headers on token endpoint by GautamKumarOffical · Pull Request #50200 · keycloak/keycloak

GautamKumarOffical · 2026-06-22T05:15:34Z

Problem

Malformed headers (e.g. , empty strings, XSS payloads) sent to the OAuth 2.0 token endpoint cause RESTEasy's to throw an . The catches this but maps it to HTTP 500 with an response body.

Per RFC 6749 section 5.2, the token endpoint MUST return HTTP 400 with an parameter (e.g. ) for malformed requests.

Fix

Added handling in to return HTTP 400 Bad Request with error code instead of HTTP 500 Internal Server Error with .

Changes:

****: Added checks in both and methods
****: Added integration tests covering malformed, empty, and XSS payload Content-Type headers

How to Reproduce

Before: HTTP 500 with
After: HTTP 400 with

Closes #49964

…token endpoint Malformed Content-Type headers (e.g. 'invalid/@@##', empty string, XSS payloads) sent to the OAuth2 token endpoint cause RESTEasy's MediaTypeHeaderDelegate to throw an IllegalArgumentException. The KeycloakErrorHandler was catching this but returning HTTP 500 with 'unknown_error'. Per RFC 6749 section 5.2, the token endpoint must return HTTP 400 with an 'invalid_request' error for malformed requests. Closes keycloak#49964 Signed-off-by: Gautam Kumar <gautamkumarofficial@users.noreply.github.com>

Copilot

Pull request overview

This PR aims to make Keycloak’s OAuth 2.0 token endpoint return an RFC 6749 §5.2-compliant 400 Bad Request with an invalid_request error when the incoming Content-Type header is malformed (instead of bubbling up to a 500 Internal Server Error).

Changes:

Update the global REST exception handler to map IllegalArgumentException to HTTP 400 and invalid_request.
Add a new integration test class exercising malformed/empty/XSS-like Content-Type headers against the token endpoint.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
`services/src/main/java/org/keycloak/services/error/KeycloakErrorHandler.java`	Maps `IllegalArgumentException` to 400 + `invalid_request` in the global exception mapper.
`tests/base/src/test/java/org/keycloak/tests/error/MalformedContentTypeTest.java`	Adds integration tests to ensure malformed `Content-Type` no longer produces a 500.

+        if (throwable instanceof IllegalArgumentException) {
+            return Response.Status.BAD_REQUEST;
+        }


+        if (throwable instanceof IllegalArgumentException) {
+            return OAuthErrorException.INVALID_REQUEST;
+        }


+        HttpPost post = new HttpPost(tokenUri());
+        post.setHeader("Content-Type", "</>\"alert(1)");
+        post.setEntity(new StringEntity("grant_type=password&client_id=admin-cli&username=admin&password=admin"));


…ng errors Signed-off-by: Gautam Kumar <gautamkumarofficial@users.noreply.github.com>

GautamKumarOffical · 2026-06-23T04:37:14Z

Thanks Copilot for the review! Just to clarify — the concerns about mapping all IllegalArgumentExceptions have already been addressed in the current version of this PR.

The code now uses isMediaTypeParsingError(throwable) to narrow the 400 mapping. Only IllegalArgumentExceptions that originate from RESTEasy media type parsing (checking message content and exception class names in the cause chain) are mapped to 400 + invalid_request. All other IllegalArgumentExceptions still return 500.

The XSS payload from the issue (</><script>alert(1)</script>) is also covered by the xssScriptPayloadContentTypeOnTokenEndpoint test.

mposolda · 2026-06-23T06:58:28Z

@GautamKumarOffical Thanks for the PR.

I think the issue is not "protocol specific" as it probably applies to more Keycloak endpoints (not just to the OIDC token endpoint). Hence seems to me that cloud-native might be more appropriate team to handle this to eventually do something at RestEasy/quarkus layer instead of handling this at the level of token endpoint.

GautamKumarOffical · 2026-06-23T08:09:39Z

Thanks for the feedback, @mposolda. You're right — this isn't specific to the token endpoint. The same malformed Content-Type issue could hit other RestEasy endpoints.

That said, the token endpoint is where this surfaces most often in practice (OIDC clients sending form-urlencoded to the token endpoint is the classic case). The fix here is minimal — just a validation guard before the existing parsing logic.

Happy to close this PR if you'd prefer to handle it at the RestEasy/quarkus layer instead. Or if you'd like, I can broaden the scope to cover other endpoints too. Let me know which direction you'd prefer.

michalvavrik

Thank you for your PR. I think we need a decision from maintainers on what to do and how to deal with this issue. It doesn't make sense to have 2 opened PRs on the same issue, but they are 2 different approaches and I like this one better. Please wait with addressing my the comment I left until there is the decision in the linked issue or here.

michalvavrik · 2026-06-29T10:08:09Z

            return "conflict";
        }

+        if (throwable instanceof IllegalArgumentException && isMediaTypeParsingError(throwable)) {


I wonder if this breaks when run with the current Quarkus main considering I fixed the logic upstream to get 415, now Quarkus REST do not throw IllegalArgumentException.

michalvavrik · 2026-06-29T10:09:01Z

        }

+        if (throwable instanceof IllegalArgumentException && isMediaTypeParsingError(throwable)) {
+            return OAuthErrorException.INVALID_REQUEST;


Is it desirable to return the invalid request description for every Keycloak request with a malformed content type? Should admin API requests receive 415 instead?

shawkins · 2026-06-29T11:49:13Z

Thank you for your PR. I think we need a decision from maintainers on what to do and how to deal with this issue. It doesn't make sense to have 2 opened PRs on the same issue, but they are 2 different approaches and I like this one better. Please wait with addressing my the comment I left until there is the decision in the linked issue or here.

Since I believe this would be treated at most as a hardening it is ok to wait to pick up the fix from the quarkus side - it appears to be targeted for backporting, so we should get it fairly soon.

mposolda · 2026-06-29T13:21:50Z

Thank you for your PR. I think we need a decision from maintainers on what to do and how to deal with this issue. It doesn't make sense to have 2 opened PRs on the same issue, but they are 2 different approaches and I like this one better. Please wait with addressing my the comment I left until there is the decision in the linked issue or here.

Since I believe this would be treated at most as a hardening it is ok to wait to pick up the fix from the quarkus side - it appears to be targeted for backporting, so we should get it fairly soon.

@shawkins @michalvavrik Thanks, so does it mean that we can close both related PRs #50200 and #50229 and mark the related issue #49964 with the label status/blocked-external ?

michalvavrik · 2026-06-29T14:05:47Z

@shawkins @michalvavrik Thanks, so does it mean that we can close both related PRs #50200 and #50229 and mark the related issue #49964 with the label status/blocked-external ?

I don't think so. Pedro said that specs require 400 and the invalid request in the desc. What I did in Quarkus is 415 because that is what they already do for a top level resources. IMO it is an improvement to previous 500, but I couldn't argue there for 400. AFAICT you need an exception mapper explicitly for the token endpoint, but I didn't look into this more....

shawkins · 2026-06-30T17:24:03Z

AFAICT you need an exception mapper explicitly for the token endpoint, but I didn't look into this more....

Right, and ideally it would be endpoint based as the KeycloakErrorHandler affects admin endpoints and a few other things beyond OAuth as well. We should probably put more thought into this as it relates to admin api v2 - because as it stands we'll have two different styles of error handling - oauth for uncaught exceptions, or the explicit handling we have in the admin layer.

michalvavrik · 2026-07-12T21:24:36Z

Hello @GautamKumarOffical, I looked into this today and we need the solution for only selected endpoints (token endpoint, device authorization endpoint and logout endpoints seems to be only affected ATM) which is possible. I agree with comments that we should wait for Quarkus 3.33.3.

Tests can look like this 74f5751. My proposed way would be @ServerExceptionMapper for @NotSupportedException in these sub-resources, but that will go down to the feedback from reviewers.

I propose to close this one and wait. However if you prefer to research more focused solutions, feel free to rework this one. I'll leave it up to you.

michalvavrik · 2026-08-03T21:42:50Z

I just spend whole day on this and this PR is just hiding actual bugs in Keycloak and Quarkus. Let's go with #51410 or re-discuss desired approach in the linked issue. Thank you for the time you invested into this PR.

Copilot AI review requested due to automatic review settings June 22, 2026 05:15

GautamKumarOffical requested a review from a team as a code owner June 22, 2026 05:15

keycloak-github-bot Bot added the team/core-protocols label Jun 22, 2026

GautamKumarOffical mentioned this pull request Jun 22, 2026

Malformed Content-Type header causes HTTP 500 on token endpoints instead of RFC 6749 §5.2 compliant 400 #49964

Closed

2 tasks

Copilot started reviewing on behalf of GautamKumarOffical June 22, 2026 05:16 View session

Copilot AI reviewed Jun 22, 2026

View reviewed changes

keycloak-github-bot Bot added the flaky-test label Jun 22, 2026

keycloak-github-bot Bot mentioned this pull request Jun 22, 2026

Flaky test: org.keycloak.testsuite.saml.SamlClientTest#testLoginWithOIDCClient #49985

Closed

fix: narrow IllegalArgumentException to 400 only for media type parsi…

2567332

…ng errors Signed-off-by: Gautam Kumar <gautamkumarofficial@users.noreply.github.com>

mposolda added team/cloud-native and removed team/core-protocols labels Jun 23, 2026

michalvavrik reviewed Jun 29, 2026

View reviewed changes

michalvavrik closed this Aug 3, 2026

Navigation Menu

Uh oh!

fix: return 400 instead of 500 for malformed Content-Type headers on token endpoint - #50200

fix: return 400 instead of 500 for malformed Content-Type headers on token endpoint#50200
GautamKumarOffical wants to merge 2 commits into
keycloak:mainfrom
GautamKumarOffical:fix-49964-malformed-content-type

GautamKumarOffical commented Jun 22, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

GautamKumarOffical commented Jun 23, 2026

Uh oh!

mposolda commented Jun 23, 2026

Uh oh!

GautamKumarOffical commented Jun 23, 2026

Uh oh!

michalvavrik left a comment

Uh oh!

michalvavrik Jun 29, 2026

Uh oh!

michalvavrik Jun 29, 2026

Uh oh!

shawkins commented Jun 29, 2026

Uh oh!

mposolda commented Jun 29, 2026

Uh oh!

michalvavrik commented Jun 29, 2026

Uh oh!

shawkins commented Jun 30, 2026

Uh oh!

michalvavrik commented Jul 12, 2026

Uh oh!

michalvavrik commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

GautamKumarOffical commented Jun 22, 2026

Problem

Fix

Changes:

How to Reproduce

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

GautamKumarOffical commented Jun 23, 2026

Uh oh!

mposolda commented Jun 23, 2026

Uh oh!

GautamKumarOffical commented Jun 23, 2026

Uh oh!

michalvavrik left a comment

Choose a reason for hiding this comment

Uh oh!

michalvavrik Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

michalvavrik Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

shawkins commented Jun 29, 2026

Uh oh!

mposolda commented Jun 29, 2026

Uh oh!

michalvavrik commented Jun 29, 2026

Uh oh!

shawkins commented Jun 30, 2026

Uh oh!

michalvavrik commented Jul 12, 2026

Uh oh!

michalvavrik commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants