Vulnerability disclosure
Found a security issue in ShadowStrike Phantom? Tell us privately. We will confirm it, fix it, and agree a disclosure date with you.
- Report to
- contact@shadowstrike.dev
- Subject
- [SECURITY] Brief description
- Encryption
- PGP key on request
01How to report
Privately, by email.
Please do not open a public issue, discussion or pull request for a vulnerability. Email contact@shadowstrike.dev with a subject line that starts with [SECURITY]. For an exploitable kernel issue, ask for our PGP key before sending the details.
A useful report includes:
- What the issue is and what an attacker could do with it
- The affected files and line numbers, or the page on this website
- The class of bug, for example a pool overflow, use-after-free, race condition, privilege escalation or logic error
- Steps to reproduce or a proof of concept; a walkthrough of the code is enough where no binary exists
- Your assessment of severity, and whether you intend to publish
- The name or handle you would like credited, if any
02Timelines
What happens after you report.
| Acknowledgement | Within 72 hours |
|---|---|
| Initial assessment | Within 7 days |
| Fix: critical or high | Target 14 days |
| Fix: medium | Target 30 days |
| Fix: low | Normal development cycle |
These are best-effort targets for a project in alpha. If a fix needs longer, we will say so and agree a new timeline with you rather than go quiet. If you have not heard back within 72 hours, please send a follow-up.
03Disclosure
Coordinated, with a 90-day window.
We ask for 90 days from acknowledgement before public disclosure. If a fix lands sooner, we agree a date together; if it cannot be fixed in time, we explain why and negotiate an extension.
We will never ask you to suppress a report indefinitely. Kernel vulnerabilities that are already being exploited get an accelerated timeline, and you are credited in the advisory unless you ask to remain anonymous.
04Scope
What the policy covers.
In scope
- Kernel-mode code: memory corruption, IRQL violations, races in callbacks, integer overflows in allocation sizes
- Ways to unload, patch, blind or otherwise bypass the sensor’s self-protection
- Privilege escalation through any Phantom component
- The channel between kernel and user mode, and the Windows service
- The update pipeline
- Detection bypasses with broad, real-world applicability
Out of scope
- Vulnerabilities in vendored third-party libraries; please report those upstream
- Bypasses that already require kernel-level access
- Theoretical issues with no plausible attack path
- Denial of service against a single isolated test machine
- Missing features that are already planned
- Social engineering, physical access, and GitHub’s own infrastructure
Not sure whether something is in scope? Email anyway; we would rather review an out-of-scope report than miss a real one.
Reports about this website are welcome through the same address. Please do not run automated scanners or load tests against it.
05Safe harbour
Good-faith research is welcome.
Research on the ShadowStrike Phantom codebase carried out under this policy is considered authorised, and we will not take legal action against researchers who act in good faith: who report privately, touch no more data than needed to demonstrate the issue, stop at a proof of concept, and wait for the agreed disclosure date.
06Recognition
Credit, not bounties.
There is no paid bug bounty. Researchers are credited in advisories, and a public hall of fame will open with the first public release.
This page summarises the policy. The authoritative text is SECURITY.md in the Phantom repository.