Repository navigation
Upgrade @opentui/solid to resolve @babel/core advisory (Dependabot alert #16) #25
Description
Summary
Dependabot alert #16 flags @babel/core (GHSA-4x5r-pxfx-6jf8, "Arbitrary File Read via sourceMappingURL Comment", low severity). Vulnerable range <= 7.29.0; first patched version 7.29.6.
This cannot be fixed by a lockfile refresh and is deliberately deferred from the security-advisory dependency update.
Why a lockfile refresh can't fix it
devDependenciesdeclares@opentui/solid: ^0.2.9, which resolves to 0.2.16 — the newest 0.2.x release.@opentui/solid@0.2.16pins@babel/coreexactly at7.28.0(not a range), sonpm updatecannot move it.@opentui/solid@0.3.1also pins@babel/core7.28.0.@opentui/solid@0.6.6(currentlatest) depends on@babel/core7.29.7, which is patched.- Dependabot PR chore(deps-dev): bump @opentui/solid from 0.2.16 to 0.3.1 #11 (
@opentui/solid0.2.16 → 0.3.1) currently fails CI, and would not resolve this alert on its own anyway.
(Verified with npm view @opentui/solid@<version> dependencies.)
Resolution
Upgrade @opentui/solid (and the matching @opentui/core / @opentui/keymap) to a release that depends on @babel/core >= 7.29.6 (e.g. 0.6.x). This is migration work: the 0.2 → 0.6 jump may include API/behavior changes in the TUI renderer, and the peerDependencies range (>=0.2.9 <1) and solid-js compatibility need to be re-validated.
Why not overrides
An npm overrides entry forcing @babel/core@7.29.x would violate @opentui/solid's exact pin and risks silently breaking the Solid JSX transform (babel-preset-solid via @opentui/solid), which would not necessarily surface as a test failure. We prefer to take the fix through a supported upstream release.
Risk / exposure
@babel/core here is part of the build-time dev toolchain only (dependency scope: development). It is not shipped in the published package's runtime (dist/), and exploitation requires processing attacker-controlled source with a crafted sourceMappingURL comment during a local/CI build.
Activity
skwid138 commentedon Oct 15, 2026
Update (2026-10-15)
Related Dependabot PRs
@opencode-ai/plugin→ 1.19.0) is blocked.@opencode-ai/plugin@1.19.0declares optional peer dependencies@opentui/core,@opentui/solid, and@opentui/keymapat>=0.4.5. That conflicts with the locked@opentui/core@0.2.16, sonpm cifails withERESOLVE(CI run 38793461986).npm_and_yarngroup:@babel/core7.28.0 → 7.29.7, plushandlebars4.7.9 → 4.7.10) also bumps@opentui/solidand@opentui/keymapfrom^0.2.9to^0.6.6(resolving@opentui/core0.6.6). Itstestandvalidatechecks pass, which makes it the de facto@opentuimigration PR for this issue. TUI behavior needs a manual check before merging, because the tests may not cover renderer behavior.@opentui/solid→ 0.3.1) still failstest. The 0.6.x path in chore(deps): bump the npm_and_yarn group across 1 directory with 2 updates #27 supersedes it.New linked advisory: seroval (Dependabot alert #95)
serovalcritical advisory GHSA-p6vx-979v-rg4c, patched in 1.6.2. The lockfile currently hasseroval@1.5.4viasolid-js@1.9.12.solid-js1.9.12–1.9.15 depend onseroval~1.5.x, andsolid-js1.9.16+ depend on~1.6.8.@opentui/solidrelease checked (0.2.16, 0.4.5, 0.5.0, 0.6.0, 0.6.6) declares the peer dependencysolid-jsat exactly1.9.12.@opentuidoes not fix seroval, and upgradingsolid-jsbreaks@opentui/solid's exact peer pin. I'm planning the seroval fix separately (either anoverridesentry or an upstream request to@opentui/solid).Handlebars (Dependabot alerts #96–98)
@semantic-release/commit-analyzer/@semantic-release/release-notes-generator→conventional-changelog-writer→handlebars) and have nothing to do with@opentui. chore(deps): bump the npm_and_yarn group across 1 directory with 2 updates #27 happens to include the patchedhandlebars4.7.10, but chore(deps): bump the npm_and_yarn group across 1 directory with 2 updates #27 is waiting on manual TUI verification, so I'll fix handlebars separately.