Boruta CVE-2026-65635

Exploitation requires that the OpenID Connect dynamic client registration entry point (Boruta.Openid.register_client/3) is enabled and reachable without authentication - this is precisely the precondition encoded as AT:P in the CVSS vector. When that endpoint is exposed, no credentials or user interaction are needed (PR:N/UI:N): the attacker simply includes security-sensitive fields (supported grant types, authorized scopes, PKCE enforcement, public refresh/revoke, token TTLs, signing settings) in the registration payload and Boruta accepts them because there is no public/admin allowlist. What LIMITS exploitation: deployments that do not enable dynamic client registration, that gate it behind an initial access token or operator approval, or that restrict the endpoint to trusted networks are not exploitable; the flaw only affects Boruta 2.3.0 through 2.3.6.

The supplied CVSS 4.0 base score of 8.3 (High) is driven by AV:N/AC:L/PR:N/UI:N with AT:P - remote, unauthenticated, low-complexity access, but with a present attack requirement, which correctly captures that the dynamic client registration endpoint must be enabled and reachable; that requirement is the single most important limiting factor. Vulnerable-system integrity is High (VI:H) because the attacker controls security-relevant client policy, while confidentiality and availability are Low, with a minor subsequent-system impact (SC:L/SI:L). No EPSS score, KEV entry, or public POC was provided, so real-world exploitation probability cannot be quantified from the input and remains inferred rather than confirmed. Treat this as a genuine priority for any deployment that exposes unauthenticated dynamic client registration, but as low real-world risk where DCR is gated behind an initial access token or disabled - verify the registration configuration before assigning severity, since the score assumes the endpoint is open.

An attacker reaches the exposed OIDC dynamic client registration endpoint of an application built on Boruta and submits a registration request that, alongside normal metadata, sets administrative attributes such as supported_grant_types: ["client_credentials"], broad authorized scopes, public_refresh_token/public_revoke, disabled PKCE, and long token lifetimes. Boruta persists these because no field-level allowlist separates public metadata from admin controls, yielding a self-provisioned, over-privileged client the attacker then uses to obtain and abuse tokens. No public POC is identified, but low complexity and unauthenticated access make exploitation straightforward wherever DCR is open.