LogTape security updates: 2.0.23, 2.1.14, 2.2.10, and 2.3.7

[dahlia]

Two security advisories affect LogTape. One covers the built-in text formatters in @logtape/logtape and @logtape/pretty, the other covers the syslog sink in @logtape/syslog. Both are fixed in 2.0.23, 2.1.14, 2.2.10, and 2.3.7. Neither has a CVE ID assigned yet, so the GitHub Security Advisories are the identifiers to cite.

Terminal control and log forgery in the built-in formatters

GHSA-hp6w-c2ch-g44w affects @logtape/logtape and @logtape/pretty.

LogTape splits a log record's message into literal parts and interpolated values. Values were escaped. Literal parts were not, and a plain string argument is entirely one literal part. So logger.info(untrustedString) wrote that string to the output byte for byte, including ESC sequences and newlines. Category segments were emitted raw for the same reason.

On a terminal this allows cursor and screen control. An attacker-influenced string can move the cursor up, clear the line, and print a forged entry over a real one, or set an attribute such as conceal that hides the records printed after it. No terminal is needed for the second variant: an embedded newline emits a line that defaultTextFormatter renders as a complete, syntactically valid record, which deceives file-based log review and any collector that splits on newlines.

The documented way to log untrusted data was never affected. Both logger.info`... ${value}` and logger.info("... {value}", { value }) put the data in a value position, where the value renderer already escaped it.

getTextFormatter(), getAnsiColorFormatter(), defaultConsoleFormatter(), and getPrettyFormatter() now neutralize ESC-introduced sequences other than SGR color codes, the remaining C0 control characters, DEL, and the C1 controls (U+0080 to U+009F). Two defaults keep existing output intact. Newlines, carriage returns, and tabs are preserved, so stack traces stay readable. SGR sequences are preserved in the message, so applications that log pre-colored strings or captured subprocess output keep their colors; a preserved sequence that is left open is closed with a reset. A category is an identifier rather than display text, so SGR is always escaped there.

The new sanitize option on TextFormatterOptions adjusts this. Pass sanitize: { newlines: "escape" } to neutralize newlines as well, which is the setting to choose when a downstream tool parses your logs line by line. Pass sanitize: false to restore the previous behavior. The SanitizationOptions interface and the sanitizeControlSequences() function are exported for custom formatters.

The same releases also escape DEL and the C1 range in getJsonLinesFormatter(), where JSON.stringify() left them as raw code points, and in getLogfmtFormatter() on the versions that have it. U+009B and U+009D are the 8-bit CSI and OSC introducers, so a terminal reading those files directly would interpret them.

Forged syslog records over TCP

GHSA-rjxr-25gw-qw92 affects @logtape/syslog on TCP transport. If you send logs to a collector or SIEM over TCP syslog, update now.

formatSyslogMessage() built the RFC 5424 MSG field by concatenating the raw text of the log message. TCP syslog is newline delimited, so a message containing a newline terminated its own frame and the remainder arrived as an independent record with an attacker-chosen priority, timestamp, hostname, application name, and process ID. A single application call such as logger.info("login failed for user " + input) could therefore place a forged authentication-success record into the collector.

This is not the same issue as CVE-2026-54511, which was fixed earlier in the structured data path and required includeStructuredData to be enabled. This one does not depend on any option, because the MSG field is emitted for every syslog record.

Message text now replaces C0 control characters with printable #NNN sequences, the same way structured data values already did. UDP transport was never exposed to frame splitting, because the datagram boundary keeps the record intact.

Updating

npm  update  @logtape/logtape @logtape/pretty @logtape/syslog
yarn upgrade @logtape/logtape @logtape/pretty @logtape/syslog
pnpm update  @logtape/logtape @logtape/pretty @logtape/syslog
bun  update  @logtape/logtape @logtape/pretty @logtape/syslog
deno update  @logtape/logtape @logtape/pretty @logtape/syslog

After updating, redeploy any service that renders logs with the built-in formatters or sends them through the syslog sink. The 1.x line and earlier did not receive a patch in this round; if you are still on one of those versions, upgrade to a 2.x release.

Thanks to @manus-use for reporting the formatter issue, and to @OryamDeune, @manus-use, @avrlab233, and @manus-pi, who each reported the syslog issue independently. All of them reported privately and gave us the time to ship fixes across every maintained release line first. Both advisories came with a precise pointer to the vulnerable code and output we could reproduce straight away, which is why these turned into narrow fixes rather than long investigations. We appreciate the care that went into them.

If anything is unclear, ask below.