chore(package): update cspell to version 10.0.0

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ cspell (9.6.0 → 10.0.0) · Repo · Changelog

Release Notes

10.0.0

More info than we can show here.

9.8.0

More info than we can show here.

9.7.0

More info than we can show here.

9.6.4

More info than we can show here.

9.6.3

More info than we can show here.

9.6.2

More info than we can show here.

9.6.1

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ commander (indirect, 14.0.2 → 14.0.3) · Repo · Changelog

Release Notes

14.0.3

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ comment-json (indirect, 4.5.1 → 4.6.2) · Repo · Changelog

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ env-paths (indirect, 3.0.0 → 4.0.0) · Repo

Release Notes

4.0.0

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ flatted (indirect, 3.3.3 → 3.4.2) · Repo

Security Advisories 🚨

🚨 Prototype Pollution via parse() in NodeJS flatted

---

Summary

The parse() function in flatted can use attacker-controlled string values from the parsed JSON as direct array index
keys, without validating that they are numeric. Since the internal input buffer is a JavaScript Array, accessing it
with the key "__proto__" returns Array.prototype via the inherited getter. This object is then treated as a legitimate
parsed value and assigned as a property of the output object, effectively leaking a live reference to Array.prototype
to the consumer. Any code that subsequently writes to that property will pollute the global prototype.

---

Root Cause

File: esm/index.js:29 (identical in cjs/index.js)

  const resolver = (input, lazy, parsed, $) => output => {
    for (let ke = keys(output), {length} = ke, y = 0; y < length; y++) {
      const k = ke[y];
      const value = output[k];    
      if (value instanceof Primitive) {
        const tmp = input[value];      // Bug is here

No validation that value is a safe numeric index input is built as a plain Array. JavaScript's property lookup on arrays traverses the prototype chain for non-numeric keys. The key "__proto__" resolves to Array.prototype, which:

• has type "object" → passes the typeof tmp === object guard at line 30
• is not in the parsed Set yet → passes the !parsed.has(tmp) guard.
• The reference to Array.prototype is then enqueued in lazy and later unconditionally assigned to the output object.

---

Replication Steps

  const Flatted = require('flatted'); 
  const parsed = Flatted.parse('[{"x":"__proto__"}]');
  parsed.x.polluted = 'pwned';
  console.log([].polluted);  // Returns true

---

Impact
An attacker can supply a crafted flatted string to parse() that causes the returned object to hold a live reference to Array.prototype, enabling any downstream code that writes to that property to pollute the global prototype chain, potentially causing denial of service or code execution.

Recommended solution
Validate that the index string represents an integer within the bounds of input before accessing it:

// Before (vulnerable)
const tmp = input[value];

// After (safe)
const idx = +value; // coerce boxed String → number
const tmp = (Number.isInteger(idx) && idx >= 0 && idx < input.length)
? input[idx]
: undefined;

🚨 flatted vulnerable to unbounded recursion DoS in parse() revive phase

Summary

flatted's parse() function uses a recursive revive() phase to resolve circular references in deserialized JSON. When given a crafted payload with deeply nested or self-referential $ indices, the recursion depth is unbounded, causing a stack overflow that crashes the Node.js process.

Impact

Denial of Service (DoS). Any application that passes untrusted input to flatted.parse() can be crashed by an unauthenticated attacker with a single request.

flatted has ~87M weekly npm downloads and is used as the circular-JSON serialization layer in many caching and logging libraries.

Proof of Concept

const flatted = require('flatted');
// Build deeply nested circular reference chain

const depth = 20000;

const arr = new Array(depth + 1);

arr[0] = '{"a":"1"}';

for (let i = 1; i <= depth; i++) {

arr[i] = {"a":"<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span> <span class="pl-c1">+</span> <span class="pl-c1">1</span><span class="pl-kos">}</span></span>"};

}

arr[depth] = '{"a":"leaf"}';
const payload = JSON.stringify(arr);

flatted.parse(payload); // RangeError: Maximum call stack size exceeded

Fix

The maintainer has already merged an iterative (non-recursive) implementation in PR #88, converting the recursive revive() to a stack-based loop.

Affected Versions

All versions prior to the PR #88 fix.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ smol-toml (indirect, 1.6.0 → 1.6.1) · Repo

Security Advisories 🚨

🚨 smol-toml: Denial of Service via TOML documents containing thousands of consecutive commented lines

Summary

An attacker can send a maliciously crafted TOML to cause the parser to crash, because of a stack overflow caused by thousands of consecutive commented lines.

The library uses recursion internally while parsing to skip over commented lines, which can be exploited to crash an application that is processing arbitrary TOML documents.

Proof of concept

require("smol-toml").parse('# comment\n'.repeat(8000) + 'key = "value"')

Impact

Applications which parse arbitrary TOML documents may suffer availability issues if they receive malicious input. If uncaught, the crash may cause the application itself to crash. The impact is deemed minor, as the function is already likely to throw errors on invalid input. Downstream users are supposed to properly handle errors in such situations.

Due to the design of most JavaScript runtimes, the uncontrolled recursion does not lead to excessive memory usage and the execution is quickly aborted.

As a reminder, it is strongly advised when working with untrusted user input to expect errors to occur and to appropriately catch them.

Patches

Version 1.6.1 uses a different approach for parsing comments, which no longer involves recursion.

Workarounds

Wrap all invocations of parse and stringify in a try/catch block when dealing with untrusted user input.

Release Notes

1.6.1

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ yaml (indirect, 2.8.2 → 2.8.3) · Repo

Security Advisories 🚨

🚨 yaml is vulnerable to Stack Overflow via deeply nested YAML collections

Parsing a YAML document with yaml may throw a RangeError due to a stack overflow.

The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a RangeError: Maximum call stack size exceeded with a small payload (~2–10 KB). The RangeError is not a YAMLParseError, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process.

Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one [ and one ]). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).

Note: the library's Parser (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.

All three public parsing APIs are affected: YAML.parse(), YAML.parseDocument(), and YAML.parseAllDocuments().

PoC

const YAML = require('yaml');
// ~10 KB payload: 5000 levels of nested flow sequences

const payload = '['.repeat(5000) + '1' + ']'.repeat(5000);
try {

YAML.parse(payload);

} catch (e) {

console.log(e.constructor.name); // RangeError (NOT YAMLParseError)

console.log(e.message);          // Maximum call stack size exceeded

}

Test environment: Node.js v24.12.0, macOS darwin arm64

Version	Nesting Depth	Input Size	Result
1.0.0	5,000	10,001 B	RangeError
1.10.2	5,000	10,001 B	RangeError
2.0.0	5,000	10,001 B	RangeError
2.8.2	5,000	10,001 B	RangeError
2.8.3	5,000	10,001 B	YAMLParseError

Depth threshold on yaml 2.8.2:

Nesting Depth	Input Size	Result
500	1,001 B	Parses successfully
1,000	2,001 B	RangeError (threshold varies by stack size)
5,000	10,001 B	RangeError

Release Notes

2.8.3

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

🆕 @​cspell/cspell-performance-monitor (added, 10.0.0)

🆕 @​cspell/cspell-worker (added, 10.0.0)

🆕 @​cspell/rpc (added, 10.0.0)

🆕 is-safe-filename (added, 0.1.1)

🆕 picomatch (added, 4.0.4)

🆕 global-directory (added, 5.0.0)

🆕 import-fresh (added, 4.0.0)

🆕 semver (added, 7.7.4)

🗑️ clear-module (removed)

🗑️ parent-module (removed)

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)