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.
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
VERSIONyou reproduced against - Whether you are willing to coordinate a fix and public disclosure, and how you would like to be credited
- 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.mdentry for the fix, unless you prefer to remain anonymous.
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) |
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)
- Treat
/etc/wardriving_api_tokenand/etc/wardriving_wifi_passas secrets (mode0600, generated byinstall.sh). - Never expose
uhttpdto the WAN. The dashboard is LAN-only. - Use the
Authorization: Bearer <token>header in scripts (the?token=…query parameter is kept forwindow.open()downloads and external tools). - Route the GPU server over a private link (WireGuard
/32for the GPU host, not the full subnet) and rotateWARDRIVING_REMOTE_SECRETregularly. - Keep the USB drive
ext4-formatted; FAT wear-leveling breaks the SQLite WAL and corruptsmaster.hc2200.