Saloon patches unsafe unserialize enabling PHP object injection

TL;DR — Saloon’s OAuth2 token authenticator used unsafe unserialize() with permissive class loading, enabling PHP object injection and potential RCE if an attacker can influence cached token state.

What happened

Saloon is a PHP library that provides tooling for building API integrations and SDKs, including OAuth2 utilities.

CVE-2026-33942 describes an insecure deserialization issue where versions prior to 4.0.0 used PHP’s unserialize() inside AccessTokenAuthenticator::unserialize() to restore OAuth token state from cache or storage, with allowed_classes => true. If an attacker can control the serialized string (for example by overwriting a cached token file or via another injection path), they can supply a serialized “gadget” object that triggers magic methods (e.g., __wakeup, __destruct) during deserialization, resulting in object injection.

In environments with common dependencies (the advisory calls out Monolog as an example), object injection can often be chained into remote code execution. This is the same failure mode that repeatedly shows up in PHP ecosystems when serialized state is persisted and later re-hydrated across trust boundaries.

Who is impacted

• Projects using saloonphp/saloon versions < 4.0.0.
• Users of Saloon’s OAuth2 utilities, specifically the AccessTokenAuthenticator class.
• Deployments where an attacker can influence the serialized token state stored in cache or on disk (e.g., writable cache directories, shared caches, or other paths that allow overwriting stored token blobs).

What to do now

• Follow vendor remediation guidance and upgrade to a patched release.

  "Upgrade to Saloon v4+"

• Identify any services using Saloon OAuth2 utilities and inventory where token state is persisted (filesystem caches, shared caches, database blobs).
• Treat token-state storage as a trust boundary: restrict write access to any cache/storage locations that can feed AccessTokenAuthenticator state, and investigate any code paths that could let untrusted inputs reach that storage.
• If compromise is suspected, assume token material and adjacent secrets reachable by the PHP process may have been exposed; scope incident response accordingly (log review + credential/token rotation based on your environment).