{"id":"CVE-2025-55001","aliases":["BIT-openbao-2025-55001","EUVD-2025-24033","GHSA-2q8q-8fgw-9p6p","GO-2025-3859","SUSE-SU-2025:02912-1","openSUSE-SU-2025:15434-1"],"status":"published","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"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.","severity":{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00262,"percentile":0.18204,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-156"],"published":"2025-08-08T15:17:09Z","modified":"2026-10-28T02:31:06Z","fixes":[{"ecosystem":"Go","package":"github.com/openbao/openbao","fixed_in":["2.3.2","0.0.0-20250807212521-c52795c1ef74"],"sources":["ghsa","osv"]},{"ecosystem":"Bitnami","package":"openbao","fixed_in":["0.0.0-20250807212521-c52795c1ef74","2.3.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/openbao/openbao","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.0"},{"fixed":"2.3.2"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/openbao/openbao","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.0-20250807212521-c52795c1ef74"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"openbao","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20250807212521-c52795c1ef74"},{"introduced":"0.0.1"},{"fixed":"2.3.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/openbao/openbao","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.0"},{"fixed":"2.3.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/openbao/openbao","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20250807212521-c52795c1ef74"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/openbao/openbao","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20250807212521-c52795c1ef74"},{"introduced":"0.1.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250811T192933-1.1"}]}],"bundled":29}],"products":[{"vendor":"openbao","product":"openbao"}],"references":[{"url":"https://github.com/openbao/openbao/security/advisories/GHSA-2q8q-8fgw-9p6p","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/openbao/openbao/commit/c52795c1ef746c7f2c510f9225aa8ccbbd44f9fc","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092","tags":["x_refsource_MISC","Not Applicable","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-6013","tags":["advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-55001","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-2q8q-8fgw-9p6p"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/55xxx/CVE-2025-55001.json","tags":["advisory"]},{"url":"https://github.com/openbao/openbao","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502912-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2021-21411","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-44906","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-44779","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47907","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-50738","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53534","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53942","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54386","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54388","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54410","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54424","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54576","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54799","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54801","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54996","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54997","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54998","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55001","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55003","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-5999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6004","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6011","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6013","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6014","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6015","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6037","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-7195","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-8341","tags":["web"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2025-55001","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"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.","status":"published","published":"2025-08-09T02:01:29.056Z","modified":"2025-08-11T14:45:37.326Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-156"],"updated_at":"2026-11-02T14:32:52.839698Z"}],"euvd":[{"id":"EUVD-2025-24033","description":"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.","status":"published","published":"2025-08-09T02:01:29Z","modified":"2025-08-11T14:45:37Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T20:31:59.900029Z"}],"ghsa":[{"id":"GHSA-2q8q-8fgw-9p6p","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"### Impact\n\nOpenBao 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.\n\n### Patches\n\nOpenBao v2.3.2 will patch this issue.\n\n### Workarounds\n\nLDAP methods are only vulnerable if using `username_as_alias=true`. Remove all usage of this parameter and update any entity aliases accordingly.\n\n### References\n\nThis issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:\n\n- https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092\n- https://nvd.nist.gov/vuln/detail/CVE-2025-6013","status":"published","published":"2025-08-08T15:17:09Z","modified":"2025-08-11T13:56:50Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-156"],"updated_at":"2026-11-02T14:38:53.767052Z"}],"nvd":[{"id":"CVE-2025-55001","description":"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.","status":"published","published":"2025-08-09T03:15:46.887Z","modified":"2026-06-17T09:41:05.64Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-156"],"updated_at":"2026-11-02T14:11:22.953396Z"}],"osv":[{"id":"CVE-2025-55001","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"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.","status":"published","published":"2025-08-09T02:01:29.056Z","modified":"2026-10-28T02:31:06.842074602Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-156"],"updated_at":"2026-11-02T15:44:50.863921Z"},{"id":"GHSA-2q8q-8fgw-9p6p","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"### Impact\n\nOpenBao 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.\n\n### Patches\n\nOpenBao v2.3.2 will patch this issue.\n\n### Workarounds\n\nLDAP methods are only vulnerable if using `username_as_alias=true`. Remove all usage of this parameter and update any entity aliases accordingly.\n\n### References\n\nThis issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:\n\n- https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092\n- https://nvd.nist.gov/vuln/detail/CVE-2025-6013","status":"published","published":"2025-08-08T15:17:09Z","modified":"2026-07-27T09:11:18.365990511Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-156"],"updated_at":"2026-11-02T15:46:34.700741Z"},{"id":"BIT-openbao-2025-55001","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias","description":"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.","status":"published","published":"2026-07-27T05:48:56.61Z","modified":"2026-09-08T08:48:16.787177995Z","updated_at":"2026-11-02T15:28:34.343258Z"},{"id":"GO-2025-3859","title":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias in github.com/openbao/openbao","description":"OpenBao LDAP MFA Enforcement Bypass When Using Username As Alias in github.com/openbao/openbao.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: github.com/openbao/openbao before v2.3.2.","status":"published","published":"2025-08-11T17:59:12Z","modified":"2026-07-27T09:11:18.365990511Z","updated_at":"2026-11-02T15:47:01.728182Z"},{"id":"openSUSE-SU-2025:15434-1","title":"govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20250811T192933-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-08-12T00:00:00Z","modified":"2026-03-23T04:53:46.634804Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"SUSE-SU-2025:02912-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20250814T182633 2025-08-14T18:26:33Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3765 CVE-2024-44906 GHSA-h4h6-vccr-44h2\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n\n- Update to version 0.0.20250811T192933 2025-08-11T19:29:33Z (jsc#PED-11136)\n  \n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3822 CVE-2025-53942 GHSA-9g4j-v8w5-7x42\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n  * GO-2025-3830 CVE-2025-54388 GHSA-x4rx-4gw3-53p4\n  * GO-2025-3831 CVE-2025-50738 GHSA-hfcf-79gh-f3jc\n  * GO-2025-3832 CVE-2021-21411 GHSA-652x-m2gr-hppm\n  * GO-2025-3833 CVE-2025-54576 GHSA-7rh7-c77v-6434\n  * GO-2025-3834 CVE-2025-54424 GHSA-8j63-96wh-wh3j\n  * GO-2025-3835 CVE-2025-54386 GHSA-q6gg-9f92-r9wg\n  * GO-2025-3836 CVE-2025-6037 GHSA-6c5r-4wfc-3mcx\n  * GO-2025-3837 CVE-2025-5999 GHSA-6h4p-m86h-hhgh\n  * GO-2025-3838 CVE-2025-6000 GHSA-mr4h-qf9j-f665\n  * GO-2025-3839 CVE-2025-6011 GHSA-mwgr-84fv-3jh9\n  * GO-2025-3840 CVE-2025-6004 GHSA-qgj7-fmq2-6cc4\n  * GO-2025-3841 CVE-2025-6014 GHSA-qv3p-fmv3-9hww\n  * GO-2025-3842 CVE-2025-6015 GHSA-v6r4-35f9-9rpw\n  * GO-2025-3843 CVE-2025-8341 GHSA-3c93-92r7-j934\n  * GO-2025-3844 CVE-2025-53534 GHSA-fm3m-jrgm-5ppg\n  * GO-2025-3845 CVE-2025-54801 GHSA-qx2q-88mx-vhg7\n  * GO-2025-3847 CVE-2025-54799 GHSA-q82r-2j7m-9rv4\n  * GO-2025-3848 CVE-2025-6013 GHSA-7rx2-769v-hrwf\n  * GO-2025-3851 CVE-2025-44779 GHSA-93jv-pvg8-hf3v\n  * GO-2025-3852 CVE-2025-7195 GHSA-856v-8qm2-9wjv\n  * GO-2025-3853 CVE-2025-55000 GHSA-f7c3-mhj2-9pvg\n  * GO-2025-3854 CVE-2025-54999 GHSA-hh28-h22f-8357\n  * GO-2025-3855 CVE-2025-54998 GHSA-j3xv-7fxp-gfhx\n  * GO-2025-3856 CVE-2025-55003 GHSA-rxp7-9q75-vj3p\n  * GO-2025-3857 CVE-2025-54996 GHSA-vf84-mxrq-crqc\n  * GO-2025-3858 CVE-2025-54997 GHSA-xp75-r577-cvhp\n  * GO-2025-3859 CVE-2025-55001 GHSA-2q8q-8fgw-9p6p\n\n- Update to version 0.0.20250807T150727 2025-08-07T15:07:27Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3849 CVE-2025-47907\n","status":"published","published":"2025-08-19T12:52:27Z","modified":"2026-03-23T04:49:48.54789Z","updated_at":"2026-11-02T15:53:57.111474Z"}]}}