PhantomRF is a research and educational tool. It is not a weapon and should never be used against systems you do not own or have explicit written authorisation to test. Read docs/legal/ before flashing the device.

This document explains how to report a security vulnerability in PhantomRF itself — that is, a bug in our firmware, build pipeline, web UI or distribution infrastructure. It does not authorise you to use the tool against any system you do not own.

We patch the most recent minor release line and the main branch. Older releases receive no security backports.

If you are running a pre-1.0 build, upgrade to main before reporting anything other than a critical issue.

Use GitHub's private vulnerability reporting on this repository. This creates a private advisory that only you, the maintainers, and (after triage) any co-disclosed parties can see.

If you cannot or will not use the GitHub Security tab, email security@example.com (PGP key: see end of this document).

For both channels, please include:

1. A clear, English-language title that describes the bug in one sentence.
2. A description of the impact: what can an attacker do, and under what conditions?
3. Affected version(s): commit hash, tag, or pio run -e <env> -t size output.
4. Reproduction steps: hardware, firmware version, attack commands, observed vs. expected behaviour. Serial-monitor output is great.
5. Your assessment of severity (Critical / High / Medium / Low) if you have one. We will confirm or adjust.
6. Whether the issue is already public (blog post, CVE, conference talk). If public, please link the source.
7. Your name / handle if you would like to be credited in the fix announcement. (Default is to stay anonymous unless you say otherwise.)

We will never ask you to run a "proof-of-concept" that connects to our infrastructure, and we will never ask for your private keys. If you receive such a request claiming to be from the PhantomRF team, it is a scam — please report it.

We aim to:

These are targets, not guarantees. If we are late, we will tell you why. You are welcome to ping us at any point in the process.

Anything that affects the confidentiality, integrity or availability of:

• PhantomRF firmware running on an ESP32(-S3 / -C3 / -S2) device.
• The PhantomRF web UI served by the device.
• The PhantomRF build / release pipeline (CI, release artifacts, GitHub Actions workflows).
• The PhantomRF flasher site (flasher/).
• PhantomRF documentation site (docs/ → gh-pages).

• An attacker on the same WiFi network can take over the web UI without authentication.
• A malicious .bin uploaded via the OTA endpoint escapes the firmware partition and corrupts user data.
• A buffer overflow in the NVS settings parser allows a malformed LittleFS file to execute arbitrary code.
• The release pipeline can be tricked into publishing an unsigned binary that downstream users will flash.
• The web flasher silently swaps the binary it's about to flash.
• CSRF / XSS in the web UI that leaks SSIDs or other sensitive settings to an attacker.

• "PhantomRF can be used to deauth a WiFi network" — by design; see docs/legal/.
• "PhantomRF transmits RF energy" — by design; you build it yourself and accept regulatory responsibility.
• Theoretical side-channel attacks (e.g. power analysis on nRF24 emissions) with no demonstrated impact.
• Reports about hardware modules (nRF24L01, CC1101) themselves; those go to Nordic / TI.

If you're not sure whether something is in scope, report it anyway — we will triage and tell you.

We follow coordinated disclosure:

1. You report privately to us.
2. We confirm and triage.
3. We develop a fix.
4. We agree on a public disclosure date (typically the day the fix ships).
5. We credit you in the release notes and the GitHub Security Advisory, unless you ask to stay anonymous.
6. After disclosure, the advisory becomes public on the GitHub Security tab.

We will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, or service disruption.
• Only test against systems they own or have written authorisation to test.
• Stop testing immediately if they find a critical issue and contact us before publishing anything.

If your testing accidentally affects a third party (e.g. a noisy spectrum sweep that disrupts a neighbour's WiFi), stop, document what happened, and tell us in the same report.

We use CVSS v3.1 as a starting point, then adjust for the research/educational framing of the project:

Security researchers who follow this policy and whose reports lead to a fix are listed in the release notes and the project README. If you would prefer to stay anonymous, say so in your initial report and we will respect that.

Hall of fame (in chronological order):

• Your name could be here.

-----BEGIN PGP PUBLIC KEY BLOCK-----
[Placeholder: rotate this section with the real key before publishing.
 Use `gpg --full-generate-key` (RSA-4096, 5y expiry), publish to
 keys.openpgp.org, and replace this block.]
-----END PGP PUBLIC KEY BLOCK-----

Key ID: PHANTOMRF-SECURITY-KEY-ID (placeholder) Fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (placeholder)

This policy is provided in good faith. It does not create any contractual obligation on the PhantomRF project or its maintainers. You remain solely responsible for ensuring that your research complies with the laws of your jurisdiction.