Security Bug Identified - Firewall rules bypassed

Security Bug Identified - Firewall rules bypassed

[W3Net Admin]

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

Re: Security Bug Identified - Firewall rules bypassed

[Stefan Hanreich]

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/<NODE>/cluster.fw
$ cat /etc/pve/firewall/<VMID>.fw

VM configuration:

$ qm config <VMID> --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
> 
> 
> 

Re: Security Bug Identified - Firewall rules bypassed

[Stefan Hanreich]

I forgot to add this in my previous mail, please also include the
current versions you are running:

$ pveversion -v


On 2/2/26 7:06 PM, Stefan Hanreich wrote:
> 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/<NODE>/cluster.fw
> $ cat /etc/pve/firewall/<VMID>.fw
> 
> VM configuration:
> 
> $ qm config <VMID> --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
>>
>>
>>
>