fix(FFESUPPORT-734): address open security vulnerabilities

[aarsilv]

Summary

Closes FFESUPPORT-734.

Clears the 2 open security advisories that composer audit reports against main, plus picks up other available minor/patch transitive bumps in the process.

Vulnerabilities resolved

Severity	Package	Where	Advisory	Fix
HIGH	google/protobuf	composer.lock (dev)	GHSA-p2gh-cfq4-4wjc / CVE-2026-6409 — Protobuf DoS via negative varints / deep recursion	v4.33.5 → v4.33.6
(Symfony CVE; not yet in Dependabot)	symfony/cache	composer.lock (prod)	CVE-2026-45073 — SQL Injection in PdoAdapter::doClear() via unsanitized $prefix	v7.3.5 → v6.4.40 (patched 6.4 line)

Files changed

• composer.lock — re-resolved via composer update --with-all-dependencies. Many transitive minor/patch bumps; key cleared advisories above.
• composer.json — added config.platform.php = 8.1.0. Composer's solver was previously implicitly targeting whatever PHP the person running composer update happened to have installed; pinning the platform to the project's declared minimum ("php": "^8.1") makes lockfile resolution deterministic across developer environments and prevents CI breakage when transitive deps that require PHP 8.4+ (e.g. symfony/var-exporter v8, doctrine/instantiator 2.1) sneak in from a newer local dev PHP.

Verification

• composer audit — "No security vulnerability advisories found."
• composer validate --strict — clean.
• make test — 98 tests, 664 assertions, all pass (matches main baseline).
• CI Run Tests workflow — passing.

Note

This PR was generated with Claude Code.

[Copilot]

Pull request overview

Updates Composer-resolved dependencies to eliminate reported security advisories while keeping the project’s dependency resolution consistent across developer environments by pinning the Composer platform PHP version to the repo’s declared minimum.

Changes:

• Re-resolves composer.lock to clear composer audit security advisories and pick up available transitive updates within existing constraints.
• Pins Composer’s solver platform to PHP 8.1.0 via composer.json (and corresponding lockfile metadata) to prevent lockfile drift based on local PHP versions.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
composer.json	Adds config.platform.php = 8.1.0 so dependency resolution targets the minimum supported PHP version consistently.
composer.lock	Updates the locked dependency graph (including symfony/cache and google/protobuf) and records the PHP platform override used for resolution.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aarsilv]

🤖 Response from AI: Good catch — PR description was stale relative to the follow-up commit. Updated to call out the composer.json change explicitly, including the reasoning (pinning the solver platform to the declared ^8.1 floor so lockfile resolution is deterministic across developer PHP versions; without it, my local 8.5 had pulled in symfony/var-exporter v8 / doctrine/instantiator 2.1 which need PHP 8.4+ and broke CI on its 8.3 image).

[aarsilv]

🤖 Context from Claude: A few non-obvious things worth flagging for reviewers:

1. The symfony/cache line looks like a downgrade. It goes from v7.3.5 to v6.4.40. That's because the config.platform.php = 8.1.0 pin (see point 3) constrains the solver to a graph compatible with PHP 8.1, and the chain through php-http/discovery / webclient/ext-redirect makes the 6.4 line easier to satisfy on PHP 8.1 than the 7.4 line. 6.4.40 is the patched 6.4 branch per the Symfony advisory (affected ranges include >=6.4.0,<6.4.40), so it does fully clear CVE-2026-45073. composer audit confirms 0 advisories on the resolved graph.

2. One of the two CVEs isn't in GitHub Dependabot yet. google/protobuf (GHSA-p2gh-cfq4-4wjc) is the only thing GitHub's Dependabot page shows. The Symfony cache SQL injection (CVE-2026-45073, reported 2026-05-20) hasn't been propagated to GitHub's advisory database yet, but it's flagged by Composer's audit / the Symfony security team. Fixing it now rather than waiting for GitHub to syndicate the advisory.

3. Why the composer.json change is needed. The first attempt at this PR landed CI-red on PHP 8.3: my local PHP is 8.5, so without the platform pin Composer happily resolved symfony/var-exporter v8.0.9 and doctrine/instantiator 2.1.0 (both require PHP 8.4+) into the lockfile, which then refused to composer install on CI's 8.3 image. Adding config.platform.php = 8.1.0 makes the solver target the project's declared ^8.1 floor regardless of who runs composer update, so the lockfile is now deterministic and consistent with composer.json. Pre-existing best practice for libraries; just hadn't been set here yet.

4. Scope is intentionally lockfile + one config line. I did not bump any direct-dependency constraint in composer.json (e.g. didn't widen symfony/cache to allow ^8.0, didn't jump phpunit to v10/11/12/13). Going to symfony/cache ^8.0 would require lifting the php constraint above 8.1 (Symfony 8 wants PHP 8.4+) which would break downstream SDK users on 8.1–8.3. Phpunit major bumps would require migrating annotation-based tests to attributes. Both worth doing as separate tickets if/when desired — kept this PR to the security cleanup.

[typotter]

Is this breaking - did we support php < 8.1.0 prior to this?

[typotter]

lgtm - just curious about blast radius of forcing php version