API: /accounts/profile returns null KDF for Argon2id accounts authenticated via OAuth2 client_credentials (API key)

[noidgoten]

Steps To Reproduce

1. On a Bitwarden Cloud account, set master-password KDF to Argon2id
   (Account Settings → Security → Master Password → Encryption Settings).
   Example: memory=64 MiB, iterations=4, parallelism=8.

2. Obtain an OAuth2 access token via the API key flow:

   curl -X POST https://identity.bitwarden.com/connect/token
   -H "Bitwarden-Client-Name: cli"
   -H "Bitwarden-Client-Version: 2026.4.1"
   -H "Device-Type: 21"
   -H "Device-Identifier: $(uuidgen)"
   -H "Device-Name: curl-test"
   --data-urlencode grant_type=client_credentials
   --data-urlencode client_id="user."
   --data-urlencode client_secret=""
   --data-urlencode scope=api
   --data-urlencode deviceType=21
   --data-urlencode deviceIdentifier="$(uuidgen)"
   --data-urlencode deviceName=curl-test

3. Call /accounts/profile with the returned access_token:

   curl https://api.bitwarden.com/accounts/profile
   -H "Authorization: Bearer "
   -H "Bitwarden-Client-Name: cli"
   -H "Bitwarden-Client-Version: 2026.4.1"
   -H "Device-Type: 21"
   -H "Device-Identifier: "
   -H "Device-Name: curl-test"

Expected Result

Response includes the account's actual KDF settings, e.g.:

{
"kdf": 1,
"kdfIterations": 4,
"kdfMemory": 64,
"kdfParallelism": 8,
"email": "user@example.com",
...
}

(kdf: 1 = Argon2id per the KdfType enum)

Actual Result

{
"kdf": null,
"kdfIterations": null,
"kdfMemory": null,
"kdfParallelism": null,
"email": "user@example.com",
...
}

All four KDF fields are null. Other profile fields (email, name, etc.) populate
normally.

Screenshots or Videos

No response

Additional Context

Downstream impact (add to description or "additional context"):
bw CLI 2026.3.0 and 2026.4.1 (bitwarden-cli-bin AUR + @bitwarden/cli on npm)
cannot derive the master key after bw login --apikey. bw unlock --raw
returns an 88-char session token, but every subsequent vault command
(bw status, bw list items, etc.) sees kdfType: null in local state,
treats the vault as locked, and falls back to the interactive master-password
prompt — which also fails since KDF is unknown. Effectively makes the
API-key auth path unusable on Argon2id accounts.

Same account works correctly on web vault, Desktop, and mobile clients;
those use the password grant type which appears to return KDF normally.

Reproduces identically on Arch Linux and macOS, on two physically separate
machines, with both pkg-bundled and npm-installed bw clients. Full local-state
wipe (~/.config/Bitwarden CLI/) + API key rotation + re-login does not
change the behavior — narrowing it to server-side, specific to the
client_credentials grant + Argon2id account combination.

Build Version

Bitwarden Cloud (N/A)

Environment

Cloud (bitwarden.com)

Environment Details

• Bitwarden Cloud: identity.bitwarden.com / api.bitwarden.com (US region)
• Account KDF: Argon2id (memory=64 MiB, iterations=4, parallelism=8)
• 2FA: WebAuthn (YubiKey) — note: API key login does authenticate successfully,
  so the token flow itself is fine; the regression is the profile response.
• Affected clients:
  • bw CLI 2026.4.1 (bitwarden-cli-bin AUR, prebuilt pkg-bundled binary)
  • bw CLI 2026.3.0 (same source, prebuilt)
  • bw CLI 2026.4.1 (@bitwarden/cli npm, system Node.js)
• Affected hosts: Arch Linux (kernel 7.0.9) and macOS
• Date observed: 2026-05-18

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-37741
Link (for internal use): https://bitwarden.atlassian.net/browse/PM-37741

[Krychaz]

Hello,

I'm passing this to our Engineering team for further investigation.

[noidgoten]

Re-evaluating after testing: bw CLI 2026.2.0 receives the same null-KDF /accounts/profile response on the same account, yet unlocks correctly — confirmed by downgrading the binary in place and running unlock + list-items successfully. This means the server response isn't the bug; the regression is in bw clients 2026.3.0+, which apparently started relying on kdf from /accounts/profile rather than fetching it via the prelogin path used by earlier versions.

Closing this. The actionable bug is in bitwarden/clients — see #20720 (clients repo).

[noidgoten]

After digging some more, and consolidating my reasoning, i'm reopening the bug.
The CLI was untouched on two machines (one Linux, one macOS) running bw 2026.4.1 for 18 and ≥7 days respectively. Both worked. Both broke around the moment yesterday, while no client-side change occurred on either. The only common variable that changed at that moment is your server response. That's a server regression by definition. The fact the CLI downgrade restores functionality just points towards the regression point.

[lbouriez]

Same on our side, we didnt update the cli it was working and all our pipelines are now failing, the cli is asking for the master password.

[Bilal-Nectari]

We have the same issue on our side! And it is really a big blocker for us. Do you have an ETA on when this will be fixed?

[ggiesen]

Same issue for us. We were running 4.1, and all of a sudden bw serve, when started with an environment variable, starts the vault in locked state, where previously it started in unlocked state. I can still make an API call to unlock it, but it's definitely a change in behaviour in the last few days.

Also hitting this issue again: https://community.bitwarden.com/t/bitwarden-cli-not-syncing-items/42328 which I assume, if not related, is perhaps part of the same backend change/update.

[lbouriez]

Rollbacking to 26.2.0 solved the issue on our side after 48H of CI stucked. Would have been nice to get an update from Bitwarden. We opened a support ticket as well.