WaratekVRT Sign in
Reset
More filters (1)
Columns
ARMR rules: Deserialization✕
Overview 3 matches · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
3matches 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 3 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 0 0.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 3 100.0%
blocked by ARMR today 3 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 0 0.0% Forecast only 0 0.0% No public exploit 3 100.0%
split by peak 3 / month
Protected by Waratek: 3 Unknown: 3 blocked by ARMR today: 3 No public exploit: 3
Nov 263 Protected by Waratek3 Unknown3 blocked by ARMR today3 No public exploit3
Nov 26
3 matches 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-71395 Unknown 2026-11-11 Protected by Waratek No public exploit unsafe deserialization in hyphenation loading vulnerability in Apache XML Graphics FOP. This issue affects Apache XML Graphics FOP: through 2.11. Users are recommended to upgrade to version 2.12, which fixes the issue.
CVE-2026-122096 Unknown 2026-11-11 Protected by Waratek No public exploit Uncontrolled Resource Consumption vulnerability in the sketch deserialization of Apache DataSketches Java. Several deserializers trusted sizes and counts declared in the serialized input. A small crafted input could make an application allocate an excessive amount of memory, leading to an OutOfMemoryError. A crafted string passed to FrequentLongsSketch.getInstance(String) could also make deserialization, or a later update, loop indefinitely. Only applications that deserialize sketches from untrusted sources are affected. This issue affects Apache DataSketches Java: through 9.0.0. Users are recommended to upgrade to version 9.1.0, which fixes the issue.
CVE-2026-111241 Unknown 2026-11-10 Protected by Waratek No public exploit When a non-default stateful session bean passivation strategy is configured, passivated bean state is written to predictably named files in the shared system temporary directory, reusing files that already exist there, and is deserialized on activation. A local attacker who can write to that directory can read passivated session state or supply data that the server deserializes, potentially leading to code execution as the server process. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue.