fix(deps): bump @babel/core to ^7.29.6 to resolve GHSA-4x5r-pxfx-6jf8#839
Merged
Conversation
Adds a pnpm override forcing @babel/core to a patched version, resolving the arbitrary file read via sourceMappingURL comment vulnerability (CVE-2026-49356, low severity) pulled in transitively via @sentry/esbuild-plugin -> @sentry/bundler-plugin-core. Closes Dependabot alert #184.
BYK
added a commit
that referenced
this pull request
Jul 1, 2026
## Summary Resolves 3 Dependabot alerts (**#186, #187, #188**), all the same advisory across both projects. - **Advisory:** [GHSA-h67p-54hq-rp68](GHSA-h67p-54hq-rp68) / CVE-2026-53550 — *js-yaml: Quadratic-complexity DoS in merge key handling via repeated aliases* (medium severity) - **Vulnerable:** \`>= 4.0.0, <= 4.1.1\` → **patched:** \`4.2.0\` These alerts were opened by the post-merge rescan right after #839 landed (newly-published advisory), not caused by that change. ## Fix | Alert | Manifest | Relationship | Change | |---|---|---|---| | #187 | root \`package.json\` | direct devDep | bump pinned \`js-yaml\` \`4.1.1\` → \`4.2.0\` | | #188 | root \`pnpm-lock.yaml\` | direct devDep | regenerated → \`4.2.0\` | | #186 | \`docs/pnpm-lock.yaml\` | transitive (astro/starlight) | \`pnpm.overrides\` \`js-yaml: ^4.2.0\` → resolves to \`4.3.0\` | - Root uses an exact pin (matching the repo's pinned-devDep convention, e.g. \`tar\`); docs uses an override (matching the docs override style) since js-yaml is transitive there. - Both lockfile diffs are 100% js-yaml-scoped — no unrelated drift. No \`@babel/core\`/other packages touched. ## Verification - Root: \`pnpm build\` ✅, \`pnpm test\` ✅ (1025 passed, 1 skipped), \`pnpm lint\` ✅ (0 errors), \`pnpm format:check\` ✅ (tracked files) - Docs: \`pnpm build\` ✅ (27 pages built) - \`grep "js-yaml@" pnpm-lock.yaml docs/pnpm-lock.yaml\` — only \`4.2.0\`/\`4.3.0\` remain; \`4.1.1\` gone. (\`@types/js-yaml\` is type-defs only, not the vulnerable package.)
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves the only open Dependabot alert on the repo (#184).
Dependency chain:
```
@sentry/esbuild-plugin@2.23.1 (direct devDep)
└─ @sentry/bundler-plugin-core@2.23.1
└─ @babel/core (vulnerable)
```
Fix
Added a `pnpm.overrides` entry `"@babel/core": "^7.29.6"`, following the repo's established pattern for transitive-dependency vulnerabilities. `pnpm install` bumped the whole `@babel/*` toolchain to `7.29.7` in lockstep.
Compatibility: the consumer `@sentry/bundler-plugin-core@2.23.1` declares `@babel/core: ^7.18.5` (and the internal `@babel/helper-module-transforms` peer range is `^7.0.0`); `7.29.7` satisfies both, and `^7.29.6` stays within the 7.x major so it cannot regress into the vulnerable range or the separate `8.0.0-alpha … <8.0.0-rc.5` vulnerable range. A bare `@babel/core` override key is correct here since there is a single copy in the lockfile. Upgrading `@sentry/esbuild-plugin` itself was rejected as it would require a 3-major jump (2.x → 5.x).
Notes:
Verification