Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Users of the OAuth2 utilities in Saloon, specifically the AccessTokenAuthenticator class. Patches Upgrade to Saloon v4+ Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4 Description The Saloon PHP library used PHP's unserialize() in AccessTokenAuthenticator::unserialize() to restore OAuth token state from cache or storage, with allowedclasses = true. An attacker who can control the serialized string (e.g. by overwriting a cached token file or via another injection) can supply a serialized "gadget" object. When unserialize() runs, PHP instantiates that object and runs its magic methods (wakeup, destruct, etc.), leading to object injection. In environments with common dependencies (e.g. Monolog), this can be chained to remote code execution (RCE). The fix removes PHP serialization from the AccessTokenAuthenticator class requiring users to store and resolve the authenticator manually. Credits Saloon thanks @HuajiHD for finding the issue and recommending…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with MockResponse fixtures that use path traversal. Patches Upgrade to Saloon v4+ Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4 Description Fixture names were used to build file paths under the configured fixture directory without validation. A name containing path segments (e.g. ../traversal or ../../etc/passwd) resulted in a path outside that directory. When the application read a fixture (e.g. for mocking) or wrote one (e.g. when recording responses), it could read or write files anywhere the process had access. If the fixture name was derived from user or attacker-controlled input (e.g. request parameters or config), this constituted a path traversal vulnerability and could lead to disclosure of sensitive files or overwriting of critical files. The fix adds validation in the fixture layer (rejecting names with /, \, .., or null bytes, and restricting to a safe character set) and defence-in-depth in the storage layer (ensuring the resolved…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users providing user generated input into the resolveEndpoint method on requests. Patches Upgrade to Saloon v4+ Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4 Description When building the request URL, Saloon combined the connector's base URL with the request endpoint. If the endpoint was a valid absolute URL (e.g. https://attacker.example.com/callback), the code used that URL as-is and ignored the base URL. The request—and any authentication headers, cookies, or tokens attached by the connector—was then sent to the attacker-controlled host. If the endpoint could be influenced by user input or configuration (e.g. redirecturi, callback URL), this allowed server-side request forgery (SSRF) and/or credential leakage to a third-party host. The fix (in the next major version) is to reject absolute URLs in the endpoint: URLHelper::join() throws InvalidArgumentException when the endpoint is a valid absolute URL, unless explicitly allowed, requiring callers to…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.