CVE-2026-93909: IBM WebSphere Liberty Auth Bypass Flaw

CVE-2026-93909 Overview

CVE-2026-93909 is an authentication bypass vulnerability affecting IBM WebSphere Application Server Liberty versions 17.0.0.3 through 26.0.0.10. The flaw exists when the samlWeb-2.0 feature is enabled, allowing network-based attackers to bypass authentication controls without user interaction or prior credentials. The weakness is classified under CWE-384: Session Fixation, indicating improper handling of session identifiers during the Security Assertion Markup Language (SAML) authentication flow. Successful exploitation can compromise the confidentiality and integrity of applications relying on the vulnerable SAML Web Single Sign-On (SSO) feature.

Critical Impact
Unauthenticated remote attackers can bypass SAML authentication to access protected resources and impersonate legitimate users on affected IBM WebSphere Liberty deployments.

Affected Products

IBM WebSphere Application Server Liberty 17.0.0.3 through 26.0.0.10 with samlWeb-2.0 feature enabled
Deployments using SAML Web SSO for federated authentication
Applications depending on Liberty SAML session management for access control

Discovery Timeline

2026-10-13 - CVE-2026-93909 published to the National Vulnerability Database (NVD)
2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-93909

Vulnerability Analysis

The vulnerability resides in the samlWeb-2.0 feature of IBM WebSphere Application Server Liberty. When the feature processes SAML authentication requests, it fails to properly manage session state tied to the authenticating subject. An attacker can leverage this flaw across the network without authentication or user interaction. The result is a bypass of the authentication layer, granting access to protected application resources that should require a valid SAML assertion.

The advisory references CWE-384 Session Fixation, meaning the server accepts or reuses a session identifier that an attacker can influence or predict. In SAML Web SSO flows, this class of weakness typically allows an adversary to pre-establish a session, trick the identity provider or service provider into binding a legitimate user's assertion to that session, and then reuse the fixed session to act as that user.

Root Cause

The root cause is improper session handling within the Liberty SAML Web profile implementation. The server does not sufficiently rotate or invalidate session identifiers across authentication state transitions. This allows a session identifier chosen or captured before authentication to remain valid after a successful SAML assertion is processed, violating the trust boundary between unauthenticated and authenticated states.

Attack Vector

The attack is network-reachable, requires low complexity, and needs no privileges or user interaction. An attacker interacts with the SAML endpoints exposed by a vulnerable Liberty server where samlWeb-2.0 is active. By manipulating the session binding during the SAML Web SSO exchange, the attacker can obtain an authenticated session associated with another identity. See the IBM Support advisory for vendor technical details.

No verified proof-of-concept code is publicly available for CVE-2026-93909.
Refer to the IBM Support advisory for technical specifics on the SAML
session-handling defect and the conditions required to trigger it.

Detection Methods for CVE-2026-93909

Indicators of Compromise

Unexpected successful SAML assertions in Liberty trace.log or messages.log that do not correlate with a prior browser-initiated login from the same session.
Session identifiers (JSESSIONID or LtpaToken2) that persist unchanged across the pre-authentication and post-authentication phases of the SAML Web SSO flow.
Access to protected URLs from client IP addresses that never completed an interactive identity provider login.

Detection Strategies

Audit WebSphere Liberty server.xml for the presence of the samlWeb-2.0 feature and enumerate exposed SAML Assertion Consumer Service (ACS) endpoints.
Correlate identity provider (IdP) authentication logs with Liberty service provider (SP) session creation events to find assertions consumed without a matching IdP login.
Alert on multiple distinct user principals being bound to the same session cookie value within a short time window.

Monitoring Recommendations

Forward Liberty security audit logs and HTTP access logs to a centralized analytics pipeline for cross-source correlation.
Monitor /ibm/saml20/* and configured ACS paths for anomalous POST volume or repeated requests reusing the same session identifier.
Track administrative access to applications protected by SAML and flag privileged actions originating from sessions with abnormal authentication histories.

How to Mitigate CVE-2026-93909

Immediate Actions Required

Inventory all IBM WebSphere Application Server Liberty instances in the version range 17.0.0.3 through 26.0.0.10 and identify those with samlWeb-2.0 enabled.
Apply the fix published by IBM as described in the IBM Support advisory to all affected servers.
Invalidate active application sessions after patching to purge any sessions established under the vulnerable code path.

Patch Information

IBM has published remediation guidance on its support site. Administrators should consult the IBM Support page for CVE-2026-93909 for the fix pack or interim fix applicable to their Liberty version and apply it following IBM's documented upgrade procedure.

Workarounds

Disable the samlWeb-2.0 feature in server.xml where SAML Web SSO is not strictly required, removing the vulnerable code path entirely.
Restrict network access to Liberty SAML endpoints using a reverse proxy or web application firewall allowlist until patching is complete.
Shorten HTTP session timeouts and enforce session identifier rotation at the fronting proxy to reduce the window for session fixation abuse.

bash

# Example: remove the vulnerable feature from a Liberty server.xml
# Edit ${WLP_USER_DIR}/servers/<serverName>/server.xml and remove:
#   <feature>samlWeb-2.0</feature>
# Then restart the server:
${WLP_INSTALL_DIR}/bin/server stop <serverName>
${WLP_INSTALL_DIR}/bin/server start <serverName>