fix(deps): resolve all Dependabot security alerts

[kherembourg]

Summary

• Fix all 18 open Dependabot security alerts by updating resolutions (yarn) and overrides (npm) across root and test-projects
• undici 7.12.0 → 7.24.4: CRLF injection, memory consumption DoS, request smuggling, WebSocket overflow
• tar 7.5.9 → 7.5.11: symlink/hardlink path traversal
• fast-xml-parser 4.5.3 → 5.5.6: stack overflow, entity expansion DoS, regex injection bypass
• minimatch 3.1.2 → 10.2.4: ReDoS via GLOBSTAR segments and extglobs
• flatted 3.3.3 → 3.4.1: unbounded recursion DoS in parse()

Test plan

• yarn test — 139 tests pass
• npm audit on expo-purchasely-test — 0 vulnerabilities
• npm audit on rn-purchasely-test — 0 vulnerabilities
• Verify CI passes (lint, typecheck, build)

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR resolves 18 open Dependabot security alerts by adding Yarn resolutions (root package.json) and npm overrides (both test projects) for five vulnerable transitive packages: undici, tar, fast-xml-parser, minimatch, and flatted. All lock files have been regenerated and correctly reflect the patched resolved versions.

Key observations:

• The undici override in test-projects/expo-purchasely-test/package.json is set to >=6.24.0 while the root Yarn resolution uses >=7.24.0. The constraint currently resolves to 7.24.4 (correct), but the lower bound is inconsistent and weaker than intended. Additionally, undici@7.24.4 raises the Node.js engine floor to >=20.18.1 (from >=18.17), which could silently break Node 18/19 CI environments.
• fast-xml-parser: ">=4.5.4" and minimatch: ">=3.1.3" resolve to major-version jumps (v5.5.6 and v10.2.4 respectively). The open-ended lower bounds mean a future install could advance to yet another incompatible major version with no visible code change.
• rn-purchasely-test correctly omits undici and tar overrides since neither package appears in that project's dependency tree.
• The fast-xml-parser override in expo-purchasely-test is technically unnecessary (the package does not appear in that project's lock file), but it is harmless.

Confidence Score: 3/5

• Safe to merge for immediate security remediation, but the undici constraint inconsistency and loose semver ranges leave room for future regressions.
• All five targeted CVEs are patched and confirmed by the lock files. The undici constraint inconsistency (>=6.24.0 vs >=7.24.0) does not cause a current security issue (resolves to 7.24.4 today), but it represents a drift from the root configuration and masks a Node.js engine version bump. The open-ended major-version ranges for fast-xml-parser and minimatch work today but could cause silent breakage on a future npm install.
• Pay close attention to test-projects/expo-purchasely-test/package.json (undici constraint) and package.json / both test-project package.json files (semver lower-bound ranges for fast-xml-parser and minimatch).

Important Files Changed

Filename	Overview
package.json	Adds Yarn resolutions for flatted, minimatch, fast-xml-parser, undici, and updates tar; the semver ranges are intentionally broad (e.g. >=3.1.3 resolves to 10.2.4) to force patched versions across the workspace.
test-projects/expo-purchasely-test/package.json	Adds npm overrides for security packages, but undici is pinned to >=6.24.0 (resolves to 7.24.4 today) while the root uses >=7.24.0; this inconsistency is a future risk and the Node.js engine requirement has silently jumped to >=20.18.1.
test-projects/rn-purchasely-test/package.json	Adds npm overrides for fast-xml-parser, flatted, and minimatch; undici and tar correctly omitted because neither package is present in this project's dependency tree.
yarn.lock	Lock file correctly reflects all security bumps: undici 7.12.0→7.24.4, tar 7.5.9→7.5.11, fast-xml-parser 4.5.3→5.5.6, minimatch 3.1.2→10.2.4, flatted 3.3.3→3.4.1; old minimatch v3/v5/v8/v9 entries are removed in favour of the single >=3.1.3 resolution.
test-projects/expo-purchasely-test/package-lock.json	Lock file confirms all overrides took effect; undici resolved to 7.24.4 despite the >=6.24.0 constraint, and tar resolved to 7.5.11.
test-projects/rn-purchasely-test/package-lock.json	Lock file confirms fast-xml-parser was bumped from 4.5.3 to 5.5.6 (major jump) via the override; minimatch and flatted overrides also applied correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Dependabot Security Alerts] --> B{Package Manager}
    B -->|Yarn workspace root| C[package.json resolutions]
    B -->|npm expo project| D[expo-purchasely-test/package.json overrides]
    B -->|npm RN project| E[rn-purchasely-test/package.json overrides]

    C --> C1[undici >=7.24.0 → 7.24.4]
    C --> C2[tar >=7.5.10 → 7.5.11]
    C --> C3[fast-xml-parser >=4.5.4 → 5.5.6]
    C --> C4[minimatch >=3.1.3 → 10.2.4]
    C --> C5[flatted >=3.3.4 → 3.4.1]

    D --> D1[undici >=6.24.0 → 7.24.4 ⚠️ inconsistent lower bound]
    D --> D2[tar >=7.5.10 → 7.5.11]
    D --> D3[fast-xml-parser >=4.5.4 → 5.5.6]
    D --> D4[minimatch >=3.1.3 → 10.2.4]
    D --> D5[flatted >=3.3.4 → 3.4.1]

    E --> E1[fast-xml-parser >=4.5.4 → 5.5.6]
    E --> E2[minimatch >=3.1.3 → 10.2.4]
    E --> E3[flatted >=3.3.4 → 3.4.1]
    E --> E4[lodash >=4.17.23 pre-existing]
    E -.->|undici not in dep tree| X[⚪ no override needed]
    E -.->|tar not in dep tree| X

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: test-projects/expo-purchasely-test/package.json
Line: 32

Comment:
**Undici version constraint is inconsistent with root and allows v6 resolution**

The constraint `>=6.24.0` technically satisfies any version at or above 6.24.0, including 7.x (and that is what resolves today — 7.24.4). However:

1. It is weaker than the root's `>=7.24.0` resolution. If npm ever adds a new 6.x candidate to its registry before the resolver cache is refreshed, a future `npm install` could theoretically settle on a 6.x release that still contains the patched vulnerabilities only partially.
2. The undici changelog introduces a new engine floor with v7: the resolved `undici@7.24.4` requires **Node.js `>=20.18.1`**, up from the previous `>=18.17`. Any CI or developer environment running Node 18/19 will now fail when installing this project, with no mention of the engine bump in the PR.

Consider aligning with the root constraint:

```suggestion
    "undici": ">=7.24.0"
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: package.json
Line: 35-36

Comment:
**Semver lower bounds allow resolution to arbitrary future major versions**

Both of these constraints resolve today to major-version jumps far beyond what the lower bound implies:

- `"fast-xml-parser": ">=4.5.4"` → resolves to **5.5.6** (v4 → v5 major bump; transitive deps in `rn-purchasely-test` declare `^4.4.1` which is semver-incompatible with v5).
- `"minimatch": ">=3.1.3"` → resolves to **10.2.4** (v3 → v10, a seven-major-version jump).

While the tests pass today, these open-ended ranges mean a future `yarn install` could silently advance to v6 of `fast-xml-parser` or v11+ of `minimatch`, potentially introducing runtime breakage with no diff-visible change. The same pattern exists in both test-project `package.json` files.

Consider pinning to the actual minimum compatible major version that was validated:

```suggestion
    "minimatch": ">=10.2.4",
    "fast-xml-parser": ">=5.0.0",
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 14cd145}

[greptile-apps]

Undici version constraint is inconsistent with root and allows v6 resolution

The constraint >=6.24.0 technically satisfies any version at or above 6.24.0, including 7.x (and that is what resolves today — 7.24.4). However:

1. It is weaker than the root's >=7.24.0 resolution. If npm ever adds a new 6.x candidate to its registry before the resolver cache is refreshed, a future npm install could theoretically settle on a 6.x release that still contains the patched vulnerabilities only partially.
2. The undici changelog introduces a new engine floor with v7: the resolved undici@7.24.4 requires Node.js >=20.18.1, up from the previous >=18.17. Any CI or developer environment running Node 18/19 will now fail when installing this project, with no mention of the engine bump in the PR.

Consider aligning with the root constraint:

Suggested change

	"undici": ">=6.24.0"
	"undici": ">=7.24.0"

Prompt To Fix With AI

This is a comment left during a code review.
Path: test-projects/expo-purchasely-test/package.json
Line: 32

Comment:
**Undici version constraint is inconsistent with root and allows v6 resolution**

The constraint `>=6.24.0` technically satisfies any version at or above 6.24.0, including 7.x (and that is what resolves today — 7.24.4). However:

1. It is weaker than the root's `>=7.24.0` resolution. If npm ever adds a new 6.x candidate to its registry before the resolver cache is refreshed, a future `npm install` could theoretically settle on a 6.x release that still contains the patched vulnerabilities only partially.
2. The undici changelog introduces a new engine floor with v7: the resolved `undici@7.24.4` requires **Node.js `>=20.18.1`**, up from the previous `>=18.17`. Any CI or developer environment running Node 18/19 will now fail when installing this project, with no mention of the engine bump in the PR.

Consider aligning with the root constraint:

```suggestion
    "undici": ">=7.24.0"
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Semver lower bounds allow resolution to arbitrary future major versions

Both of these constraints resolve today to major-version jumps far beyond what the lower bound implies:

• "fast-xml-parser": ">=4.5.4" → resolves to 5.5.6 (v4 → v5 major bump; transitive deps in rn-purchasely-test declare ^4.4.1 which is semver-incompatible with v5).
• "minimatch": ">=3.1.3" → resolves to 10.2.4 (v3 → v10, a seven-major-version jump).

While the tests pass today, these open-ended ranges mean a future yarn install could silently advance to v6 of fast-xml-parser or v11+ of minimatch, potentially introducing runtime breakage with no diff-visible change. The same pattern exists in both test-project package.json files.

Consider pinning to the actual minimum compatible major version that was validated:

Suggested change

	"minimatch": ">=3.1.3",
	"fast-xml-parser": ">=4.5.4",
	"minimatch": ">=10.2.4",
	"fast-xml-parser": ">=5.0.0",

Prompt To Fix With AI

This is a comment left during a code review.
Path: package.json
Line: 35-36

Comment:
**Semver lower bounds allow resolution to arbitrary future major versions**

Both of these constraints resolve today to major-version jumps far beyond what the lower bound implies:

- `"fast-xml-parser": ">=4.5.4"` → resolves to **5.5.6** (v4 → v5 major bump; transitive deps in `rn-purchasely-test` declare `^4.4.1` which is semver-incompatible with v5).
- `"minimatch": ">=3.1.3"` → resolves to **10.2.4** (v3 → v10, a seven-major-version jump).

While the tests pass today, these open-ended ranges mean a future `yarn install` could silently advance to v6 of `fast-xml-parser` or v11+ of `minimatch`, potentially introducing runtime breakage with no diff-visible change. The same pattern exists in both test-project `package.json` files.

Consider pinning to the actual minimum compatible major version that was validated:

```suggestion
    "minimatch": ">=10.2.4",
    "fast-xml-parser": ">=5.0.0",
```

How can I resolve this? If you propose a fix, please make it concise.