Apache MINA's 9.8-rated fix reached only one branch

Apache has attached a maximum severity rating to a fix that never reached two of Apache MINA's maintenance branches. On 21 September the project published CVE-2026-94301 for MINA 2.0.0 before 2.0.31 and 2.1.0 before 2.1.15 — the two lines where a June patch for a deserialisation allow-list bypass was announced as shipped but was in fact committed only to the 2.2.X branch.

What Apache has disclosed

“The fix for CVE-2026-47065/ZDRES-232 … released on 2026-06-02 and announced as ‘Fully addressed’ in MINA 2.2.8, 2.1.13 and 2.0.29, was committed to the 2.2.X branch only,” the advisory reads. “The 2.0.X and 2.1.X maintenance branches never received the resolveProxyClass() override, so the 2.0.29 and 2.1.13 artifacts listed as fixed — and every later release on those lines, up to and including the current 2.0.30 and 2.1.14 — remain vulnerable to the exact allow-list bypass that CVE-2026-47065 was meant to close.” Apache credits the researcher tonghuaroot with reporting the mistake.

Why the bypass matters

The original flaw, CVE-2026-47065, sits in how MINA handles Java object deserialisation. When a serialised stream carries a proxy class descriptor, the JDK's own resolveProxyClass() path runs and calls Class.forName() for each interface name in that stream, which steps around the accept-list MINA's ObjectSerializationFilter is supposed to enforce. The June release notes said the flaw was fully addressed in MINA 2.2.8, 2.1.13 and 2.0.29. Only the 2.2.X branch actually received the override, so two thirds of that promise was never on disk.

Which versions are affected

Everything on the 2.0.X line from 2.0.0 up to and including 2.0.30, and everything on the 2.1.X line from 2.1.0 up to and including 2.1.14. The National Vulnerability Database lists CVE-2026-94301 as CWE-502, deserialisation of untrusted data, with a CVSS 3.1 base score of 9.8, and records it as published on 21 September 2026. The fixed versions are 2.0.31 and 2.1.15, which the project announced on 27 June 2026 in a bug-fix release whose notes already flagged that the CVE-2026-47065 fix had not been backported to those branches.

What it means for applications

MINA is a socket and protocol framework that few teams install on purpose. It arrives inside other Java software as a dependency, which is why the fix runs through the applications that embed it rather than one server package. A version pinned in a build file months ago will not surface the problem by itself, and the 2.0.29 and 2.1.13 artefacts named as fixed in the original release notes are exactly the ones that still carry the bypass. Anyone shipping either maintenance line should move to 2.0.31 or 2.1.15.

Our opinion

Release notes are a promise, and ‘fully addressed’ is the strongest version of one a project can write. Apache's mistake was not the finding, it was the phrasing: a fix is only addressed if it exists on every branch you are still shipping, and 2.0.X and 2.1.X were still being shipped. The credit here goes to an outside researcher who read the code rather than the changelog, and to a project willing to cut a CVE against its own announcement three months later. That is the system working, even when it looks like an own goal.

The more uncomfortable lesson is about the shape of maintenance branches. Long-lived 2.x lines exist so that people running older stacks can keep patching security holes without a rewrite, and that guarantee is only as good as the discipline behind the backport. Any team that treats a version number in a release note as proof of a fix is trusting a label rather than an artefact. If you embed MINA, check the branch you actually resolve before you trust the changelog that told you it was done.