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

Istio

Bug bounty on Sorona istio.io

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
14
Public CVEs
29
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.
Replies within 3 days
As the policy promises.
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
Response
Within 3 days The published process acknowledges within three working days
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

14 assets you may test, 6 excluded.

Web 1

  • https://istio.io

Products and areas 13

  • AuthorizationPolicy, RequestAuthentication and PeerAuthentication evaluation, including path, header, method and principal matching and the interaction between ALLOW, DENY and CUSTOM actions
  • Gateway API support alongside the Gateway, VirtualService and DestinationRule resources, and the route matching each drives
  • istioctl and the debug and status endpoints istiod exposes about mesh configuration
  • istiod, the control plane, and the xDS configuration it computes and pushes to every proxy
  • Multicluster deployments, trust domain federation, the east-west gateways and the remote secrets that let one cluster read another's endpoints
  • Telemetry and tracing configuration, and the headers and metadata each adds to a request
  • The ambient dataplane in full: ztunnel, the waypoint proxies, HBONE tunnelling and the policy enforcement point in each
  • The CNI plugin and the traffic redirection it installs on the node
  • The Envoy configuration Istio generates, the filters it enables, the extension provider mechanism and WASM extension loading
  • The JWT validation path and the mapping from token claims to request principals and to policy conditions
  • The published process asks for private reports to the Istio security mailing list and declares no boundary narrower than the Istio project. Everything below sits inside that
  • The sidecar injection webhook and every field of the pod specification it produces, including the init container and the iptables rules it installs
  • Workload identity issuance: the certificate authority istiod runs, the SDS path to each proxy, the SPIFFE identities it mints and the trust domain behind them
Out of scope (6)
  • An AuthorizationPolicy an operator wrote that is simply more permissive than intended
  • Envoy upstream, a separate project with its own security process and a Google Patch Rewards pathway, unless Istio's configuration of it is what makes the defect reachable
  • Kubernetes itself and the container runtime beneath the mesh
  • The applications inside the mesh
  • Third-party WASM extensions and external authorization services the mesh is configured to call
  • Vendor distributions of Istio, which have their own advisory streams

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz.
  • Do not open a public GitHub issue or raise it in the community Slack.
  • Give the full policy set in YAML, the workload identities on both sides and the request that reproduces it.
  • Say whether the deployment used sidecars or the ambient dataplane.
  • If the defect lives in Envoy rather than in Istio's configuration of it, say so.

Not accepted

  • An AuthorizationPolicy an operator wrote that is simply more permissive than intended
  • Vendor distributions of Istio, which have their own advisory streams
  • Third-party WASM extensions and external authorization services the mesh is configured to call
  • The applications inside the mesh

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-111497 Critical 9.2 22 Oct 2026
CVE-2026-41413 Medium 5.0 7 May 2026
CVE-2026-39350 Medium 5.4 15 Apr 2026
CVE-2026-31837 High 8.7 10 Mar 2026
CVE-2026-31838 Medium 6.9 10 Mar 2026
CVE-2023-44487 High 7.5 10 Oct 2023
CVE-2022-39388 High 7.6 10 Nov 2022
CVE-2022-39278 High 7.5 13 Oct 2022
CVE-2022-31045 High 7.0 9 Jun 2022
CVE-2022-24726 High 7.5 10 Mar 2022
CVE-2022-23635 High 7.5 22 Feb 2022
CVE-2022-21701 Medium 5.0 19 Jan 2022
CVE-2022-21679 Medium 6.8 19 Jan 2022
CVE-2021-39156 High 8.1 24 Aug 2021
CVE-2021-39155 High 8.3 24 Aug 2021
CVE-2021-34824 High 8.8 29 Jun 2021
CVE-2021-31921 Critical 9.8 2 Jun 2021
CVE-2021-31920 Medium 6.5 27 May 2021
CVE-2019-25014 Medium 6.5 29 Jan 2021
CVE-2020-16844 Medium 6.8 1 Oct 2020
CVE-2020-10739 High 7.5 2 Jun 2020
CVE-2020-11767 Low 3.1 15 Apr 2020
CVE-2020-8843 High 7.4 14 Feb 2020
CVE-2020-8595 High 7.3 12 Feb 2020
CVE-2019-18817 High 7.5 12 Nov 2019
CVE-2019-18836 High 7.5 11 Nov 2019
CVE-2019-14993 High 7.5 13 Aug 2019
CVE-2019-12995 High 7.5 28 Jun 2019
CVE-2019-12243 High 7.5 5 Jun 2019

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 4 Last 12 months 13 Lifetime Policy bypass 40 % Auth bypass 25 % Identity confusion 20 % Info disclosure 15 % Latest advisories Loading the feed Overview Istio is the standard service mesh in enterprise Kubernetes. Its sidecars and ambient dataplane sit in the path of every service-to-service call in the cluster, and its control plane issues the workload identities and mutual TLS certificates those calls authenticate with. Authorization policy in Istio is frequently the only thing separating two services, so a policy-evaluation or request-parsing defect removes that separation without changing any configuration an operator would think to inspect. Istio's reports go to a private Google Group and the project pays nothing at any severity. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published process asks for private reports to the Istio security mailing list and declares no boundary narrower than the Istio project. Everything below sits inside that istiod, the control plane, and the xDS configuration it computes and pushes to every proxy AuthorizationPolicy, RequestAuthentication and PeerAuthentication evaluation, including path, header, method and principal matching and the interaction between ALLOW, DENY and CUSTOM actions The JWT validation path and the mapping from token claims to request principals and to policy conditions Workload identity issuance: the certificate authority istiod runs, the SDS path to each proxy, the SPIFFE identities it mints and the trust domain behind them The sidecar injection webhook and every field of the pod specification it produces, including the init container and the iptables rules it installs The ambient dataplane in full: ztunnel, the waypoint proxies, HBONE tunnelling and the policy enforcement point in each The Envoy configuration Istio generates, the filters it enables, the extension provider mechanism and WASM extension loading Gateway API support alongside the Gateway, VirtualService and DestinationRule resources, and the route matching each drives The CNI plugin and the traffic redirection it installs on the node Multicluster deployments, trust domain federation, the east-west gateways and the remote secrets that let one cluster read another's endpoints Telemetry and tracing configuration, and the headers and metadata each adds to a request istioctl and the debug and status endpoints istiod exposes about mesh configuration Out of scope Envoy upstream, a separate project with its own security process and a Google Patch Rewards pathway, unless Istio's configuration of it is what makes the defect reachable Kubernetes itself and the container runtime beneath the mesh An AuthorizationPolicy an operator wrote that is simply more permissive than intended Vendor distributions of Istio, which have their own advisory streams Third-party WASM extensions and external authorization services the mesh is configured to call The applications inside the mesh Most-valued findings Authorization policy bypass, any request that reaches a workload a policy denies. Path normalisation and header handling differences between the proxy and the application are the recurring route to this JWT validation defects in RequestAuthentication, where an unsigned, expired, wrongly-audienced or wrongly-issued token yields a request principal a policy then honours Identity issuance defects, where a workload obtains a certificate for a service account it does not run under. Every mTLS-based policy in the mesh rests on that binding Sidecar injection and CNI redirection paths that let a pod escape interception entirely, since an uninterceptable pod is outside all policy ztunnel and waypoint handling in the ambient dataplane, the newest enforcement path in the project and correspondingly the least examined xDS computation where a resource in one namespace influences the configuration pushed to another namespace's proxies, which crosses the cluster's tenancy boundary Trust domain and multicluster federation defects that let identities from one cluster or mesh be accepted in another The istiod debug and status endpoints reachable from inside the cluster, which describe the whole mesh's configuration including its policies Anything that downgrades a connection from mutual TLS to plaintext without the policy noticing, since PeerAuthentication in permissive mode is extremely common 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. Report by email to the private list [email protected] . The published process acknowledges within three working days Do not open a public GitHub issue or raise it in the community Slack. Istio maintains a private early-disclosure list for partners and coordinates through it Nothing is paid at any severity. The process offers acknowledgement and triage, and there is nothing to negotiate Give the full policy set in YAML, the workload identities on both sides and the request that reproduces it. Policy findings turn entirely on how a principal and a request were matched Say whether the deployment used sidecars or the ambient dataplane. ztunnel and waypoint proxies are a different enforcement path from the sidecar one and a finding on one may not exist on the other If the defect lives in Envoy rather than in Istio's configuration of it, say so. Envoy has its own security process and a separate reward pathway, so misrouting it wastes the embargo Disclosure Coordinated privately with the Istio product security working group, which acknowledges within three working days, notifies a private early-disclosure list of partners and distributors, then publishes an advisory on istio.io alongside patched releases across supported minor versions. The embargo runs to that coordinated release rather than to a day count you choose. 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