CVE-2000-0536: xinetd 2.1.8.x does not properly restrict connections if hostnames are used for access control and the conn...

Security readout for executives and security teams

A flaw in older xinetd (2.1.8.x) allowed unwanted connections through when administrators used hostnames for access control and the connecting system had no reverse DNS record. In practice, hosts that should have been blocked could reach services because the check silently permitted them. This is a legacy Unix service-management issue disclosed in 2000 affecting Debian and similar distributions of that era. Exposure is limited to legacy Unix systems still running xinetd 2.1.8.x with hostname-based ACLs, primarily late-1990s to early-2000s Debian and similar distributions. Modern supported Linux releases shipped patched xinetd long ago, and many environments have replaced inetd-style supervision with systemd socket activation. Any remaining exposure would be internet-facing legacy hosts or unmaintained appliances. Low priority for modern estates. Treat as a hygiene item during legacy Unix decommissioning or audits of long-lived appliances. No indication of active exploitation, no KEV listing, and mainstream distributions patched this decades ago. Escalate only if inventory reveals unsupported systems still exposing xinetd services to untrusted networks. Mitigation focus: Upgrade xinetd to the vendor-patched release referenced in the Debian 2000-06-19 advisory or later.; Prefer IP address or CIDR ranges over hostnames in only_from and no_access directives.; If hostnames must be used, ensure firewall rules deny untrusted networks before xinetd sees the connection..

Prepared

Jul 12, 2026, 01:09 UTC (UTC+00:00)

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.