Apache MINA: AbstractIoBuffer.resolveClass() null-clazz Branch Skips acceptMatchers Filter — Full Object Deserialization RCE (take 2)
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.1.12, 2.2.7
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 proof of concept on GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: total
Summary
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
Timeline
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- CVE published
- Record last updated
Affected versions
- org.apache.mina:mina-core
From 2.2.X · through 2.2.6; From 2.1.X · through 2.1.11
- org.apache.mina:mina-coreMaven
From 2.1.0 · fixed in 2.1.12
- org.apache.mina:mina-coreMaven
From 2.2.0 · fixed in 2.2.7