8 września 2026 Apache Nutch ujawnił trzy CVE w legacy Nutch Server / REST API (wszystkie ≤ 1.22): CVE-2026-41870 — unauthenticated RCE przez JEXL injection, CVE-2026-41871 — unauthenticated reflection-based job execution, CVE-2026-41869 — unauthenticated forced shutdown. Wspólny fixed version to 1.23 — ale najważniejszy fakt: 1.23 usuwa legacy JAX-RS Nutch Server/REST API. To nie patch endpointu; projekt usuwa cały attack surface.
Problem był architektoniczny
REST API nie było zwykłym application endpointem — było remote control plane bez authentication/authorization, które nie powinno być publicznie dostępne. Naprawa jednego parsera (JEXL) nie rozwiązałaby całości: root issue to legacy REST API + brak trust boundary + bardzo wysokie capabilities backendu. CVE-41871 pokazuje wariant bez JEXL (unsafe reflection), a CVE-41869 — availability impact (forced shutdown crawlera).
Usunięcie funkcji jako typ remediation
Zamiast ratować legacy feature (auth middleware, filtr JEXL, blokada kilku klas reflection), Apache wybiera mocniejszy model: remove legacy server. Dla VM to osobny typ:
Ale upgrade do 1.23 bywa breaking change — jeśli organizacja używa Nutch Server jako integration surface, po upgrade API zniknie. To security remediation → application architecture change (alternatywny orchestration/CLI/authenticated wrapper) — security-driven deprecation project.
Jeśli nie można zaktualizować; internal ≠ trusted
Apache mitigation: „ograniczyć dostęp do Nutch Service wyłącznie do trusted users” — dosłownie: nie „behind firewall”, lecz reachability graph pokazujący tylko trusted principals/networks (localhost-only, dedicated VLAN, reverse proxy z strong auth, mTLS, network policy, host allowlist). Jeśli dowolny workload w dużym K8s może połączyć się z usługą, „internal” nie znaczy „trusted”. Internet-facing instance = emergency (unauth RCE, nie czekaj na EPSS).
Weryfikacja: potwierdź, że funkcja zniknęła
Dla 1.23: runtime 1.23+, legacy REST listener nie istnieje, stare procesy 1.22 zatrzymane, LB/Ingress nie kieruje do starej instancji, rollback image nie przywróci 1.22, attack endpoint zwraca brak usługi (nie tylko 401 z pozostawionym backendem). Trzy CVE → jedna remediation campaign, ale osobne findings (różne impact classes). Przy wcześniejszej ekspozycji dla niezaufanych — rozważ compromise assessment (patch/feature removal nie odpowiada, czy wcześniej wykonano kod).
Wniosek
Apache Nutch daje mocną lekcję: gdy model zaufania funkcji jest nie do obrony, jej usunięcie bywa niezawodniejsze niż kolejne częściowe fixes. Remediation może być jednocześnie patchem, feature retirement, migracją architektury i attack surface reduction.
Powiązane na blogu
- Uptrain: EOL jako finding — brak bezpiecznej przyszłości komponentu
- ABRT: usuń zamiast patchować — redukcja attack surface jako remediacja
Źródła
- Apache Nutch — Security page (09.09.2026) — nutch.apache.org
- oss-security — CVE-2026-41870 (08.09.2026) — seclists.org
Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-41870/41871/41869 (legacy Apache Nutch Server ≤1.22); fix 1.23 usuwa cały JAX-RS REST API. Dostęp do API ≈ dostęp do hosta. Artykuł koncentruje się na feature removal jako typie remediacji i weryfikacji, że funkcja zniknęła.