You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
12
12
- Fixed blame gutter commit navigation to use the file path as it existed at the attributing commit, so clicking a blame line whose commit predates a rename resolves to the correct historical path. [#1178](https://github.com/sourcebot-dev/sourcebot/pull/1178)
13
13
- Bumped transitive `fast-uri` dependency to `^3.1.2`. [#1181](https://github.com/sourcebot-dev/sourcebot/pull/1181)
14
14
- Upgraded `simple-git` to `3.36.0` to address CVE-2026-6951. [#1183](https://github.com/sourcebot-dev/sourcebot/pull/1183)
15
+
- Upgraded `hono` to `^4.12.18` to address CVE-2026-44455, CVE-2026-44456, CVE-2026-44457, CVE-2026-44458. [#1186](https://github.com/sourcebot-dev/sourcebot/pull/1186)
16
+
- Upgraded `ip-address` to `^10.2.0` to address CVE-2026-42338. [#1189](https://github.com/sourcebot-dev/sourcebot/pull/1189)
17
+
- Upgraded `fast-xml-builder` to `^1.2.0` to address CVE-2026-44664, CVE-2026-44665. [#1184](https://github.com/sourcebot-dev/sourcebot/pull/1184)
15
18
- Added `postcss` resolutions override to force all instances to `^8.5.10` to address CVE-2026-41305. [#1191](https://github.com/sourcebot-dev/sourcebot/pull/1191)
Copy file name to clipboardExpand all lines: CLAUDE.md
+64-6Lines changed: 64 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -255,26 +255,84 @@ Images added to `.mdx` files in `docs/` should be wrapped in a `<Frame>` compone
255
255
256
256
When fixing a CVE in a transitive dependency, prefer a real top-level upgrade over a forced `resolutions` override.
257
257
258
-
1.**Trace the dependency chain** to find which top-level package in `package.json` brings in the vulnerable transitive dep:
258
+
1.**Trace the dependency chain to a package in your own `package.json`.** Run:
259
259
260
260
```bash
261
261
yarn why <vulnerable-package> --recursive
262
262
```
263
263
264
-
2.**Prefer bumping the top-level dependency**to a version whose transitive tree no longer includes the vulnerable version. This is a real, supported upgrade and avoids forcing a version on a consumer that may not expect it.
264
+
"Top-level" means a package **literally listed in this repo's root or workspace `package.json`**under `dependencies`, `devDependencies`, or `peerDependencies` — not just any ancestor in the chain. If the chain is `vulnerable-pkg → mid-pkg → top-pkg`, do not stop at `mid-pkg`; keep walking until you reach `top-pkg`.
265
265
266
-
3.**Fall back to a `resolutions` override** only if no top-level bump resolves it (no compatible version exists, or it would require a breaking major). Match the existing format in `package.json` and pin with `^`, not `>=`:
266
+
2.**Check whether the existing ranges already allow a patched version.** Often the lockfile is just stale: every `^x.y.z` range in the chain still admits the patched version, but `yarn.lock` was written before that version existed. In that case, refresh the lockfile entry — no `package.json` change, no `resolutions` override:
267
+
268
+
```bash
269
+
yarn up <intermediate-or-vulnerable-pkg>
270
+
# or, to refresh many at once:
271
+
yarn dedupe
272
+
```
273
+
274
+
This is the lightest-weight fix: it doesn't force a version, it just bumps the lock to the latest version that satisfies the constraints already in the tree. Verify with `yarn why <vulnerable-package>` afterward — if every instance is now patched, you're done.
275
+
276
+
3.**If a refresh isn't enough, bump the top-level dependency** to a version whose transitive tree no longer includes the vulnerable version. This is also a real, supported upgrade. Verify the upgrade actually removes the vulnerable version with `yarn why <vulnerable-package>` after running `yarn install`.
277
+
278
+
4.**Fall back to a `resolutions` override** only if neither a refresh nor a top-level bump resolves it (no compatible version exists in the existing ranges, or a top-level upgrade would require a breaking major). Use the **qualified** form keyed to the existing source range (not a bare key, which overrides every requester unnecessarily), and pin with `^`, not `>=`:
267
279
268
280
```json
269
281
"resolutions": {
270
-
"<pkg>@npm:<existing-range>": "^<patched>"
282
+
"<pkg>@npm:<existing-source-range>": "^<patched>"
271
283
}
272
284
```
273
285
286
+
The `<existing-source-range>` is whatever range is currently requesting the vulnerable version (find it in `yarn.lock`, e.g. `^2.8.3`). Avoid the bare-key form `"<pkg>": "^x.y.z"`.
287
+
288
+
### Branch naming for CVE fixes
289
+
290
+
Use a **package-keyed** branch name, not a CVE-keyed one:
291
+
292
+
```
293
+
cursor/cve/<package>
294
+
```
295
+
296
+
Multiple CVEs against the same package commonly land in one upstream release, so package-keyed branches let sibling work join the same PR (see "Batching CVEs" below). Do not include the CVE ID or a Linear issue ID in the branch name.
297
+
298
+
### Batching CVEs that share a package
299
+
300
+
CVEs often arrive in clusters because one package release fixes several at once. Before opening a new PR, check whether a sibling PR is already addressing the same package.
301
+
302
+
1.**Extract**`<package>` and `<min-patched-version>` from the Linear issue (the Dependabot-sourced body lists both — affected package and fixed version).
303
+
304
+
2.**Look for a sibling PR**:
305
+
306
+
```bash
307
+
gh pr list --state open --search '<package> in:title' --json number,title,headRefName
308
+
```
309
+
310
+
3.**Decide based on the result**:
311
+
312
+
-**Sibling PR exists and its branch already pins ≥ `<min-patched-version>`**:
313
+
-`gh pr checkout <number>`
314
+
-**Edit** the existing CHANGELOG line for this PR — append this CVE ID to the comma-separated list. Do not add a new CHANGELOG line.
315
+
-`gh pr edit <number>` to append the CVE ID to the title and body, and add a `Fixes <LINEAR-ID>` line to the PR body alongside any existing `Fixes` lines (this auto-links the Linear issue and Linear will mark it Done when the PR merges).
316
+
- Do not transition the Linear issue manually — leave it for the merge to close.
317
+
-**Do not open a new PR.**
318
+
319
+
-**Sibling PR exists but its pin is too low to cover this CVE**:
320
+
- Check out the branch.
321
+
- Bump the resolution / package version higher to cover both.
322
+
-**Edit** the existing CHANGELOG line — append this CVE and update the version. Update the PR title and body, and add `Fixes <LINEAR-ID>` to the PR body.
323
+
- Do not transition the Linear issue manually — leave it for the merge to close.
324
+
325
+
-**No sibling PR exists**:
326
+
- Create a new `cursor/cve/<package>` branch and open the PR as usual.
327
+
328
+
4.**Post-flight (race-window backstop)**: After opening a new PR, re-run step 2. If a competing PR with a *lower* number appeared while you were working, close yours, push your CHANGELOG entry and Linear link onto the older PR.
329
+
274
330
### CHANGELOG and PR conventions for CVE fixes
275
331
276
-
- CHANGELOG entry (under `[Unreleased] → Fixed`): `Upgraded \`<pkg>\` to \`^x.y.z\` to address CVE-XXXX-XXXXX. [#<PR>]`
277
-
- Keep entries short. The CVE ID is enough.
332
+
- CHANGELOG entry (under `[Unreleased] → Fixed`): `Upgraded \`<pkg>\` to \`^x.y.z\` to address CVE-A, CVE-B, .... [#<PR>]`
333
+
-**One CHANGELOG line per PR**, not per CVE. When the PR addresses multiple CVEs (batched), list all of them comma-separated on a single line.
334
+
- PR title format: `chore: upgrade <pkg> to ^x.y.z to address CVE-A, CVE-B, ...` (list every CVE the PR resolves).
0 commit comments