Vaultwarden—the popular lightweight, self-hosted password manager—recently patched a critical vulnerability tracked as CVE-2024-55225. This issue, found in the src/api/identity.rs Rust source file, could let an attacker impersonate any user, including Administrators, with a specially crafted authorization request.

Below, we break down how this bug worked, its impact, how an attacker could exploit it, and what you should do right now. All technical code is kept as simple as possible for clarity.

What is Vaultwarden?

Vaultwarden (previously called Bitwarden_RS) is an unofficial, self-hosted server implementation of the Bitwarden password manager, written in Rust. It's easy to run on low-resource servers like Raspberry Pi.

Official repo

- https://github.com/dani-garcia/vaultwarden

Affected versions: All Vaultwarden versions before v1.32.5

- Component: src/api/identity.rs

Severity: Critical

- Impact: Any user, including admin accounts, can be impersonated just by abusing a flaw in authorization logic.

How the Bug Happens

Vaultwarden uses tokens (like JWTs) to prove who you are. But, before version 1.32.5, it incorrectly validated these tokens at a certain authentication point: Token fields weren't checked strictly enough, especially on critical endpoints.

In particular, when handling certain types of login or authorization requests, Vaultwarden would extract the user’s identity (“sub”) from the token but fail to verify the token’s signature or other fields properly. So, a hacker could create a fake authorization token where they set the sub (subject) field to any user’s ID—including an admin's.

Here’s a simplified example how an attacker could fake a token

// (Pseudocode, not full exploit)

let fake_token_payload = serde_json::json!({
    "sub": "target_admin_user_id",
    "exp": 1999999999, // not expired
    // other irrelevant fields
});

// encode without valid signature (or with a dummy signature)
let token_str = base64::encode(fake_token_payload.to_string()) + ".FAKESIGNATURE";

// Craft an HTTP Authorization header:
let client = reqwest::blocking::Client::new();
let res = client
    .get("http://target.vaultwarden.instance/api/identity/account";)
    .header("Authorization", format!("Bearer {}", token_str))
    .send()
    .unwrap();

println!("{:?}", res.text());

Result: Vaultwarden would regard you as target_admin_user_id and let you act as the admin!

Who needs access?

- Anyone who can send HTTP requests to your Vaultwarden server—most commonly, LAN or internet users (if your server is exposed).

Here’s the basic flow

1. Get a valid User ID: The attacker figures out the victim's user id (possible via registration timing, enumeration, or public info).

Send API requests: They use this forged token to interact with Vaultwarden as the victim.

4. Enjoy admin or user control: If this token names the admin id, the attacker now becomes the admin.

Patch and Fix

Maintainer’s fix:
The Vaultwarden team fixed the bug in v1.32.5 by strictly verifying signatures on each sensitive endpoint and improving token parsing and validation in src/api/identity.rs.

Commit diff:
- Relevant commit
- Release notes 1.32.5

Mitigation:

References

- CVE-2024-55225 at NVD (Not yet fully populated at time of writing)
- Vaultwarden Official Release
- HackerOne writeup for similar issues *(not this CVE, but similar flaw for context)*
- Vaultwarden Security Policy

Conclusion

CVE-2024-55225 is a dangerous flaw—one of the most serious bugs seen in Vaultwarden for years. With only a forged token, attackers could become anyone, even admins. If you run Vaultwarden, upgrade to v1.32.5 or later now.

Don’t delay: This issue has a simple exploit and is easy to automate. Your security depends on swift action!


*If you found this useful, share with other self-hosters and sysadmins. Stay safe!*

Timeline

Published on: 01/09/2025 21:15:29 UTC
Last modified on: 01/10/2025 18:15:24 UTC