A denial-of-service flaw in the widely used Go logging library logrus can render Entry.Writer unusable when it receives a single-line log payload larger than 64 KB with no newline characters, creating the potential for sustained or persistent application unavailability until the library is patched or the process is restarted.
Background / Overview
github.com/sirupsen/logrus is one of the most common structured logging libraries in the Go ecosystem. Its
Entry.Writer helper provides an io.Writer interface for piping output into the log pipeline, which is convenient for capturing subprocess stdout/stderr, HTTP headers, or other text blobs directly into application logs.
On December 4, 2025 the defect catalogued as CVE-2025-65637 was published: when
Entry.Writer reads a
single-line payload larger than 64 KB that contains no newline characters, the library’s internal use of
bufio.Scanner hits its token-size limit, the scanner returns an error ("token too long"), and the writer's read end of the pipe is closed. That closure leaves the
Writer object unusable and can cause the host application to lose logging functionality or become unavailable. The maintainers and multiple vulnerability trackers confirm the affected and fixed versions, and the upstream project merged a fix that changes the scanner semantics to chunk input and preserve the writer after error handling. Key, verifiable facts:
- The failure mode is triggered by newline-free input greater than 64 KB read via
Entry.Writer.
- The underlying cause is the
bufio.Scanner token size limitation and how it is used by the writerScanner implementation.
- A pull request and subsequent releases implement chunked scanning (split function + increased buffer handling) to prevent the pipe from being permanently closed when the token is too large.
- A public proof-of-concept (PoC) repository reproduces the behavior and documents test outcomes across versions.
Multiple CVE/OSV/NVD entries and the GitHub Advisory Database list the same technical description and the same fixed versions (
v1.8.3,
v1.9.1,
v1.9.3+) while enumerating the vulnerable releases (
< v1.8.3,
v1.9.0,
v1.9.2). These authoritative advisories also classify the issue as an availability-impacting DoS and rate it in the high severity range under modern CVSS/SSVC frameworks.
How the bug works — technical breakdown
The Entry.Writer pattern and the attack primitive
Entry.Writer returns an io.Writer that forwards bytes into logrus’ processing pipeline. Many applications wire untrusted or semi‑trusted strings to that writer — for example, forwarding HTTP header values, receiving stdin/stdout from a subprocess, or relaying remote telemetry.
The dangerous shape of input is specific:
- A single, unbroken line (no newline bytes)
- Larger than 64 KB (the practical
bufio.Scanner token threshold)
- Delivered into the application via an io pipe into
Entry.Writer
When these conditions are met,
bufio.Scanner — by default designed for line-oriented or tokenized scanning — hits its internal token limit and returns a "
token too long" error. The current (vulnerable) implementation propagates that error in a way that closes the writer pipe and leaves the writer unusable, making subsequent writes fail and potentially disabling logging or even triggering a crash/lockup depending on supervisor code paths.
Why bufio.Scanner is the hinge point
bufio.Scanner is convenient but not intended for arbitrarily large tokens. It offers a safe default cap to avoid unbounded memory allocation when scanning tokens. If code does not explicitly use a split function that handles very large tokens or does not configure the scanner's buffer size, a large token will cause the scanner to error.
The fix merged into logrus replaces the naïve scanner usage with a custom split function that chunks input into manageable pieces (max chunk size ≈ 64 KB) and explicitly sets the scanner buffer size to the maximum expected token size. This allows the reader to consume long lines incrementally and ensures the write end of the pipe is not closed on scanner error.
Affected versions and the fix
- Vulnerable: all
github.com/sirupsen/logrus releases before v1.8.3, and specific releases v1.9.0 and v1.9.2.
- Patched:
v1.8.3, v1.9.1, and v1.9.3 and later. The repository merged a change that scans the input in 64 KB chunks and preserves writer behavior after a scanner error.
A public PoC demonstrates consistent behavior across test runs and lists result tables confirming the vulnerability in
v1.8.1,
v1.8.2,
v1.9.0, and
v1.9.2, while showing
v1.8.3,
v1.9.1, and
v1.9.3 behave correctly. This PoC is suitable for defenders to reproduce the exact failure mode in a controlled lab.
Impact: availability, blast radius, and practical exploitability
Nature of the impact
This is a classic
resource exhaustion / uncontrolled resource consumption vulnerability (CWE‑400) that impacts
availability only — there is no confidentiality or integrity compromise inherent to this defect. However, the operational consequences can be severe:
- Total loss of availability for the logging path: the writer becomes unusable for as long as the process continues; depending on how the application is written, this can cascade into broader service outages.
- Sustained attack feasibility: an attacker who can repeatedly send suitably crafted payloads (e.g., via an exposed ingestion endpoint, log-injection surface, or by influencing a subprocess’ stdout) can sustain denial of service.
- Persistent condition possibility: because the writer can be left in a broken state, the application may remain impaired even after the attack stops until a supervisor restarts the process or the underlying library is updated and the service rebuilt.
Who can exploit it?
Exploitability depends on whether an attacker can cause newline-free multi‑kilobyte strings to be written to
Entry.Writer in the target application. Realistic attack vectors include:
- Malicious header values or request bodies that the application pipes into the logger.
- Remote-controlled subprocesses (e.g., code that logs third-party tool output directly into
Writer) where an attacker can influence output.
- Telemetry or ingestion endpoints where unvalidated large fields are forwarded to
Writer.
If the application never routes untrusted large single-line data into
Entry.Writer, attack surface is low. But many real-world apps do exactly that in the name of convenience, and supply‑chain code or vendored libraries may introduce the vulnerable pattern indirectly.
Severity scores and tracker differences
Advisories list this as a high-severity availability issue (GitHub Advisory reports CVSS v4 score ≈ 8.7). Some OS/distribution trackers that map downstream packaging may temporarily show different CVSS v3 assessments (for example, some feeds summarize an equivalent CVSS v3 as 7.5). The important point is that multiple authoritative trackers classify it as a
DoS/availability vulnerability with real operational impact; defenders should act accordingly.
Exploitation example (high level)
The public proof‑of‑concept contains a small Go program and test scripts that:
- Create a large, newline-free byte sequence > 64 KB.
- Obtain
Entry.Writer from a logrus.Entry.
- Write the sequence into that writer and observe the scanner error and closed pipe.
- Test writing again and observe the writer remains unusable in affected versions; patched versions accept further writes (or log the error but continue).
Because the attack payload is trivial to construct and the PoC reproduces the issue reliably, the only real barrier to exploitation in a target environment is whether the attacker can get such input into the writer path.
What maintainers changed and why it fixes the problem
The upstream change:
- Implements a custom scanner split function that chunks long inputs into up-to-64 KB pieces instead of relying on a single large token.
- Adjusts scanner buffer configuration to accommodate expected chunk sizes and prevents the scanner from failing on a single token.
- Ensures that, even when an error is logged for a token, the
Writer remains functional for subsequent writes.
This approach avoids
bufio.Scanner’s token-size ceiling causing the read end of the writer to close. The change is minimal, backwards compatible for existing call sites, and suitable as an upstream patch.
Remediation: immediate steps for teams
- Upgrade logrus:
- Update to
v1.8.3, v1.9.1, or v1.9.3 (or any later release that contains the fix). These versions include the scanner-chunking fix that prevents the writer from becoming unusable.
- Verify your dependency graph:
- Run
go list -m all or inspect go.mod / go.sum to find modules that directly import github.com/sirupsen/logrus.
- Check for vendored or copied logrus code inside third‑party dependencies; some projects vendor dependencies and will not pick up upstream fixes until they update the vendored snapshots. Rebuild all artifacts that include the vulnerable code.
- Rebuild binaries and container images:
- Any binaries built with a vulnerable snapshot must be rebuilt after dependency upgrade. Containers and CI caches often keep old versions; refresh base images, clear module caches, and rebuild.
- If immediate upgrade is impossible, apply configuration/workarounds:
- Avoid piping untrusted long single-line data into
Entry.Writer; sanitize or split the input first.
- Wrap inbound data with an
io.LimitReader and ensure you inject newlines or chunk before writing to the logger.
- Replace direct use of
Entry.Writer with a controlled writer that enforces max-line length and safe chunking.
- Add process supervisors to restart broken processes quickly, but treat that as mitigation — it does not remove the underlying vulnerability.
- Detection & hunting:
- Search codebases for uses of
Entry.Writer and evaluate call sites for exposure to untrusted input.
- Alert on log messages or application logs containing "bufio.Scanner: token too long" or similar runtime errors, and on sudden loss of logging or repeated process restarts. The PoC and issue discussion show the "
token too long" string as an indicator of the scanner failure.
- Test the fix in staging:
- Use the PoC repo to reproduce the issue in a safe environment and to validate that your upgraded builds are immune. The repository includes scripts for automated testing across versions.
Developer and ops checklist (practical controls)
- Inventory: enumerate services that import
github.com/sirupsen/logrus directly or transitively.
- Prioritize: push updates first to externally‑exposed services and to agents that process untrusted text (inbound HTTP, ingestion endpoints, log forwarders).
- Rebuild: refresh containers, CI pipelines, and reproducible build artifacts that include logrus.
- Harden logging calls: where you accept external text, sanitize and chunk before logging; do not log massive single-line values raw.
- Add monitoring: detect scanner-related runtime errors, broken writers, and loss of logs.
- Vendor management: ask suppliers to confirm their builds have been rebuilt with patched logrus versions or provide patched artifacts.
Why this matters to WindowsForum readers and enterprise teams
- Many enterprise services use Go backend components or Go-based utilities in telemetry/data pipelines. Indirect exposure via third‑party code and vendor artifacts is common. The vulnerability is not a memory corruption or code‑exec bug — it is an operational DoS that can be trivially weaponized if an attacker can supply a crafted long single-line payload. The practical outcome can be a long or persistent outage for critical components (logging, telemetry ingestion, connectors), and that makes it an urgent patch for network‑reachable services.
- This defect also highlights a recurring class of issues: algorithmic complexity and misuse of bounded utilities (
bufio.Scanner) in code that handles untrusted inputs. Application teams must treat line-oriented scanning primitives cautiously and enforce explicit bounds, chunking, and timeouts. The community guidance for similar Go library fixes emphasizes replacing O(n^2) or unbounded behavior with buffering/streaming patterns and builder abstractions where appropriate.
Timeline, disclosure and upstream coordination
- The issue and the PR that addressed it were discussed and merged into the logrus repository; the maintainers released point versions that include the fix. The GitHub Advisory Database and OSV entries list the CVE and map the fixed versions. The PoC author(s) published an exploit repository and test harness confirming the behavior and fixed-version outcomes.
- Operational teams should cross-reference the GitHub advisory, internal SBOMs, and vendor lifecycle mapping in their patch automation to ensure the right artifact is replaced — especially when dealing with vendor-provided binaries or containers that may embed older snapshots. This pattern of "upstream fix exists but downstream artifacts must be rebuilt" is a common patching friction point in supply-chain management.
Limitations, caveats and unverifiable areas
- The technical behavior within a live target depends on how
Entry.Writer is used in the application. If code paths sanitize, chunk, or never accept very large single-line strings, the practical attack surface may be negligible. That assessment is application-specific and requires code review or dynamic testing.
- Some trackers present variant CVSS numbers (v3 vs. v4 or vendor-mapped scores), and distribution advisories can lag as downstream packs are rebuilt. When in doubt, validate the fixed artifact by rebuilding and testing rather than relying on an advisory’s version string alone.
Final analysis and recommendations
This vulnerability — CVE‑2025‑65637 — is a textbook example of an availability-only flaw caused by an interaction between a convenient but bounded scanning primitive and a real-world logging pattern (piping potentially large, unvalidated text into a logger). The vulnerability is easy to describe, straightforward to reproduce (public PoC exists), and has a small, safe upstream fix that preserves backward compatibility: chunk input and handle scanner errors without closing the writer. For practical risk reduction:
- Immediately identify and patch all services using vulnerable
logrus versions and rebuild any artifacts that embed the vulnerable code.
- Sanitize and bound untrusted input before logging; avoid piping raw external text into
Entry.Writer without validation.
- Use the PoC only in controlled lab environments to confirm patched behavior, and add monitoring rules for scanner-related errors.
This vulnerability is fixable with an update and a rebuild; the operational challenge is ensuring every artifact and downstream consumer adopts the patched snapshot. Treat it as a high-priority maintenance item for any network‑facing Go services or any system that logs untrusted text.
By aligning quick patching, artifact rebuilds, input sanitation, and detection, teams can close a low‑cost but potentially disruptive attack vector and reduce the likelihood of an attacker achieving sustained or persistent denial of service through log injection.
Source: MSRC
Security Update Guide - Microsoft Security Response Center