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

Julia

Bug bounty on Sorona julialang.org

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
12
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

12 assets you may test, 6 excluded.

Web 1

  • https://julialang.org

Products and areas 11

  • Base itself: string handling, array indexing, arithmetic and the unsafe_ family that deliberately leaves the checked subset
  • Distributed and the cluster machinery, which moves serialised work between processes and hosts
  • Pkg, the package manager, and everything it does with a registry: resolution, download, artifact verification and precompilation
  • Serialisation and deserialisation across the standard library, covering Serialization, the package precompilation cache and any format that reconstructs objects from bytes
  • The binary artifacts and JLL packages the distribution pulls in, and the verification applied to them
  • The ccall and foreign-function boundary, where the safety guarantees stop
  • The JIT and the LLVM lowering path, where a miscompilation can drop a bounds check the language guarantees
  • The published security policy asks for vulnerabilities by email to the project's security address and states that the LTS and current stable releases receive security updates. It declares no component boundary, so the Julia distribution as shipped is the target
  • The REPL and the code-loading path behind include, using and import
  • The runtime written in C and C++, including the garbage collector, the task scheduler and the threading implementation
  • The standard library networking and cryptography modules and the C libraries they bind to
Out of scope (6)
  • Findings that reproduce only on a nightly build or on a release outside the supported LTS and stable window
  • JuliaHub and other commercial services built on the language, which are separate products
  • LLVM itself, as distinct from Julia's use of it
  • Registered Julia packages, unless Pkg's handling of them is what makes the defect reachable
  • Running untrusted Julia source deliberately, since the language ships no sandbox and claims none
  • The unsafe_ family behaving as documented. Those functions exist to skip checks, and skipping them is the contract

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.
  • Email the address on the policy page , the address the repository's published security policy names
  • Say whether the bug is in the runtime, in the compiler or in a standard library module, and whether Base or an stdlib is involved
  • Show how attacker-controlled data reaches the defect.
  • For a Pkg finding, state whether the malicious input is a registry entry, an artifact, a package tarball or a precompilation step
  • Hold detail until patched releases are out on both supported branches.

Not accepted

  • The unsafe_ family behaving as documented
  • Running untrusted Julia source deliberately
  • Findings that reproduce only on a nightly build or on a release outside the supported LTS and stable window

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-2025-52480 High 8.1 25 Jun 2025
CVE-2025-52483 High 8.1 25 Jun 2025
CVE-2021-4048 Critical 9.1 8 Dec 2021

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 Latest advisories Loading the feed Overview Julia is a JIT-compiled language for numerical work, and the places it runs matter: national labs, pharmaceutical modelling, quantitative finance and academic research, on data and results that feed real decisions. The project markets itself on memory safety against US national-security software standards, so an unpatched memory-safety defect in its own C and C++ runtime is an expensive thing to have. No advisory has been published on the GitHub repository, so there is no reference CVE and no map of where the bugs are. Reports go to [email protected] , and the policy mentions no reward of any kind. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published security policy asks for vulnerabilities by email to the project's security address and states that the LTS and current stable releases receive security updates. It declares no component boundary, so the Julia distribution as shipped is the target The runtime written in C and C++, including the garbage collector, the task scheduler and the threading implementation The JIT and the LLVM lowering path, where a miscompilation can drop a bounds check the language guarantees Serialisation and deserialisation across the standard library, covering Serialization , the package precompilation cache and any format that reconstructs objects from bytes Base itself: string handling, array indexing, arithmetic and the unsafe_ family that deliberately leaves the checked subset Pkg , the package manager, and everything it does with a registry: resolution, download, artifact verification and precompilation The standard library networking and cryptography modules and the C libraries they bind to The ccall and foreign-function boundary, where the safety guarantees stop Distributed and the cluster machinery, which moves serialised work between processes and hosts The REPL and the code-loading path behind include , using and import The binary artifacts and JLL packages the distribution pulls in, and the verification applied to them Out of scope Registered Julia packages, unless Pkg 's handling of them is what makes the defect reachable LLVM itself, as distinct from Julia's use of it Findings that reproduce only on a nightly build or on a release outside the supported LTS and stable window The unsafe_ family behaving as documented. Those functions exist to skip checks, and skipping them is the contract Running untrusted Julia source deliberately, since the language ships no sandbox and claims none JuliaHub and other commercial services built on the language, which are separate products Most-valued findings Memory-safety defects in the C and C++ runtime, in the garbage collector and at the ccall boundary. The project's public argument for itself is memory safety, so heap corruption in its own runtime is the finding it can least afford Deserialisation reaching code execution, through Serialization , a precompilation cache or a package artifact. Scientific pipelines pass serialised objects between machines constantly Supply-chain defects in Pkg : registry handling, artifact verification, or any path where installing or precompiling a package executes something it should not JIT miscompilation that drops a bounds check, since array safety is a language-level promise the compiler has to keep Defects in Distributed where a worker accepts and executes work from an unauthenticated peer, given how routinely these workloads span a cluster Anything in the standard library that parses an untrusted file format, since data volume is what these workloads are made of There is no published advisory record to prioritise against, so treat the whole runtime as unmapped rather than reading a pattern into an empty list 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. Email [email protected] , the address the repository's published security policy names Security updates cover the LTS release and the current stable release. A finding that only reproduces on an older release or on a nightly build sits outside that window Say whether the bug is in the runtime, in the compiler or in a standard library module, and whether Base or an stdlib is involved Show how attacker-controlled data reaches the defect. Much Julia code runs on trusted local input, so the reports that land start from a file, a network response or a serialised object For a Pkg finding, state whether the malicious input is a registry entry, an artifact, a package tarball or a precompilation step There is no bounty. The policy mentions no reward at any severity Disclosure Coordinated by email with the security team and published against fixed releases on the supported branches, the LTS and the current stable. The project has no GitHub advisory record to read a cadence from, so agree the disclosure date in the thread rather than assuming a day count. Hold detail until patched releases are out on both supported branches. 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