This is a side door cut into the fence for DNS replies and forgotten open for any UDP packet wearing a port-53 nametag
Plugin 11580 is an old network check for firewalls that trust UDP source port 53 too broadly. Tenable ties it primarily to Kerio Personal Firewall 2.1.4 (CVE-2003-1491), while also cross-referencing similar behavior in older Symantec Firewall/VPN Appliance and Gateway Security firmware (CVE-2004-1473). The flaw does not execute code by itself; it lets an external sender slip UDP packets past a filtering rule that should have blocked them.
Tenable's HIGH label is too generous for enterprise triage in 2026. The real-world attack chain is narrow: the attacker must find a genuinely exposed firewall with this exact source-port trust mistake, then there must be a useful UDP service behind it, and usually a second bug or dangerous service is needed for meaningful impact. Add the age of the affected products and the scanner's false-positive history on stateless firewalls, and this drops to backlog-grade risk unless you verify a real internet-facing exposure.
4 steps from start to impact.
Map the UDP trust hole with nmap -sU / -g 53
-g 53 option. If the firewall filters the first probe but allows the second, the attacker has confirmed that the rule set trusts the source port instead of real session state. Reference: Nmap firewall/IDS evasion docs.- Internet reachability to the firewall or protected host
- A firewall rule that trusts inbound UDP traffic purely because the source port is
53
- Many modern stateful firewalls do not make this mistake
- UDP testing is noisy and ambiguous;
open|filteredresults often require manual validation - Some products are flagged by scanners even when behavior is by design, not exploitable in the same way
paranoid mode, and Broadcom documents scanner flags on ESXi that are design-related rather than a classic product vuln.Reach a blocked UDP service behind the policy
161/udp), TFTP (69/udp), or ISAKMP/IKE (500/udp) on the device or protected host.- A useful UDP service is listening behind the firewall
- The chosen destination UDP port is blocked in baseline testing but reachable when the probe uses source port
53
- Many enterprise assets do not expose interesting UDP services at all
- Firewalls often restrict these services to management networks or specific IP allowlists
- UDP payloads usually need protocol-aware packets to get a meaningful response
Abuse the newly reachable service
- A reachable service with insecure behavior or a known flaw
- Ability to speak the service protocol well enough to trigger the next stage
- No direct code execution comes from the bypass alone
- Modern SNMPv3, hardened IKE, or disabled TFTP sharply reduce payoff
- EDR/NDR may still catch the follow-on activity even if the firewall policy is weak
Escalate from policy bypass to business impact
- A high-value management or appliance service reachable over UDP
- Weak segmentation so the newly reachable service can affect broader infrastructure
- Blast radius is often limited to the single appliance or service reached
- Most enterprises have better initial-access options than chasing a UDP-only edge case
- The attack is brittle compared with modern web/RCE paths
udp src port 53 — Rewrite rules so DNS responses are allowed by state/conntrack or by explicit resolver IP allowlists plus expected destination ephemeral ranges, not by trusting the source port alone. For a LOW verdict there is no SLA (treat as backlog hygiene), so fold this into normal firewall policy cleanup unless validation proves real internet exposure to a sensitive UDP service.LOW, but it belongs in the next routine network change window.161/udp, 69/udp, 500/udp, custom agents, appliance management listeners, or legacy daemons. If you find a sensitive service that becomes reachable from the internet with source-port-53 probes, pull that specific case forward even though the plugin itself remains LOW.-g 53 against a UDP port that should be blocked. This matters because the plugin is prone to false positives and product-by-design flags; spending ten minutes validating can save weeks of bad remediation work across a large estate.- WAF rules do nothing here; this is a network-layer UDP filtering problem, not an HTTP problem.
- MFA is irrelevant unless the reachable UDP service later hands off to an authenticated workflow; it does not stop the packet bypass.
- EDR on downstream servers may catch a second-stage exploit, but it does not fix the perimeter rule that admits spoofable UDP traffic.
- Blocking destination port 53 alone misses the point; the dangerous logic is trusting source port
53on inbound packets.
The supporting signals.
| In-the-wild status | No current evidence of active exploitation found in the fetched primary sources. This is an old, well-understood firewall filtering mistake, not a current campaign driver. |
|---|---|
| Proof-of-concept availability | Publicly documented and trivial to test. Full Disclosure published an nmap -v -P0 -sU -p 1900 <target> -g 53 example in April 2003, and Nmap still documents -g / --source-port specifically for this class of weakness. |
| KEV status | Not found in CISA KEV based on catalog-targeted searches during this assessment. No KEV signal means no evidence that CISA considers this a currently exploited priority. |
| EPSS | Not a useful decision driver here. This is a legacy CVE with weak modern exploit-probability signal; secondary mirrors show low single-digit or sub-1% values and are inconsistent across mirrors, which is exactly why this finding should be validated operationally instead of trusted numerically. |
| CVSS vector | Tenable maps CVE-2003-1491 to CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L (7.3) and NVD keeps the older CVSSv2 7.5. That overstates reality because the score assumes direct impact, while the actual flaw usually only restores UDP reachability to something else. |
| Affected versions | Primary mapping: Kerio Personal Firewall 2.1.4. Similar historical case: Symantec Firewall/VPN Appliance 100/200/200R before 1.63 and Gateway Security 320/360/360R before build 622. |
| Fixed versions | For the Symantec branch, CERT/NVD point to fixes in firmware 1.63 and build 622. For the Kerio branch, fetched authoritative sources confirm the affected version (2.1.4) but do not cleanly expose a vendor-published fixed version, so treat it as legacy/unsupported software risk unless you have old vendor release notes. |
| Scanning and exposure reality | Scanner noise is a real issue. Broadcom documents ESXi 7.0/8.0 being flagged because its firewall is stateless and permits DNS-response-shaped traffic by design. That means this plugin can represent a genuine policy flaw, a product limitation, or a false-priority finding depending on context. |
| Why source port 53 matters | Microsoft documents that normal DNS queries use high-numbered ephemeral source ports to destination 53, and replies come from source port 53 back to a high destination port. Any firewall rule that simply trusts inbound packets because the source port is 53 is trusting a header field attackers can spoof in UDP. |
| Disclosure and reporting | CVE-2003-1491 traces to David F. Madrid's April 22, 2003 Full Disclosure post on Kerio. The Symantec variant was publicly disclosed on 2004-09-22, and CERT credits Mike Sues / Rigel Kent Security & Advisory Services. |
Sources.
Why this verdict
- Downgrade #1: this is a filter bypass, not an RCE. The flaw only helps packets cross a policy boundary; it does not itself run code, dump creds, or hand over admin access.
- Downgrade #2: it requires a useful UDP target behind the firewall. No reachable SNMP/TFTP/IKE/other UDP service means the attack dies after the packet trick.
- Downgrade #3: exposed population is narrow and old. The core product mapping is
Kerio Personal Firewall 2.1.4from 2003, and comparable Symantec appliance cases are also legacy. - Downgrade #4: modern controls should already reduce payoff. Stateful firewalls, management-plane isolation, allowlists, and segmentation all cut the reachable population hard.
- Downgrade #5: scanner reliability is imperfect. Broadcom's ESXi guidance shows this exact finding can fire on stateless DNS-permitting behavior that is not the same thing as a practical perimeter bypass.
Why not higher?
There is no fetched KEV signal, no current exploitation evidence, and no modern mass-exploitation pattern attached to this plugin. More importantly, the attacker still needs a second-stage opportunity after reaching a UDP service; the finding is rarely the compromise itself.
Why not lower?
If this is real on an internet-facing edge and it exposes administrative UDP services that were supposed to be blocked, it can absolutely become the first domino in a larger appliance compromise. That keeps it above IGNORE: confirmed source-port trust on a perimeter control is sloppy and should be fixed, just not treated like a crisis.
Crowdsourced verification payload.
Run this from an external auditor workstation or a test host on the untrusted side of the firewall, not from the target itself. Invoke it as sudo ./check_udp53_bypass.sh 203.0.113.10 161 where the second argument is a UDP port that should be blocked from the internet; it needs nmap installed and root/admin rights for raw-packet scans.
#!/usr/bin/env bash
# check_udp53_bypass.sh
# Test for UDP source-port-53 firewall ruleset bypass.
# Usage: sudo ./check_udp53_bypass.sh <target_ip_or_name> <udp_port>
# Exit codes:
# 0 = PATCHED (no bypass observed)
# 1 = VULNERABLE (baseline filtered, source-port-53 less filtered)
# 2 = UNKNOWN (inconclusive / prerequisites missing)
set -euo pipefail
if [[ $# -ne 2 ]]; then
echo "UNKNOWN: usage: sudo $0 <target_ip_or_name> <udp_port>"
exit 2
fi
TARGET="$1"
PORT="$2"
if ! command -v nmap >/dev/null 2>&1; then
echo "UNKNOWN: nmap is required"
exit 2
fi
if [[ "$PORT" =~ ^[0-9]+$ ]] && (( PORT >= 1 && PORT <= 65535 )); then
:
else
echo "UNKNOWN: invalid UDP port '$PORT'"
exit 2
fi
scan_port_state() {
local extra_args="$1"
local out state
out=$(nmap -n -Pn -sU -p "$PORT" --max-retries 1 --host-timeout 30s $extra_args "$TARGET" 2>/dev/null || true)
state=$(awk -v p="$PORT/udp" '$1==p {print $2}' <<< "$out" | head -n1)
if [[ -z "$state" ]]; then
echo "unknown"
else
echo "$state"
fi
}
BASE_STATE=$(scan_port_state "")
SRC53_STATE=$(scan_port_state "-g 53")
echo "Target: $TARGET"
echo "Test UDP port: $PORT"
echo "Baseline state: $BASE_STATE"
echo "Source-port-53 state: $SRC53_STATE"
# Interpretation guidance:
# - If baseline is filtered/open|filtered but source-port-53 becomes open or closed,
# the firewall likely treated source port 53 specially and the port became reachable.
# - If both are identical, no bypass was observed.
# - If both are open/open|filtered, choose a different UDP port that is EXPECTED to be blocked.
if [[ "$BASE_STATE" == "filtered" || "$BASE_STATE" == "open|filtered" || "$BASE_STATE" == "unknown" ]]; then
if [[ "$SRC53_STATE" == "open" || "$SRC53_STATE" == "closed" || "$SRC53_STATE" == "unfiltered" ]]; then
echo "VULNERABLE"
exit 1
fi
fi
if [[ "$BASE_STATE" == "$SRC53_STATE" ]]; then
if [[ "$BASE_STATE" == "open" || "$BASE_STATE" == "closed" ]]; then
echo "UNKNOWN"
echo "Note: chosen UDP port may already be reachable without source-port manipulation; pick a port that should be blocked."
exit 2
fi
echo "PATCHED"
exit 0
fi
echo "UNKNOWN"
echo "Note: results were inconclusive; validate with a protocol-aware UDP service test and packet capture."
exit 2