CVE-2026-5366: Prefect GitRepository Argument Injection RCE
| Field | Value |
|---|---|
| CVE ID | CVE-2026-5366 |
| CVSS score | 9.9 |
| Attack vector | Remote code execution via git argument injection in worker-side operations |
| Auth required | Not fully unauthenticated; NVD indicates a user with deployment creation permissions is required |
| Patch status | A fix is likely available beyond 3.6.23, but the exact first fixed version was not confirmed from retrieved primary sources |
TL;DR - Critical Prefect RCE in
GitRepositoryhandling ofcommit_shaanddirectories. - Confirmed affected version is3.6.23; admins should move off it immediately. - No confirmed in-the-wild exploitation yet, but impact on shared workers is high.
Vulnerability at a Glance
CVE-2026-5366 is a critical remote code execution issue in Prefect, specifically in the GitRepository storage class. According to the NVD description, Prefect 3.6.23 improperly handles user-controlled input in the commit_sha and directories parameters when building git command invocations. That weakness allows git argument injection, which can result in arbitrary command execution on worker machines.
For defenders, the practical risk is not just “git misuse” but worker compromise. In Prefect environments where users can create or modify deployments, an attacker may be able to turn deployment configuration into code execution on infrastructure that often has secrets, repository access, cloud credentials, and network reachability to internal systems. The impact is especially serious in shared work pools and multi-tenant environments, where one tenant’s deployment permissions may become another tenant’s infrastructure problem.
What This Vulnerability Actually Means for Operators
This is not described in the retrieved sources as a generic internet-wide pre-auth RCE against every Prefect deployment. The known precondition is more specific: the attacker needs deployment creation permissions. That still makes the issue operationally significant because many teams delegate deployment creation to developers, data engineers, CI systems, or tenant-scoped users who are not intended to have shell-level access to worker hosts.
The vulnerable behavior stems from passing user input into git commands without sufficient separation between trusted flags and untrusted values. NVD specifically notes that commit_sha lacks validation and does not use a -- separator to distinguish the end of command options. It also states that directories can be abused during sparse-checkout operations. In practice, this means values that should be treated as data may instead be interpreted by git as command-line flags, enabling dangerous behavior such as abuse of --upload-pack and potentially external program execution.
Who Is Affected
The product affected is Prefect, maintained under the PrefectHQ project. Based on the retrieved primary-source content, the only explicitly confirmed vulnerable version is Prefect 3.6.23. The affected component is the GitRepository storage class, and the attack surface involves deployment storage settings that influence git operations, especially commit_sha and directories.
A broader affected range was not confirmed from the source material provided. That matters because many CVE explainers overstate version impact by assuming “all prior versions” or “all 3.x releases” without a vendor advisory. Here, the evidence-based position is narrower: confirmed affected version: 3.6.23; broader range: unknown from retrieved sources. Defenders should assume other nearby versions may warrant review, but should not rely on an unverified range for change management or exposure reporting.
Technical Notes
The NVD description identifies these vulnerable inputs:
Affected component: GitRepository storage class
Potentially dangerous user-controlled fields:
- commit_sha
- directories
A conservative review target is any deployment definition or storage configuration referencing git-backed code retrieval, especially if workers perform clone, checkout, or sparse-checkout actions based on user-supplied parameters.
Severity and Risk Context
The NVD entry assigns CVSS v3 base score 9.9, which places this issue in the critical range. The full vector string was not exposed in the retrieved data, so practitioners should avoid repeating a vector that has not been verified. Even without the full vector, the score alone signals that the impact and exploitability characteristics are severe enough to justify priority handling.
From a business and operations perspective, the criticality is justified. Worker compromise can expose secrets used by flows, service account tokens, repository credentials, cloud API keys, or lateral movement paths into orchestration infrastructure. In many SMB and enterprise deployments, workflow workers sit in trusted network zones and routinely handle sensitive automation. That makes an attacker with mere deployment-authoring rights much more dangerous than their nominal role would suggest.
Exploitation Status and PoC Availability
At the time of lookup, CISA KEV does not list CVE-2026-5366. That means there is no CISA-confirmed evidence, via KEV, that the vulnerability is actively exploited in the wild. It is important not to overstate this point: “not in KEV” does not mean safe, only that KEV did not confirm active exploitation at lookup time.
A public disclosure path exists through a Huntr bounty reference listed by NVD. However, based on the retrieved source material, a public PoC repository or reliably reproducible exploit code was not verified. The right practitioner summary is therefore:
| Status item | Evidence-based conclusion |
|---|---|
| In-the-wild exploitation | Not confirmed from retrieved sources |
| KEV listing | No |
| Public disclosure | Yes, via Huntr reference |
| Public PoC code | Not verified from retrieved sources |
In the absence of confirmed exploitation telemetry, defenders should assume the barrier to weaponization is moderate because the bug class is straightforward: argument injection into git operations. That makes rapid mitigation prudent even without exploitation confirmation.
What Defenders Should Do Next
First, inventory all Prefect instances and identify whether any are on version 3.6.23. Then determine whether they use GitRepository storage and whether deployment creation rights are broadly assigned. This quickly tells you whether the issue is merely present in software inventory or actually exposed in your operating model.
Second, treat worker hosts as the key containment boundary. Review what secrets they can access, what cloud roles they hold, what networks they can reach, and whether they are shared across teams or tenants. Even if you find no signs of exploitation, CVE-2026-5366 is a reminder that orchestration workers often have privilege far beyond their apparent function. That makes patching and segmentation worth prioritizing.
Bottom Line
CVE-2026-5366 is a critical Prefect vulnerability that can let a user with deployment creation permissions execute arbitrary commands on worker machines by abusing git argument handling in GitRepository. The confirmed affected version is 3.6.23. The exact fixed version was not confirmed from retrieved primary sources, and in-the-wild exploitation is not confirmed.
That uncertainty should not slow response. If you run Prefect and allow git-backed deployments, especially in shared worker pools, assume this issue is high priority: upgrade off 3.6.23, reduce who can create deployments, hunt for suspicious git invocations, and isolate workers that process untrusted tenant workloads.
For further information on how attackers exploit vulnerabilities, check our article on how attackers use mailbox rules to hide email fraud. For a deeper understanding of secure design principles, visit our secure by design glossary.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How to Detect Suspected Exploitation
Detection should focus on worker-side process execution, deployment configuration changes, and unusual git command arguments. Because the root issue is command/argument injection, artifacts may appear in process command lines, audit logs, EDR telemetry, or shell history on worker hosts rather than in traditional web application logs.
Start by identifying any deployment updates that use GitRepository, especially where commit_sha or directories contain unexpected values. Legitimate commit_sha values should generally look like hex commit identifiers. If you see embedded spaces, leading dashes, or option-like strings, treat that as suspicious. The same logic applies to sparse-checkout directory values that resemble git flags rather than directory names.
Technical Notes
Example suspicious patterns to hunt for in process logs or EDR command-line telemetry:
git .* --upload-pack
git checkout .* --.*
git sparse-checkout .* --.*
If you collect Linux process execution events in Splunk, a starter query could look like this:
index=edr OR index=sysmon_linux process_name=git
| search process_command_line="*--upload-pack*" OR process_command_line="*sparse-checkout* --*" OR process_command_line="*checkout* --*"
| table _time host user parent_process_name process_name process_command_line
For Elastic-style process event hunting:
process.name:"git" and (
process.command_line:*--upload-pack* or
process.command_line:(*sparse-checkout* and *--*) or
process.command_line:(*checkout* and *--*)
)
On systems with auditd, you can search for git executions with option-like payloads:
ausearch -i -x git | egrep 'upload-pack|sparse-checkout| checkout | --'
These patterns are not definitive proof of exploitation, because some advanced git workflows may use uncommon flags legitimately. The value is in prioritizing review of git processes launched by Prefect workers, especially if the parent process ties back to a Prefect worker service account or a deployment run shortly before anomalous activity.
Mitigation and Patching Guidance
The most important immediate action is to move off Prefect 3.6.23. Based on the retrieved sources, the exact fixed version number was not confirmed, so defenders should not claim a specific patch version unless they validate it from Prefect release notes, a vendor advisory, or the fixing commit. In the absence of that confirmation, the safest assumption is: upgrade to the latest vendor-supported release that is newer than 3.6.23, then verify release notes before production rollout.
If an immediate upgrade is not possible, reduce exposure by tightening deployment creation permissions and isolating workers. This is one of those cases where least privilege and tenancy separation materially reduce blast radius. Shared work pools should be treated as high risk until patched. If users from different trust domains can submit deployments to the same workers, assume those workers are at elevated risk of cross-tenant compromise.
Technical Notes
If you installed Prefect with pip, a practical upgrade action is:
python -m pip install --upgrade prefect
python -m pip show prefect
If you need to pin away from the confirmed vulnerable release while you validate the fixed version:
python -m pip install "prefect!=3.6.23"
python -m pip show prefect
If you manage Prefect via Poetry:
poetry add prefect@latest
poetry show prefect
Workarounds if patch validation is delayed:
1. Remove or disable untrusted use of GitRepository-backed deployments.
2. Restrict who can create or modify deployments.
3. Avoid shared worker pools across trust boundaries.
4. Review existing deployments for commit_sha and directories values.
A practical temporary control is to review deployment definitions and reject suspicious values:
- commit_sha should look like a commit identifier, not a flag.
- directories should be path-like entries, not strings beginning with - or containing git option syntax.
References
- NVD: CVE-2026-5366
- CISA KEV catalog: CISA KEV
- Huntr reference: Huntr Bounty
- Prefect documentation: Prefect Docs
- Prefect 3.6 release notes: Version 3.6 Release Notes
- PrefectHQ releases: Prefect Releases