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
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. |
noisgate verdict.
The decisive downgrade factor is that this finding usually grants only UDP reachability, not compromise. Without a second vulnerable or sensitive UDP service behind the firewall, the blast radius is small and the attack path is materially narrower than the vendor's base score implies.
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.
What to do — in priority order.
- Stop trusting inbound
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 aLOWverdict 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. - Restrict DNS to known resolvers — If the platform cannot do stateful DNS handling, allow inbound DNS-response traffic only from your approved recursive resolvers or upstream DNS providers. This shrinks the attack population dramatically and is the cleanest interim control for stateless products; again, no formal mitigation deadline applies for
LOW, but it belongs in the next routine network change window. - Audit reachable UDP services behind the edge — Inventory what would actually answer if this bypass were real:
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 remainsLOW. - Validate from outside before opening a ticket storm — Run a controlled external test with and without
-g 53against 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.
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
If you remember one thing.
LOW verdict, the noisgate mitigation SLA is no SLA (treat as backlog hygiene), and the noisgate remediation SLA is also no SLA—treat as backlog hygiene; in practice that means confirm the finding from an external vantage, document false positives or product-by-design cases, and fix confirmed source-port-trusting rules during normal firewall policy maintenance. The only reason to pull it forward is if your external test proves that a sensitive UDP management service becomes reachable from the internet when probes use source port 53.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.