Prefect CVE-2026-3514

Exploitation requires that the target Prefect server (version 3.6.19) has server-side authentication enabled via PREFECT_SERVER_API_AUTH_STRING - instances running with no auth are not in scope of this bypass - and that the attacker has network reachability to the server's HTTP API. The attacker must either know an existing resource name (variable, flow, work pool, work queue, or deployment) whose name happens to end in 'health' or 'ready', or be able to create such a resource; a related Host-header variant works against ordinary endpoints when the attacker can set the Host header to a value like 'localhost/health?' (demonstrated in the regression test test_host_header_manipulation_does_not_bypass_auth). No user interaction, no credentials, and no special client tooling are required beyond an HTTP client. Limiting factors: the bypass yields confidentiality impact only (C:H/I:N/A:N), so it does not directly grant write access, and only GET requests are exempted by the middleware.

The CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N vector aligns cleanly with the technical reality: network-reachable, no privileges, no user interaction, and a confidentiality-only impact since the bypass exposes read access to variables, flows, work pools, work queues, and deployment metadata that frequently store API keys and database credentials. Real-world risk is meaningfully elevated by the fact that Prefect servers are often deployed inside internal networks but increasingly exposed via ingress for remote workers, and exploitation requires only knowing or guessing resource names ending in the exempted suffixes - which an attacker can also create themselves if any write path is reachable. EPSS and KEV data are not present in the provided intelligence, so I cannot quantitatively rank exploitation probability, but the trivial attack complexity, public huntr disclosure with a bounty writeup, and presence of a regression-tested fix in the upstream commit all argue this should be treated as a high-priority patch rather than a theoretical issue. There is no conflict between the CVSS network vector and the description; both consistently describe an unauthenticated HTTP-level bypass.

An attacker who can reach an authenticated Prefect 3.6.19 server (directly or via a misconfigured ingress) sends GET /api/variables/name/system-health and, because the auth middleware sees a path ending in 'health', receives the variable's value - which Prefect commonly uses to store API keys, database DSNs, and other secrets. The same trick works against /api/flows/.../system-ready, /api/work_pools/<n>-health, /api/work_queues/<n>-ready, and /api/deployments/<n>-health, letting the attacker enumerate orchestration state and harvest credentials without ever presenting the basic-auth header. No public exploit identified at time of analysis, but the regression tests committed alongside the fix effectively document the exact request shapes needed.