[claudesecuritypatcher]

Closes #15
Closes #11

Bundles the in-range yarn.lock re-resolves for Wiz findings into one PR (supersedes #16 and #14). Wiz posture issues 5f20cf64-222b-4dd8-a6f4-0abe6700a3c0 (#15) and 29ccf336-36e1-4d5e-ba34-ce958b0c3f94 (#11).

Re-resolved packages

package	from → to	advisory	closes
lodash	4.17.21 → 4.18.1	CVE-2026-4800	Closes #15
lodash-es	4.17.21 → 4.18.1	CVE-2026-4800	Closes #15
json5	1.0.1 → 1.0.2, 2.2.1 → 2.2.3	CVE-2022-46175	Closes #15
braces	3.0.2 → 3.0.3	CVE-2024-4068	Closes #15
semver	5.7.1 → 5.7.2, 6.3.0 → 6.3.1, 7.3.8 → 7.8.5	CVE-2022-25883	Closes #15
brace-expansion	1.1.11 → 1.1.21	CVE-2026-14257, CVE-2026-69152	Closes #11
universal-github-app-jwt (→ jsonwebtoken 8.5.1 → 9.0.3, jws 3.2.2 → 4.0.1, jwa 1.4.1 → 2.0.1)	1.1.0 → 1.2.0	CVE-2022-23539/-23540/-23541, CVE-2025-65945	Closes #11

Why this matters

The worst of the lint-tree packages is lodash's _.template, which can run injected code if untrusted strings end up as options.imports key names. The others are a json5 prototype pollution and denial-of-service bugs in braces, semver and brace-expansion, where a crafted glob pattern can make expansion take very long. None of these ship in the action. yarn why traces each one to the xo lint toolchain (brace-expansion comes in via eslint-plugin-import → minimatch@3), and ncc bundles only @actions/* and @octokit/* into dist/index.js. They still run on CI runners and developer machines during yarn install / yarn run xo, and a lock refresh costs nothing, so they are fixed rather than deferred.

The JWT chain is runtime code. @octokit/auth-app signs the App JWT through universal-github-app-jwt → jsonwebtoken, and the old jsonwebtoken/jws had flaws in how they check keys and algorithms. The action only signs and never verifies an untrusted token, so the practical exposure was small, but this is the path that handles the private key. This row was #14, which is folded in here.

Risk of this change

Only yarn.lock changes; package.json is untouched. Every existing range (lodash@^4.17.21, json5@^1.0.1/^2.2.1, braces@^3.0.2, semver@^5.7.1/^6.0.0/^7.3.7, brace-expansion@^1.1.7, universal-github-app-jwt@^1.0.1) already allowed the fixed versions, so the lock was just stale. brace-expansion stays on the 1.1.x line that minimatch@3 calls as a CJS export. It is not moved to 2.x/5.x, which would break eslint. universal-github-app-jwt 1.2.0's only change is moving to jsonwebtoken@^9. jsonwebtoken 9's breaking changes are on the verify side (it rejects insecure key types and none by default). The action signs with RS256 and an RSA key, which v9 still accepts. A blanket yarn upgrade was avoided on purpose: it pulls in new runtime advisories via @actions/http-client. No override was added, so Dependabot keeps these current.

Verification

Ran the test.yml steps locally with Node 22 and yarn 1.22.22: yarn install --frozen-lockfile (exit 0), yarn-deduplicate --fail --strategy fewer (exit 0), yarn run build (ncc, exit 0), yarn run xo (exit 0, so this exercises minimatch@3 with the new brace-expansion). Resolved in the lock:

lodash 4.18.1 · lodash-es 4.18.1 · json5 1.0.2, 2.2.3 · braces 3.0.3 · semver 5.7.2, 6.3.1, 7.8.5
brace-expansion 1.1.21 · universal-github-app-jwt 1.2.0 · jsonwebtoken 9.0.3 · jws 4.0.1 · jwa 2.0.1

yarn audit --groups dependencies --level high reports no high-severity runtime advisory. 19 moderate advisories remain, for example @octokit/request*, @octokit/plugin-paginate-rest and uuid. Those need major bumps of @actions/github/@octokit/auth-app/@actions/core, are not part of either Wiz finding here, and are out of scope. I did not do a live token exchange against GitHub. CI: the Test check is red at its Prettier step, and the only file it flags is README.md. prettier --check README.md fails the same way on origin/main, so the failure was already on the base and this PR doesn't cause it.

🤖 Generated with Claude Code

[claudesecuritypatcher]

Security review: the lock refresh removes the vulnerable versions for every row of the table, including both brace-expansion CVEs from issue 11 — no security objection to merging. The red Test check is a pre-existing README formatting failure, not caused by this PR.

Verified (rung: lock-file read of yarn.lock on this branch, plus yarn audit through ./.wiz-resolve)

• Issue 11 (Wiz posture finding, read via read_finding): CVE-2026-14257 (fixed in 1.1.17) and CVE-2026-69152 (fixed in 1.1.18), both on brace-expansion. The lock now has a single copy, brace-expansion@^1.1.7 → 1.1.21, which is above both. It stays on the 1.1.x line, so it does not break minimatch@3.
• JWT chain: jsonwebtoken@^9.0.2 → 9.0.3, jws@^4.0.1 → 4.0.1, jwa@^2.0.1 → 2.0.1, and no 8.x copy remains in the lock. universal-github-app-jwt 1.2.0 requires ^9.0.2.
• Issue 15 rows: lodash and lodash-es 4.18.1, json5 1.0.2 and 2.2.3, braces 3.0.3, semver 5.7.2 / 6.3.1 / 7.8.5. Every copy of each is at or above its fix. package.json is untouched and there are no overrides, so this is an in-range re-resolve, the right kind of fix.
• TARGET-AUDIT: yarn audit --groups dependencies --level high reports 0 high or critical and 19 moderate advisories. The moderates are outside this PR's table (the PR body names @octokit/request* and uuid). One earlier note still stands: braces 3.0.3 is flagged by GHSA-vfj7-8cjw-p6xm, a different advisory from CVE-2024-4068, and 3.0.3 is the latest published braces, so no fix exists yet.

CI

• Test fails only at the Prettier step on README.md. I ran prettier --check README.md on this tree and it fails, and the PR does not touch README.md. The PR body says it fails the same way on origin/main; I did not run that on main, so that part rests on the body. All six Wiz scanners pass.
• The build and xo results in the PR body are the author's own claims, which I did not re-run.

Not checked: a live token exchange with the jsonwebtoken 9 signing path (the PR body also says it did not do one), and the Test run on main.

Automated non-fixing second opinion; a human decides.

[claudesecuritypatcher]

The red Test check is not caused by this PR. It fails at the Format step (yarn run prettier --check), and the only file Prettier flags is README.md. This PR leaves README.md alone: git diff --stat origin/main HEAD shows only yarn.lock, and the lock diff doesn't touch the prettier entry, so CI used the same Prettier version as main. I ran prettier --check README.md locally on origin/main (f61e816, "Update README.md") and it fails the same way ([warn] README.md, exit 1). main has no test.yml runs to compare against, because the workflow only runs on PRs. Fixing it would mean reformatting README.md, which is outside this security change, so I left it alone. All Wiz scanners on this PR pass.

[claudesecuritypatcher]

Its own checks are failing

Test fails, so this PR cannot be merged as it stands. If the base has moved on since it was opened it may be obsolete; closing it with a one-line reason is a valid answer, and the finding returns to the automation against the current base.

Automated check on each sweep; this comment is rewritten in place. The security review, if any, is a separate comment.

[claudesecuritypatcher]

Checked the base directly this time: on a clean worktree of origin/main (f61e816), yarn install --frozen-lockfile followed by the exact CI command prettier --ignore-path .gitignore "./**/*.{cjs,js,json,md,ts,yml}" --check exits 1 with [warn] README.md as the only file flagged. That matches the Format step failure in run 39223037269. README.md is byte-identical between main and this branch, which only changes yarn.lock. So the red Test check was already failing on the base (it dates from the README edit in f61e816), not caused by this PR. I have left the build alone; running prettier --write README.md on main fixes it. All six Wiz scanners on this PR pass.