WebSphere: 14 Flaws, Server Takeover Without a Login (CVE-2026-14512)

On July 28, 2026, IBM disclosed 14 vulnerabilities at once in WebSphere Application Server, its enterprise application platform. The most severe is CVE-2026-14512, rated 9.8 (Critical) out of 10 on the CVSS severity scale. It can let an attacker run arbitrary programs on the server without ever passing a login screen.

WebSphere Application Server (WAS) still sits underneath the systems that large enterprises cannot afford to stop: core banking, retail inventory, manufacturing production control. The affected products this time are the 8.5 and 9.0 lines (traditional) and the lightweight Liberty edition. The 8.5.5 line shipped in June 2013, yet IBM states plainly that "there is no planned end-of-support date for WebSphere 8.5.5 and 9.0.5." A 13-year-old release line is still supported, and still a live target.

The awkward part is that no complete fix (Fix Pack) exists yet for any of the 14. IBM's guidance is to apply an interim fix now or wait for a Fix Pack due in September or later, and the "Workarounds and Mitigations" field reads "None" on all 14 bulletins. What follows sorts the 14 by behavior and gives you a lookup table for deciding whether your environment is affected. IBM vulnerabilities have hit the WebSphere family almost every month since May, and this batch stands out for sheer volume.

All 14 vulnerabilities at a glance

Registration in the US National Vulnerability Database (NVD) happened in a single window, between 20:17 and 21:17 UTC on July 28. Every CVSS score is IBM's own assignment, and NVD has not yet completed its own reanalysis (12 records are "Received" and 2 are "Awaiting Analysis"). Here is the full list.

Counting it up: 10 of the 14 affect traditional (8.5 / 9.0) and 8 affect Liberty, with 4 (CVE-2026-14981 / 15064 / 15325 / 15328) spanning both. Both 9.8 entries exist only on the traditional side. If you run Liberty alone, your worst score is 8.7.

Who comes for the deepest layer of the business

WAS usually lives in the deepest part of a company. It processes transfers, allocates stock, drives production plans. Stop it and the business stops. The people who seriously come after that are not the sloppy scanners that hop between any weak host they find. They are initial access brokers who build entry points into corporate networks and sell them on underground markets, and the ransomware crews who buy those entry points and carry them through to a ransom demand. They comb through the IP ranges of large enterprises looking for a WAS whose admin console is visible from outside.

Three of the 14 bypass authentication, and those are the ones with obvious use to them. Concretely, the play is to craft a "boxed-up Java object" that the server automatically reassembles on receipt, throw it at the entry point, and get commands running on the server without ever touching a login screen. No credential theft step, no phishing campaign. One crafted request into the front door and they stand where the administrator stands.

Data exfiltration, encryption, and a "pay if you want it back" demand: that is what the company running WAS gets from here, and it is a sequence Japan has watched play out repeatedly. Because it is a core system there is no fallback, and every day of downtime turns straight into lost revenue. End users of that system see orders failing, balances not showing, certificates not issuing, and later receive a notice saying their information may have been exposed. That is exactly why the fastest way to deal with these 14 is to settle first, using the table below, whether your environment is even in scope.

Attacks against WebSphere deserialization (the process of turning stored data back into live objects) are not theoretical. CVE-2015-7450 was the same family, and CISA added it to the Known Exploited Vulnerabilities catalog on January 10, 2022. The same class keeps getting exploited in Apache MINA and Adobe ColdFusion too. Designs that accept boxed Java objects from outside have been breaking at the same joint for a decade.

Check this first: traditional and Liberty are different products

Misreading the scope usually starts here. Two structurally different products share the WebSphere Application Server name.

• WAS traditional (8.5 / 9.0): the heavyweight original, with an admin console, deployment manager and SOAP/JMX connector. Fix Packs are four-part numbers like 9.0.5.28 or 8.5.5.29
• WAS Liberty: the lightweight edition introduced in 2012. You enable exactly the capabilities you need as "features" in server.xml, and versions take a year-and-month shape like 26.0.0.7

The shape of the version number tells you which you have. 8.5.5.x or 9.0.5.x means traditional; 26.0.0.x means Liberty. And because both 9.8 entries are traditional-only, a Liberty-only environment does not need to jump straight to the worst-case assumption.

On the Liberty side you can narrow further by asking which features are enabled. IBM states the condition in each bulletin and publishes a dedicated document on how to check. The conditions are not equally meaningful, though.

• Any of servlet-3.0 through servlet-6.1 enabled (CVE-2026-14981 / 15064 / 15325 / 15328 / 15057): this narrows nothing in practice. If Liberty is serving a web application, one of the servlet features is enabled
• collectiveController-1.0 enabled (CVE-2026-14976 / 15280): only used when several servers are managed centrally as a collective. A standalone server is out of scope
• restConnector-1.0 or restConnector-2.0 enabled (CVE-2026-16192): applies where JMX REST management or the Admin Center is turned on. Out of scope if management interfaces are closed

In short, 3 of Liberty's 8 are feature-gated and irrelevant if you do not use those features. Reading "8 issues in Liberty" without that split leads to emergency maintenance windows nobody needed.

Version lookup table: affected CVEs and fixing Fix Pack

This cross-references IBM's eight bulletins for the fixing Fix Pack, the interim fix identifier (APAR) and the expected availability. Availability dates come from IBM's recommended updates list and are all flagged there as estimated future release dates.

That last row needs careful wording. IBM's disclaimer in every bulletin states that the "Affected Products and Versions" list covers only versions still within support, and that omission does not constitute a determination that other versions are unaffected. Liberty older than 17.0.0.3 should be read as not examined, not as safe.

Note also that moving Liberty to 26.0.0.8 clears five entries (CVE-2026-14981 / 15064 / 15325 / 15328 / 15057), but the three feature-gated ones (CVE-2026-14976 / 15280 / 16192) still apply at 26.0.0.8. You cannot look at the Liberty version number alone and conclude you are current and therefore safe.

There is no full fix yet, only interim patches

All 14 bulletins use the same remediation structure: apply an interim fix, or wait for a Fix Pack. And every Fix Pack is described as "targeted availability 3Q2026", not a committed date.

Cross-checking against IBM's recommended updates list shows how much slack that leaves.

• traditional 9.0: latest shipped is 9.0.5.28, released June 16, 2026. The fixing 9.0.5.29 is estimated for September 8, 2026 — roughly six weeks out
• traditional 8.5: latest shipped is 8.5.5.29, released February 9, 2026. 8.5.5.30 is listed with an estimated date of July 27, 2026, but the bulletins include 8.5.5.30 in the affected range, so the fix lands in 8.5.5.31, which has no row on the recommended updates list at all
• Liberty: latest shipped is 26.0.0.7, released July 14, 2026. 26.0.0.8 is estimated for August 11, 2026. 26.0.0.9, which carries the three feature-gated fixes, is not listed

In other words, waiting for a Fix Pack leaves the two 9.8 issues open for one to two months. The workaround field is "None" on all 14. IBM writes that it "strongly recommends addressing the vulnerability now," which in practice offers no option other than applying the interim fix.

Operationally, the annoying part is that the traditional side splits across five separate interim fixes. CVE-2026-14446 is DT496500; CVE-2026-14512 and CVE-2026-14528 are PH72166; CVE-2026-14974 and CVE-2026-14515 are DT496118; CVE-2026-16184 is DT496677; and the four smuggling and DoS entries are PH72192. Closing all ten means applying five fixes in sequence, each with a precondition of first raising the install to the minimum Fix Pack level the interim fix requires. This is not one maintenance window of work.

One gap stands out: of those five, only DT496500 (CVE-2026-14446, CVSS 9.8) has no distribution page we could locate at publication time. The bulletin does not link one either. The other four have download pages, which leaves the highest-severity item as the one with the least clear path to a patch. Contacting IBM Support directly is the reliable route here.

As a side note, the DT496118 distribution page is titled "OIDC v1.5.5," which suggests CVE-2026-14974 and CVE-2026-14515 sit in OpenID Connect-related components. The bulletin text states no "only if OIDC is in use" condition, though, so it is safer not to treat them as conditional.

Three that get in without a login (CVE-2026-14512 and others)

When deciding the order of work, look at these three first. All are usable by someone holding no credentials.

CVE-2026-14512: pre-authentication deserialization, leading to auth bypass or code execution (CVSS 9.8)

The heaviest of the 14. IBM describes WAS traditional as "vulnerable to pre-authentication unsafe deserialization which could allow a remote attacker to bypass authentication or execute arbitrary code." The class is CWE-502 (deserialization of untrusted data), and the vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: over the network, low complexity, no privileges, no user interaction. That is about as permissive as exploitation conditions get.

Deserialization is the step where a Java program takes data that was boxed into a byte stream for storage or transport and rebuilds it into live objects. The danger is that if the side opening the box builds it without inspecting the contents, an attacker can send a box rigged so that opening it runs code of their choosing. That this happens before authentication means the attack succeeds at the reception desk, before the login screen is ever reached.

Affected: 9.0.0.0-9.0.5.28 and 8.5.0.0-8.5.5.30. Interim fix PH72166; fixing Fix Packs 9.0.5.29 and 8.5.5.31. IBM's guidance is in bulletin 7281649. This single entry is reason enough to act this week if you have WAS facing outward.

IBM does not name which endpoint or component performs the pre-auth deserialization. In past WebSphere issues, the SOAP/JMX connector, SAML Web SSO, and JAX-WS endpoints with WS-Security enabled have served as that entry point, but nothing in the public record identifies the path this time. There is no material suggesting "disable feature X and you are safe," so hunting for an escape other than the interim fix is a poor use of time.

CVE-2026-14446: broken access control in the administrative console (CVSS 9.8)

A break in access control in the WAS traditional administrative console, the browser-based screen used to change configuration. IBM titles the bulletin "privilege escalation," but the class is CWE-306 (missing authentication for critical function) and the vector says PR:N, no privileges required.

This is worth reading carefully. "Privilege escalation" invites the assumption that you first need some account, but the vector and CWE say someone holding no account at all can reach administrative functions. The wording is more modest than the reality. Any environment exposing the admin console to the internet should expect this to be the first door tried.

The interim fix is APAR DT496500; fixing Fix Packs are 9.0.5.29 and 8.5.5.31. Details are in bulletin 7281631. As noted above, no distribution page for this interim fix could be confirmed at publication time.

CVE-2026-16184: authentication bypass via a crafted unauthenticated request (CVSS 7.0)

IBM describes a remote attacker bypassing authentication "by sending a crafted unauthenticated request." The class is CWE-862 (missing authorization). By name it sounds as alarming as the two 9.8 entries, yet the score sits at 7.0, and the vector explains why: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H. Attack complexity is High, and the impact breaks down as Low confidentiality, Low integrity, High availability.

An authentication bypass rated Low for information exposure looks inconsistent at first glance. Neither IBM nor NVD published detail, so this cannot be settled, but the scoring is consistent with a reading where what lies past the bypass is limited and the practical outcome is mostly loss of availability. The bypass itself is still real. Per bulletin 7281628 the interim fix is APAR DT496677, and a distribution page exists. Authentication bypasses are a recurring pattern in identity management products as well, so there is no case for deferring this one.

Three about rebuilding data and leaking information

CVE-2026-14974: remote code execution via unsafe deserialization (CVSS 8.1)

Same CWE-502 as CVE-2026-14512, but this one is not described as pre-authentication. The vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H: no privileges needed, but attack complexity rises to High, which drops the score to 8.1. High complexity describes situations where the attacker must gather environment details in advance or hit a timing window. Harder, not impossible.

Affected: traditional 8.5 and 9.0. The interim fix is APAR DT496118, and the same single fix also closes CVE-2026-14515. See bulletin 7281641. Two deserialization issues landing on the same day shows this class is far from exhausted across Java application servers generally.

CVE-2026-14528: remote attacker can obtain sensitive information (CVSS 7.4)

IBM says only that "a remote attacker could obtain sensitive information," with no path described. The class is CWE-532 (insertion of sensitive information into a log file), which points to a shape where values that should never be logged end up in logs, and those logs are readable from outside. It is covered by the same bulletin 7281649 as CVE-2026-14512 and shares the PH72166 interim fix.

The score breakdown here is odd. The vector reads C:H/I:H/A:N, meaning integrity impact is rated High even though the description is purely about obtaining information. A pure disclosure issue would normally be C:H/I:N/A:N, which scores 5.9. Whether the extra integrity rating is deliberate or a data-entry error cannot be determined from IBM's text. Before taking 7.4 at face value, internal prioritisation may be closer to reality if it treats this as an information disclosure issue.

CVE-2026-14515: cross-site scripting (CVSS 6.1)

The lowest score of the 14. Cross-site scripting mixes attacker-supplied script into a web page, and as the UI:R in the vector shows, a victim has to click a crafted link. This is not the kind of flaw that hands over a server on its own.

That said, it carries S:C (scope changed), meaning the impact is judged to reach beyond WAS itself. If someone who works in the WAS admin screens clicks the link, administrative actions running in that person's session is a plausible outcome. The interim fix is DT496118, shared with CVE-2026-14974, so fixing that one fixes this one. No separate emergency window is needed.

Three smuggling issues, and what happens at the proxy in front

Three of the 14 are HTTP smuggling, all classed as CWE-444 (inconsistent interpretation of HTTP requests). Their arriving together is no coincidence: bulletin 7281625 handles them alongside one DoS issue. The interim fix is PH72191 on the Liberty side and PH72192 on traditional, one each.

Smuggling here means smuggling the boundaries of an HTTP exchange. When the device in front and WAS disagree about where one request ends, you can hide inside what the front counts as a single message something WAS will pick up as a second one.

CVE-2026-15064: response smuggling via non-standard HTTP version tokens (CVSS 8.7)

The heaviest of the three. Handling of version tokens that do not follow the standard HTTP/1.1 form is loose enough that response boundaries can be shifted. The vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N. The S:C matters: it means impact reaches past WAS's own authority scope. Smuggling a response essentially means delivering A's response to B, so the victim is not WAS but other users of the system.

CVE-2026-15325: request smuggling via TRACE handling (CVSS 8.7)

TRACE is a diagnostic HTTP method that echoes a request back. It is normally disabled in production, and this flaw arises from how it is handled. Also S:C, also 8.7. IBM's description text for this entry says only "IBM WebSphere Application Server" and does not mention Liberty, but the affected products table in the same bulletin explicitly lists Liberty 17.0.0.3 through 26.0.0.7, and NVD's description includes Liberty too. Do not read the description alone and conclude Liberty is out of scope.

CVE-2026-15328: HTTP request smuggling (CVSS 7.4)

The third has the shortest description of all: "vulnerable to HTTP request smuggling." The vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. Unlike the other two it carries S:U (scope unchanged), so impact is judged to stay inside WAS, and that difference alone drops it to 7.4.

These three deserve a closer look because WAS is almost never the first thing traffic touches. A traditional deployment normally has IBM HTTP Server and the WebSphere Web Server Plug-in in front, with a load balancer, reverse proxy or CDN ahead of that. When smuggling works in that chain, the damage does not stop at one WAS instance.

• The upstream cache gets poisoned: if the injected response is cached as the legitimate response for a URL, everyone who requests that URL afterwards receives the attacker's content
• Upstream authentication and access control get bypassed: a front-end rule saying "/admin only from internal IPs" does not help if a second request is hidden inside one that passes, because the hidden one never faces the check
• Sessions of other users get crossed: where connections are reused, the response to a smuggled request can be delivered to a different user

So the usual comfort of "WAS is internal, we are fine" works against you here, because the mismatch in the back end nullifies the controls you believe the front end is enforcing. The plug-in side also had a request smuggling flaw in June 2026 (CVE-2026-8620), leaving the same class appearing on both sides of the chain. Attacks that exploit HTTP interpretation gaps are a staple in Apache HTTP Server too; this is not a WebSphere-only story.

Two that lead to service outage

CVE-2026-14981: HTTP channel unbounded allocation causing denial of service (CVSS 7.5)

The HTTP channel allocates resources without an upper limit. The class is CWE-400 (uncontrolled resource consumption) and the vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H: no privileges, low complexity, availability impact only. Nothing leaks and nothing is rewritten, but anyone on the network can take the server down. Both traditional and Liberty are affected, sharing the interim fix with the three smuggling entries.

For a core system, an outage surfaces as business damage faster than a data leak does. Ranking this lower purely because it scores 7.5 puts your order of work out of step with where the pain actually lands.

CVE-2026-15057: uncontrolled heap allocation causing denial of service (CVSS 7.5)

Affects Liberty 17.0.0.3 through 26.0.0.7 when any of servlet-3.1, 4.0, 5.0, 6.0 or 6.1 is enabled — which, as noted, means essentially every Liberty instance serving a web application. The interim fix is APAR PH72167, distributed as the Web Container cumulative interim security fix.

Two notes belong on this one. First, bulletin 7280126 was first published on July 21, 2026, a week before the batch of the 28th, with affected features added on July 22. It only looks like part of the batch because NVD registered it on the same day as the other 13.

Second, the classification does not line up. IBM assigns CWE-787 (out-of-bounds write), yet the description reads "denial of service due to uncontrolled heap allocation" and the impact is availability only (C:N/I:N/A:H). A genuine out-of-bounds write would normally carry integrity impact. CWE-789 (memory allocation with excessive size value) fits the description better, but IBM's record says CWE-787. Mechanically importing the classification and raising your assessment on the grounds that "memory corruption might turn into RCE" has thin support in the public record.

Three that do not apply unless a feature is enabled

The remaining three are Liberty-only and apply only where a specific feature is enabled. There is no need to panic over the count. These are the entire set of conditions.

CVE-2026-14976: code execution with collectiveController-1.0 enabled (CVSS 7.1)

The phrase "remote code execution" triggers a reflex, but the vector shows the conditions are narrow: AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H. AV:A means adjacent network, so the attacker must be on the same network segment rather than out on the internet. On top of that come AC:H (high attack complexity) and UI:R (someone has to act).

Three conditions stack: (1) you run Liberty 17.0.0.3 through 26.0.0.8, (2) the collectiveController-1.0 feature is enabled, and (3) the attacker is on the same network. Without all three, nothing happens. collectiveController-1.0 is for centrally managing a group of Liberty servers, so a standalone deployment is simply out of scope. Checking server.xml settles it.

The interim fix is APAR DT496531, with a distribution page available. The fixing Fix Pack is 26.0.0.9; details are in bulletin 7281633.

CVE-2026-15280: path-segment injection in collective routing (CVSS 7.5)

Covered by the same bulletin and the same interim fix as CVE-2026-14976. The routing mechanism in Liberty's ND Collective Controller (the central management role in a Network Deployment setup) allows part of a URL path to be injected. The class is CWE-22 (path traversal) and the vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: confidentiality only, meaning reading.

Unlike 14976, this one is AV:N (over the network) with AC:L (low complexity), so if the Collective Controller is reachable from outside, take the 7.5 at face value. Conversely, an environment with no collective configuration is unaffected.

CVE-2026-16192: denial of service with restConnector enabled (CVSS 7.1)

The class is CWE-674 (uncontrolled recursion), where processing calls itself endlessly until the server stops responding. The vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H. This is the only one of the 14 with PR:L, meaning it assumes the attacker holds some account. A pure outsider cannot do it alone.

The stated condition is inconsistent. The CVE description and NVD record say "when the restConnector-2.0 feature is enabled," while the summary and remediation steps in bulletin 7281648 say "restConnector-1.0 or restConnector-2.0." Assess against the broader reading, including 1.0. restConnector is enabled for JMX REST management or the Admin Center, so environments with Liberty management interfaces closed off are out of scope. The interim fix is APAR DT496294, with a distribution page.

The published numbers do not always agree

Cross-checking all 14 against primary sources surfaced gaps between IBM's bulletins and the NVD records that are worth knowing before you let a score decide your priorities.

CVSS scores derive deterministically from the vector, so the "8.9" on CVE-2026-15064's page is most likely a transcription error. Either way both land in the same "High" band, so the response does not change. Vendors and databases disagreeing on severity happens in other products too, and organisations that auto-assign internal priority from the score alone will inherit that discrepancy unchanged.

Nothing on JVN yet, and nothing in the press either

As of midday on July 29, 2026, none of the 14 appear in Japan's domestic advisory channels.

• JVN iPedia (JVNDB): searching "WebSphere" through the MyJVN API returns no records matching the 14
• JPCERT/CC: no alert or Weekly Report mention
• IPA: not listed among important security notices
• Japanese-language press: no article covering the 14. The most recent piece from Security NEXT, which follows WebSphere vulnerabilities consistently, is dated June 2 and covers the four disclosed on June 1 (CVE-2026-8644 and others)

JVN iPedia typically publishes Japanese summaries days to weeks after a CVE appears, so records may show up next week. For now, though, there is essentially no primary Japanese-language treatment, and operators in Japan have to read IBM's English bulletins directly. Waiting for a JVN entry means leaving the two 9.8 issues untouched for one to two weeks.

The GitHub Security Advisory database is populating: CVE-2026-14512 appears as GHSA-p6cg-6q97-cwjw. Organisations running automated dependency checks may catch these there.

No evidence of exploitation so far

On exploitation status, three things are confirmed.

• None of the 14 are in the CISA KEV catalog (version 2026.07.27, 1,655 entries). There is no US government record of active exploitation yet (CISA catalog / searchable dashboard)
• Exploit probability estimates (EPSS) have not been calculated. Querying FIRST's API for all 14 returns zero records, which is expected one day after disclosure
• No public proof-of-concept could be found. IBM's bulletins include an Acknowledgement field, but it is empty on all 14, leaving no thread to follow toward an external researcher's write-up

This is not a reason to relax. As noted, the WebSphere deserialization family has been exploited for real and made it into KEV. Flaws that reach code execution without authentication tend to have a short gap between disclosure and public exploit code; with Oracle EBS and SharePoint, that gap was measured in weeks. For the two 9.8 entries, planning on a one-to-two-week application window rather than waiting for a KEV listing is the sound reading.

IBM Aspera also had four disclosed on July 28

On the same day as the WebSphere 14, IBM also disclosed four issues in IBM Aspera, its high-speed file transfer product (CVE-2026-14973 / 14958 / 14959 / 14996). Aspera underpins file transfer for broadcasters and large enterprises, and buffer overflow flaws have surfaced there before. Those four are covered in that separate article, so we do not chase them here. If you run both, check both.

Across IBM's portfolio, 2026 has brought a steady run of serious flaws in products close to the business core: the WebSphere family, Db2, Aspera and Engineering Lifecycle Management. Rather than deciding case by case, building an inventory of IBM products and a template procedure for applying fixes ends up being faster.

How to sequence the work up to applying the interim fix

Start with an inventory, not with patches. Write down the version number of every WAS instance you have. 8.5.5.x or 9.0.5.x is traditional; 2x.0.0.x is Liberty. Then check whether any admin console is visible from the internet. Both 9.8 entries are traditional, and one of them uses the admin console itself as the entry point. If a host has its admin screen exposed, that host is your first priority.

For traditional hosts, decide which of the five interim fixes to apply. All five is the right answer, but if you have to split the downtime, put PH72166 (CVE-2026-14512 and 14528) and DT496500 (CVE-2026-14446) first. Each interim fix requires raising the install to a minimum Fix Pack level beforehand, so checking the gap between your current level and the required one in advance will spare you incidents on the day. Because DT496500 has no confirmed distribution page, plan on opening a case with IBM Support in parallel.

For Liberty hosts, read the feature definitions in server.xml and check for collectiveController-1.0 and restConnector-1.0/2.0. If neither is in use, your exposure drops to five issues, and all five are resolved by 26.0.0.8, estimated for August 11. That makes it defensible to fold the work into your normal Fix Pack cycle instead of rushing an interim fix. If either is in use, you are waiting for 26.0.0.9, so consider the DT496531 and DT496294 interim fixes.

The layer in front is worth reviewing too. The three smuggling issues only become real damage in combination with an upstream proxy or cache. Is TRACE dropped at the front? Are non-standard HTTP version tokens rejected? Are pages that require authentication kept out of shared caches? The practical mitigation while you wait on the WAS-side fix lives up there. (IBM officially lists workarounds as "None," so treat this paragraph as the author's judgement.)

Finally, bookmark IBM's recommended updates list and check the four rows for 9.0.5.29, 8.5.5.31, 26.0.0.8 and 26.0.0.9 weekly. Every one of them is an estimate today, and nothing is settled until a real date appears.

What IBM put in writing, and what it left out

Sources

• ▸IBM Security Bulletin 7281649 - unsafe deserialization and exposure of sensitive information (CVE-2026-14512, CVE-2026-14528) (July 28, 2026)
• ▸IBM Security Bulletin 7281631 - privilege escalation (CVE-2026-14446) (July 28, 2026)
• ▸IBM Security Bulletin 7281625 - multiple vulnerabilities (CVE-2026-14981, 15064, 15325, 15328) (July 28, 2026)
• ▸IBM Security Bulletin 7281641 - cross-site scripting and deserialization (CVE-2026-14974, CVE-2026-14515) (July 28, 2026)
• ▸IBM Security Bulletin 7281633 - remote code execution and path-segment injection (CVE-2026-14976, CVE-2026-15280) (July 28, 2026)
• ▸IBM Security Bulletin 7281628 - authentication bypass (CVE-2026-16184) (July 28, 2026)
• ▸IBM Security Bulletin 7281648 - denial of service (CVE-2026-16192) (July 28, 2026)
• ▸IBM Security Bulletin 7280126 - Liberty denial of service (CVE-2026-15057) (first published July 21, 2026; updated July 22)
• ▸IBM - Recommended Updates for WebSphere Application Server
• ▸IBM - WebSphere Application Server support (statement on end-of-support dates)
• ▸IBM - How to determine if Liberty is using a specific feature
• ▸NVD - CVE-2026-14512 (CVSS 9.8 / CWE-502)
• ▸NVD - CVE-2026-14446 (CVSS 9.8 / CWE-306)
• ▸CVE.org - CVE-2026-14512
• ▸GitHub Advisory Database - GHSA-p6cg-6q97-cwjw (CVE-2026-14512)
• ▸CISA - Known Exploited Vulnerabilities Catalog (version 2026.07.27, 1,655 entries)
• ▸FIRST - EPSS (Exploit Prediction Scoring System)
• ▸Security NEXT - Multiple serious vulnerabilities in WebSphere App Server (June 2, 2026, on the June batch)