WaratekVRT Sign in
Reset
More filters (2)
Columns
Vendor org.apache.mina✕Has a public PoC✕
Overview 1 match · 0 exploited · 0 CISA KEV · 0 EPSS ≥ 0.5
1match 0exploited0.0% 0CISA KEV0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 1 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 1 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 100.0% Forecast only 0 0.0% No public exploit 0 0.0%
split by peak 1 / month
Protected by Waratek: 1 Critical: 1 blocked by ARMR today: 1 Proof of concept only: 1
May 26
1 match Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-42779 Critical 2026-05-01 Protected by Waratek Proof of concept only 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.