CVE-2025-41759: Universal Bacnet Router Auth Bypass Flaw

CVE-2025-41759 Overview

CVE-2025-41759 is an input validation vulnerability affecting MBS Solutions Universal BACnet Router firmware. An administrator may attempt to block all networks by specifying "*" or "all" as the network identifier. However, these values are not supported and do not trigger any validation error. Instead, they are silently interpreted as network 0 which results in no networks being blocked at all.

This security flaw represents an improper input validation issue where the system fails to properly handle and validate special wildcard characters, leading to a security policy bypass condition.

Critical Impact

Administrators believing they have blocked all network traffic may have inadvertently left their BACnet network completely unprotected due to silent input validation failure.

Affected Products

• MBS Solutions Universal BACnet Router Firmware
• MBS Solutions UBR-01 MK II
• MBS Solutions UBR-02
• MBS Solutions UBR-LON

Discovery Timeline

• 2026-03-09 - CVE CVE-2025-41759 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2025-41759

Vulnerability Analysis

This vulnerability is classified under CWE-636 (Not Failing Securely) and stems from how the Universal BACnet Router firmware processes network blocking configuration parameters. When an administrator attempts to use wildcard characters such as "*" or keywords like "all" to block all networks, the system does not reject these invalid inputs with an error message.

The firmware silently converts these unsupported values to network identifier 0, which effectively results in no network blocking being applied. This creates a dangerous security gap where administrators have a false sense of security, believing their blocking rules are in effect when in reality no protection is being enforced.

The vulnerability is exploitable over the network and requires high privileges (administrator access) to trigger, limiting the direct attack surface but creating significant operational security risks.

Root Cause

The root cause lies in the firmware's input parsing logic which fails to implement proper validation for network identifier parameters. Instead of rejecting unsupported wildcard characters ("*") or keywords ("all") with an appropriate error message, the parsing routine converts these values to a default of network 0. This "fail open" behavior violates secure design principles that mandate systems should fail securely by rejecting invalid inputs rather than silently accepting and misinterpreting them.

Attack Vector

The attack vector for this vulnerability is network-based. An attacker with administrative credentials, or an unwitting administrator, could configure the BACnet router with the intention of blocking all network traffic. By entering "*" or "all" as the network identifier—a logical assumption based on common wildcard conventions—the administrator unknowingly creates a configuration where no networks are actually blocked.

While this vulnerability requires administrative privileges to exploit, the primary risk is that it undermines security configurations rather than providing direct unauthorized access. In an industrial control system (ICS) environment where BACnet routers are deployed, this could leave building automation systems exposed to unauthorized network traffic.

Detection Methods for CVE-2025-41759

Indicators of Compromise

• Network blocking configurations containing "*" or "all" as network identifiers
• Unexpected network traffic passing through BACnet routers despite blocking rules being configured
• Configuration files showing network identifier value of 0 when wildcard blocking was intended
• Audit logs showing administrator attempts to configure wildcard network blocking

Detection Strategies

• Review current router configurations for any network blocking rules using "*", "all", or network 0 as identifiers
• Implement network traffic monitoring to verify that expected blocking rules are functioning correctly
• Compare expected network blocking behavior against actual traffic patterns through the BACnet router
• Audit configuration change logs for entries where wildcard network blocking was attempted

Monitoring Recommendations

• Establish baseline network traffic patterns and monitor for deviations indicating failed blocking rules
• Implement automated configuration auditing to flag potentially misconfigured network blocking rules
• Deploy ICS-aware network monitoring solutions to detect unexpected BACnet traffic flows
• Set up alerts for configuration changes to network blocking parameters

How to Mitigate CVE-2025-41759

Immediate Actions Required

• Review all existing network blocking configurations on affected MBS Solutions BACnet routers
• Replace any "*" or "all" network identifier entries with explicit network numbers
• Verify that intended blocking rules are functioning by testing network traffic
• Consult the MBS Solutions Security Advisory for vendor-specific guidance

Patch Information

MBS Solutions has released a security advisory addressing this vulnerability. Administrators should consult the vendor advisory at the MBS Solutions Security Portal for firmware update information and detailed remediation guidance. Apply the latest firmware version that includes proper input validation for network identifier fields.

Workarounds

• Avoid using wildcard characters ("*") or keywords ("all") when configuring network blocking rules
• Explicitly enumerate each network number that should be blocked rather than attempting wildcard configurations
• Implement compensating network segmentation controls upstream of the BACnet router
• Document all network blocking configurations and verify their effectiveness through traffic analysis

# Configuration verification example
# Review current network blocking configuration on the router
# Ensure no entries use "*", "all", or network 0 when wildcard blocking was intended

# Example: Proper explicit network blocking configuration
# Instead of using "all" or "*", enumerate specific networks:
# network_block: 1, 2, 3, 4, 5

# Verify configuration is active by checking router status
# and monitoring actual network traffic through the device