CVE-2026-54162: Medium severity go/github.com/alexandre-daubois/ember vulnerability
Summary
Ember's interactive TUI renders fields taken from the monitored Caddy server's access logs — most notably the request URI — straight to the operator's terminal without neutralising terminal escape or control sequences (CWE-150). Those log fields are populated from arbitrary, unauthenticated HTTP requests, so any remote client can embed ANSI/OSC/CSI control bytes that the operator's terminal emulator interprets when the log row is displayed. The bytes survive the whole pipeline: Caddy escapes them into its JSON access log as unicode escapes, ember's ParseLogLine decodes them back to raw 0x1b/0x07 bytes, and the row formatters concatenate them into the bubbletea View() output with no encoding before they reach os.Stdout.
Impact
An unauthenticated, remote attacker who can send HTTP requests to the Caddy server that ember monitors can inject terminal escape sequences into the operator's TUI. The trigger is a single ordinary HTTP request with control bytes in the request target. It requires no authentication; because the payload is reflected through Caddy's normal access log, it works even when ember's log listener is bound only to loopback. When the operator views the Logs tab — ember's default, zero-config mode — the terminal emulator interprets the injected sequences. Broadly-supported, demonstrated impact includes:
- Monitoring-dashboard spoofing — CSI cursor/erase/scroll sequences forge or hide log rows so the operator misjudges the monitored server's state. - Clipboard hijacking (OSC 52) — attacker-chosen text is written into the operator's system clipboard, staging a payload the operator may later paste into a shell. - Window-title spoofing (OSC 0/2) — to support social engineering.
The impact ceiling depends on the operator's terminal emulator and usually requires a further operator action (e.g. a paste) to fully escalate; this is not general-case RCE, though specific terminal emulators have historically escalated escape sequences further. The Certificates and Routes tabs share the same unneutralised render path as secondary sinks. The --json/--once and daemon (--expose) modes are not affected, as they do not render to an interactive terminal.
References
- https://github.com/alexandre-daubois/ember/blob/main/internal/ui/logtable.go#L18 — the unneutralised render helper (fitCellLeft) and row formatters (the sink) - https://github.com/alexandre-daubois/ember/blob/main/internal/fetcher/lognetlistener.go — the unauthenticated TCP access-log listener (input source) - https://github.com/alexandre-daubois/ember/blob/main/internal/fetcher/logentry.go — ParseLogLine, where the JSON decode restores raw control bytes - https://cwe.mitre.org/data/definitions/150.html — CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/alexandre-daubois/emberto a version that resolves this vulnerability.Fixed in 1.4.2
Event History
Frequently Asked Questions
Who is exposed to this issue?
Operators using Ember to monitor a Caddy server are exposed if the monitored server accepts HTTP requests from untrusted remote clients. The attacker-controlled request URI is carried through Caddy's normal access log and rendered in Ember's interactive terminal interface.
Does binding Ember's log listener to loopback prevent exploitation?
No. The payload reaches Ember through Caddy's normal access log, so an attacker only needs to be able to send an HTTP request to the monitored Caddy server; they do not need network access to Ember's log listener.
What does an attacker need to do to trigger the issue?
An unauthenticated attacker can send a single ordinary HTTP request whose request target contains terminal escape or control bytes. Exploitation occurs when an operator displays the resulting log row in Ember's TUI.