Server takeover flaw in Prefect (CVE-2026-5366): update to the latest

A critical flaw that lets an attacker run arbitrary programs on a server has been found in Prefect, the popular tool for building and automatically running data pipelines in Python. It is tracked as CVE-2026-5366, rated CVSS 9.9 out of 10. The U.S. vulnerability database NVD published it on June 20, 2026. The fix landed in PR #21384 and is in place from 3.6.25.dev7 onward. If you self-host an earlier version, you need to update.

The problem lives in the part of Prefect that fetches pipeline code from git (the system for storing and retrieving source code). The "commit number" (commit_sha) and "target folders" (directories) you specify when fetching were passed straight to the git command as arguments, without validation. An attacker can slip in a git instruction (option) disguised as a plain number. This is what's called "argument injection," and it ends in arbitrary commands running on the worker (the machine that actually does the work).

What makes it scary is that no high privilege is needed to trigger it. In environments where Prefect is shared across several people or teams, anyone with roughly "can register a deployment" permission can hit this hole. And the CVSS rating of 9.9 already factors in that the impact reaches beyond your own scope to the shared workers and other users' processing (a scope change). A single account can become the entrance to the whole shared platform.

What Prefect actually does

Prefect is an open-source tool for running data processing written in Python on autopilot, including "when, in what order, and how to retry on failure." It is used to run recurring jobs such as data ingestion, aggregation, and machine-learning preprocessing reliably and without manual effort. It is one of the leading tools in this space (workflow orchestration), with over 17,000 GitHub stars. Alongside tools like Apache Airflow, it is widely adopted in data engineering.

There are two main ways to use it. One is Prefect Cloud, the vendor's managed service; the other is self-hosting "Prefect Server" on your own infrastructure. The flaw mainly bites the latter, especially cases where a single Prefect environment is shared by multiple teams or users.

In a typical Prefect setup, a user registers a deployment saying "run this code from this git repository," and a machine called a worker fetches that code from git and runs it. Because the worker is the one actually doing the data processing, it usually holds strong cloud permissions, database access, and various passwords and secret keys. Knowing that makes it clear what flows out when it's taken over.

One instruction disguised as a number, and whoever holds the data platform walks off with what

A score of CVSS 9.9 is hard to connect to your own losses, so let's first describe concretely who reaches for a Prefect worker, and what they're after. A Prefect worker sits where a company's data and the keys that move that data are gathered together. What pours out when that place is pried open is the real danger of this flaw.

The person who hits this hole isn't necessarily a hacker group in a far-off country. The starker motives belong to an outside contractor who temporarily holds an account, a soon-to-leave employee planning to walk off with data, or an intruder who only phished a single staff member's login. All they need is the minimal "can register a deployment" permission, and with that they can run commands on the worker. What they target is not abstract "data" but concrete goods: the connection passwords for data warehouses (Snowflake, databases), AWS and GCP access keys, the various tokens stored in Prefect, and the customer data flowing through the pipelines themselves. The moment they get one git option disguised as a number through, the worker's entire key ring passes into their hands, and the processing platform is taken over.

In security terms, a data-platform worker is an ideal launch pad for "lateral movement." Workers sit deep inside the cloud or internal network and can legitimately connect to data warehouses and production databases. Using that as a starting point, an attacker can spread to systems they should never have reached. And because this flaw involves a scope change, they can reach past their own team's boundary into the jobs and credentials of other teams sharing the same worker. The more you run it as multi-tenant (one platform shared by many users), the less the damage stops at one person's boundary.

CVSS 9.9 is only a gauge of technical severity. For a company running its data platform on Prefect, the real pain isn't a server briefly going down. It is that the data-warehouse and cloud keys spill out wholesale, and customer-data leakage and intrusion into other teams' territory happen at once. A convenient automation mechanism can turn out to be the shortest path to the entire company's data.

CVE-2026-5366: slipping an instruction into git's arguments

CVE-2026-5366: argument injection via the commit number in GitRepository (CVSS 9.9)

CVE-2026-5366 lives in the code that fetches code from a git repository (the GitRepository storage, in the file src/prefect/runner/storage.py). NVD classifies it as CWE-94 (Improper Control of Generation of Code). The CVSS is 9.9, rated as requiring low privileges (PR:L) while the impact reaches outside its scope (a scope change).

When a user registers a deployment, they can specify a commit_sha indicating "which commit's code to use" and directories indicating "which folders to fetch." Normally commit_sha should be a hexadecimal number like a1b2c3d.... But Prefect passed this value straight to the git command without validating it.

That's the trap. A command like git interprets an argument beginning with -- as "this is an option (an instruction), not a value." If an attacker puts a string like --upload-pack=touch /tmp/pwned into commit_sha instead of a number, git receives it as an option and runs the command the attacker specified. The report and public proof of concept went through the bug-bounty platform huntr.

Why "git's arguments" turn into command execution

The key to this attack is the "options that invoke external programs" that git carries. Options like --upload-pack and --exec, for example, launch a specified program partway through fetching a repository. They exist for legitimate operations, but once an attacker can freely set the value, they become a trigger for arbitrary command execution.

This "pass user input straight into a command's arguments" type of flaw is not unique to Prefect; it recurs across tools with git integration. In April 2026, GitHub itself disclosed CVE-2026-3854, where a single git push could lead to remote control. The more a place takes external values for the sake of convenient automation, the more it must distinguish at the entrance "is this value really a number, or is it an instruction?" We continue to cover cases where missing input validation led directly to takeover, such as the Langflow tar-link abuse.

The fix, and a fix PR written by an AI

The vendor addressed it in PR #21384 by adding value checks at the entrance. Specifically, it restricts commit_sha to the regular expression ^[0-9a-fA-F]{4,64}$ (hexadecimal, 4-64 characters), rejecting instruction-shaped values before any command runs. The lower bound of 4 matches git's shortest allowed abbreviated number, and the upper bound of 64 covers both SHA-1 (40 chars) and SHA-256 (64 chars). It also warns when directories begins with --, and adds a -- separator to git sparse-checkout set to mark "everything after this is a value."

A notable detail this time is that the fix PR was auto-generated by the coding AI Devin and merged by a maintainer on April 2, 2026. It is one example of an AI agent writing security-fix code, with a human reviewing and merging it, actually happening on a real critical vulnerability. The fix shipped as 3.6.25.dev7, and versions before it (up to 3.6.25.dev6) are affected.

Is your Prefect affected? (version quick reference)

If you self-host Prefect, first check your situation in the table below. If you use the cloud version (Prefect Cloud), the server side is handled by the vendor.

Note that, whether self-hosted or cloud, the workers that actually run the jobs are often running in your own environment. Even if the server itself is fixed, the hole stays open if an old Prefect worker remains. Check the worker version too.

What to do right now

1. Update Prefect to the latest version. Update both server and workers to 3.6.25.dev7 or later (ideally a later stable release) that contains the fix. If installed as a Python package, run pip install -U prefect; with Docker, pull the latest image and recreate the worker. Don't forget the workers that fetch and run the code, not just the server.

2. Review who can register deployments. This flaw can be triggered with just "can register a deployment" permission. In shared environments, narrow the permission so only those who truly need it can create deployments, and disable accounts of outside staff or departed employees that are no longer needed. A state where anyone can freely register pipelines is itself a risk.

3. Rotate the keys the workers hold. If you ran an affected version in a shared environment, treat the cloud access keys, data-warehouse and database credentials, and tokens stored in Prefect that the workers could reach as leaked, and reissue them. Prioritize AWS/GCP keys, as their blast radius is wide.

4. Minimize worker permissions. The fundamental way to shrink the damage from incidents like this is to narrow the permissions given to workers in the first place. Instead of giving one worker strong access to all data, redesign so each job receives only the minimal permissions it needs.

5. Inspect for signs of compromise. On worker machines, check ps aux for unfamiliar processes, /tmp and /var/tmp for unknown executables, and for suspicious cron entries or outbound connections. If anything looks off, rebuilding from a clean environment is the surest path.

Actively exploited CVEs and related reading

As of June 2026, CVE-2026-5366 is not listed in the U.S. CISA "Known Exploited Vulnerabilities (KEV)" catalog. Still, a CWE-94 (code injection) rated CVSS 9.9 is top-tier, and given the nature of a data platform, abuse from insiders or compromised accounts is a realistic risk. We keep the latest status of confirmed-exploited CVEs updated in our CISA KEV dashboard (Japanese).

Vulnerabilities in pip-distributed OSS like Prefect can spread into unexpected places through dependency chains. To check whether the packages you use carry known holes, see our OSS supply-chain scanner. The same "execute external input as-is" type of incident keeps happening across development and data tools, as we've covered with the overrideConfig flaw in the AI builder Flowise and the LiteLLM command injection.

Summary

CVE-2026-5366 is an argument-injection flaw born because Prefect passed the user-specified "commit number" straight into the git command's arguments when fetching code. Simply sending a git option disguised as a number runs an arbitrary command on the worker that does the processing, and it is rated CVSS 9.9. The fix landed in PR #21384 and is in place from 3.6.25.dev7 onward.

The real danger of this hole is that it needs no high privilege to trigger, and its impact reaches other users of the shared platform. A data platform is where the data itself and the key ring that moves it gather, so one takeover chains into broader damage. If you use Prefect self-hosted, in addition to updating the server and workers, take this moment to inventory "who can register deployments" and "how far the workers' keys reach."

References

• ▸ NVD - CVE-2026-5366
• ▸ huntr - Prefect GitRepository argument injection (report)
• ▸ PrefectHQ/prefect - PR #21384 (fix)
• ▸ Prefect official repository (GitHub)
• ▸ The Hacker News - GitHub CVE-2026-3854 (same git-integration class)
• ▸ CISA - Known Exploited Vulnerabilities Catalog