Edit: even if the TLD they use is .ai and they heavily promote themselves as revolutionary AI security firm yadda yadda yadda
I would be curious what AI tools assisted in this and also what tools/models could re-discover them on the unpatched code base now that we know they exist.
Edit: replaced link with link to HN post, not the article in that post.
One of the vault backends has a size limit and so secret keys larger than 2048 bits would not fit. Amazing tool.
But I'm neither a security person nor have I done much with authentication since my 2000's PHP hobbying. I suspect an LDAP server has to deal with or try and manage a lot of garbage input because of the sheer number of integrations they often have.
I'm very disappointed to hear that the researchers did not disclose these findings to the OpenBao project before publishing them, so you now have to rush a release like this
Will you reach out to the researchers for an explanation after you've fixed the issues?
explanation ≠ excuse
My impression is that there is an information gap about forked projects that lead to this issue
I'm on vacation right now, but when I'm back I'll try to setup a small site that lists forks of popular projects and maybe some information on when in time the project was forked
Hopefully something like that can make it more likely that these things are responsibly disclosed to all relevant projects
It also doesn't sound like the researchers made an effort to safely disclose these findings to the OpenBao project before publishing them, which I think would have been the right thing to do
Wait, why would I care this is "daka" in Hebrew? Is this a hallucination or did they edit poorly?
That said, I think it's weird; the vulnerabilities seem to have been found by doing a thorough code review and comprehension, why then cut corners by passing the writeup through AI?
CVE-2025-6010 - [REDACTED]
CVE-2025-6004 - Lockout Bypass https://feedly.com/cve/CVE-2025-6004
Via case permutation in userpass auth Via input normalization mismatch in LDAP auth
CVE-2025-6011 - Timing-Based Username Enumeration https://feedly.com/cve/CVE-2025-6011
Identify valid usernames
CVE-2025-6003 - MFA Enforcement Bypass https://feedly.com/cve/CVE-2025-6003
Via username_as_alias configuration in LDAP
CVE-2025-6013 - Multiple EntityID Generation https://feedly.com/cve/CVE-2025-6013
Allows LDAP users to generate multiple EntityIDs for the same identity
CVE-2025-6016 - TOTP MFA Weaknesses https://feedly.com/cve/CVE-2025-6016
Aggregated logic flaws in TOTP implementation
CVE-2025-6037 - Certificate Entity Impersonation https://feedly.com/cve/CVE-2025-6037
Existed for 8+ years in Vault
CVE-2025-5999 - Root Privilege Escalation https://feedly.com/cve/CVE-2025-5999
Admin to root escalation via policy normalization
CVE-2025-6000 - Remote Code Execution https://feedly.com/cve/CVE-2025-6000
First public RCE in Vault (existed for 9 years) Via plugin catalog abuse > https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vau...
In non-CA mode, an attacker who has access to the private key of a pinned certificate can:
Present a certificate with the correct public key
Modify the CN in the client certificate to any arbitrary value
Cause Vault to assign the resulting alias.Name to that CN
I agree that this is an issue, but if an attacker has access to the private key of a pinned certificate, you might have some bigger issues...If your input from user is a string, define a newtype like UserName and do all validation and normalization once to convert it. All subsequent code should be using that type and not raw strings, so it will be consistent everywhere.
v5v3•2h ago