<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T23:19:16.000828+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-45726</id>
    <title>CVE-2026-45726 — Omni: Reader-level users can retrieve imported cluster CA keys via ResourceService</title>
    <updated>2026-10-05T23:19:16.015373+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> siderolabs omni</p>
<p>Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. From 1.3.0 until 1.6.6 and 1.7.3, importing a standalone Talos cluster creates an ImportedClusterSecrets resource containing the cluster's complete CA secrets bundle. The access rules in internal/backend/runtime/omni/state_access.go allow an authenticated user with the Reader role to retrieve the resource through ResourceService if the importing actor has not rotated those secrets, exposing Kubernetes, Talos, and etcd CA private keys plus the service-account key. The Kubernetes CA private key permits certificate signing for privileged identities such as system:masters and provides control of the imported cluster outside Omni's authorization boundary, including its workloads, credentials, and secrets. This issue is fixed in versions 1.6.6 and 1.7.3.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-45726"/>
  </entry>
</feed>
