CVE-2025-25290: octokit request.js · ReDoS
Affects octokit request.jsSource CVE Database V5
Not known to be exploited · CVSS 5.3 Medium.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.7% chance of exploitation in 30 days – higher than 55% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 14 Feb 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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
AI-suggested
To mitigate CVE-2025-25290, European organizations should: 1) Upgrade all instances of octokit request.js to version 9.2.1 or later, or 8.4.1 or later, where the regex vulnerability is fixed. 2) Implement input validation and sanitization on HTTP headers, particularly the 'link' header, to detect and reject suspicious or malformed inputs that could trigger regex backtracking. 3) Employ rate limiting and anomaly detection on API endpoints or services that process GitHub API responses to reduce the risk of resource exhaustion attacks. 4) Monitor application logs and performance metrics for unusual CPU spikes or slowdowns during API interactions that could indicate attempted exploitation. 5) For critical infrastructure, consider isolating or sandboxing components that parse external HTTP headers to limit the impact of potential DoS attacks. 6) Educate development teams about the risks of ReDoS vulnerabilities and encourage secure coding practices when handling untrusted input. 7) Review and update dependency management policies to ensure timely patching of third-party libraries. These measures collectively reduce the likelihood and impact of exploitation beyond simply upgrading the vulnerable library.
Description
@octokit/request sends parameterized requests to GitHub’s APIs with sensible defaults in browsers and Node. Starting in version 1.0.0 and prior to versions 9.2.1 and 8.4.1, the regular expression `/<([^>]+)>; rel="deprecation"/` used to match the `link` header in HTTP responses is vulnerable to a ReDoS (Regular Expression Denial of Service) attack. This vulnerability arises due to the unbounded nature of the regex's matching behavior, which can lead to catastrophic backtracking when processing specially crafted input. An attacker could exploit this flaw by sending a malicious `link` header, resulting in excessive CPU usage and potentially causing the server to become unresponsive, impacting service availability. Versions 9.2.1 and 8.4.1 fix the issue.
References
- github.com/octokit/request.js/security/advisories/GHSA-rmvr-2pp2-xj38 (opens in a new tab)
- github.com/octokit/request.js/commit/34ff07ee86fc5c20865982d77391bc910ef19c68 (opens in a new tab)
- github.com/octokit/request.js/commit/356411e3217019aa9fc8a68f4236af82490873c2 (opens in a new tab)
- github.com/octokit/request.js/commit/6bb29ba92a52f7bf94469c3433707c682c17126c (opens in a new tab)
- github.com/octokit/request.js/releases/tag/v8.4.1 (opens in a new tab)
- github.com/octokit/request.js/releases/tag/v9.2.1 (opens in a new tab)