TL;DR: Seven WebSphere Liberty flaws can take an attacker from pre-authenticated SAML cookie forgery to arbitrary file write and full server compromise, according to Oligo Security, while reader-role access can expose passwords, LTPA keys, and encrypted configuration values. The deeper lesson is that identity controls fail when their secrets, role boundaries, and integrity checks are broken at the same time.
At a glance
What this is: This research shows that multiple WebSphere Liberty weaknesses can collapse both pre-authentication SAML trust and post-authentication admin boundaries, creating paths from unauthenticated access to full server compromise.
Why it matters: IAM and PAM teams need to treat application control planes as identity-critical surfaces because broken token integrity, weak role separation, and recoverable secrets can turn low privilege into total compromise.
Context
WebSphere Liberty is not just an application server. In this report, it behaves like an identity-adjacent control plane because it handles SAML single sign-on, administrative roles, token signing, and encrypted configuration values that govern who can access what.
The security problem is that those trust boundaries fail in layered ways. A forged SAML cookie can bypass authentication, while low-privilege access to AdminCenter can expose secrets, recoverable tokens, and configuration data that should never be readable to ordinary users.
For identity teams, the important question is not whether Liberty is an application vulnerability or an IAM issue. It is both: once a runtime owns identity data, secret material, and admin workflows, control-plane failures become identity failures.
Key questions
A: Role-based access stops being meaningful when a read-only user can reach authentication keys, plaintext passwords, or encrypted values that are easily reversible. In that situation, the role no longer limits impact, because the user can often impersonate others or recover higher-privilege credentials. Teams should classify those endpoints as identity-critical, not informational, and review them with the same rigor as admin functions.
Q: Why do hardcoded secret-protection modes create long-term identity risk?
A: Hardcoded secret-protection modes create long-term risk because they make protected values reversible across systems, backups, and old snapshots. Once a fixed key or default password is known, every credential ever encoded with it becomes recoverable. That turns what looks like historical data into active identity material and extends exposure far beyond the live system.
A: If the flaw changes who can authenticate, impersonate, sign tokens, or access secret material, it is an IAM problem as well as an application flaw. The presence of middleware does not reduce identity impact when the middleware issues or protects credentials. Teams should route these issues through both application security and identity governance reviews.
Q: What should organisations do when a management console can expose passwords or token keys?
A: They should remove that console from any assumption of harmless read-only access and treat it as a privileged identity surface. That means tightening role boundaries, eliminating secret exposure through the UI, and auditing whether configuration views leak data that can be used for impersonation. If they do, the console is part of the credential attack path.
Technical breakdown
How a forgeable SAML cookie breaks pre-authentication trust
WebSphere Liberty's SAML Web SSO flow serializes request state into a browser cookie and later deserializes it on the server. The intended protection is a digest that should bind the cookie to a server secret, but the bug discards the secret's contribution, so the integrity check no longer proves anything. That matters because the server then deserializes attacker-controlled data with ObjectInputStream.readObject(), which is a direct path to unsafe object creation before any authentication occurs. In practice, the control that failed is not SAML itself but the assumption that a server-bound cookie can be trusted once its digest verifies.
Practical implication: Treat any pre-authentication deserialization path as an authentication boundary and remove cookie-based state that can be forged or replayed.
Why reader-role access becomes a secrets exposure problem
AdminCenter's reader role is supposed to provide visibility without write power, but the file-access endpoint ignores that trust model and returns sensitive server files to authenticated users. That breaks the separation between observability and authority because files like ltpa.keys contain the material used to sign authentication tokens. Once those keys are exposed, token forgery becomes possible, which means file-read access turns into identity impersonation. The wider lesson is that role-based access is not meaningful if the role can reach secret-bearing configuration and signing material through adjacent administrative APIs.
Practical implication: Review any admin UI that mixes read-only visibility with access to key material, configuration files, or token-signing inputs.
How hardcoded encryption keys turn configuration protection into reversible secrecy
The report shows two separate weaknesses in configuration protection. The default securityUtility mode uses a fixed single-character XOR key, while the AES option relies on a hardcoded universal key. Both create the same failure mode: encrypted passwords remain recoverable across installations, backups, and snapshots because the protection is not instance-specific and not operator-controlled. That means 'encrypted' configuration can still be live credentials exposure, especially when passwords are stored in server.xml or archived for long periods. Identity governance fails here because secret protection is treated as formatting rather than lifecycle security.
Practical implication: Assume any configuration secret protected by fixed or hardcoded keys is recoverable and handle it as exposed credential material.
Threat narrative
Attacker objective: The attacker aims to move from network reach or low privilege to full control of the Liberty server and the credentials or workloads it protects.
- Entry occurs through two distinct paths: an unauthenticated attacker can use the SAML cookie flaw, or an authenticated low-privilege user can enter through AdminCenter reader access.
- Credential access follows when the reader role retrieves ltpa.keys, plaintext configuration passwords, or reversibly encoded secrets from server configuration and management endpoints.
- Escalation happens when the attacker forges authentication tokens or recovers administrator credentials, then uses admin access to upload a crafted archive that escapes the intended write directory.
- Impact is full server compromise through arbitrary file write, configuration overwrite, or remote code execution in a trusted enterprise runtime.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity control planes fail when their secret material and trust boundaries are managed as separate problems. WebSphere Liberty shows that a runtime can hold authentication, signing, and configuration secrets while still presenting itself as a normal application server. Once those assets sit inside the same control plane, one broken check can invalidate several others. The practitioner lesson is that identity-aware infrastructure must be evaluated as a single trust surface, not as isolated features.
Reader access is not harmless when it can reach signing keys, encrypted configuration, or identity tokens. The article shows that a role intended for observation can still unlock impersonation if the adjacent APIs expose ltpa.keys or recoverable passwords. That is a governance failure, not just an authorization bug, because the role definition no longer matches the actual blast radius. Practitioners need to treat read-only admin roles as potential credential-recovery paths.
Hardcoded secrets create identity debt because they make historical exposure permanently relevant. Once a vendor ships reversible protection, every backup, snapshot, and archived configuration encrypted under that scheme remains suspect. That changes secret governance from periodic hygiene to irreversible exposure review. The implication is simple: if the encryption boundary is fixed across environments, lifecycle controls cannot restore the lost trust.
Control-plane compromise in middleware is an IAM problem as much as an application problem. Liberty sits between users, tokens, admin workflows, and backend services, so a flaw in its security model can become an enterprise-wide identity pivot. That is why application runtime reviews should include token issuance, secret handling, and role enforcement in the same assessment. The practitioner conclusion is to audit middleware as part of identity architecture, not just application security.
Broken integrity checks and broken secret protection together produce a false sense of safety. The article's strongest signal is not any single CVE but the pattern of protective mechanisms that exist in name only. A digest that ignores its secret, a token key that can be read, and encrypted values that are reversible all point to the same governance gap: controls cannot be credited simply because they are configured. Practitioners should verify whether a control changes attacker capability, not whether it exists on paper.
What this signals
Control-plane reviews need to move closer to identity governance. When middleware can issue tokens, store secrets, and expose admin files, conventional appsec review is not enough because the blast radius is an impersonation problem first and a software flaw second. Practitioners should put token material, signing keys, and role boundaries into the same governance workflow.
Credential recovery risk is the hidden pattern here. The article shows that reader access, reversible encoding, and exposed configuration can combine into a practical privilege-escalation path. That is a strong signal to review any control plane where a low-privilege view can surface material that later becomes an authentication bypass.
Identity trust now depends on runtime integrity, not just login design. If the server can be tricked into accepting forged state or can leak the material used to sign that state, the access model is already compromised. The operational signal is clear: treat administrative middleware as part of the trust boundary, not a neutral platform layer.
For practitioners
- Audit pre-authentication deserialization paths Find any SAML or session-handling code that serializes client-controlled state and confirm whether server-side integrity checks actually bind to a secret before deserialization occurs.
- Reclassify reader roles as secret-bearing access Map every AdminCenter-style read-only role to the files, keys, and configuration values it can reach, then treat token-signing material and password-bearing config as privileged data.
- Rotate every secret created under default encoding Identify passwords protected with fixed XOR or hardcoded AES keys and replace them with new credentials, because old backups and snapshots remain recoverable.
- Restrict administrative file upload and extraction Require path validation on every archive entry before server-side expansion and ensure upload features cannot write outside the intended configuration directory.
- Review middleware as identity infrastructure Include application servers in IAM and PAM reviews when they issue tokens, store signing keys, or expose encrypted configuration, not just when they host applications.
Key takeaways
- WebSphere Liberty's control plane failures show that authentication, role boundaries, and secret handling can collapse together when the runtime is trusted too broadly.
- The report describes a chain from forged SAML state and low-privilege file access to recoverable credentials and full server compromise.
- The defensive priority is to remove reversible secret protection, tighten read-only admin exposure, and verify that token and cookie integrity checks actually bind to server-held secrets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Reader access, config exposure, and hardcoded keys all expose secrets that should remain protected. |
| NHI-05 — Overprivileged NHI | AdminCenter and token-signing paths give low privilege more reach than the role model suggests. | |
| NHI-07 — Long-Lived Secrets | Hardcoded and reusable keys make old credentials and archived configurations permanently risky. | |
| Recommendation — Inventory and revoke any exposed NHI secrets before they can be reused for impersonation. Reduce NHI access scopes where read-only roles can still reach authentication material. Replace fixed secret-protection schemes with environment-specific credentials and rotation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on weak management of passwords, token keys, and recoverable authentication material. |
| Recommendation — Apply authenticator management controls to rotate and replace every credential exposed by the control plane. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0008;TA0040 — Credential Access; Privilege Escalation; Lateral Movement; Impact | The exploit chain moves from credential exposure to escalation, then broader compromise. |
| Recommendation — Map the chain to credential access and privilege escalation tactics to prioritise detection and hardening. | ||
Key terms
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- SAML SSO: SAML SSO is a way for a user to sign in once and then access multiple applications without logging in again. Technically, it uses Security Assertion Markup Language to pass signed authentication assertions from an identity provider to a service provider, enabling federated authentication and centralized session control.
- LTPA Token: An LTPA token is a signed authentication token used to carry a user's session identity across requests in WebSphere environments. It depends on protected signing keys, so if those keys are exposed or recoverable, impersonation can follow even when the original password is unknown.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 3, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org