Apache Tomcat CVE-2025-55754

Exploitation requires Tomcat running in an interactive console on Windows operating systems (Windows 10 or later with VT sequence support enabled, or third-party terminals like Windows Terminal, ConEmu), not as a Windows service which is standard production configuration. An administrator must actively view Tomcat logs in this ANSI-capable console environment either during real-time monitoring or historical log review. The attack is limited by required user interaction (UI:R in CVSS) - logs must be viewed in vulnerable terminals rather than through log aggregation systems, text editors, or remote log viewers that don't interpret ANSI sequences. While the CVSS vector shows no authentication required (PR:N) for sending the malicious request to Tomcat, the attack chain critically depends on administrator behavior and specific deployment architecture. Standard production deployments where Tomcat runs as a background service on Linux or Windows, or where logs are consumed via SIEM/log management platforms, are not exploitable despite the vulnerability's presence. The vendor notes no attack vector found for non-Windows systems despite theoretical possibility, further constraining realistic exploitation to Windows console scenarios.

The 9.6 CVSS score (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) appears inflated relative to realistic exploitation risk. While network-accessible (AV:N) and low-complexity (AC:L), the mandatory user interaction (UI:R) significantly constrains exploitation - an administrator must actively view logs in a vulnerable console configuration. The scope change (S:C) correctly reflects console/clipboard compromise beyond the Tomcat process boundary, but this requires the uncommon deployment scenario of running Tomcat interactively in a Windows console rather than as a background service. Most production Tomcat deployments run as Windows services or on Linux systems where administrators view logs via text editors or log aggregation tools that don't interpret ANSI sequences. The vendor explicitly states 'no attack vector was found' for non-Windows systems despite theoretical possibility. No CISA KEV listing or public exploit code identified, suggesting no confirmed active exploitation. EPSS score unavailable for risk comparison. The primary real-world scenario is social engineering against administrators in development/testing Windows environments, not automated exploitation of production servers. Priority should be moderate for Windows-based Tomcat instances with console access, low for typical production Linux deployments or Windows service configurations.

An attacker identifies a public-facing Tomcat instance and crafts a malicious URL containing embedded ANSI escape sequences designed to manipulate console output, such as sequences that clear the screen and display fake error messages followed by a suggested 'fix' command that actually runs attacker code. When a Windows administrator monitoring the Tomcat console in real-time (or reviewing recent logs in an ANSI-capable terminal) accesses the server logs after the malicious request is logged, the escape sequences execute in their console, displaying convincing fake security warnings prompting them to run a PowerShell command to 'remediate the issue.' The administrator, trusting the apparently legitimate log output from their Tomcat server, copies and executes the command, resulting in system compromise. No public exploit code exists, but the attack requires only HTTP request crafting and social engineering rather than technical exploitation complexity.