The official source for security vulnerabilities disclosed in Firezone.
Found a vulnerability? See reporting a vulnerability for how to disclose it privately.
On Linux Gateways prior to 1.6.3, the authenticate command did not set the permissions of the token file it wrote, so in some setups any local user could read the Gateway's token.
Gateways from 1.4.6 through 1.6.0 installed the DNS Resource proxy IPs chosen by a Client without checking that they fall inside the reserved ranges, so a Client authorized for a DNS Resource could reach any host the Gateway can reach, subject only to that Resource's port filters.
Firezone's email sign-in one-time code had insufficient entropy and the verification endpoint enforced no per-code attempt limit, so a distributed attacker could brute-force a live code within its 15-minute window and sign in as another user. The issue has been resolved in the managed service; no action is required.
On Windows Clients prior to 1.5.13, the device ID file was readable by any local user, so its contents could be copied to another machine to bypass device verification policies.
Windows GUI Clients prior to 1.5.13 stored their advanced settings in a user-writable directory and read MDM policy from the per-user registry hive, letting any same-user process change how the privileged tunnel connects.
Linux GUI Clients prior to 1.5.13 stored their advanced settings in a directory under the user's home that any same-user process could modify, influencing how the privileged tunnel connects.
Windows GUI Clients prior to 1.5.13 created their tunnel and GUI named pipes without package-scoped access control, letting other local processes drive the privileged tunnel service, change settings, or hijack deep-link handoff.
Linux GUI Clients prior to 1.5.13 authorized peers on the tunnel service IPC socket only by group membership, letting any process running as the desktop user drive the privileged tunnel and change Client settings.
macOS Clients from 1.4.15 through 1.5.15 stored their configuration in a UserDefaults domain writable by any unprivileged local process, allowing the Client's settings to be tampered with. Clients with configuration forced via MDM are not affected.