Apache MINA Flaw CVE-2026-47065 Lets Attackers Take Over Servers Without a Login

A networking component called Apache MINA, which quietly runs underneath many enterprise Java systems, has a vulnerability that lets attackers take over a server remotely without logging in. Tracked as CVE-2026-47065, it carries a severity score of 9.8 out of 10 (Critical).

What makes this troubling is that it is not the first hole of its kind. Apache MINA has repeatedly patched the same class of vulnerability since 2024, yet each fix has been followed by a new way to slip past it. This one is the third miss. On June 2, 2026, the Apache Software Foundation released the fixed versions Apache MINA 2.2.8 / 2.1.13 / 2.0.29 and urged affected systems to update immediately.

What Is Apache MINA?

Apache MINA is a framework (a set of building blocks) for writing applications that communicate over a network. It is developed by the Apache Software Foundation, the non-profit that stewards a large share of the world's open-source software. Chat servers, business systems, machine-to-machine communication—anything that "exchanges data across a network"—has long relied on MINA as a foundation to write that logic efficiently in Java.

End users almost never see the name Apache MINA. It is the kind of behind-the-scenes part that silently handles communication inside an application, much like a component supplier. That is exactly why its reach is hard to see, and many companies "cannot immediately tell whether Apache MINA is bundled inside their own systems." The MINA core (mina-core) is sometimes used directly and sometimes pulled in indirectly as a part of another piece of software.

This problem occurs when that networking component "reconstructs received data back into its original form." This "turning data back into objects" step is technically called deserialization, and in the Java world it has long been known as a dangerous, accident-prone operation. Incidents rooted in the same mechanism keep appearing, from the major Oracle WebLogic Server vulnerability to Oracle's monthly patch releases.

What CVE-2026-47065 Does

An attacker only has to send crafted data to a server that uses Apache MINA, and they can run any program they want on that server. This is called remote code execution (RCE), the most serious category of vulnerability, leading straight to a full server takeover. No login is required, so anyone who can reach the server over the network can attempt it.

As of this writing, CVE-2026-47065 is not listed in the CISA KEV catalog, the U.S. government's list of "known exploited vulnerabilities." No report of real-world exploitation and no public proof-of-concept code have been confirmed so far. Even so, given the high severity and the history here, there is plenty of value in acting before exploitation catches up.

When a Spare Key Turns in a Lock You Thought Was Fixed

The people who covet a hole like this are the ones drawn to its "cheapness": no login, no theft of credentials, just a single crafted packet to seize full control. Specifically, that means ransomware crews who encrypt corporate servers and demand a ransom, initial-access brokers who build a way in and resell it to other criminals, state-sponsored espionage units after secrets, and operators of automated bots that hijack other people's servers to mine cryptocurrency. What they walk off with is the heart of the company: the administrator rights of the business app running on that server, the customer lists and transaction records inside the internal database, and the API keys and authentication tokens that connect to outside services. The instant this one line of MINA that rebuilds incoming data is triggered, the attacker's program starts running on the server, and the machine hosting the app turns wholesale into someone else's control panel.

A takeover never stops at one machine. Using the first server as a stepping stone, attackers walk sideways into other servers on the same internal network, encrypt entire business databases to halt operations, and hold them for ransom. In parallel, the customer data they siphon off is sold on the dark web, and the email addresses and credentials obtained there fuel the next intrusion, impersonating partners and customers. A single hole in one company's networking component becomes the entry point for a chain of damage that drags in its partners and customers—that is the real danger of this kind of takeover.

And the bill comes back to the operator in the end. If customer data leaks, the operating company faces the duty to report to data-protection authorities and notify the individuals affected, plus inquiry handling, damage compensation, explanations to partners, and the long road of rebuilding lost trust. The number "CVSS 9.8" only reflects the technical maximum of severity; for the company entrusted with the system, the real loss lies in halted operations and departed customers. Whether you can inspect and update your own Apache MINA right now is what tips that balance.

Which Systems Are Affected?

An important point: using Apache MINA does not make you unconditionally vulnerable. This flaw is triggered only when an application reconstructs received data directly into Java objects. Technically, as the official MINA description states, configurations that reconstruct data from untrusted senders via AbstractIoBuffer.getObject() or ObjectSerializationDecoder are affected. Conversely, if you exchange data in your own custom format, you do not pass through this path.

That said, few teams can instantly answer "through which path does my app receive data." The safest move is to first check the version of mina-core you use and bring it up to the fixed release for your branch using the table below. Because the attack requires no authentication, upgrading the version to close the hole itself is faster and safer than leaving it on a "probably fine" basis.

Working out which of your software products bundle open-source components is itself a laborious task. The mindset of inventorying dependencies in bulk is laid out in our piece on scanning the open-source supply chain.

What Is Happening Technically

In response to past incidents, Apache MINA had added a defense: "only allow classes registered on an allowlist (acceptMatchers) to be reconstructed, and reject everything else." This vulnerability is two side paths that slip past that allowlist check. The official Apache notice describes them under the labels "ZDRES-232" and "ZDRES-233."

CVE-2026-47065: Slipping Past the Allowlist via Proxy Classes (ZDRES-232)

The first abuses Java's "Proxy" mechanism. When the incoming data contains a marker for a proxy class (TC_PROXYCLASSDESC), Java's default handling is invoked and builds that class without going through the allowlist check. Quoting Apache's description, the JDK's default resolveProxyClass runs Class.forName for each interface name and "constructs the proxy class, bypassing the accepted classes list." In other words, the carefully built allowlist simply does not apply on this path.

ZDRES-233: Even Allowed Classes Get "Initialized"

The second is that even for a supposedly safe class on the allowlist, the moment its name appears in the data, that class's static initializer runs. A static initializer executes once, the first time a class is loaded. It is meant to be harmless, but if a side-effecting routine is planted in it, unintended behavior can occur before any instance is even constructed. Apache marks both issues as "Fully addressed."

The pattern of unauthenticated, heavy code execution has appeared recently in the unauthenticated RCE in Dassault products and the remote code execution in Samba. The entry points differ, but the root is the same: "trusting and processing data that arrived from the outside."

Fix, Bypass, Re-fix, Bypass Again

What makes this vulnerability more unsettling is that it is the latest in a string of misses. Apache MINA's deserialization problems have continued since late 2024, and with every fix a "new side path around that fix" has surfaced. The timeline below traces the history.

← Swipe to navigate

CVE-2024-52046: The Origin That Scored a Perfect 10

The starting point of the whole chain was CVE-2024-52046, disclosed at the end of 2024. MINA's ObjectSerializationDecoder had an unsafe deserialization flaw, and its severity was a rare perfect 10.0. Fixes landed in 2.0.27 / 2.1.10 / 2.2.4 at the time, but that was the beginning of a long game of catch-up.

CVE-2026-42778 / CVE-2026-42779: The Previous Misses

On April 30, 2026, CVE-2026-42778 and CVE-2026-42779 were published and 2.2.7 / 2.1.12 were released. Both were additional fixes because earlier patches were incomplete; security reporting noted that "only apps using the getObject() method are affected." Belgium's government cybersecurity center also urged everyone to "patch immediately." This CVE-2026-47065 is the third side path found after all of that.

A Second Flaw Fixed at the Same Time: CVE-2026-47321

CVE-2026-47321: A DoS That Exhausts Memory with Compressed Data

The June 2, 2026 release also fixed another issue, CVE-2026-47321. Here, MINA's compression handling (CompressionFilter) had no cap on the size of decompressed data. If an attacker sends extremely high-ratio compressed data—exceeding 1,000:1—decompression exhausts memory and can take the service down. This is a denial-of-service (DoS) type flaw, and the fix lets you set limits on both the decompressed size and the compression ratio. It is not as urgent as CVE-2026-47065, which leads straight to takeover, but since the same update closes it too, upgrading everything to the 2.2.8 line together is the sensible move.

What to Do Right Now

The remedy is simple: bring the mina-core you use up to the fixed release—2.2.8 for the 2.2 branch, 2.1.13 for 2.1, and 2.0.29 for 2.0. If circumstances prevent an immediate full-app update, the interim defense, as Apache advises, is to explicitly limit the acceptable classes with acceptMatchers and avoid casually deserializing data arriving from untrusted networks.

The surest way to know whether Apache MINA is embedded inside your own products is to list out your dependencies and inventory them. The same kind of update response continues across enterprise authentication and cloud platforms; just like the vulnerabilities in the internal login platform authentik and the flaw in Cloud Foundry's authentication component, this is a textbook case of "a component you rely on quietly carrying a vulnerability." We track vulnerability response trends for companies in Japan in our JVN roundup as well.

Frequently Asked Questions

Sources

• ▸NVD - CVE-2026-47065 Detail
• ▸NVD - CVE-2026-47321 Detail
• ▸Apache MINA Security Advisory (lists.apache.org)
• ▸Apache MINA - News / Releases (June 2, 2026)
• ▸NVD - CVE-2024-52046 Detail
• ▸SecurityWeek - Critical, High-Severity Vulnerabilities Patched in Apache MINA
• ▸BleepingComputer - Apache warns of critical flaws in MINA, HugeGraph, Traffic Control
• ▸CCB Belgium - Warning: Critical RCE in Apache MINA
• ▸oss-security - ZDRES-059 / CVE-2026-41635
• ▸Wikipedia - Apache MINA