Skip to content

EEF-CVE-2026-65635 CVE-2026-65635 GHSA-w869-fcf2-68vp

Boruta dynamic client registration allows creation of over-privileged OAuth clients

Not rated yet Hex
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

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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

Is this in your code?

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