|
|
- **Bumped `js-yaml` to 5.4.2 for a merge-key denial-of-service advisory** — In versions up to 5.4.0, the `maxTotalMergeKeys` limit does not count empty mappings. A small YAML document that merges a long list of `{}` many times (`<<: *arr`) can keep the CPU busy for seconds per few hundred kilobytes without ever reaching the limit. It only applies when merge keys are enabled, which means the YAML 1.1 schema. The fix counts each merged mapping towards the budget. **No running Bambuddy install was exposed, and the issue was not reachable at build time either.** `js-yaml` is a development-only transitive dependency, pulled in by `eslint` through `@eslint/eslintrc`, and it is not in the shipped image. `@eslint/eslintrc` only parses legacy `.eslintrc.yaml`/`.eslintrc.yml` files, and this repository has none. Linting uses the flat `frontend/eslint.config.js`, so no YAML is loaded at all. The existing `overrides` pin in `frontend/package.json` moves from `^5.2.3` to `^5.4.1`, so a regenerated lockfile cannot resolve back below the fix. The lockfile changes in one entry only, with nothing added or removed, and the shipped bundle does not change. Verified with eslint, typecheck, the production build, and the full frontend suite (4022 tests across 297 files). `npm audit` reports no `js-yaml` findings.
|
|
|
- **Bumped `brace-expansion` to 5.0.12 for three denial-of-service advisories** — Two high-severity issues, fixed in 5.0.10 and 5.0.11, let deeply nested brace groups exhaust the native stack. Roughly 3,100 levels of `{{{...a,b...}}}`, about 6 KB of input, crashed the process: once through the recursive comma splitter and once through the expander itself. The medium-severity third, fixed in 5.0.12, is the bash `{a},b}` quirk. The parser handles it by rewriting the string and rescanning once per trailing `}`, so the cost grows quadratically, and 128 KB of input blocked the event loop for 27 seconds. 5.0.12 makes the comma splitter iterative and caps nesting depth and rewrite passes at 1,000 each. Input past either cap is kept as plain text rather than throwing, the same way the existing `max` and `maxLength` limits work. **No running Bambuddy install was exposed, and none of the issues was reachable at build time either.** `brace-expansion` is a development-only transitive dependency, pulled in by `eslint` through `minimatch`, and it is not in the shipped image. The only patterns it ever expands are the fixed globs in `frontend/eslint.config.js`. Before the bump, the output of 5.0.9 and 5.0.12 was compared on every glob in that file plus ranges, nested sets, escaped braces and the `{a},b}` quirk, and it was identical. The same comparison confirmed the fixes: 5,000 levels of nesting overflow the stack on 5.0.9 and expand cleanly on 5.0.12, and a 20,000-brace rewrite input drops from 3 seconds to 13 ms. The existing `overrides` pin in `frontend/package.json` moves from `^5.0.9` to `^5.0.12`, because `minimatch` still asks for only `^5.0.2`. The lockfile changes in one entry only, `balanced-match` is untouched, nothing is added or removed, and the shipped bundle does not change. Verified with eslint, typecheck, the production build and the full frontend suite (4022 tests across 297 files). `npm audit` reports zero vulnerabilities with and without dev dependencies.
|
|
|
- **Bumped `dompurify` to 3.4.17, `zod` to 4.6.7 and Vitest to 4.1.12 for npm audit advisories** — DOMPurify 3.4.17 fixes three bypasses: `SAFE_FOR_TEMPLATES` with shadow roots, `IN_PLACE` with hooks that remove nodes, and the SMIL `attributeName` guard in XHTML mode. Bambuddy sanitizes project notes, project pages and MakerWorld descriptions with a plain `sanitize()` call and none of those options or hooks, so it was not exposed; the bump keeps the one runtime dependency of the three clean, and its floor in `frontend/package.json` moves to `^3.4.17`. zod 4.6.6 checks array, set and map size limits before parsing their elements, so an oversized collection can no longer exhaust memory; it is a development-only dependency, pulled in by `eslint-plugin-react-hooks` and `knip`, and is not in the shipped image. Vitest 4.1.12 hardens `@vitest/mocker`'s manual and redirect mocks; the test suite uses neither `__mocks__` folders nor redirect mocks, and the mocker runs only during tests. Vitest and `@vitest/coverage-v8` pin each other exactly, so `npm audit fix` alone left them on 4.1.11; both floors move to `^4.1.12`, and Vitest's own `chai`, `std-env` and `tinyrainbow` move with it. Verified with eslint, knip, typecheck, the production build and its Safari 16 baseline check, i18n parity and the full frontend suite (5207 tests across 394 files). `npm audit` reports zero vulnerabilities.
|
|
|
+- **Bumped the development tools' `virtualenv` to 21.14.9, `filelock` to 4.2.1 and `setuptools` to 84.1.0 for pip-audit advisories** — All three are development-only and none is in the shipped image or `requirements.lock`: `virtualenv` and `filelock` arrive through `pre-commit`, `setuptools` through `bandit[sarif]` and `pbr`. `requirements-dev.txt` now sets them as minimums, the way it already does for `msgpack`, so a development install audits clean. `filelock` 4 is a new major version; its breaking change is the on-disk format of `SoftReadWriteLock`, which `virtualenv` does not use, and `virtualenv` 21.14.9 accepts it. Verified with the pre-commit hooks, a bandit SARIF run, ruff, typecheck and the full backend suite. `pip-audit` reports zero vulnerabilities.
|
maziggy