<?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-04T11:33:51.709563+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/bdu:2025-11279</id>
    <title>bdu:2025-11279</title>
    <updated>2026-10-04T11:33:51.718504+00:00</updated>
    <content>bdu:2025-11279</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-11279"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bit-openbao-2025-55001</id>
    <title>BIT-openbao-2025-55001 — OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias</title>
    <updated>2026-10-04T11:33:51.718538+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Bitnami: openbao</p>
<p>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, OpenBao allowed the assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When the username_as_alias=true parameter in the LDAP auth method was in use, the caller-supplied username was used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements. This issue was fixed in version 2.3.2. To work around this, remove all usage of the username_as_alias=true parameter and update any entity aliases accordingly.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bit-openbao-2025-55001"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cnvd-2025-18598</id>
    <title>cnvd-2025-18598</title>
    <updated>2026-10-04T11:33:51.718574+00:00</updated>
    <content>cnvd-2025-18598</content>
    <link href="https://cve.radiocsirt.org/vuln/cnvd-2025-18598"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-249400</id>
    <title>EUVD-2026-249400</title>
    <updated>2026-10-04T11:33:51.718587+00:00</updated>
    <content>EUVD-2026-249400</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-249400"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-55001</id>
    <title>fkie_cve-2025-55001</title>
    <updated>2026-10-04T11:33:51.718598+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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, OpenBao allowed the assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When the username_as_alias=true parameter in the LDAP auth method was in use, the caller-supplied username was used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements. This issue was fixed in version 2.3.2. To work around this, remove all usage of the username_as_alias=true parameter and update any entity aliases accordingly.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-55001"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-2q8q-8fgw-9p6p</id>
    <title>GHSA-2q8q-8fgw-9p6p — OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias</title>
    <updated>2026-10-04T11:33:51.718620+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/openbao/openbao</p>
<p>### Impact</p>
<p>OpenBao allows assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When using the `username_as_alias=true` parameter in the LDAP auth method, the caller-supplied username is used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements.</p>
<p>### Patches</p>
<p>OpenBao v2.3.2 will patch this issue.</p>
<p>### Workarounds</p>
<p>LDAP methods are only vulnerable if using `username_as_alias=true`. Remove all usage of this parameter and update any entity aliases accordingly.</p>
<p>### References</p>
<p>This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:</p>
<p>- https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092
- https://nvd.nist.gov/vuln/detail/CVE-2025-6013</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-2q8q-8fgw-9p6p"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15434-1</id>
    <title>openSUSE-SU-2025:15434-1 — govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media</title>
    <updated>2026-10-04T11:33:51.718656+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2025:15434-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1855</id>
    <title>WID-SEC-W-2025-1855 — OpenBao: Mehrere Schwachstellen</title>
    <updated>2026-10-04T11:33:51.718681+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1855"/>
  </entry>
</feed>
