Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Tools/GitHubGitHub/dinosn/cve-2026-42779
SchwachstellenanalyseExploitationWebanwendungs-ExploitationPapers & ForschungLernen & Bildung
GitHubdinosn/cve-2026-42779

CVE-2026-42779

Proof-of-Concept, das eine Umgehung des Deserialisierungsfilters in Apache MINA demonstriert, die zu Remote-Code-Ausführung führt, mit detaillierter Ursachenanalyse, Exploit-PoCs und Anleitung zur Behebung.

Repository anzeigen
112vor 3 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

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 über standardmäßige Java-Deserialisierungs-Gadget-Ketten (z. B. Commons Collections) ermöglicht.

vollständige Remote Code Execution

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

ZweigVerwundbarBehoben
2.1.x2.1.0 – 2.1.112.1.12
2.2.x2.2.0 – 2.2.62.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:

root@kitploit:~
// 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:

root@kitploit:~
// 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

root@kitploit:~
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:

PoCWas es beweist
FilterBypassPoC.javaFilter-Bypass für primitive Typen, nicht-serialisierbare Klassen, Arrays
CraftedBypassPoC.javaAngreifer-erstellte Typ-0-Payloads umgehen den Filter für JEDE serialisierbare Klasse
RcePoC.javaVollstä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:

Filter-Bypass auf verwundbarem MINA 2.2.6

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:

Erstelltes Payload-Bypass

3. Vollständige RCE — Befehlsausführung

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

RCE auf MINA 2.2.6 bestätigt

4. Filter-Bypass (MINA 2.2.7 — Gepatcht)

Die gleichen Tests werden auf der behobenen Version blockiert:

Filter-Bypass auf MINA 2.2.7 blockiert

5. RCE blockiert (MINA 2.2.7 — Gepatcht)

Die Gadget-Kette wird vom Filter abgelehnt:

RCE auf MINA 2.2.7 blockiert

Schnellstart (Docker)

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

root@kitploit:~
# 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:

root@kitploit:~
# Verwundbare Version klonen und bauen
git clone https://github.com/apache/mina.git /tmp/apache-mina
cd /tmp/apache-mina
git checkout 2.2.6
mvn install -pl mina-core -DskipTests -q

# commons-collections herunterladen (für RCE-PoC)
curl -sL "https://repo1.maven.org/maven2/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar" \
  -o commons-collections-3.2.2.jar

# Die PoCs kompilieren
javac -cp mina-core/target/mina-core-2.2.6.jar FilterBypassPoC.java
javac -cp mina-core/target/mina-core-2.2.6.jar CraftedBypassPoC.java
javac -cp mina-core/target/mina-core-2.2.6.jar:commons-collections-3.2.2.jar RcePoC.java

# Filter-Bypass-PoC ausführen
java -cp .:mina-core/target/mina-core-2.2.6.jar FilterBypassPoC

# Erstelltes Payload-PoC ausführen
java -cp .:mina-core/target/mina-core-2.2.6.jar CraftedBypassPoC

# Vollständigen RCE-PoC ausführen
java -Dorg.apache.commons.collections.enableUnsafeSerialization=true \
     --add-opens java.base/java.util=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -cp .:mina-core/target/mina-core-2.2.6.jar:commons-collections-3.2.2.jar \
     RcePoC

Oder verwenden Sie das enthaltene Makefile:

root@kitploit:~
make run-all    # Alle drei PoCs bauen und ausführen
make run-rce    # Nur den RCE-PoC

Anforderungen: JDK 11+ und Maven (für Quellcode-Build) oder Docker (für Container)

Abhilfe

Upgrade auf Apache MINA 2.1.12 oder 2.2.7.

Wenn ein Upgrade nicht sofort möglich ist:

  • Verwenden Sie IoBuffer.getObject() oder ObjectSerializationCodecFactory nicht mit nicht vertrauenswürdigen Eingaben
  • Erwägen Sie einen JEP-290-Serialisierungsfilter als zusätzliche Verteidigungsebene

Zeitplan

DatumEreignis
2026-05-01Advisory vom Apache MINA PMC veröffentlicht
2026-05-01Behobene Versionen 2.1.12 und 2.2.7 veröffentlicht
2026-05-02Dieser PoC entwickelt und getestet

Referenzen

  • Apache MINA Advisory
  • CVE-Eintrag
  • NVD-Eintrag
  • Apache MINA Downloads

Haftungsausschluss

Dieser Proof of Concept wird ausschließlich für defensive Sicherheitsforschung, Bildung und autorisierte Penetrationstests bereitgestellt. Verwenden Sie ihn verantwortungsvoll und nur gegen Systeme, für die Sie die Erlaubnis zum Testen haben.

Tool herunterladen