Skip to main content
VulnerabilityPublished Updated

CVE-2025-65637: logrus · Uncontrolled Resource Consumption

Affects logrusSource CVE Database V5

0

Not known to be exploited · CVSS 7.5 High : upgrade to 1.8.3 soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.6% chance of exploitation in 30 days – higher than 49% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 1.8.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Dec 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade github.com/sirupsen/logrus to 1.8.3.

Affected software

ProductAffectedFixed in
Gogithub.com/sirupsen/logruspkg:golang/github.com/sirupsen/logrusOther threatsAffected
  • <1.8.3
  • =1.9.0
  • =1.9.2
Fixed in
  • 1.8.3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

European organizations should immediately identify all applications and services using the logrus library, particularly versions prior to 1.8.3, 1.9.0, and 1.9.2. The primary mitigation is to upgrade to logrus versions 1.8.3, 1.9.1, 1.9.3, or later, where the vulnerability is fixed by chunking input to avoid scanner failures. If upgrading is not immediately feasible, organizations should implement input validation and sanitization to prevent logging of excessively large single-line payloads without newline characters. Rate limiting or filtering suspicious log inputs at the application or network level can reduce the risk of exploitation. Monitoring logs for unusual large entries and implementing alerting on logging failures can provide early detection of exploitation attempts. Additionally, segregating logging infrastructure and ensuring fallback logging mechanisms can help maintain availability during an attack. Security teams should also review application logging configurations to avoid logging untrusted or user-controlled data without proper controls.

Description

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.

References

Community reviews

Loading reviews…