EEF-CVE-2026-65635 CVE-2026-65635 GHSA-w869-fcf2-68vp
Boruta dynamic client registration allows creation of over-privileged OAuth clients
- Severity
- 0.0 / 10
- Unknown · CVSS 4.0
- Exploit chance (EPSS)
- 0.38%
- Chance of exploitation in the next 30 days. Higher than 32.31% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-653 Improper Isolation or Compartmentalization
- Fix
2.3.7- Upgrade boruta to this version or later
Description
Summary
Improper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval.
This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2.
This issue affects boruta from 2.3.0 before 2.3.7.
Workarounds
Disable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function.
Configurations
A deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| boruta | >= 2.3.0, < 2.3.7 |
2.3.7 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
boruta Hex → 2.3.7
- mix
{:boruta, "~> 2.3.7"} # then: mix deps.update boruta
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:L/SC:L/SI:L/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- Low
- Integrity (subsequent systems)
- Low
- Availability (subsequent systems)
- None
Weakness
CWE-653: Improper Isolation or Compartmentalization
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
How to prevent it
- Architecture and Design: Break up privileges between different modules, objects, or entities. Minimize the interfaces between modules and require strong access control between them.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-53431 Boruta accepts expired JWT client assertions due to missing exp claim validation | Not rated yet | Also affects boruta |
| EEF-CVE-2026-54885 Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching | Not rated yet | Also affects boruta |
| GHSA-69qc-f5m6-889c Ghost: Stored XSS via Embed Card Previews | High | Same weakness, CWE-653 |
| GHSA-fcqc-726x-5wfc vm2: Sandboxed code can read and write host-realm memory via Node's shared Buffer pool | Critical | Same weakness, CWE-653 |
| GHSA-62fc-8686-hfmq Traefik: `allowCrossNamespace=false` bypass via `@kubernetescrd` TraefikService backendRef | Medium | Same weakness, CWE-653 |
| GHSA-9vg3-4rfj-wgcm vm2 has Sandbox Breakout Through Null Proto Exception | Critical | Same weakness, CWE-653 |
| GHSA-vwrp-x96c-mhwq vm2: Mutable Proxies for Host Intrinsic Prototypes Allows Sandbox Escape | Critical | Same weakness, CWE-653 |
| GHSA-47x8-96vw-5wg6 vm2 Access to Host Object Enables Sandbox Escape | Critical | Same weakness, CWE-653 |
Credits: Jonatan Männchen / EEF, Pascal Knoth
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor