How to Report a Vulnerability
Prepare Your Report
Include the following information:
- Description: Clear explanation of the vulnerability
- Reproduction Steps: Detailed steps to reproduce the issue
- Impact Assessment: Potential security impact and exploitability
- Affected Components: Kernel, userland, agent runtime, etc.
- Suggested Fix: (Optional) Proposed patch or mitigation
Send Encrypted Email
Email: [email protected]
Await Acknowledgment
You will receive an acknowledgment within 24 hours confirming receipt of your report.
Response Timeline (SLA)
Our response times are based on CVSS severity scores:| Action | Timeline |
|---|---|
| Acknowledgement of report | 24 hours |
| Initial triage and severity assessment | 72 hours |
| Fix for Critical (CVSS ≥ 9.0) | 7 days |
| Fix for High (CVSS 7.0–8.9) | 14 days |
| Fix for Medium (CVSS 4.0–6.9) | 30 days |
| Fix for Low (CVSS < 4.0) | 90 days |
| Public advisory published | Within 7 days of fix release |
These are target timelines. Complex vulnerabilities may require additional time. We will communicate any delays transparently.
Severity Assessment
We use the CVSS v3.1 calculator to determine severity scores. Critical (CVSS ≥ 9.0):- Kernel privilege escalation from userspace
- Remote code execution without authentication
- Complete sandbox escape from agent runtime
- Information disclosure of kernel memory
- Authentication bypass
- Denial of service affecting entire system
- Limited information disclosure
- Capabilities bypass with preconditions
- Localized denial of service
- Minor information leaks
- Theoretical attacks with no practical exploit
Coordinated Disclosure Policy
90-Day Disclosure Deadline
We follow industry-standard coordinated disclosure practices:- 90-day window: If a fix is not available within 90 days of the initial report, the reporter may disclose the vulnerability publicly.
- Early disclosure: We may request early disclosure if a vulnerability is actively exploited in the wild.
- Delayed disclosure: We may request additional time for complex fixes, subject to mutual agreement.
CVE Assignment
- We request CVE IDs via MITRE for all confirmed vulnerabilities rated Medium or above.
- CVE assignment typically occurs during the triage phase (within 72 hours).
- The CVE ID will be included in the public security advisory.
Public Advisory Format
Each security advisory includes:Advisory Metadata
Advisory Metadata
- CVE ID: CVE-YYYY-NNNNN
- CVSS Score: X.X (Severity)
- Affected Versions: Aurora OS vX.X.X through vY.Y.Y
- Fixed in Version: vZ.Z.Z
- Publication Date: YYYY-MM-DD
Vulnerability Description
Vulnerability Description
- Clear explanation of the vulnerability
- Attack vector and prerequisites
- Potential impact (confidentiality, integrity, availability)
Technical Details
Technical Details
- Root cause analysis
- Affected code location (file:line)
- Patch commit hash (e.g.,
git commit abc123def)
Mitigation Steps
Mitigation Steps
- Upgrade instructions
- Workarounds (if available)
- Configuration changes to reduce risk
Credits
Credits
- Reporter name(s) or handle(s)
- Affiliation (if applicable)
- Date of initial report
Security Scope
In Scope
The following are in scope for security vulnerability reports:Kernel Vulnerabilities
Kernel Vulnerabilities
- Memory corruption (buffer overflows, use-after-free, double-free)
- Privilege escalation (ring 3 → ring 0)
- Information disclosure (kernel memory leaks)
- Integer overflows in syscall parameter handling
- Race conditions in process/thread management
kernel/src/Agent Runtime Sandbox Escapes
Agent Runtime Sandbox Escapes
- Syscall filter bypass
- Capability token forgery
- Resource quota evasion
- IPC channel escape to unauthorized processes
- Filesystem access outside sandbox boundaries
userland/agent-runtime/WASM Runtime Security
WASM Runtime Security
- WASM sandbox escape to native code execution
- Browser sandbox bypass via kernel-wasm bridge
- Spectre-style side-channel attacks
- JIT compiler bugs allowing arbitrary code execution
wasm-runtime/bridge/kernel-wasm.cAuthentication/Authorization Bypasses
Authentication/Authorization Bypasses
Cryptographic Weaknesses
Cryptographic Weaknesses
- Module signature verification bypass
- KASLR entropy exhaustion or bias
- Stack canary predictability
- Update verification vulnerabilities
kernel/src/security/Supply Chain Attacks
Supply Chain Attacks
- Compromised build pipeline
- Malicious dependencies in release artifacts
- Backdoored kernel modules
Out of Scope
The following are out of scope and should not be reported as security vulnerabilities:-
Denial of Service via Resource Exhaustion: Unless the attack is trivially exploitable (e.g., single malformed packet crashes the kernel).
- Example: Slowly exhausting memory by allocating small chunks is not in scope.
- Example: Instant kernel panic via malformed TCP packet is in scope.
- Physical Access Attacks: Issues requiring physical access to hardware (e.g., DMA attacks, cold boot attacks, BIOS modifications).
- Social Engineering: Attacks that rely on tricking users into running malicious code.
-
Third-Party Dependency Vulnerabilities: Security issues in upstream libraries (e.g., GCC, Clang, libc).
- Action: Report these vulnerabilities to the upstream project.
- Notify Us: We appreciate a heads-up so we can track the issue and plan upgrades.
Security Hall of Fame
We maintain a public hall of fame to recognize security researchers who responsibly disclose vulnerabilities. Credit Policy:- Reporters are credited by name (or handle) in the security advisory.
- Affiliation and social media links may be included (with permission).
- Reporters may request anonymity if preferred.
(To be published on aurora-os.dev/security/hall-of-fame)
Bug Bounty Program
Status: To be determined
A bug bounty program is under consideration for post-v1.0 releases. Check
A bug bounty program is under consideration for post-v1.0 releases. Check
docs/security.md for updates.- Critical vulnerabilities: Kernel privilege escalation, RCE, sandbox escape
- High vulnerabilities: Authentication bypass, significant information disclosure
- Exclusions: Third-party dependencies, social engineering, physical attacks
Responsible Disclosure Examples
Example 1: Kernel Memory Leak
Report:“TheOur Response:sys_read()syscall inkernel/src/proc/syscall.c:245does not zero the kernel buffer before copying data to userspace. This allows unprivileged processes to read up to 4KB of uninitialized kernel memory.”
- Acknowledged within 24 hours (CVSS 6.5, Medium)
- Triaged and confirmed within 72 hours
- Patch developed and tested within 14 days
- CVE-2026-11111 assigned
- Public advisory published 7 days after v0.2.1 release
- Reporter credited as “Alice Smith (@asmith)“
Example 2: Sandbox Escape
Report:“The agent runtime syscall filter can be bypassed by invoking syscall number -1, which wraps around the bitmap index. This allows agents to execute arbitrary syscalls.”Our Response:
- Acknowledged within 24 hours (CVSS 9.3, Critical)
- Triaged and confirmed within 48 hours
- Emergency patch deployed within 5 days
- CVE-2026-22222 assigned
- Public advisory published immediately after fix
- Reporter credited as “Anonymous Researcher (requested anonymity)“
Frequently Asked Questions
Can I test for vulnerabilities on production systems?
Can I test for vulnerabilities on production systems?
No. Only test on your own systems or with explicit written permission from the system owner.For Aurora OS development:
- Use local VMs or bare-metal test machines
- Do not test on shared infrastructure
What if I accidentally triggered a vulnerability?
What if I accidentally triggered a vulnerability?
If you discover a vulnerability during normal use (without intentional testing), please report it responsibly. We will not take legal action against good-faith security research.
Can I publish a blog post about the vulnerability?
Can I publish a blog post about the vulnerability?
Yes, after the coordinated disclosure period ends (either 90 days or upon mutual agreement for early release). We encourage detailed technical write-ups and will link to them from our advisory.
What if I disagree with the severity assessment?
What if I disagree with the severity assessment?
We are open to discussion. If you believe our CVSS score is incorrect, please provide your reasoning and we will reassess.
Do you offer legal safe harbor for security researchers?
Do you offer legal safe harbor for security researchers?
Yes. We will not pursue legal action against security researchers who:
- Report vulnerabilities in good faith
- Do not exploit vulnerabilities beyond proof-of-concept
- Do not access or exfiltrate user data
- Follow our coordinated disclosure policy
Contact Information
Email: [email protected]PGP Key: To be published before v1.0 GA
Expected Response Time: 24 hours for acknowledgment
References
- CVSS v3.1 Calculator
- MITRE CVE Request Form
- Google Project Zero Disclosure Policy
- HackerOne Disclosure Guidelines
- CERT Coordinated Vulnerability Disclosure
Related Documentation
- Security Overview — Security architecture and hardening features
- Threat Model — Attack surfaces and security assumptions
- SECURITY.md — Full security policy