Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The kanidmd OAuth2 token-exchange (/oauth2/token) and token-introspection (/oauth2/token/introspect) endpoints compare the supplied clientsecret against the stored secret using Rust's PartialEq on String, which short-circuits on the first mismatching byte. This produces an observable timing discrepancy that varies with the length of the matching prefix. Details - https://github.com/kanidm/kanidm/blob/master/server/lib/src/idm/oauth2.rs#L1135 — variable-time comparison in checkoauth2tokenexchange - https://cwe.mitre.org/data/definitions/208.html — CWE-208: Observable Timing Discrepancy PoC Static analysis only — no timing-recovery script was run because remote recovery of a 48-byte high-entropy secret over HTTPS is not practically demonstrable. The variable-time behaviour is established by inspection: String: PartialEq delegates to <[u8] as PartialEq::eq, which checks length equality then iterates byte-by-byte and returns on the first difference. Impact An unauthenticated…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The kanidmd web UI renders the WebAuthn passkey-registration challenge as raw JSON inside an inline <script id="data" element using the Askama |safe filter. The challenge embeds the account's displayname, which serdejson serialises without escaping </. A displayname containing </script therefore terminates the script element early and injects arbitrary HTML into the credential-update page. Because the page is htmx-driven and the server's CSP allows 'unsafe-eval', injected hx- attributes can issue authenticated same-origin API requests with the viewer's bearer cookie. Impact An authenticated attacker who is a member of idmpeopleadmins can write the displayname of any Person entry — including high-privilege persons — because idmacppeoplepiimanage carries no high-privilege exclusion filter. When the targeted high-privilege user later opens Add Passkey on their own credential-update page (/ui/reset), the injected markup is swapped into the DOM and htmx fires attacker-chosen…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.