Jonatan Kłosko

An issue exists where improper neutralization of input during web page generation allows mutation Cross-site Scripting (XSS). This occurs during a parse and serialize round-trip of attacker-supplied HTML. The functions `LazyHTML.to html/2` and `LazyHTML.Tree.to html/2` determine whether to escape an element's text based solely on its tag name. Consequently, a `style` or `script` element within SVG or MathML foreign content is parsed with decoded character references but serialized as an HTML raw-text element, causing the text to be emitted unescaped. This allows encoded markup to close the element upon re-parsing and become active markup. Applications that parse untrusted HTML, filter the document or tree, and then serialize it for display are affected because the payload remains a plain text node that bypasses element or attribute filters.

An OS Command Injection issue exists where deployment setup commands are generated without proper shell escaping of environment variable values. The functions `docker instructions/2` and `fly instructions/4` in `lib/livebook web/live/hub/teams/deployment group agent component.ex` interpolate these values, which are processed through `online docker info/3`. Because values are placed within double-quoted shell words, an attacker with privileges to set deployment group environment variables can use command substitution (such as `$(...)` or backticks) or double quotes to inject arbitrary commands. These commands are then executed on the local machine of any user who copies and runs the generated setup instructions from the web interface. Kubernetes instructions are not affected as they use YAML manifest escaping.

An origin validation error allows untrusted notebook output JavaScript to trigger session-wide keyboard shortcuts. The JS-view feature renders JavaScript in a sandboxed, cross-origin iframe. However, the iframe shell in `iframe/priv/static/iframe/v5.html` forwards `keydown` events to the parent page without verifying `Event.isTrusted`. Consequently, events synthesized via `window.dispatchEvent` are treated as genuine keystrokes. The relay in `assets/js/hooks/js view.js` re-dispatches these events, which are then processed by the global shortcut handler in `assets/js/hooks/session.js` during the capture phase. This allows sandboxed scripts to execute shortcuts in `LivebookWeb.SessionLive`, such as forcing the evaluation of all cells in the notebook or restarting the runtime, which discards in-memory state. A third shortcut can delete the focused cell. The most critical impact is the forced full evaluation, which executes the notebook's Elixir code without user consent. This can occur when a user opens a notebook from a third party or published documentation, and the effect is mirrored to all connected collaborators.

A Relative Path Traversal issue allows an attacker to write a file with controlled content to an arbitrary path on the system. This occurs because the import path in `Livebook.LiveMarkdown.Import.file entry metadata to attrs/1` takes the name from the notebook source verbatim without validation. For URL-type file entries, the function `Livebook.Session.file entry cache file/2` resolves the name beneath the session temporary directory without verifying if the result remains within that directory. Additionally, `Livebook.FileSystem.Utils.resolve unix like path/2` collapses parent-directory segments but only clamps at the filesystem root. Consequently, when content is requested and no cache exists, the system writes the response body to the resolved path, creating parent directories as needed. This allows an attacker to control both the destination and content of the written file anywhere the process has write permissions. A similar lack of containment check exists in `Livebook.Session.to attachment file entry/2`. A victim triggers this by opening an attacker-supplied notebook and causing the entry to be fetched within their authenticated session.

A Cross-Site Request Forgery (CSRF) issue exists when Livebook is configured to use Livebook Teams for identity. The `handle request/4` function in `lib/livebook/zta/livebook teams.ex` processes OAuth-style callbacks containing a `teams identity` marker and a `code` parameter. Because the `create auth request/1` function in `lib/livebook/teams/requests.ex` does not generate a state or nonce, the system fails to verify if the callback corresponds to the session that initiated the login. An attacker within the same Livebook Teams organization can initiate a login flow, capture the authorization code, and trick a victim into opening a URL containing that code. This causes the victim's session to be bound to the attacker's identity. Consequently, any work, secrets, or data produced by the victim are attributed to and accessible by the attacker, while the victim believes they are using their own account.

A failing open issue in livebook allows an unauthenticated network client to gain full access to a server that enforces identity through Livebook Teams. This occurs when a Livebook Agent or App Server caches a deployment group identifier that becomes unresolvable, such as when the group is deleted while the agent is disconnected. The function `handle call/3` in `lib/livebook/hubs/team client.ex` fails to distinguish between an unresolvable group and one where identity enforcement is disabled, leading the system to report enforcement as switched off. Consequently, the `authenticate/3` function in `lib/livebook/zta/livebook teams.ex` returns empty identity metadata, which `build current user/3` in `LivebookWeb.UserPlug` merges into a new user with default full access. This is then granted access by `authorized?/1` in `LivebookWeb.AuthPlug`. An attacker can exploit this to read notebooks and secrets, execute code on the server's runtime, and disrupt operations.