Logged-Out SSO Cookie Tracking, mpHealth REST Endpoint Controls, and more in 26.0.0.7
This release enables logged-out SSO cookie tracking by default to prevent cookie replay after logout and adds an option to disable mpHealth REST endpoints when file-based health checks are enabled.
In Open Liberty 26.0.0.7:
Along with the new features and functions added to the runtime, we’ve also made updates to our guides.
View the list of fixed bugs in 26.0.0.7.
Check out previous Open Liberty GA release blog posts.
Develop and run your apps using 26.0.0.7
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.
Tracking logged-out SSO cookies enabled by default
To continuously improve built-in security for applications, Open Liberty 26.0.0.7 now enables the tracking of logged-out Single Sign-On (SSO) cookies by default. With this feature, logged-out SSO cookies can no longer be replayed after logout.
What is the potential impact?
When a logged-out SSO cookie is replayed, the user is explicitly prompted to reauthenticate, helping to harden application security.
Tracking logged-out SSO cookies can still be disabled with the following server configuration:
<webAppSecurity trackLoggedOutSSOCookies="false"/>
For more information, check out the tracking logged-out SSO cookies documentation.
Disabling mpHealth-4.0 REST endpoints when file-based health checks are enabled
The mpHealth-4.0 feature adds MicroProfile Health 4.0 support to Open Liberty. The feature includes a file-based health check mechanism as an alternative to the /health REST endpoints. When the file-based health check mechanism is enabled, you can disable the /health/started, /health/live, and /health/ready REST endpoints using server configuration attributes.
Previously, when file-based health checks were enabled, the REST-based MicroProfile Health endpoints were still registered and accessible. This behavior was often redundant for Kubernetes deployments that rely on file-based health checks, where users typically configure probes using the exec strategy rather than httpGet or gRPC. In these scenarios, the REST health endpoints are not used.
To address this redundancy, this release introduces a new optional enableEndpoints="false" attribute on the mpHealth server configuration element in server.xml file. An equivalent environment variable, MP_HEALTH_ENABLE_ENDPOINTS=false, is also supported.
When this option is set to false and file-based health checks are enabled, the server does not register or expose the MicroProfile Health REST endpoints (/health, /health/live, /health/ready, /health/started). Requests to these endpoints return a '404 Not Found' response.
File-based health checks can be enabled with the checkInterval configuration attribute or the MP_HEALTH_CHECK_INTERVAL environment variable.
If both the environment variable and server.xml configuration are specified, the server.xml setting takes precedence at runtime.
<server>
<featureManager>
<feature>mpHealth-4.0</feature>
</featureManager>
<!-- Enable file-based health checks but disable HTTP endpoints -->
<mpHealth startupCheckInterval="1s" checkInterval="5s" enableEndpoints="false" />
...
</server>
If the enableEndpoints configuration attribute or the MP_HEALTH_ENABLE_ENDPOINTS environment variable is not set, the default value is true and the health check REST endpoints are enabled and exposed.
Note: This capability is supported only when the file‑based health check mechanism is enabled. If file-based health checks are not enabled and the enableEndpoints configuration attribute or environment variable is specified, a warning message is logged. The REST health endpoints remain enabled by default.
For more information, see the documentation.
Security vulnerability (CVE) fixes in this release
| CVE | CVSS Score | Vulnerability Assessment | Versions Affected | Notes |
|---|---|---|---|---|
8.1 |
HTTP request smuggling |
17.0.0.3-26.0.0.6 |
Affects the servlet-3.0, servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, servlet-6.1, websocket-1.0, websocket-1.1, websocket-2.0, websocket-2.1, and websocket-2.2 features |
|
5.9 |
Denial of service |
17.0.0.3-26.0.0.6 |
Affects the servlet-3.0, servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, servlet-6.1, websocket-1.0, websocket-1.1, websocket-2.0, websocket-2.1, and websocket-2.2 features |
|
7.1 |
Denial of service |
17.0.0.3-26.0.0.6 |
Affects servlet-3.0, servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, servlet-6.1, websocket-1.0, websocket-1.1, websocket-2.0, websocket-2.1, and websocket-2.2 features |
|
7.5 |
Denial of service |
17.0.0.3-26.0.0.6 |
Affects jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features |
|
7.5 |
Denial of service |
17.0.0.3-26.0.0.6 |
Affects jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features |
|
7.2 |
Server-Side Request Forgery |
17.0.0.3-26.0.0.6 |
Affects jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features |
|
7.2 |
HTTP request smuggling |
17.0.0.3-26.0.0.6 |
Affects restConnector-2.0 feature |
|
7.4 |
HTTP request smuggling |
17.0.0.3-26.0.0.6 |
For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.
Notable bugs fixed in this release
We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 26.0.0.7.
Get Open Liberty 26.0.0.7 now
Available through Maven, Gradle, Docker, and as a downloadable archive.