- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 1
- 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 | Relative size | 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, 5 excluded.
Web 1
- https://apparmor.net
Products and areas 12
- AppArmor publishes three private intake channels and asks that none of them be public: a GitLab issue marked confidential, which is the preferred route, a Launchpad bug set to Private Security, or the security address that forwards to the team rather than to a public list. No part of the userspace tree is carved out
- Mediation rules as the userspace expresses them, covering mount, pivot_root, unix socket, network, ptrace, signal and dbus
- Profile abstractions and the include mechanism, along with the abstractions shipped by the project
- Profile transitions in full: exec transitions, hats, profile stacking and the fallbacks to unconfined
- The compiled policy cache, its invalidation logic and the files written under the cache directory
- The D-Bus mediation path and the bus name, path and interface matching behind it
- The libapparmor library, including its log parsing and its change_hat and change_profile interfaces
- The policy compiler (apparmor_parser) end to end, from profile text through to the policy loaded into the kernel
- The profile generation paths that snapd, LXD and container tooling build on top of
- The profile language itself: variables, globbing, path rules, aliases, rule precedence and the deny semantics
- The profiles shipped by the project for common daemons
- The utilities: aa-genprof, aa-logprof, aa-complain, aa-enforce and aa-status, plus the Python and Perl code behind them
Out of scope (5)
- A permissive profile an administrator or a distribution wrote deliberately
- Applications running unconfined because no profile exists for them, which is a packaging decision rather than an AppArmor defect
- Confinement policy authored by LXD, Incus or snapd rather than AppArmor's enforcement of it
- Distribution-specific profile sets rather than the profiles in the upstream tree
- The in-kernel AppArmor LSM, which belongs to the Linux kernel security process
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Never open a public GitLab issue or an ordinary Launchpad bug for a security finding
-
Say whether the defect is in the userspace tree or in the in-kernel LSM.
-
Show the profile source alongside the compiled policy.
-
Name the distribution and the profile set.
-
If the impact lands on a downstream consumer, say so.
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2017-6507 | An issue was discovered in AppArmor before 2.12. Incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to the common logic to handle 'restart' operations removing AppArmor profiles that aren't found in the | Medium 5.9 | 24 Mar 2017 |
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 AppArmor is the mandatory access control layer switched on by default in Ubuntu, Debian and SUSE, and it is the confinement backend that LXD, Incus, LXC, snapd and Firejail all build on. Its profiles are what stand between a compromised service and the rest of the host. Advisory volume is low and blast radius is high: a parser or policy-compilation defect means every profile generated above it confines less than its author believed. Canonical states in writing that it does not pay for bug reports in its software, and no bounty exists on the SUSE or community side either. sorona.xyz pays you directly on qualified, reproduced findings. In scope AppArmor publishes three private intake channels and asks that none of them be public: a GitLab issue marked confidential, which is the preferred route, a Launchpad bug set to Private Security, or the security address that forwards to the team rather than to a public list. No part of the userspace tree is carved out The policy compiler (apparmor_parser) end to end, from profile text through to the policy loaded into the kernel The profile language itself: variables, globbing, path rules, aliases, rule precedence and the deny semantics Profile abstractions and the include mechanism, along with the abstractions shipped by the project The libapparmor library, including its log parsing and its change_hat and change_profile interfaces Profile transitions in full: exec transitions, hats, profile stacking and the fallbacks to unconfined Mediation rules as the userspace expresses them, covering mount, pivot_root, unix socket, network, ptrace, signal and dbus The D-Bus mediation path and the bus name, path and interface matching behind it The utilities: aa-genprof, aa-logprof, aa-complain, aa-enforce and aa-status, plus the Python and Perl code behind them The compiled policy cache, its invalidation logic and the files written under the cache directory The profiles shipped by the project for common daemons The profile generation paths that snapd, LXD and container tooling build on top of Out of scope The in-kernel AppArmor LSM, which belongs to the Linux kernel security process A permissive profile an administrator or a distribution wrote deliberately Applications running unconfined because no profile exists for them, which is a packaging decision rather than an AppArmor defect Distribution-specific profile sets rather than the profiles in the upstream tree Confinement policy authored by LXD, Incus or snapd rather than AppArmor's enforcement of it Most-valued findings Anything that compiles a profile into a policy weaker than its text describes. That defect propagates to every profile on every host that compiled it, which is what makes low advisory volume misleading here Path resolution and globbing errors in the parser, where a rule matches more paths than written or a denied path is reachable through an alternate spelling Profile transition defects, particularly a transition that lands in a less confined profile or in unconfined Mediation gaps on mount, ptrace or unix socket rules, where an operation the profile denies is permitted anyway Cache handling, including compiled policy loaded from a cache file that no longer matches its profile source Privilege escalation through the tooling, since several utilities run as root while parsing files a less privileged user can influence Memory safety in apparmor_parser or libapparmor, reachable from profile text or from log data Anything that weakens the container confinement profiles LXD, Incus and LXC generate, since one parser bug degrades every container on the host 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 through one of the three documented private channels: a GitLab issue with the confidential box ticked, which the project prefers, a Launchpad bug set to Private Security, or [email protected] The security address forwards to the security team and explicitly not to a public list, so it is a genuine private channel rather than a mailing list with an unfortunate name Never open a public GitLab issue or an ordinary Launchpad bug for a security finding Say whether the defect is in the userspace tree or in the in-kernel LSM. The kernel side belongs to the Linux kernel security process and will be redirected Show the profile source alongside the compiled policy. On this codebase the gap between what a profile says and what it enforces is the finding Name the distribution and the profile set. Ubuntu, Debian and SUSE ship different profiles and different parser versions If the impact lands on a downstream consumer, say so. LXD, Incus, snapd and Firejail all generate profiles on top of this parser and inherit anything it gets wrong Disclosure Coordinated privately with the AppArmor security team through whichever of the three channels was used, with fixes landing in the upstream tree and then in the Ubuntu, Debian and SUSE package streams. Canonical's own disclosure and embargo policy governs its side of the coordination. Distributions ship AppArmor by default, so the practical embargo runs to the coordinated package release 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