@octokit/request-error versions 1.2.1 and 1.2.0 offer developers a robust error class specifically designed for handling request errors within the Octokit ecosystem. Both versions share core functionalities, including dependencies like "once," "deprecation," and "@octokit/types," ensuring consistent error handling across different Octokit libraries. The library empowers developers to gracefully manage and interpret errors originating from Octokit requests, facilitating more resilient and user-friendly applications.
The key differences between versions 1.2.0 and 1.2.1 lie primarily in their development dependencies and release dates. Version 1.2.1, released on January 30, 2020, incorporates later versions of development tools such as "@types/jest," "@types/node," "@pika/plugin-build-web," "@pika/plugin-build-node," "@pika/plugin-bundle-web," and "@pika/plugin-ts-standard-pkg." These updates likely include bug fixes and performance improvements introduced in those dependencies. Furthermore, version 1.2.1 uses a newer version of "semantic-release". Version 1.2.0 arrived earlier, on November 4, 2019, with slightly older versions of the same tools. These updates are mainly relevant for contributors and maintainers of the @octokit/request-error library itself, rather than for developers directly using the error class in their projects. For consumers of the library, the change between 1.2.0 and 1.2.1 is unlikely to impact their code, as no changes are introduced in the public API. Both versions provide the same core functionality for error handling in Octokit-based applications.
All the vulnerabilities related to the version 1.2.1 of the package
@octokit/request-error has a Regular Expression in index that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking
A Regular Expression Denial of Service (ReDoS) vulnerability exists in the processing of HTTP request headers. By sending an authorization header containing an excessively long sequence of spaces followed by a newline and "@", an attacker can exploit inefficient regular expression processing, leading to excessive resource consumption. This can significantly degrade server performance or cause a denial-of-service (DoS) condition, impacting availability.
The issue occurs at line 52 of iterator.ts in the @octokit/request-error repository.
The vulnerability is caused by the use of an inefficient regular expression in the handling of the authorization header within the request processing logic:
authorization: options.request.headers.authorization.replace(
/ .*$/,
" [REDACTED]"
)
The regular expression / .*$/ matches a space followed by any number of characters until the end of the line. This pattern is vulnerable to Regular Expression Denial of Service (ReDoS) when processing specially crafted input. Specifically, an attacker can send an authorization header containing a long sequence of spaces followed by a newline and "@", such as:
headers: {
authorization: "" + " ".repeat(100000) + "\n@",
}
Due to the way JavaScript's regular expression engine backtracks while attempting to match the space followed by arbitrary characters, this input can cause excessive CPU usage, significantly slowing down or even freezing the server. This leads to a denial-of-service condition, impacting availability.
import { RequestError } from "@octokit/request-error";
const error = new RequestError("Oops", 500, {
request: {
method: "POST",
url: "https://api.github.com/foo",
body: {
bar: "baz",
},
headers: {
authorization: ""+" ".repeat(100000)+"\n@",
},
},
response: {
status: 500,
url: "https://api.github.com/foo",
headers: {
"x-github-request-id": "1:2:3:4",
},
data: {
foo: "bar",
},
},
});
This is a Regular Expression Denial of Service (ReDoS) vulnerability, which occurs due to an inefficient regular expression (/ .*$/) used to sanitize the authorization header. An attacker can craft a malicious input that triggers excessive backtracking in the regex engine, leading to high CPU consumption and potential denial-of-service (DoS).
authorization headers are at risk, especially those processing a large volume of authentication requests.