back to all blogsSee all blog posts

Enhanced JWT validation, Java 26 support, and more in 26.0.0.4

image of author
Navaneeth S Nair on Apr 21, 2026
announcements , microprofile , java-se , release , security ,
Post available in languages:

This release introduces support for selecting JWT signature algorithms from JOSE headers and adds Java 26 support. It also removes the default LTPA keys password for enhanced security, and includes file transfer restrictions and security vulnerability fixes.

In Open Liberty 26.0.0.4:

View the list of fixed bugs in 26.0.0.4.

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 26.0.0.4

If you’re using Maven, include the following in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.0</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code, or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging, and application management all from within your IDE.

Ask a question on Stack Overflow

File Transfer changes for 26.0.0.4

Liberty’s FileService MBean provided by the restConnector-2.0 feature now includes an extra blocklist attribute. This attribute is configured by the <blockDir> config element in the server.xml file. The default value of this attribute is ${server.output.dir}/resources/security. This behavior change resolves the security vulnerability CVE-2025-14915, by restricting default FileTransfer access to ${server.output.dir}/resources/security.

If FileTransfer access to ${server.output.dir}/resources/security is required, the original behavior can be restored by setting an empty blocklist.

For more information, see the documentation.

Default LTPA keys password removal

The default LTPA keys password is removed to resolve the security vulnerability CVE-2025-14917.

Previously, a default password for the LTPA keys was used when the keysPassword attribute was not defined in the <ltpa /> element. With this change, the default password is no longer supported.

For existing servers, if the LTPA keys password is not configured in the server.xml file, the keystore_password in the server.env file is used. This value re-encrypts the LTPA keys in the ltpa.keys file. The LTPA keys themselves are not impacted. The keystore_password is configured in the server.env file during server creation unless the --no-password option is used with the server create command.

If a keysPassword is not defined in the <ltpa /> element in the server.xml file and a keystore_password is not defined in the server.env file, the LTPA service fails. The following error message is displayed:

CWWKS4118E: LTPA configuration error. A keysPassword attribute is not configured on the <ltpa /> element, the 'ltpa_keys_password' environment variable is not set, and the 'keystore_password' environment variable is not set.

Confirm that an LTPA keys password is set up by doing the following steps:

  1. Check to see whether a keysPassword attribute is provided for the <ltpa /> element in the server.xml file (for example, <ltpa keysPassword="myKeysPassword" />).

    • If it is provided, this update does not affect you and no further action is needed.

    • If it is not provided, do not add it and proceed to the next step.

  2. Check to see whether the keystore_password environment variable exists in the server.env file (for example, keystore_password=myKeystorePassword).

    • If it exists, then the keystore_password is used to reencrypt the LTPA keys that were previously encrypted with the default keysPassword when the server starts.

    • If it does not exist, proceed to the next step.

  3. Add the following environment variable to the server.env file (ensure you use the keystore_password here and not the ltpa_keys_password described in the next section for new servers):

    keystore_password=your-desired-password

    • The keystore_password is used to reencrypt the LTPA keys that were previously encrypted with the default keysPassword when the server starts.

For new servers, a new ltpa_keys_password is randomly generated during server creation. It is stored in the server.env file unless the --no-password option is specified with the server create command. The randomly generated ltpa_keys_password is used if the keysPassword attribute is not defined for the <ltpa /> element.

For more information, see the LTPA configuration element.

Support selecting JWT signature and decryption algorithms from JOSE header

JSON Web Tokens (JWTs) can be signed by using various cryptographic signature algorithms. With this release, the JWT Consumer, MicroProfile JWT, OpenID Connect Client, and Social Media Login features support selecting the JWT signature algorithm from the JOSE header. This support allows different signature algorithms to be used based on the token header.

Previously, only one single signature algorithm (for example, RS256) was able to be configured for each configuration in the server.xml file. If the incoming JWT was signed with a different algorithm, validation would fail. This update allows the signature algorithm from the JWT header to be used for validation. It provides the flexibility of using different signature algorithms within a single configuration.

How to use

To enable signature algorithm selection from the header, set the signatureAlgorithm attribute to FROM_HEADER and optionally configure the allowedSignatureAlgorithms attribute to specify which algorithms are permitted.

If allowedSignatureAlgorithms is not configured, the default list contains all Open Liberty-supported signature algorithms: RS256, RS384, RS512, HS256, HS384, HS512, ES256, ES384, and ES512.

When using FROM_HEADER with asymmetric algorithms and a trust store setup, the public keys must be prefixed with their corresponding algorithm (e.g., RS256_keyalias) for automatic selection. During validation, the server searches the trust store for an alias that begins with the algorithm specified in the JWT’s header. If no algorithm-prefixed alias is found, the client falls back to using the alias specified by the trustedAlias attribute (for jwtConsumer) or trustAliasName attribute (for openidConnectClient, oidcLogin and mpJwt), if configured.

See the following server.xml file configurations for examples on how to apply these settings to the supported elements:

<jwtConsumer
    signatureAlgorithm="FROM_HEADER"
    allowedSignatureAlgorithms="RS256, ES384, HS512"
    ...
/>

<mpJwt
    signatureAlgorithm="FROM_HEADER"
    allowedSignatureAlgorithms="RS256, ES384, HS512"
    ...
/>

<openidConnectClient
    signatureAlgorithm="FROM_HEADER"
    allowedSignatureAlgorithms="RS256, ES384, HS512"
    ...
/>

<oidcLogin
    signatureAlgorithm="FROM_HEADER"
    allowedSignatureAlgorithms="RS256, ES384, HS512"
    ...
/>

Learn more

Server configurations:

Documentation:

Support for Java 26

Java 26 is a recent Java release that introduces new features and enhancements over earlier versions that can be useful to review. This release is not a long-term support (LTS) release.

There are 10 new features (JEPs) in Java 26. Five are test features and five are fully delivered.

Test Features:

Delivered Features:

A new change JEP 500 ("Prepare to Make Final Mean Final") in Java 26 starts enforcing true immutability of final fields by restricting their mutation when using deep reflection. In Java 26, such mutations still work but trigger runtime warnings by default, preparing developers for stricter enforcement. Future releases would likely throw exceptions instead, making the final truly nonmutable.

Developers can opt in early to this stricter behavior by using a JVM flag (for example, --illegal-final-field-mutation=deny) to detect issues sooner. This change improves program correctness, security, and JVM optimizations.

Take advantage of these changes now to gain more time to evaluate how your applications and microservices behave on Java 26.

Get started today by downloading the latest release of IBM Semeru Runtime 26 or Temurin 26, then download and install the Open Liberty 26.0.0.4. Update your Liberty server’s server.env file with JAVA_HOME set to your Java 26 installation directory and start testing.

For more information on Java 26, see the Java 26 release notes page and API Javadoc page.

displayCustomizedExceptionText property

This release adds documentation and tests for the displayCustomizedExceptionText configuration, which allows users to override Liberty’s default error messages (such as SRVE0218E: Forbidden and SRVE0232E: An exception occurred) with clearer, user-defined messages.

The feature is enabled through simple server.xml file configuration, where custom messages can be mapped to specific HTTP status codes (403 and 500).

Testing ensures that these custom messages correctly replace Liberty’s defaults across all supported platforms, confirming that the configured text is returned consistently in all scenarios.

<webContainer displaycustomizedexceptiontext="Custom error message"/>

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2025-14915

6.5

Privilege escalation

17.0.0.3-26.0.0.3

Affects the restConnector-2.0 feature

CVE-2025-14917

6.7

Weaker security

17.0.0.3-26.0.0.3

Affects the appSecurity-1.0, appSecurity-2.0, appSecurity-3.0, appSecurity-4.0, and appSecurity-5.0 features

CVE-2026-1561

5.4

Server-side request forgery

17.0.0.3-26.0.0.3

Affects the samlWeb-2.0 feature

CVE-2026-29063

8.7

Prototype pollution

17.0.0.3-26.0.0.3

Affects the openapi-3.1, mpOpenAPI-1.0, mpOpenAPI-1.1, mpOpenAPI-2.0, mpOpenAPI-3.0, mpOpenAPI-3.1, mpOpenAPI-4.0 and mpOpenAPI-4.1 features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Get Open Liberty 26.0.0.4 now

Available through Maven, Gradle, Docker, and as a downloadable archive.