IBM Support

WebSphere Liberty behavior changes

Release Notes


Abstract

Behavior changes in WebSphere Liberty by release.

Content

WebSphere Liberty adopts a zero-migration architecture, meaning customers can move to the latest version of Liberty with minimal impact to your current applications and configurations.

There are occasions, however, when behavior cannot be guaranteed to remain the same when moving from version to version. Behavior changes might be introduced to fix security vulnerabilities, address significant usability concerns, or various other reasons. This page is intended to document such potential behavior changes across releases of WebSphere Liberty.

For more information about zero-migration, see Zero-migration architecture in the Open Liberty docs.

Changes by release:

26.0.0.8

Default parsing limits added to JSON4J

The JSON4J parser that Liberty uses internally now enforces default limits on the size and structure of the JSON it parses. JSON that exceeds a limit is now rejected with an IOException instead of being parsed.

If an application legitimately processes JSON that exceeds a default limit, parsing now fails with an error message that names the limit and the system property that controls it. To raise a limit, set the corresponding system property, for example in the jvm.options file:

LimitSystem propertyDefault
Elements in an arraycom.ibm.json4j.max.array.size100000
Members in an objectcom.ibm.json4j.max.object.members10000
Nesting depthcom.ibm.json4j.max.nesting.depth500
String length, in characterscom.ibm.json4j.max.string.length1048576
Number length, in characterscom.ibm.json4j.max.number.length100
Estimated total size of parsed content, in bytescom.ibm.json4j.max.total.size104857600 (100 MB)

The properties are read once, when the JSON4J parser is first loaded, so restart the server after you change them.

26.0.0.7

Liberty container images updated to UBI 10 Minimal

Beginning with 26.0.0.7, all Liberty container images based on UBI Minimal (-ubi-minimal tags) are built on Red Hat Universal Base Image (UBI) 10 Minimal instead of UBI 9 Minimal. The container image tag names are unchanged, so no updates to image references are required. Releases prior to 26.0.0.7 continue to use UBI 9 Minimal and continue to receive operating system and Java security updates through their supported lifecycle.

For more information, see Liberty container images updated to UBI 10 Minimal in the 26.0.0.7 blog.

Tracking logged-out SSO cookies enabled by default

Liberty now tracks logged-out Single Sign-On (SSO) cookies by default, so a logged-out SSO cookie can no longer be replayed after logout. If a logged-out SSO cookie is replayed, the user is prompted to reauthenticate.

To restore the previous behavior, disable tracking in server.xml:

<webAppSecurity trackLoggedOutSSOCookies="false"/>

For more information, see Tracking logged-out SSO cookies enabled by default in the 26.0.0.7 blog.

26.0.0.5

Update to TLS/SSL Cipher support

Liberty now uses the effective cipher list from the underlying JDK for SSL configuration. The securityLevel attribute on the <ssl> element is no longer used and is ignored because cipher categories such as MEDIUM and LOW no longer contain any remaining ciphers.

If securityLevel is configured on an <ssl> element in server.xml (for example, securityLevel="HIGH"), it can be removed. Liberty now defaults to using the effective JDK cipher list.

Additionally, the enabledCiphers attribute has been updated to support new filtering options for customizing cipher suites.

For more information, see Update to TLS/SSL Cipher support in the 26.0.0.5 blog.

26.0.0.4

Blocklist added to FileService MBean

The FileService MBean provided by the restConnector-2.0 feature in Liberty now includes a 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.

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 Blocklist added to FileService MBean in the 26.0.0.4 blog.

Default LTPA keys password removal

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

  • Check server.xml. Look for keysPassword on the <ltpa /> element.
    • If it's set, you don't need to do anything.
    • If it's not set, don't add it. Go to the next step.
  • Check server.env. Look for keystore_password.
    • If it's set, you don't need to do anything else. On startup, Liberty uses it to re-encrypt the keys in ltpa.keys. The LTPA keys themselves don't change.
    • If it's not set, go to the next step.
  • Add keystore_password=<your-password> to server.env. Use keystore_password, not ltpa_keys_password. On startup, Liberty uses it to re-encrypt the LTPA keys that the default password protected.
  • Watch for startup failures. If neither keysPassword nor keystore_password is set, the LTPA service fails with CWWKS4118E.
  • Servers created with --no-password. These servers have no keystore_password in server.env, so you must add one.
  • New servers. Liberty generates a random ltpa_keys_password and stores it in server.env (unless you use --no-password). It's used when keysPassword isn't set. You don't need to do anything.

For more information, see Default LTPA keys password removal in the 26.0.0.4 blog.

26.0.0.3

Jandex Index Format Support

Open Liberty supports Jandex index formats 11, 12, and 13. Jandex versions 3.1.0 through the current latest version, 3.5.3, generate indexes that use these formats. Previously, Open Liberty supported Jandex index format versions only up to and including version 10.

Previously, when Jandex usage was enabled and an application included Jandex indexes that used formats 11 through 13, Open Liberty displayed an error message and ignored those indexes. In such cases, annotation scanning was performed by using Liberty's internal annotation scanning mechanism.

With the addition of support for Jandex index formats 11 through 13, Open Liberty now uses indexes that are generated in these formats. These indexes must be kept up to date with the application classes. Ensure that the Jandex indexes packaged with your application accurately reflect the current application classes.

For more information, see Jandex Index Format Support Update in the 26.0.0.3 blog.

AES encoding changes

The securityUtility encode command now requires a key to be specified for AES encodings. Specify a key by including one of the following options: --key, --base64Key, --aesConfigFile, or --keyring.

For more information, see AES encoding changes in the 26.0.0.3 blog.

24.0.0.9

Hostname and IP address verification enabled by default

Hostname and IP address verification are now enabled by default. This verification is enforced for target servers in all SSL connections through Liberty socket factories.

For more information, see Hostname verification for Liberty.

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m3p000000F7xeAAC","label":"IBM WebSphere Liberty-All Platforms"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"19.0.0;20.0.0;21.0.0;22.0.0;23.0.0;8.5.5;9.0.0;9.0.5;Liberty"}]

Document Information

Modified date:
26 October 2026

UID

ibm17289469