CVE-2025-65637 in logrus
Summary
by MITRE • 12/04/2025
A denial-of-service vulnerability exists in github.com/sirupsen/logrus when using Entry.Writer() to log a single-line payload larger than 64KB without newline characters. Due to limitations in the internal bufio.Scanner, the read fails with "token too long" and the writer pipe is closed, leaving Writer() unusable and causing application unavailability (DoS). This affects versions < 1.8.3, 1.9.0, and 1.9.2. The issue is fixed in 1.8.3, 1.9.1, and 1.9.3+, where the input is chunked and the writer continues to function even if an error is logged.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/05/2026
The vulnerability described in CVE-2025-65637 represents a critical denial-of-service condition within the popular go logging library logrus maintained by sirupsen. This issue manifests specifically when applications utilize the Entry.Writer() method to process log messages exceeding 64KB in size without embedded newline characters. The flaw stems from the library's internal handling of large payloads through bufio.Scanner which imposes inherent limitations on token size processing. When a log entry surpasses the 64KB threshold without proper line termination, the scanner encounters a "token too long" error that propagates through the logging pipeline. This error condition causes the underlying writer pipe to close abruptly, effectively rendering the logging mechanism inoperable for subsequent log operations. The operational impact extends beyond simple logging failures as it can lead to complete application unavailability since the logging system becomes the primary mechanism for capturing application state and error conditions.
The technical root cause of this vulnerability aligns with CWE-704, which addresses improper handling of large data inputs in buffer operations. The implementation utilizes bufio.Scanner internally without proper input validation or chunking mechanisms for oversized payloads, creating a scenario where the system cannot gracefully handle edge cases in data processing. This weakness directly impacts the application's fault tolerance and resilience characteristics, particularly in environments where large log entries might be generated during error conditions or when processing extensive data structures. The vulnerability affects multiple release versions including those prior to 1.8.3, 1.9.0, and 1.9.2, indicating a persistent design flaw that required multiple patch releases to address properly. The fix implemented in versions 1.8.3, 1.9.1, and 1.9.3+ demonstrates a shift toward more robust input handling through chunking mechanisms that prevent the scanner from encountering oversized tokens while maintaining continuous writer functionality.
From an operational security perspective, this vulnerability presents significant risk to applications that rely heavily on structured logging for monitoring and debugging purposes. The DoS condition can be easily triggered through controlled input manipulation, making it particularly dangerous in environments where external inputs are logged without sanitization. Attackers could exploit this weakness to cause application downtime by sending large unstructured log entries that exceed the 64KB limit, effectively crashing the logging system and potentially leading to cascading failures in application availability. The ATT&CK framework categorizes this type of vulnerability under T1499.004 - Endpoint Denial of Service, as it specifically targets the availability of application endpoints through logging mechanisms. Organizations implementing logrus in production environments must consider this vulnerability as a potential attack surface, particularly in systems where logging is performed on user-provided data or where log aggregation services might be targeted through malformed log entries. The remediation strategy requires immediate patching of affected versions to ensure that the chunking mechanism prevents token size limitations while maintaining backward compatibility with existing logging configurations.