MyOS2026 is an experimental operating system. Treat anything you run on it as untrusted by default, and do not deploy it to production. That caveat aside, the project takes security reports seriously and will work them through to a fix.

Please do not file a public GitHub issue. Use one of the private channels below.

1. GitHub Security Advisory (preferred): open a private report via the Security tab → "Report a vulnerability". This creates a private collaboration space where you, the maintainer, and any additional reviewers can scope the issue, develop a fix, and coordinate disclosure without exposing the report.
2. GitHub direct message to the maintainer (@mohnkhan) as a fallback if the Security Advisory flow is unavailable.

When you report, please include:

• A clear description of the vulnerability and its impact (what the attacker gains, what they need to start from).
• The kernel/userland commit SHA you reproduced on (git rev-parse HEAD).
• The image variant (make image, image-kasan, image-kassert, etc.) and the QEMU invocation.
• A minimal reproducer — ideally a small C program in the shape of tests/syscall_diff/corpus/, or a shell sequence inside nsh. Captured serial output (especially any panic/backtrace block) accelerates triage significantly.
• Whether you'd like to be credited in the advisory, and under what name/handle.

• Acknowledge within 7 days of receipt.
• Triage (confirm reproducibility, scope blast radius, decide severity) within 30 days.
• Fix and disclose on a timeline proportional to severity:
  • Severe (kernel memory-safety, sandbox escape, persistent privilege gain): targeted within 30 days of triage; coordinated disclosure with the reporter.
  • Moderate (POSIX-deviation that breaks an isolation boundary, leak of kernel pointers to userland): targeted within 60 days; standard advisory after fix lands.
  • Low (information leaks without isolation impact, advisory-only POSIX nits): rolled into normal feature work; no advisory required, but reporter is credited in the relevant PR.

If your timeline differs (academic-paper coordination, conference deadline, etc.) say so up front and we'll work to it.

MyOS2026 is pre-1.0 and changes shape rapidly. Only the master branch is "supported" in the security sense — fixes will land there. There are no maintained release branches. If you reproduce on a commit older than 90 days, please re-test on current master before reporting; the surface may already have changed.

In-scope (please report):

• Kernel memory safety: any out-of-bounds, use-after-free, double-free, or uninitialised-memory issue reachable from a syscall or device-driver input path. KASAN reports are particularly welcome (make image-kasan is the intended verification path).
• Syscall ABI safety: any syscall arg that, with valid permissions, can corrupt unrelated kernel state, escape the per-process address space, or panic the kernel from userland.
• Sandbox / sandboxed-process escapes: the sandbox binary is intended to confine an untrusted child; an escape that returns capabilities the parent didn't grant is in-scope.
• Verified-boot / hash-chain bypass: anything that allows booting a modified kernel without invalidating the BLAKE2b chain.
• Build pipeline integrity: ways to inject malicious content into a reproducible build that still produces the expected SHA-256.
• Network stack: any remote-trigger from a malformed packet on the test virtio-net interface (DoS-only is welcome but lower-severity).

Out-of-scope (please file as a normal issue instead):

• Bugs that crash the kernel with no security impact (these are normal bug reports; use the bug_report issue template).
• POSIX deviations without an isolation impact (the differential syscall harness in tests/syscall_diff/ is the right venue — propose adding a test case).
• Performance / DoS issues that require an already-privileged process inside the VM.
• Findings against third-party code shipped as part of userland (e.g. dropbear under userland/sshd/build/); those should go upstream first.

Once a fix lands on master, the GitHub Security Advisory will be published with:

• A description of the issue and its impact.
• The fix commit(s) and the affected commit range.
• Credit to the reporter (handle or anonymous, per their request).
• A CVE identifier where applicable (we'll request one via GitHub for in-scope issues with real-world impact).

We don't run a paid bug bounty.

A few defaults you should know about before testing:

• The kernel's kmsg ring (Feature 038) and panic infrastructure (Feature 046) include process state (PIDs, CR3, last syscall) in serial output. This is intentional for diagnosability; on a real deployment you'd disable serial-mirror or sanitise. The current ABI assumes a trusted host watching the serial port.
• getuid() currently returns 0 for every process; MyOS does not yet model UIDs per task. Permission gates that "should" check UID (e.g. /proc/<pid>/trace's caller-is-target rule) are currently structural, not enforced via a real user model. This is documented and intentional pre-1.0 — please don't file "any process can read another's trace flag" as a security bug; it's a known v1 limitation slated for the UID-model work.
• The default cloud-init config places an SSH dev key in the image. This is intended for the test harness only and is NOT a credential rotation issue.

Thanks for helping keep MyOS2026 safe.