CVE-2025-55193

What it actually does

This flaw is an ANSI escape sequence injection issue in Active Record logging. In affected Rails versions prior to 7.1.5.2, 7.2.2.2, and 8.0.2.1, values passed as IDs to find and similar methods may be written to logs without escaping terminal control characters. If those logs are viewed directly in a terminal or emitted to terminal-backed stdout/stderr, a crafted ID can cause the terminal to interpret embedded ANSI/OSC sequences rather than display them as text. This can alter terminal output, hide or rewrite visible log lines, change formatting, inject misleading content, or potentially interact with terminal features such as hyperlinks or clipboard control depending on terminal configuration. The issue does not directly provide code execution, database access, or application takeover; its primary technical impact is log/terminal manipulation and low-integrity impact to operator-visible output.

Why it matters to the business

The main risk is operational deception: an attacker may make application logs shown in terminals misleading, unreadable, or visually altered, which can slow incident response, obscure suspicious requests, or cause engineers to misinterpret system behavior. The likelihood is currently low based on the provided EPSS score, there is no CISA KEV listing, no ransomware association, and no stated mature exploit activity; however, Rails is widely used and terminal/stdout logging is common in development, containers, and operational workflows, so affected applications should still be updated during normal patch cycles or sooner where logs are reviewed interactively.

How an attack unfolds

An attacker identifies an endpoint where user-controlled input is used as an Active Record lookup identifier, such as a route parameter passed to find, find_by, or related lookup logic. The attacker submits a crafted identifier containing raw or encoded ANSI escape sequences. The lookup may fail or be logged as part of Active Record query/error output. In vulnerable versions, the ID is written to the Rails log without terminal escaping. If the log stream is displayed directly in a terminal, such as via local server output, container logs, kubectl logs, tail -f, or journalctl output, the terminal interprets the escape sequences. The attacker’s payload can then clear parts of the screen, move the cursor, alter colors, create misleading visible log entries, hide following output, or trigger terminal-supported OSC behavior such as hyperlinks or clipboard-setting sequences. Successful exploitation depends on the malicious value reaching Active Record logging and the resulting log being viewed in a terminal that honors those control sequences.

How to fix it

Upgrade affected Rails applications to a patched version: Rails/Active Record 7.1.5.2, 7.2.2.2, 8.0.2.1, or later. For source-based Rails deployments, ensure the fix corresponding to rails/rails commit ddb56de25997491b57868d3a119b6aa3cd31ad4b is present. For affected Chainguard or Wolfi kubescape packages, upgrade to kubescape 3.0.37-r1 or later. If immediate upgrade is not possible, reduce exposure by ensuring logs are rendered through tools that escape control characters, avoid viewing untrusted application logs directly in terminals, sanitize or reject control characters in route parameters and IDs, and configure log pipelines to encode non-printable characters before display. Treat these mitigations as temporary; the durable fix is to upgrade the affected dependency/package.

How to confirm the fix worked

Confirm the installed Rails/Active Record version is 7.1.5.2, 7.2.2.2, 8.0.2.1, or later, or that the patched commit is included in the deployed Rails source. For packaged kubescape images or packages from Chainguard/Wolfi, confirm the package version is 3.0.37-r1 or later. Review Gemfile.lock, package manifests, container SBOMs, and runtime dependency output such as bundle info activerecord or rails -v. As a functional validation, in a non-production test environment submit a lookup ID containing a harmless escape-like sequence and verify that logs display the sequence as escaped text rather than causing terminal behavior such as color changes, cursor movement, or screen clearing. Also verify that log aggregation and viewer tooling encodes or safely renders non-printable control characters.

Typical attack path

1. Find a Rails application or packaged product running an affected Active Record version.
2. Identify a route or API parameter that is treated as a record ID and passed into Active Record lookup methods.
3. Send a request with an ID containing ANSI or OSC terminal escape sequences, often raw or URL-encoded.
4. Cause the application to log the lookup, SQL activity, parameter value, or resulting ActiveRecord::RecordNotFound/error context.
5. Wait for an engineer, operator, or log collection workflow to display the vulnerable log output in a terminal.
6. Use the interpreted terminal control sequence to manipulate visible terminal output, obscure evidence, or inject misleading text.

How to detect it

To determine whether exploitation was attempted, search web access logs, reverse-proxy logs, Rails production/development logs, application stdout/stderr, container logs, systemd/journald output, Kubernetes log exports, and SIEM-normalized HTTP events for ANSI escape characters or encoded terminal-control sequences in request paths, route IDs, query strings, parameters, and error messages. Pay particular attention to requests that produce ActiveRecord::RecordNotFound, routing errors, 400/404 responses, or unusual ID values containing ESC, CSI, or OSC patterns. Historical terminal manipulation may not leave an obvious visual trace after display, so inspect raw log bytes or safely encoded log exports rather than relying on terminal-rendered output. Look for payloads that clear the screen, move the cursor, change colors, set terminal titles, create terminal hyperlinks, or use OSC 52 clipboard sequences. If found, correlate source IPs, user agents, requested routes, timestamps, and subsequent activity to determine whether the activity was probing, exploitation, or part of broader suspicious behavior.

• %1b[
• %1B[
• %1b%5b
• %1B%5B
• %5C033[
• %5Cx1b[
• \u001b[
• \x1b[
• \033[
• ESC[
• ^[[
• %1b]
• %1B]
• %1b%5d
• %1B%5D
• \u001b]
• \x1b]
• \033]
• ESC]
• \x1b[2J
• \u001b[2J
• %1b%5b2J
• %1B%5B2J
• \x1b[H
• \u001b[H
• %1b%5bH
• \x1b]52;
• \u001b]52;
• %1b%5d52%3b
• %1B%5D52%3B
• \x1b]8;;
• \u001b]8;;
• %1b%5d8%3b%3b
• %1B%5D8%3B%3B
• ActiveRecord::RecordNotFound

What your security team should do

• Inventory Rails applications, containers, and packaged products that include Active Record versions prior to 7.1.5.2, 7.2.2.2, or 8.0.2.1.
• Prioritize upgrades for internet-facing Rails applications, systems where application logs are viewed directly via terminals, and containerized workloads whose stdout/stderr logs are commonly inspected interactively.
• Upgrade Rails/Active Record to 7.1.5.2, 7.2.2.2, 8.0.2.1, or later; upgrade Chainguard/Wolfi kubescape packages to 3.0.37-r1 or later where applicable.
• Add detection for ANSI/OSC control sequences in URL paths, query parameters, request bodies, Rails logs, container logs, and reverse-proxy logs.
• Configure log viewers, SIEM pipelines, and terminal-based operational tooling to escape or visibly encode non-printable characters before display.
• Review recent logs for suspicious requests containing encoded ESC characters or terminal-control patterns, especially requests that produced 400, 404, or ActiveRecord::RecordNotFound outcomes.
• Because this is not KEV-listed, not ransomware-associated, and has low EPSS, handle as a normal-priority dependency update unless local exposure or operational practices increase risk.