CVE-2026-42779 — Apache MINA Deserialisierungs-Filter-Bypass zu RCE

CVSS 3.1: 9.8 KRITISCH AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H CWE: CWE-502 Deserialisierung nicht vertrauenswürdiger Daten Melder: Venkatraman Kumar, Securin Advisory: Apache Mailing List

Überblick

Apache MINA Versionen 2.1.0 bis 2.1.11 und 2.2.0 bis 2.2.6 enthalten einen Deserialisierungs-Filter-Bypass in AbstractIoBuffer.resolveClass(). Die acceptMatchers-Allowlist — die einschränken soll, welche Java-Klassen deserialisiert werden können — wird vollständig übersprungen, wenn ObjectStreamClass.forClass() null zurückgibt.

Ein Angreifer mit Netzwerkzugriff auf einen MINA-Endpunkt, der ObjectSerializationCodecFactory verwendet, kann ein Protokoll-Payload erstellen, das den Klassenfilter umgeht und so vollständige Remote Code Execution über standardmäßige Java-Deserialisierungs-Gadget-Ketten (z. B. Commons Collections) ermöglicht.

Dies ist ein unvollständiger Fix für CVE-2026-41635. Der ursprüngliche Patch wurde auf den 2.0.x-Zweig angewendet, aber aufgrund eines Merge-Versehens nie auf 2.1.x oder 2.2.x zurückportiert.

Betroffene Versionen

Zweig	Verwundbar	Behoben
2.1.x	2.1.0 – 2.1.11	2.1.12
2.2.x	2.2.0 – 2.2.6	2.2.7

Grundursache

Die Schwachstelle liegt in AbstractIoBuffer.resolveClass(), das die Klassenauflösung während der Deserialisierung von Java-Objekten übernimmt.

MINA verwendet ein benutzerdefiniertes Serialisierungsprotokoll mit zwei Klassendeskriptor-Typen:

• Typ 0 — nicht-serialisierbare Klassen, primitive Typen und Arrays (Standard-Java-Klassendeskriptor-Format)
• Typ 1 — serialisierbare Klassen (kompaktes Klassennamen-Format)

Im verwundbaren Code wird der acceptMatchers-Filter nur im Typ-1-Zweig geprüft (wenn forClass() nicht-null zurückgibt). Der Typ-0-Zweig ruft Class.forName() direkt auf und umgeht den Filter vollständig:

// AbstractIoBuffer.java — VERWUNDBAR (2.2.6)
protected Class<?> resolveClass(ObjectStreamClass desc) {
    Class<?> clazz = desc.forClass();

    if (clazz == null) {
        // FEHLER: Keine acceptMatchers-Prüfung — Filter vollständig umgangen
        return Class.forName(name, false, classLoader);
    } else {
        // Filter wird nur hier angewendet
        for (ClassNameMatcher matcher : acceptMatchers) { ... }
    }
}

Der Fix in 2.2.7 verschiebt die Filterprüfung vor den Zweig:

// AbstractIoBuffer.java — BEHOBEN (2.2.7)
protected Class<?> resolveClass(ObjectStreamClass desc) {
    String className = desc.getName();

    // Filter wird ZUERST angewendet, unabhängig vom forClass()-Ergebnis
    if (!acceptMatchers.stream().anyMatch(m -> m.matches(className))) {
        throw new ClassNotFoundException("Class not in accept list " + className);
    }

    Class<?> clazz = desc.forClass();
    // ... sichere Auflösung folgt
}

Ausnutzung

Angriffsablauf

Angreifer                                    Verwundbarer MINA-Server
   |                                              |
   |  1. MINA-Payload mit Typ-0-                  |
   |     Deskriptoren für Gadget-Ketten-Klassen   |
   |                                              |
   |  2. Senden an Endpunkt mit                   |
   |     ObjectSerializationCodecFactory -------->|
   |                                              |
   |          3. readClassDescriptor() liest Typ-0|
   |             → delegiert an super (Std. Java) |
   |                                              |
   |          4. resolveClass() sieht forClass()==null
   |             → Class.forName() OHNE Filter    |
   |                                              |
   |          5. Gadget-Kette vollständig deserialisiert
   |             → readObject() löst Kette aus    |
   |             → Runtime.exec() wird ausgelöst  |
   |                                              |
   |                               RCE ERREICHT  |

Voraussetzungen

1. Die Zielanwendung verwendet IoBuffer.getObject() oder ObjectSerializationCodecFactory
2. Das Ziel hat accept() konfiguriert (Anwendungen ohne Filter waren bereits über CVE-2026-41635 ausnutzbar)
3. Eine Gadget-Ketten-Bibliothek (Commons Collections, Spring usw.) befindet sich im Klassenpfad

Kern-Erkenntnis

Der Angreifer kontrolliert den serialisierten Bytestrom. Durch die Verwendung von Typ-0-Klassendeskriptoren (anstatt Typ-1) für serialisierbare Gadget-Ketten-Klassen umgeht jede Klasse im Deserialisierungsgraphen den acceptMatchers-Filter, unabhängig von der Allowlist-Konfiguration der Anwendung.

Proof of Concept

Drei PoCs demonstrieren eine zunehmende Auswirkung:

PoC	Was es beweist
FilterBypassPoC.java	Filter-Bypass für primitive Typen, nicht-serialisierbare Klassen, Arrays
CraftedBypassPoC.java	Angreifer-erstellte Typ-0-Payloads umgehen den Filter für JEDE serialisierbare Klasse
RcePoC.java	Vollständige RCE über CC6-Gadget-Kette durch den Filter-Bypass

1. Filter-Bypass (MINA 2.2.6 — Verwundbar)

Klassen, die nicht in der Accept-Liste stehen, werden ohne Einschränkung deserialisiert:

2. Erstelltes Payload — Beliebige Klassenladung

Ein Angreifer erstellt MINA-Protokoll-Payloads mit Typ-0-Deskriptoren, um jede Klasse an einer reinen String-Accept-Liste vorbeizuladen:

3. Vollständige RCE — Befehlsausführung

CC6-Varianten-Gadget-Kette (HashSet → TiedMapEntry → LazyMap → ChainedTransformer → Runtime.exec()) erreicht Befehlsausführung durch den Filter-Bypass:

4. Filter-Bypass (MINA 2.2.7 — Gepatcht)

Die gleichen Tests werden auf der behobenen Version blockiert:

5. RCE blockiert (MINA 2.2.7 — Gepatcht)

Die Gadget-Kette wird vom Filter abgelehnt:

Schnellstart (Docker)

Der schnellste Weg zum Testen — kein JDK oder Maven erforderlich:

# Dieses Repo klonen
git clone https://github.com/dinosn/CVE-2026-42779.git
cd CVE-2026-42779

# Alle PoCs bauen und ausführen
docker build -t cve-2026-42779 .
docker run --rm cve-2026-42779

# Einzelne PoCs ausführen
docker run --rm cve-2026-42779 bypass     # Nur Filter-Bypass
docker run --rm cve-2026-42779 crafted    # Erstelltes Payload-Bypass
docker run --rm cve-2026-42779 rce        # Vollständige RCE

# In eine Shell wechseln zum Erkunden
docker run --rm -it cve-2026-42779 shell

Das Image enthält das verwundbare MINA 2.2.6-JAR, Commons Collections 3.2.2 und alle drei vorkompilierten PoCs. Alles läuft eigenständig im Container.

Reproduktion (aus dem Quellcode)

Wenn Sie lieber aus dem Quellcode bauen möchten: