Red Hat EAP/Artemis: mechanizm allow-list istnieje, ale pusta lista znaczy „zaufaj wszystkim klasom” — kiedy security feature jest obecne, a default semantycznie je wyłącza

CVE-2026-86404 dotyczy deserializacji w Artemis messaging w Red Hat JBoss EAP. ObjectMessage.getObject() korzysta z ObjectInputStreamWithClassLoader, która ma security filtering oparty na allow-list i block-list oraz checkSecurity()/isTrustedType(). Na papierze dobrze. Problem: domyślnie obie listy są puste, a pusta allow-list jest interpretowana jako „allow everything” — isTrustedType() zwraca true dla wszystkich klas.

CVE-2026-86404 (CVSS 8.8, PR:L): pusta domyślna allow-list → deserializacja dowolnej klasy z classpath; nie unauth internet RCE, ale wymaga dostarczenia złośliwego ObjectMessage.

Workaround: restrykcyjna deserialization-allow-list dla każdego pooled-connection-factory (np. ograniczona do com.yourapp).

Pusty allow-list to podatna konfiguracja, nie „brak konfiguracji”

Vendor mówi, że deserialization jest dozwolona domyślnie właśnie z powodu tej semantyki — to CVE, nie tylko missing-hardening. Java deserialization jest groźna, bo attacker steruje serialized object graph i w classpath mogą istnieć gadget chains. Poprawna kontrola redukuje zbiór dopuszczalnych klas do minimum (default deny + explicit allow). W podatnym default: allow-list empty → isTrustedType()==true → every available class potentially deserializable.

Feature present ≠ security property enforced

Host z affected version i dobrą allow-listą nie jest automatycznie exploitable. Finding wymaga evidence:

version_affected: true object_message_path_present: true/false deserialization_allow_list: { configured: true/false, restrictive: true/false } attacker_can_send_object_message: true/false

To idealny VEX (component affected / environment not exploitable / justification: vulnerable function protected by vendor-documented configuration) — ale tylko z evidence każdego connection factory (3 factory, allow-lista na 2 → property nie jest globalna). Ta podatność generuje oba błędy: false positive (skaner: EAP affected, a wszędzie restrictive allow-list) i false negative (audyt: allow-list feature supported = safe, a runtime: allow-list empty = allow all).

Product mapping, patch i weryfikacja

Red Hat rozróżnia produkty: EAP 7 i 8 affected, część innych produktów z powiązanymi Artemis/Camel — unaffected (same library family ≠ same product affectedness). Na moment analizy nie wymyślaj fixed version, jeśli record jej nie publikuje (patch_target: unknown/pending, vendor_workaround: available). Weryfikacja przechodzi z „configuration review” w „security property verification”: affected component obecny? ObjectMessage używane? wszystkie factory z restrykcyjną allow-listą? expected messages działają? obiekt spoza listy odrzucany? runtime załadował config i przetrwał restart?

Wniosek

CVE-2026-86404 to pułapka semantyczna: security control istnieje, ale default znaczy jego przeciwieństwo. A gdy vendor podaje deterministyczny workaround, modeluj go jako machine-verifiable compensating control (product_remediation: pending / environment_exploitability: blocked), nie ręcznie odnawiany wyjątek.

Powiązane na blogu

Axolotl: flaga nie na każdej ścieżce — obecność kontroli ≠ skuteczność
Cua: kompozycja defaultów — secure by default jako system

Źródła

Red Hat — CVE-2026-86404 — access.redhat.com
CIRCL Vulnerability-Lookup — CVE-2026-86404 — vulnerability.circl.lu

Nota redakcyjna: stan informacji 8 września 2026. CVE-2026-86404 (Red Hat JBoss EAP/Artemis, CVSS 8.8): pusta domyślna deserialization allow-list jest interpretowana jako „allow all”; workaround to restrykcyjna allow-list per pooled-connection-factory. Artykuł koncentruje się na semantyce efektywnego stanu i per-factory evidence.