{"vulnerability": "CVE-2026-4716", "sightings": [{"uuid": "7cce2891-261e-4413-8ef3-8f66a2ace5e1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://bsky.app/profile/thehackerwire.bsky.social/post/3mhtw5rqakf2r", "content": "", "creation_timestamp": "2026-03-25T01:17:20.745355Z"}, {"uuid": "5c4a3391-d8ea-4711-919e-4bb95fbc8074", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/mozilla-products-multiple-vulnerabilities_20260325", "content": "", "creation_timestamp": "2026-03-25T03:00:00.000000Z"}, {"uuid": "132a361c-4fed-42ad-af16-f9ad43cfa48e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://bsky.app/profile/slackers.it/post/3mhu7d5fxxt2w", "content": "", "creation_timestamp": "2026-03-25T04:01:25.901942Z"}, {"uuid": "c847ba69-6614-4061-81f8-c80992fae357", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://bsky.app/profile/thehackerwire.bsky.social/post/3mhtva2knmm2r", "content": "", "creation_timestamp": "2026-03-25T01:00:43.485300Z"}, {"uuid": "d3fff99c-8a9e-4bc3-8783-e1f870430a84", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://bsky.app/profile/thehackerwire.bsky.social/post/3mhtvafbhdx2x", "content": "", "creation_timestamp": "2026-03-25T01:00:54.267852Z"}, {"uuid": "0f372fda-2725-432b-9212-5c06cd0a88f2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-4716", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/actualite/CERTFR-2026-ACT-013/", "content": "", "creation_timestamp": "2026-03-29T17:00:00.000000Z"}, {"uuid": "778c0159-dc37-4f86-8d42-c77ec02fea35", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-47164", "type": "seen", "source": "https://gist.github.com/Atomics-hub/546bf5d8d27b37858eec964a75f37206", "content": "# Vaultwarden SSO existing-user binding skips the IdP `email_verified` check (CVE-2026-47164)\n\n**Advisory:** [GHSA-6x5c-84vm-5j56](https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-6x5c-84vm-5j56)\n**CVE:** CVE-2026-47164\n**Severity:** HIGH \u2014 CVSS 7.7 (`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L`)\n**CWE:** CWE-284 (Improper Access Control)\n**Affected:** vaultwarden \u2264 1.35.8 \u2014 **Fixed in [1.36.0](https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0)**\n**Credits:** [@ch1nhpd](https://github.com/ch1nhpd) (original reporter, 2026-03-22) and [@Atomics-hub](https://github.com/Atomics-hub) (independent reporter, 2026-04-29). I'm Atomics-hub. ch1nhpd was first by about five weeks; my submission was triaged as a duplicate and I was credited on the published advisory.\n\nThis writeup is the independent-reporter perspective. I didn't see ch1nhpd's report when I submitted \u2014 Vaultwarden's pre-publication advisories aren't visible to non-collaborators, and the bug had not yet been disclosed when I started auditing. That's the structural risk of being second on a fresh source audit; I'll come back to it at the end.\n\n## TL;DR\n\nVaultwarden's OIDC SSO login flow has two paths after the IdP callback: a new-user-creation branch and an existing-user-binding branch. The new-user branch enforces the IdP's `email_verified` claim. The existing-user branch, in versions \u2264 1.35.8, did not.\n\nIf an attacker can register an account at the configured IdP claiming a victim's email address \u2014 with `email_verified` set to `false` or `null` \u2014 Vaultwarden's existing-user branch will bind the attacker's IdP identity to the victim's pre-existing Vaultwarden account and issue a session token for that account. The documented \"safe\" defaults (`SSO_SIGNUPS_MATCH_EMAIL=true`, `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false`) do not stop this. 2FA on the victim account does stop it; the attack is gated by Vaultwarden's existing 2FA challenge.\n\n## The bug\n\nAll line numbers below are from [`src/api/identity.rs`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/identity.rs) at commit `62748100` \u2014 the upstream `main` at the time I submitted (2026-04-28).\n\nThe SSO login handler resolves the incoming IdP identity by:\n\n1. Looking up an existing `SsoUser` by stable identifier (issuer + subject).\n2. If none, falling back to looking up a local user by the IdP-supplied email.\n\n```rust\n// src/api/identity.rs:204-234\nlet user_with_sso = match SsoUser::find_by_identifier(&user_infos.identifier, conn).await {\n    None => match SsoUser::find_by_mail(&user_infos.email, conn).await {\n        None => None,\n        Some((user, Some(_))) => err_silent!(\"Existing SSO user with same email\", ...),\n        Some((user, None)) if user.private_key.is_some() && !CONFIG.sso_signups_match_email() =>\n            err_silent!(\"Existing non SSO user with same email\", ...),\n        Some((user, None)) => Some((user, None)),   // existing-user binding\n    },\n    Some((user, sso_user)) => Some((user, Some(sso_user))),\n};\n```\n\nThe path that returns `Some((user, None))` binds the IdP identity to any existing Vaultwarden user that matches by email, as long as `sso_signups_match_email()` is true (the default).\n\nThen a second `match` decides how to finish the login. The new-user branch (lines 239-273) checks `email_verified`:\n\n```rust\n// src/api/identity.rs:249-264\nmatch user_infos.email_verified {\n    None if !CONFIG.sso_allow_unknown_email_verification() => err!(\n        \"Your provider does not send email verification status...\"\n    ),\n    Some(false) => err!(\n        \"You need to verify your email with your provider before you can log in\"\n    ),\n    _ => (),\n}\n```\n\nThe existing-user branch (lines 283-307) does not. It goes straight to `twofactor_auth` and, if the victim has no 2FA, hands out a session bound to the victim's UUID:\n\n```rust\n// src/api/identity.rs:283-307\nSome((mut user, sso_user)) => {\n    let mut device = get_device(&data, conn, &user).await?;\n    let twofactor_token = twofactor_auth(&mut user, &data, &mut device, ip, client_version, conn).await?;\n    // ... no email_verified check anywhere on this branch ...\n    if user.email != user_infos.email {\n        if CONFIG.mail_enabled() {\n            mail::send_sso_change_email(&user_infos.email).await?;\n        }\n        info!(\"User {} email changed in SSO provider from {} to {}\", user.uuid, user.email, user_infos.email);\n    }\n    (user, device, twofactor_token, sso_user)\n}\n```\n\nThe `user.email != user_infos.email` notification at line 298 never fires for this attack because the IdP claim has to match an existing Vaultwarden email exactly for the lookup at line 205 to succeed.\n\nThe maintainer's own warning on `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION` in [`src/config.rs:809`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/config.rs#L809) reads:\n\n> Allow unknown email verification status |> Allowing this with `SSO_SIGNUPS_MATCH_EMAIL=true` open potential account takeover.\n\nThe threat model was already understood; the warning was conditioned on the unsafe combination. The bug here defeats the documented safe default \u2014 even with `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false`, the existing-user branch never reaches the gate.\n\n## 2FA mitigation\n\n`twofactor_auth` at line 286 is the only check between the existing-user binding and session issuance. Its early-return for users without 2FA is what makes this exploitable:\n\n```rust\n// src/api/identity.rs:740-746\nlet twofactors = TwoFactor::find_by_user(&user.uuid, conn).await;\n\n// No twofactor token if twofactor is disabled\nif twofactors.is_empty() {\n    enforce_2fa_policy(user, &user.uuid, device.atype, &ip.ip, conn).await?;\n    return Ok(None);\n}\n```\n\nA victim with any usable 2FA method blocks at line 758 (\"No enabled and usable two factor providers are available\") or line 777 (\"2FA token not provided\"). A 2FA-protected victim is not exploitable through this path.\n\nVaultwarden does not enforce 2FA by default, so whether this mitigation applies depends on the individual user.\n\n## Comparison with upstream Bitwarden\n\nBitwarden's official server does not bind SSO to an existing user via IdP email alone. It requires an invite-acceptance round-trip: an org admin invites the email, the recipient clicks an emailed link, the row goes from `Invited` to `Accepted`, and only then can SSO attach.\n\nThe relevant block lives in [`bitwarden_license/src/Sso/Controllers/AccountController.cs`](https://github.com/bitwarden/server/blob/main/bitwarden_license/src/Sso/Controllers/AccountController.cs) and is prefaced with a comment header titled \"Critical Code Check Here\":\n\n```csharp\n// bitwarden_license/src/Sso/Controllers/AccountController.cs:533-562\nOrganizationUser guaranteedOrgUser = possibleOrgUser\n    ?? throw new Exception(_i18nService.T(\"UserAlreadyExistsInviteProcess\"));\n\n/*\n * ----------------------------------------------------\n *              Critical Code Check Here\n *\n * We want to ensure a user is not in the invited state\n * explicitly. User's in the invited state should not\n * be able to authenticate via SSO.\n *\n * See internal doc called \"Added Context for SSO Login\n * Flows\" for further details.\n * ----------------------------------------------------\n */\nif (guaranteedOrgUser.Status == OrganizationUserStatusType.Invited)\n{\n    throw new Exception(\n        _i18nService.T(\"AcceptInviteBeforeUsingSSO\", organization.DisplayName()));\n}\n\nEnforceAllowedOrgUserStatus(\n    guaranteedOrgUser.Status,\n    allowedStatuses: [\n        OrganizationUserStatusType.Accepted,\n        OrganizationUserStatusType.Confirmed\n    ],\n    organization.DisplayName());\n```\n\nEmail ownership is proved by the invite-acceptance round-trip, so the `email_verified` IdP claim is not load-bearing. Vaultwarden's existing-user branch performs neither check \u2014 the binding succeeds based purely on the IdP-supplied email matching a row in the `users` table.\n\nI bring this up not as a direct port suggestion \u2014 Vaultwarden is an independent reimplementation and has its own constraints \u2014 but because the upstream's comment (\"Critical Code Check Here\") is exactly the comment a Vaultwarden maintainer would want next to the existing-user branch.\n\n## PoC\n\nI reproduced this against `vaultwarden/server:latest` on 2026-04-28 with Keycloak as the IdP. The reproducer (`docker/run_poc.sh`):\n\n1. Provisions a Vaultwarden OIDC client in Keycloak via the admin API.\n2. Starts Vaultwarden with the documented \"safe\" defaults: `SSO_ENABLED=true`, `SSO_SIGNUPS_MATCH_EMAIL=true`, `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false`.\n3. Registers victim `victim@example.com` in Vaultwarden via password registration. No 2FA.\n4. Creates Keycloak user `attacker` with `email=victim@example.com`, `emailVerified=false`.\n5. Drives the OIDC flow attacker-side and exchanges the code at `/identity/connect/token`.\n\nThe token-exchange response on the affected build:\n\n```\n=== access_token claims (decoded) ===\n  \"sub\": \"97e87705-2166-4d84-9090-088f0eb1d13c\",   <- victim's user UUID\n  \"name\": \"Victim\",\n  \"email\": \"victim@example.com\",\n  \"email_verified\": true,                          <- Vaultwarden asserts true; IdP claim was false\n  \"device\": \"00000000-0000-0000-0000-000000000001\" <- attacker's newly-registered device\n\n=== Capability probes ===\n  \u2713 read profile (PII)                             HTTP 200\n  \u2713 read full vault sync (encrypted ciphers)       HTTP 200\n  \u2713 list 2FA providers                             HTTP 200\n  \u2713 list authorized devices                        HTTP 200\n  \u2713 list emergency-access trustees                 HTTP 200\n\n  profile.id == victim's user UUID\n  profile.email == victim@example.com\n```\n\nThe token-exchange response also returns the victim's `PrivateKey` envelope (see [`src/api/identity.rs:511`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/identity.rs#L511)), encrypted under a key derived from the victim's master password. Plaintext vault contents are not directly readable from the response \u2014 they remain encrypted under that master-key envelope. The encrypted material is suitable for offline brute-force against weak master passwords. The default KDF in Vaultwarden is PBKDF2-SHA256 with `CLIENT_KDF_ITER_DEFAULT = 600_000` ([`src/db/models/user.rs:106`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/db/models/user.rs#L106)); Argon2id is selectable per-user. Brute-force economics scale accordingly.\n\nNegative control: re-running the PoC with `SSO_SIGNUPS_MATCH_EMAIL=false` blocks the attack at the token-exchange step with `{\"message\":\"Existing non SSO user with same email\"}`. This is the maintainer's documented mitigation knob; the bug is that the safe default does not invoke it.\n\n## Impact past the initial session\n\n- **Session lifetime.** 2-hour access token plus 30-day refresh token bound to the victim's UUID, per `DEFAULT_ACCESS_VALIDITY` and `DEFAULT_REFRESH_VALIDITY` in [`src/auth.rs:30-32`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/auth.rs#L30-L32). I did not find code that re-validates IdP session state on refresh; the refresh window appears to outlive the original IdP login.\n- **Persistent SSO binding.** A new `SsoUser` row linking the attacker's IdP subject to the victim's user UUID is persisted by `sso::redeem` ([`src/api/identity.rs:313`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/identity.rs#L313)). The attacker can re-authenticate via SSO until that row is removed.\n- **Org-Owner privilege escalation.** If the victim is an `Owner` of any Vaultwarden organization, the hijacked session passes the role-edit gate at [`src/api/core/organizations.rs:1565-1570`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/core/organizations.rs#L1565-L1570):\n\n  ```rust\n  if new_type != member_to_edit.atype\n      && (member_to_edit.atype >= MembershipType::Admin || new_type >= MembershipType::Admin)\n      && headers.membership_type != MembershipType::Owner\n  {\n      err!(\"Only Owners can grant and remove Admin or Owner privileges\")\n  }\n  ```\n\n  The session caller is an Owner, so the check passes, and the attacker can promote their attacker-side membership entry to `Owner`. Owner role on the org survives the hijacked session.\n- **Emergency-access grant.** Vaultwarden supports emergency-access ([`src/api/core/emergency_access.rs`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/core/emergency_access.rs)). A hijacked session can create a grant naming the attacker as a recovery contact; after the configured wait window elapses without the victim disabling it, recovery completes outside the original session window.\n\n## Recon\n\nOne unauthenticated endpoint lowers the targeting cost: [`POST /organizations/domain/sso/verified`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/core/organizations.rs#L919-L941) takes an email and returns the matching organization's name and identifier if SSO is configured for it (or a fake-identifier sentinel otherwise). With a victim email, an attacker can confirm a target Vaultwarden instance has SSO enabled and identify the org before any IdP-side activity. The endpoint is intentionally unauthenticated by design (clients need it pre-login to discover SSO config), but it's worth noting as part of the realistic attack surface.\n\nI had originally framed `POST /accounts/prelogin` as a clean email-enumeration primitive. Rechecking [`src/api/core/accounts.rs:1236-1250`](https://github.com/dani-garcia/vaultwarden/blob/62748100f04178b9b2df7f9fd8f9884fab59fbd8/src/api/core/accounts.rs#L1236-L1250): Vaultwarden returns `(CLIENT_KDF_TYPE_DEFAULT, CLIENT_KDF_ITER_DEFAULT, None, None)` for unknown emails, matching what a freshly-registered default-KDF user would return. So it's *not* a clean enumeration primitive \u2014 it only distinguishes users who have customized their KDF (changed iteration count, switched to Argon2id, etc.) from \"unknown email OR default-KDF user.\" That's a much weaker signal than I claimed in the original submission, and against the population of Vaultwarden users likely to be on default settings it's near-useless. I'm calling that out explicitly because it was in my draft and I want the public version to be honest.\n\n## CVSS framing\n\nCVSS:3.1 `AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L` \u2014 7.7 HIGH, as published.\n\n`AC:H` reflects two preconditions: the attacker needs an IdP that allows registering an identity claiming the victim's email with `email_verified` either `false` or unset, and the victim must not have Vaultwarden 2FA configured. Both can be tightened by the operator (use an IdP that strongly enforces domain ownership; require 2FA), but the second one isn't actionable from the Vaultwarden side at config-write time.\n\n`C:H` covers PII plus retrieval of the encrypted vault envelope.\n`I:H` covers the device-registration, emergency-access, and org-Owner-promotion vectors.\n`A:L` is the published score's nod to the persistent SSO binding and the operational disruption of a confirmed-owner switch.\n\nMy original draft scored this as `A:N` and total 7.5; the published 7.7 with `A:L` is the advisor's framing and I'm not going to argue with it.\n\n## Fix\n\nThe 1.36.0 patch [moves the `email_verified` gate up into the email-resolution step itself](https://github.com/dani-garcia/vaultwarden/blob/1.36.0/src/api/identity.rs#L233-L259), so both branches enter the second `match` with the email-verification invariant already enforced:\n\n```rust\n// src/api/identity.rs (1.36.0):233-259\nSome((user, None)) => match user_infos.email_verified {\n    None if !CONFIG.sso_allow_unknown_email_verification() => {\n        err_silent!(\"Email verification status is unknown\", ...)\n    }\n    Some(false) => {\n        err_silent!(\"Email is not verified by the SSO provider\", ...)\n    }\n    _ => Some((user, None)),\n},\n```\n\nThis is structurally tighter than the option I proposed in my submission (duplicate the check inside the existing-user branch before `twofactor_auth`). Pushing the check up into the resolution step makes it impossible to reach either downstream branch without having passed the gate, which is exactly the right shape \u2014 checks at the boundary, not at the consumer.\n\n## Disclosure timeline\n\n- **2026-04-28 22:34Z**: Submitted GHSA-j4j8-gpvj-7fqr to Vaultwarden with PoC and audit notes.\n- **2026-04-28 22:38Z**: Daniel Garc\u00eda added [@BlackDex](https://github.com/BlackDex) as a collaborator on the report.\n- **2026-05-03 12:54Z**: Vaultwarden [1.36.0](https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0) released. Release notes list \"SSO existing-user binding\" among the security fixes and reference both GHSA-j4j8-gpvj-7fqr and GHSA-6x5c-84vm-5j56, noting \"These are private for now, pending CVE assignment.\" (At this point both my report and ch1nhpd's still pointed at distinct GHSA IDs; the merge to single CVE happened at publication.)\n- **2026-05-17 18:57Z**: Daniel closed my advisory as a duplicate of ch1nhpd's 2026-03-22 report, and offered to add me as an independent-reporter credit on the public advisory.\n- **2026-05-19 21:27Z**: [GHSA-6x5c-84vm-5j56](https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-6x5c-84vm-5j56) / CVE-2026-47164 published.\n- **2026-05-19 ~22:30Z**: Accepted the credit invite. Atomics-hub now appears in structured Credits alongside ch1nhpd on the published advisory.\n\nNo bounty \u2014 Vaultwarden does not operate a bug bounty program. The artifact is the public CVE credit.\n\n## What worked, what didn't\n\nWhat worked: a fresh source audit of `src/api/identity.rs` flagged the asymmetric placement of the `email_verified` check across the two branches almost immediately. The check existed on one path but not the other; the maintainer's config-comment warning on `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION` confirmed the threat model was already understood. That mismatch was the lead. End-to-end PoC against the live Docker image confirmed it before submission.\n\nWhat didn't: I missed an obvious check that I'd add to my pre-submission gate from now on. GitHub Security Advisories has a public Advisories tab per repo. The list of *published* advisories is searchable, and `dani-garcia/vaultwarden` had no public advisory for this bug class at the time. But pre-publication advisories (private to the maintainer) can also include a window where collaborator activity is visible in unusual ways \u2014 a maintainer adding a collaborator, an issue or PR getting unusual gating, a release notes draft appearing. The 2026-04-28 22:38Z addition of @BlackDex as a collaborator on my own report, four minutes after I submitted, is consistent with maintainer behaviour around an existing private advisory. I should have looked harder at the activity timeline of the repo before drafting the submission.\n\nFor OSS targets with active GHSA usage, the lesson I'm banking: before drafting a submission, spend ten minutes on the project's commit graph, recent collaborator additions, and release notes drafts. Five weeks is a long gap, but it's also evidence that ch1nhpd's report sat in private triage for that whole window. The signal was probably in the public repo activity if I'd known to look.\n\nThe other thing I'm taking away from this: the AC:H precondition tree is real and exploitable in practice. Self-hosted Keycloak with open registration is common. Vaultwarden users without 2FA are common. The intersection is smaller than either set alone, but it's not zero, and the impact-on-success is genuinely high. Operators running Vaultwarden with SSO should be on 1.36.0 or later. Operators running Vaultwarden with SSO and a permissive IdP should set `SSO_SIGNUPS_MATCH_EMAIL=false` regardless of version \u2014 the fix relies on the IdP truthfully reporting `email_verified`, and an IdP that can be made to lie about that defeats the fix the same way it defeated the safe default.\n\n---\n\n*Reporter: [@Atomics-hub](https://github.com/Atomics-hub). Co-reporter who got there first: [@ch1nhpd](https://github.com/ch1nhpd). Advisory: [GHSA-6x5c-84vm-5j56](https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-6x5c-84vm-5j56) / CVE-2026-47164. Affected commit: [`62748100`](https://github.com/dani-garcia/vaultwarden/tree/62748100f04178b9b2df7f9fd8f9884fab59fbd8). Fixed in [1.36.0](https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0).*\n", "creation_timestamp": "2026-05-20T14:58:37.000000Z"}]}