If kdcproxy receives a request for a realm which does not have server addresses defined in its configuration

kdcproxy is a small WSGI app from the latchset project that lets clients tunnel Kerberos over HTTPS to a KDC — commonly fronted by Apache/mod_wsgi on FreeIPA and Red Hat Identity Management servers. When a client asks for a realm that isn't hard-coded in kdcproxy.conf, the default behavior is to resolve _kerberos._tcp.<REALM> via DNS SRV and connect wherever those records point. An unauthenticated attacker who controls a DNS zone can publish SRV records that resolve to 127.0.0.1:22, 169.254.169.254:80, or any internal RFC1918 host and port, and the kdcproxy server will happily open a TCP connection on their behalf. Affected: all python-kdcproxy versions prior to the latchset PR #68 fix; Red Hat has shipped errata (RHSA-2025:21142, :21748, :21820, :21821) for RHEL 8/9/10 and IdM.

The vendor HIGH / 8.6 score comes from AV:N/AC:L/PR:N/UI:N/S:C/C:H — unauth network reach, scope-change, high confidentiality. That vector is technically defensible (it *is* unauth SSRF crossing a trust boundary), but the C:H reading is generous: kdcproxy speaks a Kerberos wire protocol, so exfiltrating arbitrary HTTP responses back to the attacker requires the target service to happen to speak something kdcproxy will forward and echo. In practice you get *blind* SSRF suitable for internal port scanning, topology mapping, and hitting side-effectful GET endpoints — a real bug, but MEDIUM territory once you audit the friction. Blast radius does not reach fleet compromise from this bug alone.

Why this verdict

• Blind SSRF, not data exfil: kdcproxy expects a Kerberos-framed reply from the upstream, so arbitrary HTTP response bodies do not round-trip cleanly back to the attacker. The vendor's C:H rating is optimistic.
• Narrow deployment footprint: kdcproxy is an optional component of FreeIPA / Red Hat IdM used to tunnel Kerberos over HTTPS for remote clients. Shodan/Censys populations for internet-facing IdM /KdcProxy endpoints are in the low hundreds globally.
• Attacker must control a DNS zone, which is trivial but leaves registrar and passive-DNS forensic breadcrumbs — raising cost for repeated / targeted use.
• Role multiplier — IdM / FreeIPA front-end: kdcproxy runs on an identity server, which IS a high-value role, but the chain here does NOT end in identity compromise. It ends in internal reconnaissance. Floor is not elevated to HIGH because the bug does not yield ticket forgery, credential access, or lateral movement on its own.
• Trivial config workaround exists: setting use_dns = false or defining explicit [REALM] blocks fully mitigates without a code change — many hardened builds already do this.

Why not higher?

HIGH would require either fleet-scale blast radius or a credible path to credential/identity compromise from this primitive alone. Neither holds: the bug is blind SSRF constrained to Kerberos framing, and there is no evidence in the PoC or vendor advisory of ticket-forgery or LDAP-relay pivots. No KEV listing, EPSS <1%.

Why not lower?

LOW would ignore that this IS an unauthenticated pre-auth primitive against an identity-plane component — cloud metadata endpoints and internal admin panels remain plausible targets, and any IdM box exposed to the internet is a real problem. MEDIUM is the honest bucket.

1. Set use_dns = false in /etc/kdcproxy.conf — Kills the entire SSRF primitive by disabling SRV fallback. Restart the WSGI worker (systemctl restart httpd on IdM). Deploy within the 365-day noisgate MEDIUM window, but do it this week if your kdcproxy is internet-reachable.
2. Define explicit [REALM] entries for every realm you actually serve — Even with use_dns=true, an explicit realm block short-circuits DNS fallback for that realm. Enumerate every trusted realm and hard-code KDC addresses.
3. Front /KdcProxy with an allowlist or mTLS at the reverse proxy — In Apache/nginx in front of kdcproxy, restrict /KdcProxy to known client CIDRs or require client certificates. Prevents opportunistic scan-and-exploit.
4. Egress-filter the kdcproxy host — The kdcproxy service should only need to reach your legitimate KDCs on 88/tcp and 464/tcp. Block loopback aliases, RFC1918 outside the KDC subnet, and 169.254.169.254 at the host firewall (iptables/nftables) or from a network SG.
5. Apply vendor patch — Install RHSA-2025:21142 / :21748 / :21820 / :21821 for RHEL 8/9/10; Ubuntu USN when available. Under noisgate remediation SLA for MEDIUM, complete within 365 days — but bundle into your next monthly IdM maintenance window.

Run on each IdM / FreeIPA server or any host with python-kdcproxy installed. Requires read access to /etc/kdcproxy.conf and the package manager — typically root. Invoke: sudo bash check-cve-2025-59088.sh.

#!/usr/bin/env bash
# check-cve-2025-59088.sh — detects vulnerable python-kdcproxy configurations
# Exit 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u

CONF=/etc/kdcproxy.conf
STATE=UNKNOWN
REASON=""

# 1. Is kdcproxy installed?
if command -v rpm >/dev/null 2>&1; then
  PKG_VER=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' python3-kdcproxy 2>/dev/null || rpm -q --qf '%{VERSION}-%{RELEASE}\n' python-kdcproxy 2>/dev/null)
elif command -v dpkg >/dev/null 2>&1; then
  PKG_VER=$(dpkg-query -W -f='${Version}\n' python3-kdcproxy 2>/dev/null)
fi

if [ -z "${PKG_VER:-}" ]; then
  echo "UNKNOWN: python-kdcproxy not installed"
  exit 2
fi

echo "Installed python-kdcproxy: $PKG_VER"

# 2. Config-level mitigation check
if [ -r "$CONF" ]; then
  if grep -Eiq '^[[:space:]]*use_dns[[:space:]]*=[[:space:]]*(false|no|0)' "$CONF"; then
    STATE=PATCHED
    REASON="use_dns explicitly disabled in $CONF"
  fi
fi

# 3. Package-level check — RHEL fixed builds
case "$PKG_VER" in
  1.0-4.el8_10*|1.0-8.el9_6*|1.0-*.el10*)
    STATE=PATCHED
    REASON="${REASON:+$REASON; }package version contains vendor fix"
    ;;
esac

if [ "$STATE" = "PATCHED" ]; then
  echo "PATCHED: $REASON"
  exit 0
fi

echo "VULNERABLE: python-kdcproxy $PKG_VER without use_dns=false and no fixed package detected"
exit 1

Sources

1. Red Hat Bugzilla 2393955 — CVE-2025-59088
2. RHSA-2025:21142
3. RHSA-2025:21748
4. RHSA-2025:21820
5. RHSA-2025:21821
6. latchset/kdcproxy PR #68 — upstream fix
7. Ubuntu security tracker — CVE-2025-59088
8. SecAlerts summary