CVE-2026-65635

If you're running Boruta OIDC in an Elixir/Phoenix deployment, check your version immediately: this vulnerability affects 2.3.0 through 2.3.6. The issue is in `register_client/3`, a function designed for OIDC dynamic client registration that inadvertently forwards certain client metadata parameters into administrative paths. When an untrusted registrant provides specific attribute combinations, they can elevate privileges beyond what public registration should permit — registering grant types, signing algorithms, or metadata fields that should require operator approval. The root cause is a boundary failure in how the library handles the public-versus-administrative parameter space. The function behaves as a general-purpose registration API, but certain parameter combinations trigger privileged behavior with no explicit signal to the developer. This is the exact failure mode that emerges when a library prioritizes flexibility over safe defaults: the developer sees a registration function, tests that registration works, and ships. The security gap between 'registration works' and 'registration exposes admin controls' is invisible during normal testing because it requires probing which parameters trigger privileged behavior — something you won't discover under deadline pressure. The fix in 2.3.7 implements field-level allowlisting, explicitly distinguishing which metadata fields a public registrant can set versus which require administrative intent. If you're on an affected version, upgrade immediately. Beyond the patch, examine your deployment: if any untrusted clients can reach the dynamic registration endpoint, assume the parameter boundary may have been probed. Audit your registered clients for unexpected grant types, redirect URIs, or signing configurations that you did not intentionally approve. This matters more in Elixir/OTP than in other ecosystems. Your OIDC provider is likely the authentication substrate for multiple Phoenix applications, background workers, and supervision trees. Compromising the client's registered grant types or signing settings doesn't just give an attacker a foothold — it propagates through process links into dependent workers and can destabilize session state across distributed nodes. The OTP supervision architecture means the blast radius extends beyond the library itself into everything bootstrapped from your identity system. There is no dialyzer spec, Credo check, or Hex static analysis rule that flags this pattern in Elixir today. The Elixir ecosystem lacks the equivalent of Python's bandit or semgrep rules for parameter forwarding to administrative paths. Until tooling catches up, treat any library function that accepts arbitrary key-value input from untrusted sources as a potential boundary failure — audit the parameter flow yourself before production deployment.

Reviewed through automated stages and approved by a human before publication.