<?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 16:30:44 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-11282</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-11282</link>
      <description>bdu:2025-11282</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-11282</guid>
    </item>
    <item>
      <title>BIT-openbao-2025-54997 — OpenBao: Privileged Operator May Execute Code on the Underlying Host</title>
      <link>https://cve.radiocsirt.org/vuln/bit-openbao-2025-54997</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: openbao&lt;/p&gt;
&lt;p&gt;OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, some OpenBao deployments intentionally limit privileged API operators from executing system code or making network connections. However, these operators can bypass both restrictions through the audit subsystem by manipulating log prefixes. This allows unauthorized code execution and network access that violates the intended security model. This issue is fixed in version 2.3.2. To workaround, users can block access to sys/audit/* endpoints using explicit deny policies, but root operators cannot be restricted this way.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: openbao&lt;/p&gt;
&lt;p&gt;OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, some OpenBao deployments intentionally limit privileged API operators from executing system code or making network connections. However, these operators can bypass both restrictions through the audit subsystem by manipulating log prefixes. This allows unauthorized code execution and network access that violates the intended security model. This issue is fixed in version 2.3.2. To workaround, users can block access to sys/audit/* endpoints using explicit deny policies, but root operators cannot be restricted this way.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bit-openbao-2025-54997</guid>
    </item>
    <item>
      <title>EUVD-2026-249393</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-249393</link>
      <description>EUVD-2026-249393</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-249393</guid>
    </item>
    <item>
      <title>fkie_cve-2025-54997</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-54997</link>
      <description>&lt;p&gt;OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, some OpenBao deployments intentionally limit privileged API operators from executing system code or making network connections. However, these operators can bypass both restrictions through the audit subsystem by manipulating log prefixes. This allows unauthorized code execution and network access that violates the intended security model. This issue is fixed in version 2.3.2. To workaround, users can block access to sys/audit/* endpoints using explicit deny policies, but root operators cannot be restricted this way.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, some OpenBao deployments intentionally limit privileged API operators from executing system code or making network connections. However, these operators can bypass both restrictions through the audit subsystem by manipulating log prefixes. This allows unauthorized code execution and network access that violates the intended security model. This issue is fixed in version 2.3.2. To workaround, users can block access to sys/audit/* endpoints using explicit deny policies, but root operators cannot be restricted this way.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-54997</guid>
    </item>
    <item>
      <title>GHSA-xp75-r577-cvhp — Privileged OpenBao Operator May Execute Code on the Underlying Host</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xp75-r577-cvhp</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/openbao/openbao&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Under certain threat models, OpenBao operators with privileged API access may not be system administrators and thus normally lack the ability to update binaries or execute code on the system. Additionally, privileged API operators should be unable to perform TCP connections to arbitrary hosts in the environment OpenBao is executing within. The API-driven audit subsystem granted privileged API operators the ability to do both with an attacker-controlled log prefix. Access to these endpoints should be restricted.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;OpenBao v2.3.2 will patch this issue.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users may deny all access to the `sys/audit/*` interface (with `create` and `update`) permission via policies with explicit deny grants. This would not restrict `root` level operators, however, for whom there are no workarounds.&lt;/p&gt;
&lt;p&gt;This interface allowed arbitrary filesystem and network (write) access as the user the OpenBao server was running as; in conjunction with allowing custom plugins or other system processes this may enable code execution.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:&lt;/p&gt;
&lt;p&gt;- https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vault-operator-may-execute-code-on-the-underlying-host/76033
- https://nvd.nist.gov/vuln/detail/CVE-2025-6000&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/openbao/openbao&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Under certain threat models, OpenBao operators with privileged API access may not be system administrators and thus normally lack the ability to update binaries or execute code on the system. Additionally, privileged API operators should be unable to perform TCP connections to arbitrary hosts in the environment OpenBao is executing within. The API-driven audit subsystem granted privileged API operators the ability to do both with an attacker-controlled log prefix. Access to these endpoints should be restricted.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;OpenBao v2.3.2 will patch this issue.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users may deny all access to the `sys/audit/*` interface (with `create` and `update`) permission via policies with explicit deny grants. This would not restrict `root` level operators, however, for whom there are no workarounds.&lt;/p&gt;
&lt;p&gt;This interface allowed arbitrary filesystem and network (write) access as the user the OpenBao server was running as; in conjunction with allowing custom plugins or other system processes this may enable code execution.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:&lt;/p&gt;
&lt;p&gt;- https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vault-operator-may-execute-code-on-the-underlying-host/76033
- https://nvd.nist.gov/vuln/detail/CVE-2025-6000&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xp75-r577-cvhp</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:15434-1 — govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15434-1</link>
      <description>&lt;p&gt;govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2025:15434-1</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1855 — OpenBao: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1855</link>
      <description>&lt;p&gt;Ein entfernter, authentisierter oder anonymer Angreifer kann mehrere Schwachstellen in OpenBao ausnutzen, um beliebigen Code auszuführen, Root-Rechte zu erlangen, Sicherheitsmaßnahmen zu umgehen und vertrauliche Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, authentisierter oder anonymer Angreifer kann mehrere Schwachstellen in OpenBao ausnutzen, um beliebigen Code auszuführen, Root-Rechte zu erlangen, Sicherheitsmaßnahmen zu umgehen und vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1855</guid>
    </item>
  </channel>
</rss>
