Apache MINA fixes critical RCE flaws in 2.1.x and 2.2.x branches

Apache MINA users should update to version 2.1.12 or 2.2.7 after the project fixed two critical vulnerabilities that can allow remote code execution in affected applications.

The flaws are tracked as CVE-2026-42778 and CVE-2026-42779. Both involve unsafe Java deserialization in Apache MINA, a network application framework used to build scalable client and server applications.

The risk does not apply to every Apache MINA deployment. It affects applications that use MINA core and call IoBuffer.getObject(), including setups that use ProtocolCodecFilter with ObjectSerializationCodecFactory in the filter chain.

What Apache fixed in the new MINA updates

Apache released MINA 2.1.12 and 2.2.7 on April 30, 2026. The project says these releases correct two security fixes that should have landed in earlier MINA releases but did not reach the 2.1.x and 2.2.x branches.

That detail matters because many developers may have assumed they already received protection after the previous release. Apache says the earlier code change reached the 2.0.x branch, but versions 2.1.11 and 2.2.6 remained in the same vulnerable state.

Both vulnerabilities can let attackers abuse serialized input. In simple terms, a vulnerable server may rebuild attacker-controlled data into Java objects before the application can safely reject it.

At a glance

Issue	Impact	Affected versions	Fixed versions
CVE-2026-42778	Remote code execution through unsafe deserialization	Apache MINA 2.1.0 to 2.1.11 and 2.2.0 to 2.2.6	Apache MINA 2.1.12 and 2.2.7
CVE-2026-42779	Remote code execution through allowlist bypass	Apache MINA 2.1.0 to 2.1.11 and 2.2.0 to 2.2.6	Apache MINA 2.1.12 and 2.2.7

Why these Apache MINA vulnerabilities are serious

CVE-2026-42778 is tied to an incomplete fix for an earlier Apache MINA deserialization issue. The class name allowlist existed, but Apache says it was applied too late in the process.

That timing problem created a dangerous gap. A static initializer in a class could run before MINA checked whether that class should have been allowed.

CVE-2026-42779 is linked to another incomplete fix. Apache says one branch inside AbstractIoBuffer.resolveClass() failed to check static classes or primitive types against the accepted class filter before loading them.

What developers need to check

Administrators should first confirm whether their software uses Apache MINA core versions in the affected ranges. The most important check is whether the application calls IoBuffer.getObject().

Apache also warns that the affected method can be reached when developers add ProtocolCodecFilter with ObjectSerializationCodecFactory. That makes dependency and code review important, especially in older Java services.

Updating the library should happen quickly, but Apache says upgrading alone does not complete the mitigation. Developers also need to explicitly allow the classes that ObjectSerializationDecoder can accept.

Recommended action

• Upgrade Apache MINA 2.1.x deployments to version 2.1.12.
• Upgrade Apache MINA 2.2.x deployments to version 2.2.7.
• Search codebases for IoBuffer.getObject().
• Review use of ObjectSerializationCodecFactory and ProtocolCodecFilter.
• Configure ObjectSerializationDecoder with a strict class allowlist.
• Avoid deserializing data from untrusted clients wherever possible.

Why the fix still needs configuration

Apache MINA now applies the class allowlist earlier, which blocks the vulnerable behavior fixed in these releases. However, the decoder rejects incoming classes by default unless developers configure accepted classes.

This means teams should not treat the update as a simple version bump. They should test the application after applying the patch and make sure legitimate serialized objects still pass through the expected allowlist.

Apache also notes that MINA subprojects such as FtpServer, SSHd, and Vysper are not affected by this issue. The advisory focuses on MINA core and the specific deserialization path.

Why this matters for enterprise Java apps

Java deserialization bugs often create high-impact security risks because they can turn network input into executable behavior. If an attacker reaches a vulnerable endpoint, the attack may not require a valid account or user interaction.

The CVSS vector listed for the issues reflects that risk. It shows a network attack path, low attack complexity, no privileges required, and high impact across confidentiality, integrity, and availability.

For enterprises, the practical response should include patching, code review, dependency scanning, and exposure checks. Internet-facing services that deserialize client-supplied data should receive priority.

FAQ