CVE-2026-14529 is a server side request forgery in IBM WebSphere Application Server and Liberty when the SIP container feature, sipServlet-1.1, is enabled. It is rated 9.4 (critical). IBM tells customers to apply the interim fix for APAR PH72053 or DT495928, or a fix pack at the levels named in its bulletin.
What's affected
- Products: IBM WebSphere Application Server 9.0 and 8.5 (traditional), and IBM WebSphere Application Server Liberty 17.0.0.3 through 26.0.0.8.
- Condition: the SIP container feature,
sipServlet-1.1, is enabled. IBM's description states the issue occurs when that feature is on. - Fix for Liberty: the interim fix for APAR PH72053 on top of the minimum fix pack level it requires, or Liberty fix pack 26.0.0.9 or later.
- Fix for traditional 9.0 (9.0.0.0 through 9.0.5.28): the interim fix for APAR DT495928, or fix pack 9.0.5.29 or later.
- Fix for traditional 8.5 (8.5.0.0 through 8.5.5.30): the interim fix for APAR DT495928, or fix pack 8.5.5.31 or later.
- Timing: IBM's bulletin lists the fix packs as targeted for the third quarter of 2026. It added interim fixes for Liberty 26.0.0.8 on 11 August 2026, so check the bulletin for current availability.
- Severity: 9.4 with the record's CWE-306 (missing authentication for critical function). Not on the CISA Known Exploited Vulnerabilities list. IBM lists no workaround.
How to check if you're exposed
The first question is whether you run the SIP container at all. Most WebSphere estates do not, which would take you out of scope for this CVE.
For Liberty, look for the feature in your server.xml and any included configuration files:
grep -rn "sipServlet" <liberty_install>/usr/servers/*/
IBM also publishes a procedure titled "How to determine if Liberty is using a specific feature", which the bulletin links. For traditional WebSphere, check whether any deployed application relies on the SIP container, and review the server's configured containers with your administrators.
Then get the exact level. On traditional WebSphere:
<was_root>/bin/versionInfo.sh
On Liberty:
<liberty_install>/bin/productInfo version
Compare the result with the ranges above. A server with the feature enabled and a level below the fix is in scope, and so is any server where nobody can say whether the feature is on.
What to do now
- Build a list of WebSphere servers, traditional and Liberty, with their version and whether sipServlet-1.1 is enabled.
- For servers with the feature on, apply the interim fix for PH72053 (Liberty) or DT495928 (traditional), after raising the fix pack level to the minimum IBM requires.
- Plan the move to Liberty 26.0.0.9, traditional 9.0.5.29 or traditional 8.5.5.31 as the fix packs become available.
- If you do not need the SIP container, remove the feature from the server configuration so the attack surface goes away. Test this in a non production server first.
- Restrict outbound network access from application servers to what they need, so a forged server side request has fewer places to go.
- Record the change and re-check the inventory after the maintenance window.
Why it matters
Server side request forgery means an attacker can make your server send requests on their behalf. The server sits inside your network, behind the perimeter, and usually has access to internal services, management interfaces and cloud metadata endpoints that outsiders cannot reach. A forged request goes out from that trusted position.
IBM's bulletin classifies this one under CWE-306, missing authentication for critical function, and scores it with network access, no privileges and no user interaction. The high score reflects the position of the server and the lack of a barrier, not a published attack. IBM says only what the flaw allows. It does not report exploitation, and the record is not in the CISA catalog, so nothing here supports saying it is under attack.
The detail that matters most for triage is the condition. The flaw is tied to an optional feature. That gives you a clean way to work: find where the feature is enabled, fix those servers first, and for the rest document that the feature is off. A scanner that reports every WebSphere 9.0 server as critical will overstate your exposure, and one that ignores the condition will understate it. Version alone is not enough, so pair it with configuration.
This is also a good case for tracking vendor advisories continuously. The bulletin changed after publication, with interim fixes added for Liberty 26.0.0.8 two weeks later, and fix packs were still described as targeted. A one time check on the publication day would have missed that. Write down which APAR you are waiting on and re-check on a schedule.
Finally, treat outbound traffic as a control. Application servers rarely need to reach arbitrary internal addresses. Egress rules and network segmentation limit what a forged request can touch even when a fix is delayed.
Try it yourself
Fix packs and interim fixes arrive on IBM's schedule, not yours. This demo shows how continuous monitoring keeps an eye on what is still unpatched.
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if the SIP container is off?
IBM states the vulnerability exists when the sipServlet-1.1 feature is enabled. Confirm the feature is not enabled in your configuration, and still schedule the fix pack.
Is there a workaround?
IBM's bulletin lists none. The options are the interim fix, the fix pack, or removing the feature if you do not use it.
Sources
Last reviewed: 19 October 2026.
