Summary
Ember has unneutralized terminal escape/control sequences from Caddy logs injected into the operator's TUI
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.
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
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.
CVE-2026-54162 has a CVSS score of 4.7 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.4.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-54162? CVE-2026-54162 is a medium-severity security vulnerability in github.com/alexandre-daubois/ember (go), affecting versions < 1.4.2. It is fixed in 1.4.2.
- How severe is CVE-2026-54162? CVE-2026-54162 has a CVSS score of 4.7 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/alexandre-daubois/ember are affected by CVE-2026-54162? github.com/alexandre-daubois/ember (go) versions < 1.4.2 is affected.
- Is there a fix for CVE-2026-54162? Yes. CVE-2026-54162 is fixed in 1.4.2. Upgrade to this version or later.
- Is CVE-2026-54162 exploitable, and should I be worried? Whether CVE-2026-54162 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54162 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54162? Upgrade
github.com/alexandre-daubois/emberto 1.4.2 or later.