GHSA-xffm-g5w8-qvg7

What it actually does

A regular expression in the ConfigCommentParser component is susceptible to catastrophic backtracking. An attacker can supply a specially crafted configuration comment in a source file that, when parsed by the ESLint plugin, causes the process to consume excessive CPU resources, leading to a denial of service (DoS). The application or build process will hang and become unresponsive.

Why it matters to the business

This vulnerability can disrupt software development and deployment pipelines. An attacker can halt CI/CD builds, prevent developers from linting or committing code, and cause a general loss of developer productivity. This leads to delays in software releases and increased operational overhead to diagnose and resolve stalled processes.

How an attack unfolds

An attacker with the ability to contribute code to a project, such as through a pull request, crafts a malicious configuration comment within a source code file. When the project's automated tooling (e.g., a CI/CD pipeline, pre-commit hook, or IDE plugin) invokes ESLint to analyze the code, the vulnerable `@eslint/plugin-kit` attempts to parse the comment. The malicious string triggers a ReDoS condition, causing the ESLint process to enter an infinite loop and consume 100% of a CPU core, effectively freezing the process and denying service to the build system or developer.

How to fix it

To remediate this vulnerability, update the `@eslint/plugin-kit` package to version 0.3.4 or later. You can achieve this by running `npm install @eslint/plugin-kit@latest` or `yarn upgrade @eslint/plugin-kit --latest` in your project's root directory. Ensure your package-lock.json or yarn.lock file is updated and committed. For systems using downstream packages, such as Alpaquita Linux, update the `linux-lts` package to version `6.6.58-r0` or newer.

How to confirm the fix worked

To verify the vulnerability is patched, check the installed version of `@eslint/plugin-kit` in your project's dependencies. Run `npm list @eslint/plugin-kit` or `yarn why @eslint/plugin-kit` to confirm that the resolved version is 0.3.4 or higher. Additionally, use a software composition analysis (SCA) tool to scan your projects for any remaining instances of the vulnerable package.

Typical attack path

1. An attacker gains the ability to submit code to a target repository.
2. The attacker crafts a source code file containing a malicious configuration comment designed to exploit the ReDoS flaw.
3. The attacker commits the malicious file to the repository.
4. A CI/CD pipeline or developer's local environment automatically runs ESLint on the submitted code.
5. The vulnerable parser within `@eslint/plugin-kit` processes the comment, causing the ESLint process to hang and consume maximum CPU.
6. The build job or linting task fails, times out, or must be manually terminated, disrupting the development workflow.

How to detect it

Detection of exploitation relies on monitoring system behavior. Look for Node.js or ESLint processes exhibiting sustained 100% CPU utilization, particularly on CI/CD runners or developer workstations. Investigate build jobs that time out or hang indefinitely without clear error messages. Correlate these performance anomalies with recent code commits to identify the source file and commit that introduced the malicious content.

What your security team should do

• Immediately patch development tools and CI/CD environments using `@eslint/plugin-kit` to version 0.3.4 or later.
• Run SCA scans across all software repositories to identify and prioritize all instances of the vulnerable package for remediation.
• Implement monitoring and alerting on CI/CD runners for processes with sustained high CPU usage, which can be an indicator of a ReDoS attack.
• Review code submission policies to scrutinize new or suspicious-looking configuration comments in pull requests from external contributors.