Prefect EUVD-2026-38128

Exploitation requires (1) an account with permission to create or edit a Prefect deployment in the target workspace, (2) that deployment using the GitRepository storage class so the attacker-controlled commit_sha or directories values reach the git subprocess, and (3) a worker that subsequently picks up the run - most impactful when a single work pool is shared across tenants. There is no user interaction on a victim's side and no admin role needed (PR:L), but the flaw is gated by Prefect's RBAC for deployment authoring and does not affect installations where Git storage is unused or where deployments are managed exclusively by trusted operators.

The supplied CVSS:3.0 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (9.9) is consistent with the description: an authenticated low-privilege Prefect user reaches the worker over the network through deployment configuration, breaks out of the Prefect trust scope onto the worker host, and gains full CIA impact - the scope change is genuine because the attacker's principal differs from the compromised worker. EPSS, KEV, and POC signals are all absent from the input, so this is not known to be actively exploited; however, the prerequisite is merely "deployment creation" which is a routine collaborator permission in multi-tenant Prefect Cloud/Server installs, making real-world risk high wherever workers are shared. The dominant uncertainty is the patched version: the only references are a huntr bounty page, an NVD link, and a VulDB entry - no PrefectHQ advisory or release tag is cited, so defenders cannot yet pin the exact fixed build from this data.

A developer with deployment-creation rights in a shared Prefect workspace creates a deployment whose GitRepository.commit_sha is set to something like --upload-pack=/tmp/payload.sh (or a similar --exec/--upload-pack flag), pointing the git remote at an attacker-controlled URL. When any tenant's flow run is scheduled onto the shared worker, the worker invokes git with the injected flag, executing the attacker's binary as the worker process and yielding code execution on the host. From there the attacker can pivot to other tenants' flow code, credentials, and result stores co-located on the worker.