TFTP Daemon Detection (Nessus plugin 11819) means a host answers Trivial File Transfer Protocol requests on UDP port 69, with no authentication or encryption. Disable the service where it is unused (tftp.socket, tftpd-hpa, dnsmasq enable-tftp, or Cisco no tftp-server). If PXE or phones need it, restrict UDP 69, serve read-only from a chroot and keep secrets out.
What the scanner is actually detecting
This is a service detection, not a vulnerability test. Nessus reports it when a TFTP server replies on the scanned host.
| Scanner | Finding title | ID | Severity | What it tells you |
|---|---|---|---|---|
| Nessus | TFTP Daemon Detection | Plugin 11819 (tftpd_detect.nasl, family Service detection) | Info | A TFTP service is reachable from the scanner. It does not tell you which files are served or whether uploads are accepted. |
Tenable’s description notes that routers and diskless hosts often use TFTP to fetch their configuration, and that worms have used it to spread. The solution field is a single line: “Disable this service if you do not use it.” Typical sources are in.tftpd on PXE hosts, dnsmasq, a Cisco tftp-server line, phone provisioning servers, Windows Deployment Services, and TFTP utilities left running after a firmware upgrade.
How serious is it, honestly
TFTP has no login and no encryption. The in.tftpd manual points out that enabling it treats every host that can reach the server as part of the public. What that exposes depends on what the server holds and how it was started:
- Reading by guessing names. There is no directory listing, but names are predictable: pxelinux.0, phone configurations named after the MAC address, firmware images. Nmap’s tftp-enum script exists to guess them.
- Secrets in served files. Device configurations can hold passwords and SNMP communities, phone configurations can hold SIP credentials, and answer files can carry account passwords, all sent in cleartext.
- More of the filesystem than intended. in.tftpd serves only world-readable files, but without –secure and a directory list, any world-readable file on the host is in scope. The dnsmasq manual warns the same about running as root with TFTP and no tftp-root.
- Uploads. With –create, or world-writable files in the directory, anyone who reaches the port can replace a boot image or configuration that other machines load. This is what turns an Info finding into an incident.
A read-only server on an isolated provisioning VLAN serving only boot loaders is low risk, and many networks need one. The same service reachable from user networks or the internet deserves prompt attention.
How to confirm it on the host
Linux
# Who owns UDP 69? With socket activation the owner shows as systemd
ss -ulnp | grep ':69 '
# Which unit or package provides it
systemctl list-units --all 'tftp*'
rpm -q tftp-server # RHEL, Rocky, AlmaLinux, Fedora
dpkg -l tftpd-hpa atftpd # Debian, Ubuntu
grep -rn 'enable-tftp' /etc/dnsmasq.conf /etc/dnsmasq.d/ 2>/dev/null
# How in.tftpd is started: look for -s (chroot) and for -c or -p
systemctl cat tftp.service 2>/dev/null | grep ExecStart
cat /etc/default/tftpd-hpa 2>/dev/nullOn CentOS Stream 9 the packaged unit runs in.tftpd -s /var/lib/tftpboot, started on demand by tftp.socket. A -c or -p flag was added locally and needs a reason. On older hosts, also check /etc/xinetd.d/tftp and /etc/inetd.conf.
From the network
nmap -sU -p 69 --script tftp-enum 10.20.30.5
curl -m 5 -o /tmp/tftp-test tftp://10.20.30.5/pxelinux.0; echo $?Nmap’s open|filtered proves nothing. A downloaded file, or curl exit code 68 (file not found on the TFTP server), confirms a live server. Phones, printers and PLCs sometimes run their own TFTP service; before probing them, read our notes on scanning fragile OT and embedded devices.
Cisco IOS and IOS XE
show running-config | include tftp-serverEach line names one file the device hands out, optionally followed by an access list number. Check whether any of those files is a configuration.
Windows
Get-NetUDPEndpoint -LocalPort 69 | Select-Object LocalAddress, OwningProcess
Get-Process -Id (Get-NetUDPEndpoint -LocalPort 69).OwningProcessHow to fix it
RHEL, Rocky, AlmaLinux and Fedora (tftp-server)
The socket unit is what listens on UDP 69 and what is enabled at boot. Stopping only tftp.service leaves the socket in place, and the next request starts the service again. Disable both, then remove the package and the firewall opening that Red Hat’s PXE procedure adds:
systemctl disable --now tftp.socket tftp.service
dnf remove tftp-server
firewall-cmd --permanent --remove-service=tftp
firewall-cmd --reloadDebian and Ubuntu (tftpd-hpa)
cp -p /etc/default/tftpd-hpa /root/tftpd-hpa.bak
systemctl disable --now tftpd-hpa
apt remove tftpd-hpaIf dpkg showed atftpd instead, remove that package the same way.
On older hosts started by xinetd, set disable = yes in /etc/xinetd.d/tftp and restart xinetd; with inetd, comment out the tftp line in /etc/inetd.conf and restart it.
dnsmasq
Comment out every enable-tftp line in /etc/dnsmasq.conf and /etc/dnsmasq.d/, then run systemctl restart dnsmasq. DHCP and DNS keep working.
Cisco IOS and IOS XE
tftp-server is disabled by default, so any line was added on purpose, often for a one-off image transfer. Remove each line with its no form, typed exactly as shown in the running configuration, and save:
configure terminal
no tftp-server flash:image-name.bin
end
copy running-config startup-configOther TFTP servers
On Windows, uninstall a standalone TFTP utility left behind after a firmware job. If the owner is Windows Deployment Services (WDSServer), TFTP is how PXE clients boot, so restrict it instead. On phone platforms and appliances, use the vendor’s TFTP setting.
If TFTP has to stay (PXE and phone provisioning)
Chroot, read-only, least privilege. Run in.tftpd with -s (–secure) and exactly one directory, and without -c or -p. Without –create, uploads can only overwrite files that already exist and are world-writable, so make sure none are:
chown -R root:root /var/lib/tftpboot
chmod -R u=rwX,go=rX /var/lib/tftpbootListen only on the provisioning interface. On Debian and Ubuntu, edit /etc/default/tftpd-hpa and restart tftpd-hpa:
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="10.20.30.5:69"
TFTP_OPTIONS="--secure --verbose"On the RHEL family, add this override with systemctl edit tftp.socket, then restart tftp.socket. The empty ListenDatagram= clears the packaged value; FreeBind= lets it bind before the address is up.
[Socket]
ListenDatagram=
ListenDatagram=10.20.30.5:69
FreeBind=yesFilter UDP 69 to client subnets. With firewalld, move the tftp service (which also loads the nf_conntrack_tftp helper) into a source-bound zone. That subnet then gets only the new zone’s services, so add DHCP or SSH there if needed.
firewall-cmd --permanent --remove-service=tftp
firewall-cmd --permanent --new-zone=provisioning
firewall-cmd --permanent --zone=provisioning --add-source=10.20.30.0/24
firewall-cmd --permanent --zone=provisioning --add-service=tftp
firewall-cmd --reloadWith ufw and a default deny policy: ufw allow proto udp from 10.20.30.0/24 to any port 69.
dnsmasq. Its TFTP server is read-only by design. Confine it to one interface and directory, and do not run it as root:
enable-tftp=eth1
tftp-root=/srv/tftp
tftp-secureWith tftp-secure, only files owned by the user dnsmasq runs as are served.
Cisco. Re-enter the line with a standard IP access list number at the end (the command reference allows 0 to 99):
access-list 10 permit 10.20.30.0 0.0.0.255
tftp-server flash:image-name.bin 10Keep secrets out. Never put device configurations or answer files with passwords in a TFTP root, and move configuration backups to SCP or SFTP.
Verify the fix and rescan
ss -ulnp | grep ':69 ' # no output expected
systemctl is-enabled tftp.socket # "disabled", or an error once the package is removed
curl -m 5 -o /dev/null tftp://10.20.30.5/pxelinux.0; echo $?From outside the allowed range, curl should time out or error, never download the file or return 68. On Cisco, show running-config | include tftp-server should return nothing, or only lines with an access list.
Rescan with the same Nessus policy and scanner. If you restricted TFTP and the scanner is inside the allowed range, plugin 11819 will still fire; record it as an accepted exception listing the controls applied.
What can break and how to roll back
- PXE boot. Clients get an address and then time out fetching the boot file. Check whether DHCP boot settings (options 66 and 67, or next-server and filename in ISC dhcpd) point at this host before you disable anything.
- IP phones and embedded devices. Devices that reboot may fail to load their configuration or firmware.
- Backups and upgrades. Jobs that push backups or pull images over TFTP fail. Run tcpdump -ni any udp port 69 for a few days first to see who still uses it.
Archive the served directory before removing a package (tar -czf /root/tftpboot.tgz /var/lib/tftpboot). To roll back on the RHEL family, reinstall tftp-server, restore the files, run restorecon -Rv /var/lib/tftpboot, then systemctl enable –now tftp.socket and re-add the firewall service. On Debian and Ubuntu, reinstall tftpd-hpa and restore your copy of /etc/default/tftpd-hpa. On Cisco, re-enter the saved line.
Common false positive reasons
True false positives are rare, because the plugin reports a service that answered. The usual disputes:
- “The service is stopped.” tftp.service is inactive, but tftp.socket still listens and starts it on the next request.
- A different daemon. dnsmasq, WDS, a phone system or an appliance’s built-in TFTP is answering, not the package you removed.
- Wrong asset. A NAT rule, a load balancer or a reused DHCP address maps the scanned IP to another device.
- Intended and restricted. The scanner sits inside the allowed range of a legitimate provisioning server. The finding is accurate; track it as an exception.
- Unsaved Cisco change. The no command was applied but not saved, and the line came back after a reload.
FAQ
Is TFTP Daemon Detection a vulnerability?
Not by itself. Nessus rates it Info because it reports an exposed service, not a flaw. The risk comes from what the server hands out and whether it accepts uploads.
Why does the finding come back after I stopped tftp.service?
On RHEL-family systems tftp.socket owns UDP 69 and starts the service on demand. Disable the socket as well, or remove the tftp-server package.
Can a Cisco router’s TFTP server accept uploads?
No. Cisco’s command reference describes it as sending copies of the named files in response to TFTP read requests. The exposure is disclosure of those files, so check what they contain.
Can TFTP be made secure?
The protocol has no authentication or encryption. You can only limit who reaches it, what it serves and whether it accepts writes.
Tracking this finding across many hosts
Provisioning servers you need and forgotten ones raise the same Info finding, so they are easy to lose track of. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and can re-test plugin 11819 finding by finding once the service is disabled. Its AI triage suggests false positives with evidence while a person makes the final call, and on Linux and Windows endpoints its agents deploy host-specific fix scripts only after human approval.