CVE-2026-44728

What it actually does

Babel versions 7.12.0 through 7.29.3 and 8.0.0-alpha.0 through 8.0.0-alpha.12 can incorrectly compile attacker-crafted JavaScript in a way that causes the generated output to execute arbitrary code. The issue is not a remotely reachable network service by itself; exploitation depends on a vulnerable Babel version processing malicious source code or build input and the resulting compiled code being executed in a build, test, server-side rendering, deployment, or runtime context. Successful exploitation can cross trust boundaries because untrusted input to a compiler can become trusted executable output.

Why it matters to the business

Organizations that compile JavaScript from third-party, user-submitted, plugin-generated, or otherwise untrusted sources may be exposed to code execution in build pipelines, developer workstations, CI/CD runners, or downstream applications. Compromise could lead to theft of source code, credentials, build secrets, package publishing tokens, or tampering with released application code. Although the current EPSS is low and there is no known KEV listing or public exploit maturity reported, the high CVSS score and broad Babel ecosystem usage make timely remediation important, especially for build systems that handle external contributions or automated dependency updates.

How an attack unfolds

An attacker first finds a path where code they control is processed by Babel, such as a pull request, package contribution, template or plugin input, build artifact, generated JavaScript, or other source that enters a compilation workflow. They craft JavaScript that triggers the vulnerable Babel behavior. When a vulnerable Babel version compiles that input, it emits output containing attacker-controlled executable logic. The attacker then relies on that generated output being executed during tests, bundling, server-side rendering, deployment, application startup, or by end users. Depending on where execution occurs, the attacker may gain access to CI secrets, modify build output, execute commands in the build environment, exfiltrate source or credentials, or introduce malicious code into a shipped application.

How to fix it

Upgrade Babel to a fixed version: use Babel 7.29.4 or later on the 7.x line, or 8.0.0-alpha.13 or later if using the 8.0.0 alpha line. Update all direct and transitive Babel packages consistently, including @babel/core and related Babel compiler packages resolved through package-lock.json, yarn.lock, pnpm-lock.yaml, or other dependency locks. Regenerate lockfiles from trusted sources and rebuild artifacts after upgrading. If immediate upgrade is not possible, avoid compiling untrusted JavaScript, disable workflows that build external contributions without review, isolate CI runners, remove access to high-value secrets from build jobs, and require manual approval before running builds from forks or untrusted branches.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles no longer resolve Babel to vulnerable versions. Check package managers with commands such as npm ls @babel/core, yarn why @babel/core, pnpm why @babel/core, or equivalent software composition analysis tooling. Verify that resolved Babel versions are 7.29.4 or later, or 8.0.0-alpha.13 or later for alpha users. Rebuild application bundles and CI images after the upgrade to ensure stale vulnerable toolchains are not still used. Validate that CI workflows for untrusted contributions do not expose secrets and that builds from forks or external submissions require explicit approval or run in restricted sandboxes.

Typical attack path

1. Identify an application, package, repository, or build workflow that uses Babel versions 7.12.0 through 7.29.3 or 8.0.0-alpha.0 through 8.0.0-alpha.12.
2. Find a route to submit or influence JavaScript source code or generated build input that Babel will compile.
3. Craft JavaScript intended to trigger the vulnerable compiler behavior and cause malicious logic to appear in the generated output.
4. Cause the target workflow to run Babel against the crafted input, such as through CI, tests, bundling, server-side rendering, or release automation.
5. Wait for the compiled output to execute in the build or runtime environment.
6. Use the resulting code execution to steal secrets, alter artifacts, pivot within the build environment, or implant malicious application code.

How to detect it

To determine whether exploitation already occurred, focus on environments where vulnerable Babel versions compiled code from untrusted or semi-trusted sources. Review CI/CD logs, build runner telemetry, package publishing logs, source control events, pull request history, artifact repositories, endpoint process logs, and network egress from build systems. Look for builds from forks, external contributors, automated dependency updates, or generated code that ran with Babel 7.12.0 through 7.29.3 or 8.0.0-alpha.0 through 8.0.0-alpha.12. Compare generated JavaScript artifacts against trusted rebuilds from fixed Babel versions and review unexpected additions such as child process execution, credential access, dynamic imports, obfuscated payloads, or outbound HTTP requests. Investigate build jobs that spawned shells or interpreters, accessed environment variables or token files unexpectedly, modified package publishing configuration, or produced artifacts that differ from source-controlled expectations. There are no public, CVE-specific payload strings or known threat actor indicators provided, so detection should be behavior-based and centered on build provenance, generated output integrity, and suspicious activity from CI runners or developer workstations.

What your security team should do

• Inventory all repositories, build images, CI templates, and JavaScript projects that use Babel, prioritizing internet-facing products, package publishing workflows, and projects that process third-party code.
• Upgrade @babel/core and related Babel dependencies to 7.29.4 or later, or 8.0.0-alpha.13 or later where applicable.
• Regenerate lockfiles and rebuild containers, build agents, and release artifacts to remove cached vulnerable Babel versions.
• Restrict untrusted pull request and fork builds from accessing secrets, deployment credentials, package publishing tokens, or production cloud permissions.
• Review recent builds that compiled external or user-controlled code while using vulnerable Babel versions, especially builds that had access to credentials or produced release artifacts.
• Add dependency policy checks to block Babel versions 7.12.0 through 7.29.3 and 8.0.0-alpha.0 through 8.0.0-alpha.12.
• Monitor for suspicious build behavior, unexpected network connections, modified generated bundles, unusual child processes, and unexplained changes to published JavaScript artifacts.