Apache shipped MINA 2.2.7 and MINA 2.1.12 this week with fixes for two critical-severity vulnerabilities, CVE-2026-42778 and CVE-2026-42779, that together represent the third and fourth iterations of a deserialization weakness the project has been chasing since CVE-2024-52046. Both new CVEs are remote code execution. Both bypass an earlier “complete fix.” If you ship anything that calls AbstractIoBuffer.getObject() on data from the network, you have until tonight.
What Apache MINA is and why this hits hard
MINA is the asynchronous I/O framework underneath a long list of Java network products: Apache Directory Server, Apache FTPServer, Apache SSHD, parts of Apache Camel, and a quietly-large catalog of vendor-internal protocol gateways and message brokers that picked MINA in the 2010s and never moved off it. It’s the kind of dependency that doesn’t show up in marketing material but does show up on mvn dependency:tree. Because the affected sink is a deserialization helper exposed at the buffer layer, anyone using MINA’s object-codec convenience methods to read Java-serialized payloads off a socket inherits the bug.
CVE-2026-42779 — allowlist bypass in resolveClass()
The earlier round of fixes (CVE-2026-41635) added a classname allowlist inside AbstractIoBuffer.resolveClass() so that getObject() would refuse to instantiate classes outside a vetted set. The check was applied late — after ObjectInputStream had already begun resolving the class graph — which left a window where an attacker could submit a serialized object whose top-level class lived in the allowlist but whose fields referenced gadget classes outside it. By the time the allowlist saw the gadget class, the JVM had already touched it.
42779 is the fix for that ordering bug: the allowlist now applies at the right point in the resolution path, before any class outside the list can be loaded. The CVE allocation is for the bypass itself, which is unauthenticated and remotely exploitable on any service that calls getObject() on attacker-controlled bytes.
CVE-2026-42778 — static-initializer trigger inside the allowlist
42778 is the cleverer of the two. Even with the allowlist correctly placed, an attacker could still pick a class inside the allowlist that had a static { ... } block doing something useful — and arrange for the JVM to load that class for the first time during deserialization, which runs the static initializer. The chosen class doesn’t need any deserialization-aware methods of its own; it just needs to be reachable from the allowlist and to do anything interesting at class-load time. Plenty of classes in any large dependency graph satisfy that bar.
This is the “incomplete fix of an incomplete fix” pattern that recently bit AviatrixController, Langflow, and a handful of others over the past year. The project’s response is the right one: rather than chasing gadget classes, MINA 2.2.7 narrows what classes are allowed in the first place and, where possible, refuses to deserialize anything whose loading has observable side effects.
Affected versions
- CVE-2026-42778: All Apache MINA 2.x prior to 2.1.12 / 2.2.7.
- CVE-2026-42779: All Apache MINA 2.x prior to 2.1.12 / 2.2.7.
- Fixed in: MINA 2.1.12 and MINA 2.2.7.
The risk is limited to applications that actually call AbstractIoBuffer.getObject() on bytes that come from the network. Applications using MINA strictly as a transport (binary protocols, custom codecs that don’t touch Java serialization) are not in scope. But the convenience method is well-known and well-used, particularly in older internal protocols where Java serialization was the default in 2014 and nobody got around to switching it out.
What to do right now
- Upgrade MINA to 2.1.12 or 2.2.7 in any application that depends on it, directly or transitively. Run
mvn dependency:tree | grep mina(or the Gradle equivalent) on every Java service you operate, including ones you inherited and don’t actively maintain. - Audit for
getObject()callers. Anywhere this method is invoked on attacker-reachable bytes, treat it as an exposed surface. The right long-term fix is to replace Java serialization with a binary or text-based codec; the short-term fix is the upgrade. - Watch your downstream Apache projects. Apache Directory Server, FTPServer, and SSHD are the obvious ones. Check vendor releases for their MINA version pin, and ratchet up if it’s still on 2.1.11 / 2.2.6.
- Check vendor appliances. A surprising amount of enterprise Java middleware ships MINA inside the box. If you can’t upgrade an appliance, restrict network reachability of any port that speaks a Java-serialization-flavored protocol until the vendor cuts a release.
The pattern is the lesson
Three CVEs in eighteen months for the same root cause — CVE-2024-52046 → CVE-2026-41409 → CVE-2026-41635 → CVE-2026-42778/42779 — is a textbook incomplete-fix chain. The original sin is shipping getObject() at all on a buffer class meant for arbitrary network input; everything since has been the project trying to bound an inherently unbounded surface. If you operate a service that uses Java serialization on the wire, take this as a forcing function: it is not getting safer, and the next iteration will land sooner than you expect.