-
Notifications
You must be signed in to change notification settings - Fork 0
SECURITY
github-actions[bot] edited this page Jul 1, 2026
·
5 revisions
kvm-pilot controls real hardware: it can power-cycle machines, mount boot
media, and inject keystrokes onto a console with no OS-level authentication on
the target. Treat it accordingly.
Please do not disclose vulnerability details in a public issue.
- Preferred: GitHub's private "Report a vulnerability" flow under the repository's Security tab. Include reproduction steps and the affected version.
- Fallback (if that button is missing — private vulnerability reporting can be toggled off): open a regular issue saying only "security report — please provide a private contact", without any vulnerability details, and a maintainer will arrange a private channel.
We aim to acknowledge reports within a few days. Do not include working exploits against third-party devices or live hosts in a public report.
- Do not expose a KVM device directly to the internet. Put it behind a VPN or an authenticated reverse proxy. The PiKVM/GLKVM web stack is not hardened for direct public exposure.
-
Use TOTP/2FA where the device supports it (
pip install "kvm-pilot[totp]").verify_ssldefaults toFalsebecause these devices ship self-signed certificates; set it toTrueand pin a real certificate if your environment allows. - Credentials resolve from arguments, environment variables, or a config file. The library never writes secrets back out, and passwords plus session tokens are redacted from error text. Still, prefer environment injection over committing a config file with secrets.
-
The safety layer is advisory, not a sandbox.
dry_runand the confirmation callback prevent accidental destructive calls; they are not a privilege boundary. Anyone who can run your script with valid credentials can disable them.
In scope: credential handling, secret redaction, the safety-gating logic, and
injection issues in how kvm-pilot constructs requests. Out of scope:
vulnerabilities in PiKVM, GLKVM, GL.iNet firmware, or third-party VLM servers —
report those to their respective projects.
- Home
- Getting started
- Architecture
- CLI reference
- Configuration
- Design decisions
- Reflexes (RFC)
- Redfish reference
- Firmware registry
- Remote firmware update
- Claude skill
- MCP server
- Contributing
- Security policy
- Analysis: 2026-07-01 deep review
- Analysis: 2026-07-03 RM1PE firmware + encoder
- Hardware compatibility