<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-07T11:11:31.282415+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-93mf-426m-g6x9</id>
    <title>GHSA-93mf-426m-g6x9 — CoreDNS: DNS Cache Pinning via etcd Lease ID Confusion</title>
    <updated>2026-11-07T11:11:31.283572+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/coredns/coredns</p>
<p># Summary</p>
<p>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.</p>
<p># Details</p>
<p>In `plugin/etcd/etcd.go`, the `TTL()` function casts the 64-bit etcd lease ID to a uint32 and uses it as the TTL:</p>
<p>```go
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
}
```</p>
<p>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.</p>
<p>This enables cache pinning attacks, such as:</p>
<p>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).
4. CoreDNS serves the record with an extreme TTL; downstream resolvers/clients cache it for a very long time.
5. 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.</p>
<p>Some resolvers implement TTL caps, but values and defaults vary widely and are not guaranteed.</p>
<p># PoC</p>
<p>1. Launch etcd:</p>
<p>```bash
etcd \
  --data-dir ./etcd-data \
  --listen-client-ur…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-93mf-426m-g6x9"/>
  </entry>
</feed>
