Skip to content

EEF-CVE-2026-68746 CVE-2026-68746 GHSA-74j5-6grg-g6wj

Livebook Teams identity check fails open when the deployment group is unresolvable, allowing unauthenticated access

High Hex
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.80%
Chance of exploitation in the next 30 days. Higher than 56.58% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-636 Not Failing Securely ('Failing Open')
Fix
0.19.9
Upgrade livebook to this version or later

Description

Summary

Not Failing Securely ('Failing Open') vulnerability in livebook-dev livebook allows an unauthenticated network client to obtain full access to a Livebook server that enforces identity through Livebook Teams.

A Livebook Agent or App Server connected to Livebook Teams caches the identifier of the deployment group it belongs to, and resolves that identifier against a locally cached list of deployment groups on every request in order to decide whether Teams identity enforcement is active. Livebook.Hubs.TeamClient.handle_call/3 in lib/livebook/hubs/team_client.ex does not distinguish a deployment group that could not be resolved from one that was resolved with identity enforcement switched off: the clause matches only the case where a group was found with enforcement enabled, and falls through to a catch-all that reports enforcement as switched off for everything else. The two neighbouring functions that decide user and application access resolve the same identifier and treat the same unresolved result as a denial.

When the identity status is reported as switched off, Livebook.ZTA.LivebookTeams.authenticate/3 in lib/livebook/zta/livebook_teams.ex returns empty identity metadata and allows the request to continue instead of halting it. LivebookWeb.UserPlug.build_current_user/3 merges that empty metadata into a newly built user, whose access type defaults to full access, and LivebookWeb.AuthPlug.authorized?/1 grants access to any user holding full access.

The cached identifier becomes unresolvable when the deployment group it refers to is deleted while the agent is not connected to receive the change, most concretely when a deployment group is deleted during the window in which an agent is disconnected or reconnecting. The client removes the group from its cached list without clearing the identifier that refers to it. Any client able to reach the affected server over the network is then granted the same access as a fully privileged member of the organisation, including the ability to read notebooks and configured secrets, execute code on the server's runtime, and disrupt its operation.

This issue affects livebook: from 0.19.7 before 0.19.9.

Configurations

This vulnerability affects Livebook servers that enforce identity through Livebook Teams. Servers not connected to Livebook Teams, or connected without a deployment group, are not affected.

Livebook Teams has also been changed to reject deletion of a deployment group while agents belonging to it are connected, which removes the most direct route into the vulnerable state. A connected agent may still reach an unresolvable cached deployment group as a result of connection failures or network errors.

Affected versions

Hex

PackageVulnerableFixed in
livebook
>= 0.19.7, < 0.19.9
0.19.9

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.

livebook Hex → 0.19.9

mix
{:livebook, "~> 0.19.9"} # then: mix deps.update livebook

Severity breakdown

CVSS 4.0 0.0

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

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
Low
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 8.8

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

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-636: Not Failing Securely ('Failing Open')

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

How to prevent it
  • Architecture and Design: Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-66885
Livebook Teams identity callback lacks state binding, allowing login CSRF
Medium Also affects livebook
EEF-CVE-2026-66298
JS-view sandboxed output can synthesize keyboard events to trigger unconfirmed global shortcuts
High Also affects livebook
EEF-CVE-2026-66297
Unescaped deployment environment variables in generated setup commands
High Also affects livebook
EEF-CVE-2026-66881
Path traversal in imported file_entries name allows arbitrary file write via URL-type entry download
High Also affects livebook
GHSA-564w-97r7-c6p9
Livebook Desktop's protocol handler can be exploited to execute arbitrary command on Windows
Critical Also affects livebook
EEF-CVE-2026-103502
hex_core's default HTTP adapter doesn't verify TLS certificates on OTP 24 and 25
Not rated yet Same weakness, CWE-636
EEF-CVE-2026-82744
Ash.Reactor change step fails open, skipping a change when its where guard raises
Not rated yet Same weakness, CWE-636
GHSA-qvw7-jm5c-6hqw
Microsoft Security Advisory CVE-2026-50528 – .NET Security Feature Bypass Vulnerability
High Same weakness, CWE-636

Credits: Hugo Baraúna, Jonatan Kłosko, José Valim, Nguyễn Công Tú

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