chore(deps): bump ip-address from 10.5.0 to 10.7.2

[tobyhede]

Summary

Updates ip-address from 10.5.0 to 10.7.2 in the lockfile, and changes nothing else. This replaces Dependabot's #990, which bumped the same package but also moved about 15 unrelated packages to new versions, some of them published only hours earlier.

The repo has a 7-day install cooldown (minimumReleaseAge: 10080 in pnpm-workspace.yaml): pnpm refuses package versions younger than a week, so a malicious release is usually caught and pulled before we install it. pnpm only enforces that rule when it picks versions. CI installs with --frozen-lockfile, which installs whatever the lockfile says without picking anything, so versions written into the lockfile by Dependabot never meet the check.

Changes

• pnpm-lock.yaml: ip-address 10.5.0 → 10.7.2 (package entry, integrity hash, and the one reference from express-rate-limit). Four lines.

Verification

• pnpm install --frozen-lockfile --lockfile-only passes against the edited lockfile.
• express-rate-limit@8.6.2 (already locked) declares ip-address: ^10.2.0, so 10.7.2 satisfies it and it does not need to move. ip-address@10.7.2 has no dependencies and the same engines as 10.5.0.
• ip-address@10.7.2 was published 2026-09-15, past the 7-day cooldown.
• The lockfile was edited by hand. pnpm update -r ip-address --lockfile-only was tried first and re-resolved hono, rollup, esbuild, postcss, jose, nanoid, picomatch and others as well, so it would have recreated the problem.

Related

• Supersedes chore(deps): bump ip-address from 10.5.0 to 10.7.2 #990.

Review notes

No changeset: the lockfile is not shipped in any published package.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3daa01f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-30T23:30:52.016988Z	3daa01f	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[freshtonic]

Approved. The diff is four lines in pnpm-lock.yaml, and it agrees with the description:

• ip-address occurs in three places in the lockfile at this head: the package entry (line 2519), the express-rate-limit snapshot (line 4951), and its own snapshot (line 5179). All three now say 10.7.2. No 10.5.0 reference remains.
• The integrity hash is the one value here that a reader cannot check by eye. The CI test jobs passed, and they install with --frozen-lockfile. A wrong hash would make that install fail, so CI has checked it.
• 10.7.2 is in the ^10.2.0 range that express-rate-limit declares, so the parent stays where it is.
• No changeset is correct. The lockfile is not in a published tarball, and the stash-supply-chain-security skill has no rule that this change affects.

I agree with the reason for the hand edit. A --frozen-lockfile install does not apply minimumReleaseAge, so a lockfile that Dependabot writes can bring in versions younger than the 7-day cooldown. Keeping this bump to one package is the correct approach. A general fix, such as a CI check that compares new lockfile versions against the cooldown, can go in a separate issue if you want one.