Skip to content

VNX-SEC-075: WireGuard private key

Reports a literal WireGuard private or preshared key (a 32-byte base64 key) in a wg-quick configuration, or assigned to a private-key name in a WireGuard-related YAML, JSON, Nix, .env, NetworkManager, RouterOS, OpenWrt or Go file.

Updated 02 Nov 2026Checked against cli@de9b52a
Field Value
Rule ID VNX-SEC-075
Severity Critical
SARIF level error
Kind secrets
Languages Any file
CWE CWE-798
CAPEC CAPEC-191
ATT&CK T1552.004
CWSS vector CWSS:1.0/TI:C/AP:A/AL:A/IC:N/FC:LT/RP:N/RL:A/AV:I/AS:N/IN:A/SC:A/BI:C/DI:H/EX:H/EC:N/P:W
Tags secrets wireguard vpn credentials
Source internal/sast/rules/vnx-sec-075.rego

Overview

This rule reports a literal WireGuard key, a 32-byte value in base64 (43 characters and a closing =), written as PrivateKey = or PresharedKey = in a wg-quick/INI configuration, or, in a file that mentions WireGuard, assigned to a private_key-style name (Ansible variables, sing-box JSON, Nix modules, WIREGUARD_PRIVATE_KEY= environment entries) or passed to wgtypes.ParseKey(). The key is masked in the finding’s snippet.

Why This Matters

Hardcoded wireguard private key values are routinely scraped by automated bots within minutes of a public push, and then used to access the account, exfiltrate data, or pivot into downstream services. Once the credential is in git history it is permanently in third-party hands.

What Gets Flagged

# FLAGGED: /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <43 base64 characters>=

[Peer]
PublicKey = <43 base64 characters>=     # public, not flagged
PresharedKey = <43 base64 characters>=  # flagged
# FLAGGED: compose environment for a WireGuard client
environment:
  - VPN_TYPE=wireguard
  - WIREGUARD_PRIVATE_KEY=<43 base64 characters>=
# FLAGGED: NetworkManager keyfile and OpenWrt UCI
private-key=<43 base64 characters>=
	option private_key '<43 base64 characters>='

Not flagged:

  • PublicKey lines, PrivateKey = ${WG_PRIVATE_KEY} and wg set wg0 private-key /etc/wireguard/private.key.
  • Values that are not a well-formed key: variable names, <placeholders>, AAAA...= or xxxx...= runs.
  • Key-shaped values under other names in files unrelated to WireGuard.
  • *.example/*.sample files, Markdown, and test, fixture, vendored and generated files.

Remediation

  1. Revoke the leaked credential in the provider’s console immediately.
  2. Replace with a short-lived alternative, OAuth 2.0 access tokens, IAM role assumption, OIDC federation, wherever the platform supports it.
  3. Store the new credential in a secrets manager (AWS Secrets Manager, HashiCorp Vault, GitHub Actions secrets, Doppler).
  4. Audit the provider’s access logs for activity you did not initiate between the leak and the revocation.
  5. Purge from git history with git filter-repo or BFG, then re-scan with gitleaks/truffleHog to confirm no other secrets remain.
  6. Enable push protection so future commits are blocked at the developer machine.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-sec-075
// nosec vnx-sec-075

Or record an ignore rule: vulnetix ignore add --rule vnx-sec-075 --reason "...". See Suppressing findings.

Edit this pageSources: cli/internal/sast/rules/vnx-sec-075.rego, cli/internal/sast/docs/vnx-sec-075.md
esc
↑ ↓ move↵ openSearches in your browser. A key like autonomy.max or a code like threshold_required jumps straight to it.