Apache Neethi CVE-2026-91867

Requires that the deploying application uses Apache Neethi to fetch a remote policy reference over the network AND that an attacker can control or influence the responding server (or interpose one) so it delivers bytes slowly without ever completing. Neethi only enforces a per-read timeout, not a total-transfer timeout, so the slow-trickle server keeps the fetch alive indefinitely. Limiting factors: applications that only use locally embedded/bundled WS-Policy documents are not exposed; meaningful denial requires repeated requests to exhaust the thread pool since each request ties up a single calling thread; impact is availability-only with no confidentiality or integrity effect.

This is a genuine but low-to-moderate priority issue. No CVSS vector, CWE, EPSS score, KEV entry, or public POC is provided in the source data, so quantitative exploitation signals are absent - the only severity anchor is the ASF vendor rating of 'moderate'. On its own merits the flaw is a pure availability defect (CWE-400 / missing total transfer timeout): Neethi limits per-read time but not total transfer time when fetching a remote policy reference, so a slow-trickle ('slow loris'-style) server can hold the calling thread indefinitely. There is no confidentiality or integrity impact and no code execution. Real-world risk is strongly gated by whether the deploying application actually resolves remote WS-Policy references and whether an attacker can influence the target URL or interpose a malicious/slow server - most SOAP deployments use locally embedded policies, which sharply narrows exposure. Exploitation status: no public exploit identified at time of analysis. Net: a legitimate hardening fix worth patching on the normal maintenance cycle, not an emergency; the headline is availability degradation, not compromise.

An application built on a Java web-services stack (e.g., Apache CXF/Axis2) that pulls a WS-Policy document from a remote URL is pointed at, or tricked into resolving, an attacker-controlled endpoint. That endpoint accepts the connection and then trickles response bytes a few at a time, staying under the per-read timeout forever; because Neethi enforces no overall transfer deadline, the fetching thread blocks indefinitely. Repeating this across many requests exhausts the worker thread pool and degrades or denies service. No public POC is referenced.