@babel/eslint-parser is the actively maintained ESLint parser that lets ESLint understand experimental or non-standard JavaScript syntax that Babel transforms, and it replaces the now-deprecated babel-eslint package. If your project still depends on babel-eslint, the single most useful security action is migrating to @babel/eslint-parser, because the old package no longer receives updates and its presence is a signal that other parts of your toolchain may be stale too. This is less about a dramatic CVE and more about dependency hygiene: unmaintained build tooling is exactly where quiet risk accumulates.
Why the package was renamed
ESLint parses JavaScript into an abstract syntax tree before its rules run. Out of the box, ESLint's default parser understands standard ECMAScript, but it does not know about syntax that only exists because Babel transforms it: stage-3 proposals, certain TypeScript-adjacent constructs, or framework-specific extensions. babel-eslint bridged that gap by handing ESLint an AST produced through Babel.
That package was deprecated as part of Babel's move to consolidate its packages under the official @babel namespace. babel-eslint became @babel/eslint-parser. The rename was not purely cosmetic. Around the v11 release, the parser began requiring @babel/core as a peer dependency and expecting a valid Babel configuration to exist, which aligned the linter's understanding of your code with your actual Babel setup instead of a separate, possibly divergent, parser configuration. You will still see the two earlier names in old tutorials and Stack Overflow answers: babel-eslint (the deprecated package) and the informal babel eslint phrasing people use when searching for it. Both point you to the same destination today.
The security angle: deprecation is the risk
There is no headline remote-code-execution CVE that defines this package. The risk profile is subtler and, for build tooling, more common: a deprecated dependency stops receiving fixes.
A linter parser runs on your source during development and CI. It executes as part of your build with access to your filesystem and, transitively, its own dependency tree. When a package is deprecated, any vulnerability discovered later in it or its dependencies will not be patched upstream, and you inherit that exposure indefinitely. Deprecated build tooling also tends to pin old versions of shared libraries, which can hold your entire toolchain back and conflict with newer, patched versions elsewhere.
So the practical security guidance for @babel/eslint-parser is: use it (not babel-eslint), keep it current, and treat a lingering babel-eslint in your lockfile as a to-do item. You can confirm what you actually resolve with:
npm ls babel-eslint @babel/eslint-parser
npm audit
If babel-eslint still appears, something in your tree is pulling it in, and that something is due for an update. A continuous dependency scan surfaces deprecated and vulnerable build-time packages the same way it does runtime ones, which matters because devDependencies are easy to forget.
Migrating from babel-eslint
The migration is straightforward. Remove the old package, add the new one, and update your ESLint configuration to reference the renamed parser.
npm uninstall babel-eslint
npm install --save-dev @babel/eslint-parser @babel/core
Then update the ESLint config. In a classic .eslintrc file:
{
"parser": "@babel/eslint-parser",
"parserOptions": {
"requireConfigFile": false,
"babelOptions": {
"presets": ["@babel/preset-env"]
}
}
}
The requireConfigFile: false option is worth knowing about. Because the parser now expects a Babel config by default, projects without a babel.config.js (for example, some pure-linting setups) need to either provide one or set this flag and pass presets inline as shown. If you already have a Babel configuration for your build, you can drop the inline babelOptions and let the parser read your real config, which is the whole point of the peer-dependency change.
Where the parser fits, and where it does not
It is worth being clear about scope so you do not over-rely on it. @babel/eslint-parser only teaches ESLint to read syntax; it does not add lint rules. The rules that actually catch problems come from ESLint core and plugins. And a linter, even with the right parser, checks code style and correctness patterns, not exploitability of your dependencies.
For a modern TypeScript project, note that many teams no longer need @babel/eslint-parser at all, because @typescript-eslint/parser handles TypeScript directly. Reach for @babel/eslint-parser specifically when you rely on Babel to transform syntax that neither the default parser nor the TypeScript parser understands. Choosing the parser that matches your build reduces the number of tools you have to keep patched, which is itself a security win. Our academy covers keeping a JavaScript toolchain lean and current.
FAQ
Is babel-eslint the same as @babel/eslint-parser?
They are the same tool at different points in its life. babel-eslint is the deprecated original; @babel/eslint-parser is its maintained replacement under the official @babel namespace. New projects should use @babel/eslint-parser, and existing projects should migrate off babel-eslint.
Does @babel/eslint-parser have known vulnerabilities?
There is no defining high-severity CVE for the package. The relevant risk is using the deprecated babel-eslint instead, which no longer receives fixes. Keep @babel/eslint-parser current and run npm audit to catch issues in its dependency tree.
Why does @babel/eslint-parser need @babel/core as a peer dependency?
Starting around its v11 release, the parser reads your actual Babel configuration so ESLint's view of your code matches your build. That requires @babel/core present as a peer dependency and a valid Babel config, or the requireConfigFile: false option with inline presets.
Do I need @babel/eslint-parser for a TypeScript project?
Often not. @typescript-eslint/parser handles TypeScript directly. Use @babel/eslint-parser when you depend on Babel to transform syntax that the default ESLint parser and the TypeScript parser do not understand.