Possible fix(deps): 2 vulnerable dependencies in composer.lock

[begininvoke]

This might be a false positive, but composer.lock around line 1038 looked worth a second pair of eyes.

The Guzzle HTTP client (versions < 7.15.2 / < 8.0.1) passes the request URI and Host header separately to the transport. The transport (cURL or StreamHandler) decodes percent‑encoded characters in the URI, potentially turning a malicious host like "127.0.0.%31" into "127.0.0.1". Meanwhile the Host header retains the original encoded value. This mismatch lets an attacker bypass the application’s host validation (e.g., IP‑literal checks) and perform Server‑Side Request Forgery (SSRF) to loopback or internal services. It also affects proxy routing (no_proxy) and redirect handling (Authorization/Cookie stripping), expanding the impact. Updating Guzzle to a patched version eliminates the divergence by normalizing the host consistently.

Something like this might fix it:

Upgrade guzzlehttp/guzzle to a fixed version (≥ 7.15.2 or ≥ 8.0.1) by updating your composer.json dependency and running composer update. For example:

    composer require guzzlehttp/guzzle:"^7.15.2" --update-with-dependencies

or, for the 8.x line:

    composer require guzzlehttp/guzzle:"^8.0.1" --update-with-dependencies

This will replace the vulnerable package in composer.lock with the patched version.

For reference: rule CVE-2026-69246. Rated high.

If I have misread how this is used, sorry for the noise — feel free to close.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.