Skip to content

Security: tuxevil/OpenWardRivingT

Security

SECURITY.md

Security policy

OpenWardRivingT is active wireless auditing software: it transmits deauthentication and probe frames and is intended exclusively for use against networks you own or have explicit written authorization to test. We take the security of the project, the safety of its deployments, and the integrity of the wider wireless ecosystem seriously.

Reporting a vulnerability

Please do not file public GitHub issues for suspected vulnerabilities.

Report privately by emailing tuxevil@gmail.com with [security] in the subject. If email is unavailable, open a private security advisory at https://github.com/tuxevil/OpenWardRivingT/security/advisories/new.

Include in the report:

  • A clear description of the vulnerability and its impact
  • A minimal, ordered reproduction (router model, OpenWrt version, exact CGI request or shell command, observed vs. expected behaviour)
  • The commit hash or VERSION you reproduced against
  • Whether you are willing to coordinate a fix and public disclosure, and how you would like to be credited

What to expect

  • Acknowledgement within 72 hours of the report.
  • A status update within 7 days describing the planned fix or asking for clarification.
  • A CVE assignment via GitHub Security Advisories for confirmed issues that affect a released VERSION. Critical issues are patched before public disclosure; lower-severity issues may be batched into the next release.
  • Credit in the release notes and the CHANGELOG.md entry for the fix, unless you prefer to remain anonymous.

Supported versions

The project follows semantic versioning. The latest release line (see the VERSION file and the Releases page) receives security fixes. Older lines are not patched; please upgrade.

Version line Supported
Latest ✅ Yes
Older ❌ No (upgrade)

Out-of-scope reports

Some classes of issue do not represent a vulnerability in OpenWardRivingT and should be filed as a regular bug instead:

  • Capture of networks you do not own or have written authorization to test (this is misuse, not a bug — see README → Legal & ethics)
  • Hashcat or wordlist availability / cracking throughput
  • Hardware-specific monitor-mode quirks that are well documented in README → Hardware and CONTEXT.md
  • Missing optional OpenWrt packages on under-resourced routers (e.g. coreutils-stat)

Hardening checklist for operators

  • Treat /etc/wardriving_api_token and /etc/wardriving_wifi_pass as secrets (mode 0600, generated by install.sh).
  • Never expose uhttpd to the WAN. The dashboard is LAN-only.
  • Use the Authorization: Bearer <token> header in scripts (the ?token=… query parameter is kept for window.open() downloads and external tools).
  • Route the GPU server over a private link (WireGuard /32 for the GPU host, not the full subnet) and rotate WARDRIVING_REMOTE_SECRET regularly.
  • Keep the USB drive ext4-formatted; FAT wear-leveling breaks the SQLite WAL and corrupts master.hc2200.

There aren't any published security advisories