openEuler

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Discretionary, set by the openEuler Security Committee; no readable grid │ not published │ not published Submit a vulnerability CVE history 0 Last 12 months 18 Lifetime Latest advisories Loading the feed Overview openEuler is an enterprise Linux distribution with an unusual amount of first-party code around it: rather than only packaging other people's software, the project authors its own container runtime (iSulad), its own Rust virtualisation platform (StratoVirt), a confidential-computing SDK (secGear), a performance-tuning service (A-Tune), a package dependency service (pkgship), a cluster deployment tool (eggo) and a container-oriented OS (KubeOS), all under the OSI-approved MulanPSL-2.0. Those native projects are exactly what the bounty scopes: upstream dependencies packaged into the distribution are excluded. The cash pathway itself is explicit: the openEuler Security Committee confirms validity, severity and the amount with the reporter by email, and Vulbox handles the payment. The amount is where the published detail stops. The reward table on Vulbox is a hosted image whose host now returns an empty reply, the detailed rules sit behind the SRC portal's login wall, and the newest published scope document still names openEuler-20.03-LTS-SP3 and 22.03-LTS, releases that are years stale by 2026. openEuler.org's own security page, refreshed in July 2026, mentions no bounty at all, only the [email protected] inbox. Treat this as live but dormant, with no published ladder to work toward. sorona.xyz adds 1.25× on top of whatever openEuler awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The scope document, version 4.0, names seven openEuler-native MulanPSL-2.0 projects and stops there: iSulad, A-Tune, secGear, StratoVirt, pkgship, eggo and KubeOS. Upstream dependencies packaged into the distribution sit outside it iSulad in full: the daemon, its CRI implementation, image and storage handling, and the container isolation it is responsible for holding StratoVirt in full: the virtual machine monitor, its device emulation and virtio implementations, the machine models and the management interface secGear in full: the confidential-computing SDK, the enclave entry and exit surface, and the host-side interfaces generated around it A-Tune in full: the tuning daemon, its client, and the collectors and models that drive a privileged reconfiguration of the system pkgship and eggo in full: the package dependency service with its HTTP API, and the cluster deployment tool with its bootstrap and certificate handling KubeOS in full: the container-oriented node operating system, its operator, its upgrade path and the image build tooling behind it The distribution releases the published scope document actually names, openEuler-20.03-LTS-SP3 and 22.03-LTS Out of scope Upstream dependencies packaged into the distribution rather than written for it, because the scope document covers openEuler-native MulanPSL-2.0 projects only, so a defect in a component another project maintains belongs upstream Anything outside the seven named native projects, however central it looks to the distribution Releases the published scope document does not name; it still lists only openEuler-20.03-LTS-SP3 and 22.03-LTS, both years stale by 2026 Findings the openEuler Security Committee does not confirm by email as valid, since that confirmation is what creates a payable amount at all Submissions from an account that has not completed the platform's identity verification, which comes before the submission step Most-valued findings A container escape out of iSulad, the highest-consequence class in this scope: the runtime's entire job is the isolation boundary, and breaking it turns one workload into every workload on the host A guest-to-host escape through StratoVirt's device emulation, the virtualisation equivalent of the same argument and the case a multi-tenant operator cannot mitigate around A break of the secGear enclave boundary that exposes or tampers with data the confidential-computing model exists to protect, since a confidential-computing SDK with a boundary bug provides no property at all Local privilege escalation through A-Tune, pkgship, eggo or KubeOS, all of which run with elevated rights on behalf of an administrator and several of which act across a whole cluster Findings in code openEuler itself authored rather than packaged, because the scope document draws that line explicitly and an upstream bug will not be paid here no matter how severe Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. There is no published reward table. The grid image is dead and the rules page is login-gated, so you are agreeing the amount after the fact rather than working toward a known number Validity, severity and the reward amount are confirmed with you by email by the openEuler Security Committee; Vulbox executes the payout only after that confirmation Scope is limited to openEuler-native MulanPSL-2.0 projects: iSulad, A-Tune, secGear, StratoVirt, pkgship, eggo and KubeOS. Upstream dependencies packaged into the distribution are excluded Identity verification is required by the platform before you can submit, so there is no anonymous route to payment here Read the per-asset conditions from inside the SRC portal before starting work: the published rules page is behind a login and nothing about prohibited testing is readable from outside it Ignore the launch promotion. The only amount ever published in plain text was an extra ￥2,000 for each of the first ten vulnerabilities, and that offer has lapsed Disclosure Mediated by two parties: the openEuler Security Committee decides whether the finding is valid and what it is worth, and Vulbox handles the money. Hold the detail until the program confirms a fix has shipped and you are clear to publish. 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