Bump lodash from 4.17.23 to 4.18.1

[dependabot]

Bumps lodash from 4.17.23 to 4.18.1.

Release notes

Sourced from lodash's releases.

4.18.1

Bugs

Fixes a ReferenceError issue in lodash lodash-es lodash-amd and lodash.template when using the template and fromPairs functions from the modular builds. See lodash/lodash#6167

These defects were related to how lodash distributions are built from the main branch using https://github.com/lodash-archive/lodash-cli. When internal dependencies change inside lodash functions, equivalent updates need to be made to a mapping in the lodash-cli. (hey, it was ahead of its time once upon a time!). We know this, but we missed it in the last release. It's the kind of thing that passes in CI, but fails bc the build is not the same thing you tested.

There is no diff on main for this, but you can see the diffs for each of the npm packages on their respective branches:

• lodash: lodash/lodash@4.18.0-npm...4.18.1-npm
• lodash-es: lodash/lodash@4.18.0-es...4.18.1-es
• lodash-amd: lodash/lodash@4.18.0-amd...4.18.1-amd
• lodash.templatelodash/lodash@4.18.0-npm-packages...4.18.1-npm-packages

4.18.0

v4.18.0

Full Changelog: lodash/lodash@4.17.23...4.18.0

Security

_.unset / _.omit: Fixed prototype pollution via constructor/prototype path traversal (GHSA-f23m-r3pf-42rh, fe8d32e). Previously, array-wrapped path segments and primitive roots could bypass the existing guards, allowing deletion of properties from built-in prototypes. Now constructor and prototype are blocked unconditionally as non-terminal path keys, matching baseSet. Calls that previously returned true and deleted the property now return false and leave the target untouched.

_.template: Fixed code injection via imports keys (GHSA-r5fr-rjxr-66jc, CVE-2026-4800, 879aaa9). Fixes an incomplete patch for CVE-2021-23337. The variable option was validated against reForbiddenIdentifierChars but importsKeys was left unguarded, allowing code injection via the same Function() constructor sink. imports keys containing forbidden identifier characters now throw "Invalid imports option passed into _.template".

Docs

• Add security notice for _.template in threat model and API docs (#6099)
• Document lower > upper behavior in _.random (#6115)
• Fix quotes in _.compact jsdoc (#6090)

lodash.* modular packages

Diff

We have also regenerated and published a select number of the lodash.* modular packages.

These modular packages had fallen out of sync significantly from the minor/patch updates to lodash. Specifically, we have brought the following packages up to parity w/ the latest lodash release because they have had CVEs on them in the past:

• lodash.orderby
• lodash.tonumber
• lodash.trim
• lodash.trimend
• lodash.sortedindexby
• lodash.zipobjectdeep
• lodash.unset
• lodash.omit
• lodash.template

Commits

• cb0b9b9 release(patch): bump main to 4.18.1 (#6177)
• 75535f5 chore: prune stale advisory refs (#6170)
• 62e91bc docs: remove n_ Node.js < 6 REPL note from README (#6165)
• 59be2de release(minor): bump to 4.18.0 (#6161)
• af63457 fix: broken tests for _.template 879aaa9
• 1073a76 fix: linting issues
• 879aaa9 fix: validate imports keys in _.template
• fe8d32e fix: block prototype pollution in baseUnset via constructor/prototype traversal
• 18ba0a3 refactor(fromPairs): use baseAssignValue for consistent assignment (#6153)
• b819080 ci: add dist sync validation workflow (#6137)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[atlas-commons-bot]

Atlas Commons PR review

Requirement	Status
DCO sign-off	pass
Required checks	fail
Summary filled	fail
Checklist	pass
Linked issue	warn

Overall: fail

• All commits include DCO sign-off.
• Required checks failed.
• Summary section is empty or still has placeholder text.
• All checklist items ticked or none present.
• No linked issue (advisory).

View PR #14 · Atlas-Commons/StreamBooru

[atlas-commons-bot]

Atlas Commons code review (LLM)

Summary

Dependabot bumps the hoisted transitive lodash package in package-lock.json from 4.17.23 to 4.18.1. StreamBooru does not depend on lodash directly; the only consumer is @malept/flatpak-bundler (via electron-builder → app-builder-lib), which uses it at build time for Flatpak packaging. Application and server source code do not import lodash. The change is a single lockfile entry update (version, resolved URL, integrity hash); package.json is unchanged, which is correct for a transitive bump.

Potential issues

1. DCO sign-off may block merge. The repo’s CI requires every PR commit to include Signed-off-by: (see .github/scripts/verify-dco.sh and the dco job in .github/workflows/ci.github.yml). Dependabot commits typically lack DCO sign-off, which matches the reported “Required checks failed” status. This is a process blocker, not a functional regression in the diff itself.

2. Security benefit is mostly supply-chain hygiene, not runtime exposure. The 4.18.x fixes (prototype pollution in _.unset/_.omit, code injection in _.template) address serious CVEs, but @malept/flatpak-bundler only uses cloneDeepWith, kebabCase, defaults, and last — none of the patched APIs. lodash is also marked dev: true in the lockfile, so it is not shipped in the Electron app runtime. The bump still helps npm audit and dependency review, but it does not close a practical exploit path in normal app usage.

3. Other lodash packages in the lockfile are unchanged. archiver-utils (pulled in by electron-builder) still depends on standalone packages such as lodash.defaults, lodash.difference, and lodash.isplainobject. This PR does not update those entries. That is expected for a targeted Dependabot PR, but it means the lockfile still contains multiple lodash-related packages at older versions; only the hoisted full lodash tree is updated.

4. No build-path verification for the actual consumer. Smoke tests (test:server, test:tags) pass after npm ci with 4.18.1, but nothing in CI exercises the Flatpak packaging path that actually loads lodash. A regression there would only surface during npm run dist on Linux with Flatpak tooling installed.

Suggestions

• Resolve the DCO failure before merge — e.g. cherry-pick the lockfile change onto a maintainer branch with git commit -s, or configure Dependabot/branch rules so automated dependency PRs satisfy DCO (some projects use a “DCO bot” or exempt Dependabot; this repo currently does not).
• After merge, run npm ci && npm run test:server && npm run test:tags on the updated lockfile (verified locally; all tests pass with 4.18.1).
• If Flatpak releases are supported, run a one-time npm run pack or npm run dist on Linux to confirm @malept/flatpak-bundler still works with 4.18.1.
• Fill in the PR template Summary (even a one-liner noting “transitive dev dep via electron-builder Flatpak bundler; no app code changes”) so future reviewers have context without reading the lockfile diff.

Overall assessment

This is a low-risk, appropriate dependency update. The diff is minimal and scoped correctly to package-lock.json; semver range ^4.17.15 from @malept/flatpak-bundler accepts 4.18.1, and smoke tests pass. The main concerns are process (DCO / empty PR description) rather than correctness. I would support merging once DCO and required checks are green; no application code changes are needed.

---

Advisory review only — not a merge approval.

View PR #14 · Atlas-Commons/StreamBooru