Fun With JWT X5u

By Red Siege | May 30, 2024

by Senior Security Consultant Douglas Berdeaux

On a recent web application penetration test engagement, I came across a JSON Web Token (JWT) that contained an x5u header parameter. I almost always see JWTs being used by target web applications during my assessments, but I had never seen the x5u JWT header parameter in use before.

The x5u JWT header parameter is used by web application and Identity and Access Management (IDM) developers and maintainers to specify the location of a digitally signed certificate that should be used to sign and verify the JWT. One of the strongest security features of JWT is that the claims being made by the user are verified by the server using integrity checking, in the form of a digital cryptographic signature appended to the end of the JWT. So, if an attacker or malicious insider were to tamper with the claims, by attempting to alter a claim value located in the payload of the JWT, as shown in the example screenshot below in which we changed the sub (subject, or username) value from “user” to “admin,” the server should recognize the tampering attempt during the token validation process using the appended signature, and the certificate or private key.


Tampered JWT Subject Claim


This is why just simply tampering with JWT payload claim values never works unless the JWT has no encryption algorithm defined and no signature. Good luck finding those 4-leaf clovers!

The x5u parameter that I observed was a URL that lacked TLS. This was the first issue that I identified. According to the official RFC for the x5u JWT header parameter definition, the URL must have integrity and security, in the form of TLS:

The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246];

This could be easily overlooked by a web application penetration tester who was not familiar with the RFC. My next step was to tamper with the x5u JWT header parameter to see if the target web application would generate traffic to my private Digital Ocean Droplet, which worked. I set up a temporary HTTP server using Python3’s http.server module and observed a connection originating from the target web application’s server. This was the second issue that I identified; the server accepted JWTs with arbitrary x5u JWT header parameter values. Again, going back the RFC that defines the proper usage of the x5u JWT header parameter, we see that the server must validate the identity of the domain specified in the user’s JWT:

… the identity of the [x5u JWT header parameter] server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].

Next, I decided to hunt for a Server-Side Request Forgery (SSRF) vulnerability by specifying internal network host names, such as,, etc. This method didn’t get me anywhere unfortunately as the error in the HTTP response did not include network connection information. But, if it did, then we can see how we’d be able to possibly map out the internal network and host services where the client’s web application server resided.

Finally, I decided to simply generate my own certificate using OpenSSL using the following two commands outlined in the screenshot below.


Generating a RSA Key and Certificate


The first command generated the certificate and private RSA key. The second extracted the public key from the certificate. All three will be used in this attack.

Then, I placed the actual certificate (CRT file) onto the Droplet that I control and hosted it with Python3’s http.server module.

Now comes the fun part: generating the new JWT. This can be done using JWT.IO as outlined in the screenshot below. The public key and private key get pasted into the RSASHA256 function, and we tampered with the JWT x5u header parameter and sub JWT claim. Interface


The target web application server should now pull down my redsiege.crt file and verify my JWT.

I observed the call to the file in Python3, but unfortunately, the attack failed as I was met with an authorization error by the target web application’s HTTP response when attempting to consume an API endpoint using this new JWT. The server simply denied the JWT altogether. Although I failed to get privilege escalation by attempting to tamper with the JWT, this was a bittersweet experience for me. On the positive side, I uncovered some security issues with the JWT implementation and learned more about how to approach JSON Web Tokens that use the x5u header parameter.

RFC for x5u JWT Header Parameter: RFC 7517: JSON Web Key (JWK)

Python3’s http.server Module: http.server — HTTP servers

OpenSSL Tool: Command Line Utilities – OpenSSLWiki


If you have any questions or want to discuss this further, please join me in our Red Siege Community Discord!

About Douglas Berdeaux, Senior Security Consultant

Douglas was a manager of a Red Team for a consulting company and has performed penetration testing for clients with high security maturity on internal networks, internal and externally facing web applications, and desktop applications. Douglas was a full-stack enterprise-class web developer for close to a decade building, securing, and testing the security of business-critical web and mobile applications. He has taught cybersecurity as an adjunct professor for Duquesne University and has published multiple books and articles about penetration testing, hardware hacking, and programming.



Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

By Red Siege | July 8, 2024

by Mike Saunders, Principal Security Consultant This blog is the fourth in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the series […]

Learn More
Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

Adventures in Shellcode Obfuscation! Part 3: Encryption

By Red Siege | July 1, 2024

By Mike Saunders, Principal Security Consultant   This blog is the third in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the […]

Learn More
Adventures in Shellcode Obfuscation! Part 3: Encryption

Phone Switch Labs CTF – Walk-Through

By Red Siege | June 26, 2024

by Douglas Berdeaux, Senior Security Consultant CTF Getting Started Phone phreaking is the practice of exploring and hacking telephones, telephone switches, telephone test equipment, and physically exploring the telephone […]

Learn More
Phone Switch Labs CTF – Walk-Through

Find Out What’s Next

Stay in the loop with our upcoming events.