Uh oh!
There was an error while loading. Please reload this page.
fix(deps): upgrade esbuild to 0.28.1 (GHSA-gv7w-rqvm-qjhr) - #2395
Merged
Conversation
Bump the esbuild catalog from ^0.27.3 (resolving 0.27.7) to ^0.28.1 to resolve the High-severity advisory GHSA-gv7w-rqvm-qjhr (missing binary integrity verification before executing downloaded binaries). All workspace consumers reference esbuild via `catalog:` (@workflow/builders, @workflow/cli, workbench/example, and the root devDependency), so the single catalog bump propagates everywhere. Adds a patch changeset for the two publishable consumers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 991f628 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Contributor
There was a problem hiding this comment.
Pull request overview
This PR upgrades the workspace’s esbuild dependency to ^0.28.1 to address GHSA-gv7w-rqvm-qjhr, propagating the bump via the pnpm catalog and updating the lockfile accordingly.
Changes:
- Bump
esbuildin the pnpm catalog from^0.27.3to^0.28.1. - Re-resolve
pnpm-lock.yamlto incorporateesbuild@0.28.1and its platform binaries. - Add a changeset to publish patch releases for
@workflow/buildersand@workflow/cli.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| pnpm-workspace.yaml | Updates the pnpm catalog to use esbuild: ^0.28.1. |
| pnpm-lock.yaml | Updates lockfile resolutions to include esbuild@0.28.1 and related dependency graph changes. |
| .changeset/bump-esbuild-0-28-1.md | Adds a patch changeset for publishable consumers impacted by the bump. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
36
to
+38
| esbuild: | ||
| specifier: ^0.27.3 | ||
| version: 0.27.7 | ||
| specifier: ^0.28.1 | ||
| version: 0.28.1 |
ContributorAuthor
There was a problem hiding this comment.
Agreed that 0.27.7 lingers transitively. I tried both remediation paths:
- Upgrade the consumers — no upstream release helps yet.
vite7.x pinsesbuild: ^0.27.0and even the latestastro(6.4.6) still pins^0.27.3, both of which exclude0.28.x(esbuild treats0.27→0.28as a breaking bump). Only a majorvite8 /astro6 jump would widen this — too risky for the example workbenches. - Force a pnpm
override(esbuild: ^0.28.1) — this does unify everything on0.28.1, but it breaks@workflow/web's production build: react-router → vite 6.4.1 → esbuild 0.28.1 fails withTransforming destructuring to the configured target environment ... is not supported yeton worker code that0.27.7compiles fine. So the override regresses a published, deployed package, and I reverted it.
Given the advisory's exploitable path is Deno-specific (lib/deno/mod.ts; the Node install path already verifies integrity) and the remaining copies are build-time-only dev tooling (vite/astro/fumadocs), the residual risk is negligible. The flagged direct dependency in packages/builders — the subject of the advisory — is on 0.28.1. I've left the transitive copies rather than ship a broken build; they'll clear as vite/astro widen their ranges.
Comment on lines
+11899
to
+11905
| hasBin: true | ||
| esbuild@0.28.1: | ||
| resolution: {integrity: sha512-HrJrvZv5ayxBzPfwphOoNzkzOIIlifzk0KJrGK2c8R4+LKpMtpYLQeUdjnwjWv/LZlkH2laZk+4w78pi99D4Vw==} |
ContributorAuthor
There was a problem hiding this comment.
Good catch on the churn — fixed in 991f628. Re-resolving the lockfile now drops esbuild@0.28.0 entirely: nitropack@2.13.4 (which declares esbuild: ^0.28.0) consolidates onto 0.28.1, so only 0.28.1 plus the upstream-pinned 0.27.7 remain.
Minor correction: 0.28.0 wasn't actually orphaned in the prior revision — it was still referenced by nitropack@2.13.4 — but that's moot now that it's gone.
The canary E2E jobs run `pnpm install --no-frozen-lockfile` (they mutate the next dependency), which re-resolves the catalog and hits the 48h `minimumReleaseAge` gate on the freshly-published esbuild@0.28.1, failing setup with ERR_PNPM_NO_MATCHING_VERSION. Add esbuild and @esbuild/* to minimumReleaseAgeExclude (pnpm's recommended fix, consistent with the existing @vercel/*, @workflow/*, turbo exclusions) so the intended, catalog-pinned security upgrade resolves under non-frozen installs. Re-resolving also drops the redundant esbuild@0.28.0 (nitropack@2.13.4 consolidates onto 0.28.1 within its ^0.28.0 range). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
pranaygp
enabled auto-merge (squash)
June 13, 2026 06:47
TooTallNate
approved these changes
Jun 13, 2026
Contributor
Backport to This is usually an infrastructure problem (e.g. the configured AI model could not be found, an AI Gateway error, or an opencode crash) rather than a merge conflict. Check the job logs linked above for details. Once the underlying issue is fixed, re-run the Backport to stable workflow manually via |
github-actionsBot
added a commit
that referenced
this pull request
Jun 13, 2026
* fix(deps): upgrade esbuild to 0.28.1 (GHSA-gv7w-rqvm-qjhr) Bump the esbuild catalog from ^0.27.3 (resolving 0.27.7) to ^0.28.1 to resolve the High-severity advisory GHSA-gv7w-rqvm-qjhr (missing binary integrity verification before executing downloaded binaries). All workspace consumers reference esbuild via `catalog:` (@workflow/builders, @workflow/cli, workbench/example, and the root devDependency), so the single catalog bump propagates everywhere. Adds a patch changeset for the two publishable consumers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ci): exclude esbuild from minimumReleaseAge gate The canary E2E jobs run `pnpm install --no-frozen-lockfile` (they mutate the next dependency), which re-resolves the catalog and hits the 48h `minimumReleaseAge` gate on the freshly-published esbuild@0.28.1, failing setup with ERR_PNPM_NO_MATCHING_VERSION. Add esbuild and @esbuild/* to minimumReleaseAgeExclude (pnpm's recommended fix, consistent with the existing @vercel/*, @workflow/*, turbo exclusions) so the intended, catalog-pinned security upgrade resolves under non-frozen installs. Re-resolving also drops the redundant esbuild@0.28.0 (nitropack@2.13.4 consolidates onto 0.28.1 within its ^0.28.0 range). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Pranay Prakash <pranay.gp@gmail.com>
Contributor
Backport PR opened against |
VaguelySerious pushed a commit
that referenced
this pull request
Jun 13, 2026
…2404) Co-authored-by: Pranay Prakash <pranay.gp@gmail.com>
Merged
pranaygp added a commit
that referenced
this pull request
Jun 14, 2026
* origin/main: docs: document run idempotency (#2011) Render attr_set events and run attributes in observability UI (#2393) [ci] Fix backport job model slug (#2403) [ci] Comment on PR when backport fails, revert to use opus 4.8 (#2400) Update queue client to 0.3.1 (#2399) fix(deps): upgrade esbuild to 0.28.1 (GHSA-gv7w-rqvm-qjhr) (#2395)
pranaygp added a commit
that referenced
this pull request
Jun 16, 2026
* origin/main: Small detail panel cleanup (#2459) Fix lazy Next workflow HMR (#2438) Prevent peer dependency-only major bumps (#2437) fix(changesets): only major-bump peer dependents when out of range (#2439) Version Packages (beta) (#2428) otel: explicit traceparent injection + linked-trace mode for bounded per-invocation traces (#2363) [next] Clarify `serverExternalPackages` warning (#2417) Add .swc gitignore handling to builder (#2427) Version Packages (beta) (#2390) [ci] Increase dev.test.ts cleanup hook timeout (#2416) [world-vercel] Switch event endpoints to v4 wire format (#2055) docs: document run idempotency (#2011) Render attr_set events and run attributes in observability UI (#2393) [ci] Fix backport job model slug (#2403) [ci] Comment on PR when backport fails, revert to use opus 4.8 (#2400) Update queue client to 0.3.1 (#2399) fix(deps): upgrade esbuild to 0.28.1 (GHSA-gv7w-rqvm-qjhr) (#2395) test: e2e coverage for run-idempotency conflict-handling strategies (#2387) # Conflicts: # pnpm-lock.yaml
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 freeto 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.
🚨 Must be backported to
stable(4.x) post-mergeResolves Linear VULN-11749.
What this fixes
Socket / GitHub advisory GHSA-gv7w-rqvm-qjhr — "Missing binary integrity verification … enables remote code execution via
NPM_CONFIG_REGISTRY" (High, CVSS 8.1). Affected range>= 0.17.0 < 0.28.1; fixed in 0.28.1.This bumps the pnpm catalog entry for esbuild from
^0.27.3(resolving0.27.7) to^0.28.1. Every workspace package that depends on esbuild references it viacatalog:—@workflow/builders,@workflow/cli,workbench/example, and the root dev dependency — so the single catalog change propagates to all of them, and the flagged direct dependency inpackages/buildersnow resolves to0.28.1.Honest risk assessment
The advisory is real and correctly flagged, but the exploitable code path is Deno-specific (
lib/deno/mod.tsdownloaded the native binary without SHA-256 verification whenNPM_CONFIG_REGISTRYis set). The Node.js install path already verified integrity, and this repo is a Node.js/pnpm project that never uses esbuild's Deno distribution — so practical exploitability here is low. Regardless,0.27.7is in the affected npm range, it's a direct dependency ofpackages/builders, and the remediation is free, so upgrading is correct and clears the alert. (esbuild0.28.0/0.28.1exist specifically to add these integrity checks.)Transitive esbuild copies (why some
0.27.7remains)0.27.7still appears transitively under build-time-only dev tooling in the example workbenches (vite, astro, fumadocs). I tried both ways to remove it:vite7.x pinsesbuild: ^0.27.0and even the latestastro(6.4.6) pins^0.27.3, both excluding0.28.x(esbuild treats0.27→0.28as breaking). Only a major vite 8 / astro 6 jump would widen this.override— unifies everything on0.28.1, but breaks@workflow/web's build (react-router → vite 6.4.1 → esbuild 0.28.1 fails with "Transforming destructuring to the configured target environment … is not supported yet" on worker code that 0.27.7 compiles fine). Reverted.Since the vuln path is Deno-only and these are build-time dev tooling, the residual risk is negligible. They'll clear as vite/astro widen their ranges. (Re-resolving did drop the redundant
0.28.0— nitropack consolidated onto0.28.1.)CI:
minimumReleaseAgefixThe canary E2E jobs run
pnpm install --no-frozen-lockfile(they mutate thenextdependency), which re-resolves the catalog and hit the workspace's 48hminimumReleaseAgegate on the freshly-publishedesbuild@0.28.1(ERR_PNPM_NO_MATCHING_VERSION). Fixed by addingesbuild+@esbuild/*tominimumReleaseAgeExclude— pnpm's recommended remedy, consistent with the existing@vercel/*,@workflow/*,turboexclusions.--frozen-lockfilejobs (Build Packages, stable E2E) were unaffected and already passed.Changes
pnpm-workspace.yaml: esbuild catalog^0.27.3→^0.28.1; addesbuild+@esbuild/*tominimumReleaseAgeExcludepnpm-lock.yaml: re-resolved esbuild graph to0.28.1(diff scoped entirely to esbuild +@esbuild/*).changeset/bump-esbuild-0-28-1.md:patchbump for@workflow/buildersand@workflow/cliVerification
@workflow/buildersbuilds and all 170 tests pass against0.28.1(exercises theesbuild.build()API directly).@workflow/webbuilds cleanly (confirming the override revert).pnpm install --no-frozen-lockfile(the canary install mode) now completes with no age-gate error and a stable lockfile.0.28.x— only install-time integrity checks plus minor codegen fixes.