Safeguard
Vulnerability Analysis•

CVE-2026-33942: Insecure Deserialization in Saloon PHP

CVE-2026-33942 (CVSS 9.8) is unsafe unserialize() in Saloon's AccessTokenAuthenticator before 4.0.0. Upgrade to Saloon 4 and store OAuth tokens without it.

Safeguard Security Team
2 min read

CVE-2026-33942 is an object injection flaw in Saloon, a PHP library for API integrations. NVD scores it 9.8. Versions before 4.0.0 used unserialize() with all classes allowed to restore OAuth tokens. Upgrade to Saloon 4.0.0. The advisory says a chain through a common logging library can reach remote code execution.

What's affected

The advisory lists Saloon before 4.0.0 as affected, for users of the OAuth2 utilities and the AccessTokenAuthenticator class. An attacker who controls the serialized string, for example by overwriting a cached token file or through another injection, can supply a gadget object. With common dependencies such as Monolog, the advisory says this can chain to remote code execution.

How to check if you're exposed

composer show saloonphp/saloon

Search your code for AccessTokenAuthenticator::unserialize and for places where tokens are stored in cache or a database in serialized form.

What to do now

  1. Upgrade saloonphp/saloon to ^4.0, along with saloonphp/laravel-plugin if used, following the upgrade guide.
  2. Store token fields yourself and rebuild the authenticator from them, since v4 removes the serialize methods.
  3. Protect cache and token storage from writes by untrusted parties.
  4. Review the other two changes in the v4 guide: absolute URL endpoint overrides and fixture path traversal.

Why it matters

The record uses CWE-502, deserialization of untrusted data. PHP runs magic methods when objects are rebuilt, so attacker chosen classes act on load. The fix removes serialization of the class entirely. The record is not marked as exploited in the wild and is not in CISA KEV.

Many PHP projects serialize objects into caches because it is convenient. The risk grows when the storage location can be written by anything other than your own code, such as a shared cache, a world writable temp file or a database field fed by users. After moving to Saloon 4, store only the token string, refresh token and expiry in your cache, and build the authenticator object from those fields when you need it. Treat cache contents as untrusted input.

Quick check

Is v4 a breaking change?

Yes. The upgrade guide says it removes the serialize methods, so you must handle token storage yourself.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.