Skip to main content
We take security seriously and appreciate responsible disclosure of vulnerabilities. This page documents our vulnerability reporting process, response timelines, and coordinated disclosure policy.

How to Report a Vulnerability

1

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
2

Send Encrypted Email

Email: [email protected]
For sensitive disclosures, encrypt your report with our PGP public key (published before v1.0 GA).
-----BEGIN PGP PUBLIC KEY BLOCK-----
(PGP key to be generated and published before v1.0 GA)
-----END PGP PUBLIC KEY BLOCK-----
3

Await Acknowledgment

You will receive an acknowledgment within 24 hours confirming receipt of your report.
4

Coordinated Disclosure

We will work with you to:
  • Validate the vulnerability
  • Develop and test a fix
  • Coordinate public disclosure timing
  • Credit you in the security advisory (unless you request anonymity)

Response Timeline (SLA)

Our response times are based on CVSS severity scores:
ActionTimeline
Acknowledgement of report24 hours
Initial triage and severity assessment72 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 publishedWithin 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
High (CVSS 7.0–8.9):
  • Information disclosure of kernel memory
  • Authentication bypass
  • Denial of service affecting entire system
Medium (CVSS 4.0–6.9):
  • Limited information disclosure
  • Capabilities bypass with preconditions
  • Localized denial of service
Low (CVSS < 4.0):
  • 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:
  • 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
  • Clear explanation of the vulnerability
  • Attack vector and prerequisites
  • Potential impact (confidentiality, integrity, availability)
  • Root cause analysis
  • Affected code location (file:line)
  • Patch commit hash (e.g., git commit abc123def)
  • Upgrade instructions
  • Workarounds (if available)
  • Configuration changes to reduce risk
  • Reporter name(s) or handle(s)
  • Affiliation (if applicable)
  • Date of initial report
Example Advisory:
# Aurora OS Security Advisory: CVE-2026-12345

**CVSS Score:** 8.8 (High)  
**Affected Versions:** Aurora OS v0.1.0 through v0.3.2  
**Fixed in Version:** v0.3.3  
**Publication Date:** 2026-03-15

## Summary
A stack-based buffer overflow in the syscall handler allows local attackers
to execute arbitrary code with kernel privileges.

## Technical Details
**Root Cause:** Missing bounds check in `kernel/src/proc/syscall.c:187`  
**Patch Commit:** `a1b2c3d4e5f6789012345678901234567890abcd`

## Mitigation
Upgrade to Aurora OS v0.3.3 or later.

## Credits
- Discovered by: Jane Doe (@jdoe)
- Reported: 2026-01-10

Security Scope

In Scope

The following are in scope for security vulnerability reports:
  • 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
Reference: kernel/src/
  • Syscall filter bypass
  • Capability token forgery
  • Resource quota evasion
  • IPC channel escape to unauthorized processes
  • Filesystem access outside sandbox boundaries
Reference: userland/agent-runtime/
  • 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
Reference: wasm-runtime/bridge/kernel-wasm.c
  • MAC policy violations
  • Capability token verification bypass
  • Privilege escalation via syscall confusion
  • Module signature verification bypass
  • KASLR entropy exhaustion or bias
  • Stack canary predictability
  • Update verification vulnerabilities
Reference: kernel/src/security/
  • 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.
If you are unsure whether an issue is in scope, please report it anyway. We will triage and provide guidance.

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.
Hall of Fame:
(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 docs/security.md for updates.
Potential scope for future bug bounty:
  • 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:
“The sys_read() syscall in kernel/src/proc/syscall.c:245 does not zero the kernel buffer before copying data to userspace. This allows unprivileged processes to read up to 4KB of uninitialized kernel memory.”
Our Response:
  1. Acknowledged within 24 hours (CVSS 6.5, Medium)
  2. Triaged and confirmed within 72 hours
  3. Patch developed and tested within 14 days
  4. CVE-2026-11111 assigned
  5. Public advisory published 7 days after v0.2.1 release
  6. 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:
  1. Acknowledged within 24 hours (CVSS 9.3, Critical)
  2. Triaged and confirmed within 48 hours
  3. Emergency patch deployed within 5 days
  4. CVE-2026-22222 assigned
  5. Public advisory published immediately after fix
  6. Reporter credited as “Anonymous Researcher (requested anonymity)“

Frequently Asked Questions

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
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.
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.
We are open to discussion. If you believe our CVSS score is incorrect, please provide your reasoning and we will reassess.

Contact Information

Email: [email protected]
PGP Key: To be published before v1.0 GA
Expected Response Time: 24 hours for acknowledgment
Do not report security vulnerabilities via GitHub issues, Discord, or other public channels. Use the [email protected] email address.

References


Build docs developers (and LLMs) love