From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 7154A1FF143 for ; Mon, 02 Feb 2026 19:08:16 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BD279E205; Mon, 2 Feb 2026 19:08:30 +0100 (CET) Message-ID: <01e4db50-3b85-4910-a601-13155a6749de@proxmox.com> Date: Mon, 2 Feb 2026 19:07:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Security Bug Identified - Firewall rules bypassed To: W3Net Admin , "pve-user@lists.proxmox.com" References: Content-Language: en-US From: Stefan Hanreich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.724 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: KMAMLLT7EV3SD3QB2UXYK5KUFUVZRPDY X-Message-ID-Hash: KMAMLLT7EV3SD3QB2UXYK5KUFUVZRPDY X-MailFrom: s.hanreich@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE user list List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Tried to quickly reproduce this on a test cluster but couldn't confirm the behavior. Could you send me the full output of the following commands (you can mail me the information directly) when the firewal is *not* working. Note that some of the commands have placeholders (NODE being the node where the issue occurs, VMID being the VM where the issue occurs). Firewall config : $ cat /etc/pve/firewall/cluster.fw $ cat /etc/pve/nodes//cluster.fw $ cat /etc/pve/firewall/.fw VM configuration: $ qm config --current Current status of network config: $ ip a $ cat /etc/network/interfaces $ cat /etc/network/interfaces.d/sdn compiled firewall output: $ iptables-save -c $ nft list ruleset syslogs: $ journalctl --since '2026-02-01' -u pve-firewall $ journalctl --since '2026-02-01' -u proxmox-firewall We have a specific channel dedicated for reporting security issues [1], so for any future security reports please utilize this one instead of the pve-user mailing list! [1] https://pve.proxmox.com/wiki/Security_Reporting On 2/2/26 6:32 PM, W3Net Admin wrote: > Hello, > > I have Identified a security bug at the DC firewall level where firewall rules are bypassed. I am concerned that this could be a zero day vulnerability. Based on the conditions below, any security group, in this case sg_pbs_stor_pbs is an empty group with NO rules, will hijack the traffic flow and stop FW filtering. If the drop rule was placed above security groups then it worked as expected. My test was pinging my host from a VM, the drop rule should have stopped the ping but if the vm was on the same host, the ping was acknowledged > > > This happens in a very specific scenario, the conditions to recreate are: > > 1. VM Must be running on its Host, this does not affect VM running on a different host. > 2. A vlan based vnet is created and tagged > 3. The host gets a static IP on the vnet > 4. Default Input Policy: Drop > > nano /etc/pve/firewall/cluster.fw > [group sg_pbs_stor_pbs] # PBS Rules #<-Empty Group, no rules > > [RULES] > > GROUP sg_pbs_stor_pbs -i vmbr1.2 #<-This will steal the traffic flow and processing will stop > IN DROP -i inf0nas -log nolog #<- it never makes it here > > /etc/network/interfaces.d/sdn > auto inf0nas > iface inf0nas > bridge_ports vmbr1.14 > bridge_stp off > bridge_fd 0 > mtu 9000 > alias NAS > > /etc/network/interfaces > auto vmbr1 > iface vmbr1 inet manual > bridge-ports enp12s0f0np0 > bridge-stp off > bridge-fd 0 > bridge-vlan-aware yes > bridge-vids 1-100 > mtu 9000 > > auto inf0nas #<- notice the use of a vnet > iface inf0nas inet static > address 10.32.14.111/24 > mtu 9000 > > > Thanks, > W3Net Admin > > >