<?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>Sun, 04 Oct 2026 23:19:29 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-11277</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-11277</link>
      <description>bdu:2025-11277</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-11277</guid>
    </item>
    <item>
      <title>BIT-openbao-2025-54999 — OpenBao: Timing Side-Channel in Userpass Auth Method</title>
      <link>https://cve.radiocsirt.org/vuln/bit-openbao-2025-54999</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 0.1.0 through 2.3.1, when using OpenBao&amp;#39;s userpass auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user. This issue was fixed in version 2.3.2. To work around this issue, users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/.&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 0.1.0 through 2.3.1, when using OpenBao&amp;#39;s userpass auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user. This issue was fixed in version 2.3.2. To work around this issue, users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bit-openbao-2025-54999</guid>
    </item>
    <item>
      <title>cnvd-2025-18600</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2025-18600</link>
      <description>cnvd-2025-18600</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2025-18600</guid>
    </item>
    <item>
      <title>EUVD-2026-249398</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-249398</link>
      <description>EUVD-2026-249398</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-249398</guid>
    </item>
    <item>
      <title>fkie_cve-2025-54999</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-54999</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 0.1.0 through 2.3.1, when using OpenBao&amp;#39;s userpass auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user. This issue was fixed in version 2.3.2. To work around this issue, users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/.&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 0.1.0 through 2.3.1, when using OpenBao&amp;#39;s userpass auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user. This issue was fixed in version 2.3.2. To work around this issue, users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-54999</guid>
    </item>
    <item>
      <title>GHSA-hh28-h22f-8357 — OpenBao has a Timing Side-Channel in the Userpass Auth Method</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hh28-h22f-8357</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;When using OpenBao&amp;#39;s `userpass` auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user.&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 use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/&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-15-timing-side-channel-in-vault-s-userpass-auth-method/76034
- https://nvd.nist.gov/vuln/detail/CVE-2025-6011&lt;/p&gt;
&lt;p&gt;Barring further information, this is also assumed to cover and remediate the following additional vulnerability:&lt;/p&gt;
&lt;p&gt;- https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enumeration-in-userpass-auth-method/76095
- https://nvd.nist.gov/vuln/detail/CVE-2025-6010&lt;/p&gt;
&lt;p&gt;If this is not the case as further details emerge, a new CVE will be assigned for remediating that. Otherwise, no further CVE will be sought.&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;When using OpenBao&amp;#39;s `userpass` auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user.&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 use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/&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-15-timing-side-channel-in-vault-s-userpass-auth-method/76034
- https://nvd.nist.gov/vuln/detail/CVE-2025-6011&lt;/p&gt;
&lt;p&gt;Barring further information, this is also assumed to cover and remediate the following additional vulnerability:&lt;/p&gt;
&lt;p&gt;- https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enumeration-in-userpass-auth-method/76095
- https://nvd.nist.gov/vuln/detail/CVE-2025-6010&lt;/p&gt;
&lt;p&gt;If this is not the case as further details emerge, a new CVE will be assigned for remediating that. Otherwise, no further CVE will be sought.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hh28-h22f-8357</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>
