Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

Prefect

Bug bounty on Sorona prefect.io

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
13
Public CVEs
3
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Report on Sorona
Submit through the program page.
Partial safe harbor
Some legal protection; read the terms.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Severity Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Safe harbor
Partial Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

13 assets you may test, 6 excluded.

Web 1

  • https://www.prefect.io

Products and areas 12

  • Artifacts, logs and flow run metadata, covering anything that renders content a flow produced
  • Blocks in full: block registration, the credential and storage block types, secret handling, and how a block's contents reach a worker process
  • Deployments and work pools, covering the pull steps that fetch flow code from git, S3 or another remote store before a run starts
  • Result storage and serialisation, including the pickle-backed result serializer and every path where a run reads back a result another run wrote
  • The CLI, the client library and the profile and API key handling behind them
  • The event and automation system, including triggers, webhooks that accept an inbound request, and the actions an automation can perform
  • The orchestration engine, covering flow and task run state transitions, retries, cancellation and the concurrency limit machinery
  • The Prefect Server API in full: every REST route, the authentication layer in front of it, and the authorisation checks that separate one workspace or tenant from another
  • The published policy asks for any security vulnerability privately through the repository's advisory workflow, and names a short explicit out-of-scope list. Everything below sits inside what it accepts
  • The web UI and the API it talks to, including every place run or deployment metadata becomes rendered HTML
  • The worker and agent processes and the infrastructure integrations that launch runs on Docker, Kubernetes, ECS and Cloud Run
  • Variables, the task-run cache and any shared state a flow can read that another flow wrote
Out of scope (6)
  • A flow author's own Python executing, which is the purpose of an orchestrator. The finding has to cross a boundary someone expected to hold
  • A self-hosted server an operator deliberately exposed without authentication, which the documentation treats as an operator decision
  • Prefect Cloud, the hosted commercial product. This card covers the open-source package and self-hosted server
  • The out-of-scope items the SECURITY.md lists by name; read that list before filing
  • Third-party Prefect integration packages and community blocks the project does not maintain
  • Upstream FastAPI, SQLAlchemy, Pydantic or Python dependency bugs, unless Prefect's own use of them is what makes the bug reachable

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.

While testing

  • Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
  • Open a GitHub Security Advisory at github.com/PrefectHQ/prefect/security/advisories/new, the channel the SECURITY.md names. Private vulnerability reporting is enabled on the repository
  • Do not open a public issue for a security bug; the policy rules that out explicitly
  • There is no security email fallback published, so the advisory workflow is the whole intake
  • Separate Prefect Server from Prefect Cloud. Cloud is the hosted commercial product; this card covers the open-source package and the server you run yourself
  • Say whether the finding needs the API to be reachable and what authentication the target had configured, since a self-hosted server is frequently deployed with none
  • Show the boundary that broke. A flow author writing Python that runs is what an orchestrator does, so the finding has to cross a tenant, workspace or privilege line
  • The project has an explicit out-of-scope list in its SECURITY.md; read it before filing rather than after triage closes your report

Not accepted

  • A flow author's own Python executing, which is the purpose of an orchestrator.
  • A self-hosted server an operator deliberately exposed without authentication
  • Third-party Prefect integration packages and community blocks the project does not maintain
  • Upstream FastAPI, SQLAlchemy, Pydantic or Python dependency bugs, unless Prefect's own use of them is what makes the bug reachable

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

Search NVD
CVESeverityPublished
CVE-2026-5366 Critical 9.9 20 Jun 2026
CVE-2026-3514 High 7.5 2 Jun 2026
CVE-2023-6022 High 8.8 16 Nov 2023

Original policy

Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 6 Last 12 months Improper access control 35 % Deserialization RCE 25 % Credential exposure 20 % Info disclosure 20 % Latest advisories Loading the feed Overview Prefect is the Python-native workflow orchestrator, and it is about to become the consolidated number two behind Airflow now that Dagster is folding into it. A Prefect deployment holds the credentials for everything it orchestrates: warehouse logins, cloud keys and API tokens stored as blocks, with workers that pull flow code from remote storage and execute it. Six advisories were published in the last twelve months, two of them high, which is real throughput for a project paying nothing. It is a target on no bounty platform, and its security policy documents a full triage and release process without a word about rewards. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for any security vulnerability privately through the repository's advisory workflow, and names a short explicit out-of-scope list. Everything below sits inside what it accepts The Prefect Server API in full: every REST route, the authentication layer in front of it, and the authorisation checks that separate one workspace or tenant from another The orchestration engine, covering flow and task run state transitions, retries, cancellation and the concurrency limit machinery Result storage and serialisation, including the pickle-backed result serializer and every path where a run reads back a result another run wrote Blocks in full: block registration, the credential and storage block types, secret handling, and how a block's contents reach a worker process Deployments and work pools, covering the pull steps that fetch flow code from git, S3 or another remote store before a run starts The worker and agent processes and the infrastructure integrations that launch runs on Docker, Kubernetes, ECS and Cloud Run The event and automation system, including triggers, webhooks that accept an inbound request, and the actions an automation can perform Artifacts, logs and flow run metadata, covering anything that renders content a flow produced The web UI and the API it talks to, including every place run or deployment metadata becomes rendered HTML The CLI, the client library and the profile and API key handling behind them Variables, the task-run cache and any shared state a flow can read that another flow wrote Out of scope Prefect Cloud, the hosted commercial product. This card covers the open-source package and self-hosted server The out-of-scope items the SECURITY.md lists by name; read that list before filing A flow author's own Python executing, which is the purpose of an orchestrator. The finding has to cross a boundary someone expected to hold A self-hosted server an operator deliberately exposed without authentication, which the documentation treats as an operator decision Third-party Prefect integration packages and community blocks the project does not maintain Upstream FastAPI, SQLAlchemy, Pydantic or Python dependency bugs, unless Prefect's own use of them is what makes the bug reachable Most-valued findings Authorisation defects on the Server API that cross a workspace or tenant boundary, since a single Prefect instance typically orchestrates several teams' pipelines and holds all of their credentials Anything that reads a block's secret contents without the authorisation the block was configured with. Blocks are where the warehouse passwords and cloud keys live, and that makes them the highest-value object in the system Deserialisation in the result storage path, where a run loads a pickled result from a store that another party can write to. This is the shortest route from data to execution on a worker Defects in deployment pull steps and work-pool code fetching, where a worker retrieves flow code from remote storage and runs it before anyone reviews it Authentication bypass on the API or in API key handling, particularly anywhere a key's scope is checked inconsistently between routes Server-side request forgery from webhooks, automation actions or any component that fetches a URL a deployment configuration sets Credential and secret leakage into logs, artifacts or flow run metadata, all of which are visible to more people than the block itself is Cross-site scripting in the UI where run metadata or an artifact a flow produced becomes rendered HTML beside an authenticated session Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Open a GitHub Security Advisory at github.com/PrefectHQ/prefect/security/advisories/new, the channel the SECURITY.md names. Private vulnerability reporting is enabled on the repository Do not open a public issue for a security bug; the policy rules that out explicitly There is no security email fallback published, so the advisory workflow is the whole intake Separate Prefect Server from Prefect Cloud. Cloud is the hosted commercial product; this card covers the open-source package and the server you run yourself Say whether the finding needs the API to be reachable and what authentication the target had configured, since a self-hosted server is frequently deployed with none Show the boundary that broke. A flow author writing Python that runs is what an orchestrator does, so the finding has to cross a tenant, workspace or privilege line The project has an explicit out-of-scope list in its SECURITY.md; read it before filing rather than after triage closes your report Disclosure Coordinated through GitHub's advisory workflow, with a documented process that runs triage, then a fix on a private branch, then a release, then publication. Six advisories in twelve months means the pipeline is exercised regularly and a reporter can expect it to move. Plan for an embargo running to the next release on PyPI rather than to a fixed day count. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability