Apache IoTDB EUVD-2026-107167

Exploitation requires an authenticated IoTDB account holding SYSTEM-level privileges - specifically USE_PIPE or MAINTAIN - and network access to the Legacy Pipe receiver protocol endpoint (handshake / sendPipeData). The attacker does NOT need WRITE_DATA or DELETE_DATA permission on the target databases, which is the core of the bypass. Limiting factors: the deployment must expose and use the Legacy Pipe API, the attacker must already possess a valid low-privileged account (no unauthenticated path is described), and only instances running Apache IoTDB 2.0.0 through 2.0.10 are affected (fixed in 2.0.11). Authentication requirements are described by the vendor as a privileged-user precondition but are not confirmed via a CVSS PR metric since no vector was supplied.

Signals are sparse: no CVSS vector/score, no CWE, no EPSS probability, no CISA KEV listing, and no public POC were provided, so quantitative exploitation likelihood cannot be anchored to external scoring. Qualitatively, the Apache advisory describes a clear authorization-model bypass: the Legacy Pipe receiver hardcodes a SUPER_USER (root) identity, so an already-authenticated user holding only SYSTEM-level privileges (USE_PIPE or MAINTAIN) but lacking WRITE_DATA/DELETE_DATA can perform data load and delete operations as root. This is a genuine integrity/availability priority for any multi-tenant or least-privilege IoTDB deployment because it defeats the permission model entirely, but it is NOT unauthenticated-trivial: it requires a valid low-privileged account with pipe-related rights and use of the Legacy Pipe API. Because no CVSS vector is supplied, authentication and attack-vector qualifiers cannot be independently confirmed - the 'authenticated low-privilege user' framing comes from the vendor description, not from a PR metric. Net: a real and credible privilege/permission-bypass bug worth prompt patching where IoTDB enforces data-level ACLs, but exploitation probability in the wild is currently unquantified and there is no evidence of active exploitation.

An insider or compromised account granted only USE_PIPE or MAINTAIN (SYSTEM-level) rights, with no WRITE_DATA or DELETE_DATA permission on target databases, crafts PipeData messages and sends them through the Legacy Pipe handshake/sendPipeData API. The receiver executes the resulting load/delete operations under the hardcoded root identity, letting the attacker insert or wipe time-series data they should never be able to touch. No public exploit code was identified at time of analysis, and exploitation requires an existing authenticated session plus network reach to the Legacy Pipe endpoint.