Which versions of Boruta are affected by CVE-2026-65635?

Boruta OAuth 2.0/OpenID Connect provider library (versions 2.3.0-2.3.6) contains an unauthenticated privilege escalation vulnerability that allows attackers to register malicious OAuth clients with…. A patch is available.

How to fix or mitigate CVE-2026-65635?

Within 24 hours, inventory all development, staging, and production systems using Boruta library and identify which are running versions 2.3.0 through 2.3.6. Within 7 days, obtain vendor-released patch 2.3.7, conduct code review of your application's OAuth client registration endpoints, and deploy the patch to staging environments for regression testing focused on client creation and token flows. Within 30 days, deploy patch 2.3.7 to all production systems running affected versions, prioritizing systems exposed to untrusted or external client registrants.

Boruta CVE-2026-65635

Q: What is the CVSS score of CVE-2026-65635?

CVE-2026-65635 has a CVSS 4.0 base score of 8.3 (High). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

EUVD-2026-51144 HIGH

Improper Isolation or Compartmentalization (CWE-653)

2026-07-30 EEF

Information Disclosure Boruta

8.3

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

8.3 HIGH

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.9 CRITICAL

Unauthenticated network attacker abuses an exposed DCR endpoint (AV:N/PR:N/UI:N); integrity of client security policy is High while confidentiality/availability are Low, and setting authz-server policy crosses a trust boundary (S:C).

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:L/SC:L/SI:L/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 30, 2026 - 15:23 vuln.today

Analysis Generated

Jul 30, 2026 - 15:23 vuln.today

CVE Published

Jul 30, 2026 - 14:17 cve.org

HIGH 8.3

DescriptionCVE.org

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.

AnalysisAI

Privilege escalation via dynamic client registration in malach-it's Boruta OAuth 2.0/OpenID Connect provider library (Elixir) lets an unauthenticated registrant create OIDC clients that carry administrative security attributes. Because Boruta.Openid.register_client/3 forwards caller-supplied parameters straight into the administrative client-creation changeset with no public/admin allowlist, a self-registering client can dictate its own supported grant types, authorized scopes, PKCE enforcement, public refresh/revocation behavior, token lifetimes, and signing settings on versions 2.3.0 through 2.3.6. There is no public exploit identified at time of analysis and it is not in CISA KEV, but a vendor-released patch (2.3.7) is available.

Technical ContextAI

Boruta is an Elixir/Ecto-based OAuth 2.0 and OpenID Connect authorization server library used to build identity providers on the BEAM/Phoenix stack. The affected surface is the OIDC Dynamic Client Registration (RFC 7591) entry point exposed through Elixir.Boruta.Openid.register_client/3 and parse_registration_params/2 in lib/boruta/openid.ex. The root cause is CWE-653 (Improper Isolation or Compartmentalization): registration parameters were passed into the same Client.create_changeset/2 used for trusted administrative client creation via lib/boruta/adapters/ecto/clients.ex, making every persisted field mass-assignable. The vendor fix introduces a dedicated registration_changeset/2 in lib/boruta/adapters/ecto/schemas/client.ex that casts only a fixed @registration_attributes allowlist (name, redirect_uris, token_endpoint auth methods/alg, jwk, jwks_uri, logo_uri) and forces safe defaults for supported_grant_types (client_credentials, authorization_code), token TTLs, and the internal signatures adapter, restoring the separation between public metadata and operator-controlled security policy.

RemediationAI

Vendor-released patch: upgrade Boruta to 2.3.7 or later, which replaces the shared create changeset with a dedicated registration_changeset that accepts only client name, redirect URIs, token endpoint auth metadata, JWKS metadata, and logo URI while forcing safe server-controlled defaults; the fix is in commits 82584c854a332482232fd25301ab12a835f9f643 and 95619a1beaff68fa766cca9b388e7c780d182525. If you cannot upgrade immediately, the most effective compensating control is to disable the OIDC dynamic client registration route or require an initial registration access token / operator approval before a client is persisted (trade-off: breaks legitimate self-service or automated client onboarding). As an interim step, restrict network access to the registration endpoint to trusted management networks and audit recently created clients for anomalous supported_grant_types, over-broad authorized scopes, disabled PKCE, extended token TTLs, or non-default signing settings, revoking any suspicious registrations (trade-off: manual review does not prevent new abuse and may miss subtle changes). See the advisory at https://github.com/malach-it/boruta_auth/security/advisories/GHSA-w869-fcf2-68vp.