TL;DR: wg-easy 15.3.0 has an OS command injection vulnerability in its client creation flow. A user with the clients.create permission can inject newline-delimited WireGuard PostUp directives into the client name field. wg-easy writes that name directly into the WireGuard configuration file without sanitizing newlines, and wg-quick executes the injected directives as root. The result is arbitrary code execution with root privileges on the VPN host.

What is wg-easy

wg-easy is the most popular self-hosted WireGuard VPN management interface. It runs as a Docker container and provides a web UI for creating WireGuard client configurations, generating QR codes for mobile enrollment, and managing peer connections. Administrators deploy it on a VPS or home server, create a client for each user, and that user gets a VPN tunnel with a single QR scan.

The project has over 16,000 GitHub stars and more than 50 million Docker Hub pulls. It is the go-to choice for homelab operators, small offices, and privacy-conscious users who want a personal VPN without manually editing WireGuard config files. The official Docker image bundles both the wg-easy web application and the WireGuard kernel module, running everything as root because WireGuard requires root for network interface configuration.

What happened

When a user creates a new WireGuard client in wg-easy, they provide a client name. That name gets written into the generated WireGuard configuration file as a comment. The vulnerability is that wg-easy does not strip or reject newline characters in the client name field.

WireGuard configuration files support directives like PostUp and PostDown, which run shell commands when the tunnel starts or stops. If an attacker submits a client name containing a newline followed by PostUp = /bin/bash -c 'payload', wg-easy writes that line into the config file as a valid directive instead of inert comment text. When wg-quick brings up the interface, it executes the injected PostUp command with root privileges.

The attack requires the clients.create permission, which in many wg-easy deployments is granted to every authenticated user. The wg-easy web interface uses a single shared password for admin access in its default configuration. Multi-user setups with separate accounts and restricted permissions would limit the blast radius, but the default deployment model gives any logged-in user the ability to create clients.

The root cause is a classic injection problem: user-controlled input written into a structured configuration file without escaping special characters. Newlines are the delimiter that separates directives in WireGuard config files. Failing to reject them turns a text field into a code execution vector.

Who is affected

Any deployment running wg-easy 15.3.0. The vulnerability is in the client creation path, so any user who can authenticate to the wg-easy web UI and has the clients.create permission can exploit it. In the default single-password configuration, anyone who knows the admin password has full exploit capability.

Deployments exposed to the public internet are at highest risk, especially if the wg-easy web port is accessible without a reverse proxy or additional authentication layer. The Docker image is commonly deployed with the web port mapped directly to a public interface.

What to do

No fixed version is listed in the CVE advisory. Mitigations:

• Restrict access to the wg-easy web UI. Put it behind a reverse proxy with authentication, or restrict the port to a VPN or trusted IP range. If attackers cannot reach the client creation form, they cannot inject the payload.
• Run wg-easy in a container with reduced capabilities if your setup allows it. The WireGuard interface still needs NET_ADMIN and SYS_MODULE capabilities, but you can drop other capabilities and use a read-only root filesystem to limit what an injected command can do.
• Audit existing client configurations. Check WireGuard config files on the host for any PostUp or PostDown directives that were not added by the administrator. A client name containing newlines will have produced visible extra lines in the config.
• Monitor wg-quick logs for unexpected command execution when interfaces start.

Watch for a patched release from the wg-easy project. The fix should sanitize newlines from the client name field or reject names containing control characters.

Why it matters

WireGuard itself is secure. The vulnerability is in the management layer that generates and writes configuration files. This pattern repeats across infrastructure tooling: a web UI that writes to a privileged config file without escaping the input. The root execution context makes the impact severe, and the wide deployment of wg-easy in self-hosted VPN setups means the attack surface is large.

The CVE has no CVSS score from NVD yet. Based on the technical description, the impact is high: authenticated code execution as root on the VPN host. The requirement for clients.create permission limits it to authenticated users, which in the default deployment means anyone with the shared admin password.

References

• CVE-2026-72603 on hol.org
• wg-easy GitHub repository
• WireGuard official site