<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 22:00:39 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12027</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12027</link>
      <description>bdu:2026-12027</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12027</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0608 — De multiples vulnérabilités ont été découvertes dans Microsoft Azure Linux. Elles permettent à un attaquant de provoque…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0608</link>
      <description>certfr-2026-avi-0608</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0608</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-BB57522 — Security fixes in kubernetes-dns-node-cache 1.25.0-r8</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-bb57522</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: kubernetes-dns-node-cache&lt;/p&gt;
&lt;p&gt;Package kubernetes-dns-node-cache version 1.25.0-r8 fixes 17 vulnerabilities: CVE-2026-41178, CVE-2026-35579, CVE-2026-46600, CVE-2025-64702, CVE-2025-68151...&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: kubernetes-dns-node-cache&lt;/p&gt;
&lt;p&gt;Package kubernetes-dns-node-cache version 1.25.0-r8 fixes 17 vulnerabilities: CVE-2026-41178, CVE-2026-35579, CVE-2026-46600, CVE-2025-64702, CVE-2025-68151...&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-bb57522</guid>
    </item>
    <item>
      <title>EUVD-2026-308635</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-308635</link>
      <description>EUVD-2026-308635</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-308635</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33489</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33489</link>
      <description>&lt;p&gt;CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. The longestMatch() function in plugin/transfer/transfer.go uses a lexicographic string comparison instead of an actual longest-suffix match to select the winning zone. As a result, a permissive parent-zone transfer rule can override a restrictive subzone rule depending on zone name ordering (e.g., &amp;#34;example.org.&amp;#34; &amp;gt; &amp;#34;a.example.org.&amp;#34; lexicographically). This allows an unauthorized remote client to perform AXFR/IXFR for the subzone and retrieve its full zone contents. This issue has been fixed in version 1.14.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. The longestMatch() function in plugin/transfer/transfer.go uses a lexicographic string comparison instead of an actual longest-suffix match to select the winning zone. As a result, a permissive parent-zone transfer rule can override a restrictive subzone rule depending on zone name ordering (e.g., &amp;#34;example.org.&amp;#34; &amp;gt; &amp;#34;a.example.org.&amp;#34; lexicographically). This allows an unauthorized remote client to perform AXFR/IXFR for the subzone and retrieve its full zone contents. This issue has been fixed in version 1.14.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33489</guid>
    </item>
    <item>
      <title>GHSA-h8mm-c463-wjq3 — CoreDNS' transfer stanza selection uses lexicographic compare (subzone ACL bypass)</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h8mm-c463-wjq3</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/coredns/coredns&lt;/p&gt;
&lt;p&gt;### Summary
CoreDNS&amp;#39; transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.&lt;/p&gt;
&lt;p&gt;### Details
In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as &amp;#34;longest zone match wins&amp;#34;, but it actually chooses the winner via a lexicographic string comparison:
- zone := &amp;#34;&amp;#34; // longest zone match wins (plugin/transfer/transfer.go)
- if z &amp;gt; zone { zone = z; x = xfr } (plugin/transfer/transfer.go)&lt;/p&gt;
&lt;p&gt;So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering (&amp;#34;example.org.&amp;#34; &amp;gt; &amp;#34;a.example.org.&amp;#34;), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.&lt;/p&gt;
&lt;p&gt;### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
2. Run python3 ./acl-repro.py
3. Expected output:
*** Baseline (only subzone transfer rule) ***
axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)&lt;/p&gt;
&lt;p&gt;*** Candidate (add permissive parent transfer rule) ***
axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount&amp;gt;0)&lt;/p&gt;
&lt;p&gt;*** OK ***
Subzone transfer ACL bypass reproduced: adding a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/coredns/coredns&lt;/p&gt;
&lt;p&gt;### Summary
CoreDNS&amp;#39; transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.&lt;/p&gt;
&lt;p&gt;### Details
In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as &amp;#34;longest zone match wins&amp;#34;, but it actually chooses the winner via a lexicographic string comparison:
- zone := &amp;#34;&amp;#34; // longest zone match wins (plugin/transfer/transfer.go)
- if z &amp;gt; zone { zone = z; x = xfr } (plugin/transfer/transfer.go)&lt;/p&gt;
&lt;p&gt;So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering (&amp;#34;example.org.&amp;#34; &amp;gt; &amp;#34;a.example.org.&amp;#34;), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.&lt;/p&gt;
&lt;p&gt;### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
2. Run python3 ./acl-repro.py
3. Expected output:
*** Baseline (only subzone transfer rule) ***
axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)&lt;/p&gt;
&lt;p&gt;*** Candidate (add permissive parent transfer rule) ***
axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount&amp;gt;0)&lt;/p&gt;
&lt;p&gt;*** OK ***
Subzone transfer ACL bypass reproduced: adding a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h8mm-c463-wjq3</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-33489 — CoreDNS transfer plugin subzone ACL bypass via lexicographic zone comparison</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-33489</link>
      <description>msrc_CVE-2026-33489</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-33489</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20703-1 — Security update for coredns</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20703-1</link>
      <description>&lt;p&gt;Security update for coredns&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for coredns&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:20703-1</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1283 — CoreDNS: Mehrere Schwachstellen ermöglichen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1283</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in CoreDNS ausnutzen, um Sicherheitsmaßnahmen zu umgehen und so vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in CoreDNS ausnutzen, um Sicherheitsmaßnahmen zu umgehen und so vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1283</guid>
    </item>
  </channel>
</rss>
