Default serializable_classes = false prevents caching Eloquent models without additional configuration

[akram-khodami]

Laravel Version

13.12.0

PHP Version

8.3.31

Database Driver & Version

MySQL

Cache Driver

database

Description

With a fresh Laravel 13 installation, the default cache configuration contains:

'serializable_classes' => false,

When caching Eloquent models or Eloquent collections using the Database cache driver, the cached value cannot be restored correctly with the default configuration.

For example:

Cache::remember('products', 3600, function () {
    return Product::latest()->get();
});

$products = Cache::get('products');

dd($products);

Instead of returning an Illuminate\Database\Eloquent\Collection containing Product models, the cached value contains __PHP_Incomplete_Class instances.

As a result, attempting to access model properties results in errors such as:

Attempt to read property "name" on string

or inspecting the cached value shows __PHP_Incomplete_Class objects.

The issue disappears after explicitly allowing the serialized classes, for example:

'serializable_classes' => [
    Illuminate\Database\Eloquent\Collection::class,
    App\Models\Product::class,
]

After clearing the cache and configuration, the same code works correctly.

Expected Behavior

I expected one of the following:

• Caching Eloquent models to work out of the box with the default configuration, or
• The default configuration or documentation to clearly indicate that Eloquent model classes must be explicitly listed in serializable_classes.

Question

Is this the intended behavior?

If so, perhaps the default configuration or documentation could better explain that Eloquent models cannot be cached unless they are explicitly allowed.

Steps To Reproduce

1. Create a fresh Laravel 13.12.0 application.
2. Configure the cache driver:

CACHE_STORE=database

3. Create a basic Product model and migration.
4. Insert at least one product into the database.
5. Cache an Eloquent collection:

Cache::remember('products', 3600, function () {
    return Product::latest()->get();
});

6. Retrieve the cached value:

$products = Cache::get('products');

dd($products);

7. Observe that the cached value contains __PHP_Incomplete_Class objects when the default configuration is:

'serializable_classes' => false,

8. Update the configuration:

'serializable_classes' => [
    Illuminate\Database\Eloquent\Collection::class,
    App\Models\Product::class,
]

9. Clear the cache and configuration:

php artisan optimize:clear

10. Repeat steps 5 and 6.

The cached collection is now restored correctly as an Illuminate\Database\Eloquent\Collection containing Product model instances.

[hosni]

Hi @akram-khodami

This is exactly why Laravel 13 introduced the new serializable_classes configuration:
https://laravel.com/docs/13.x/upgrade#cache-serializable_classes-configuration

The goal is to reduce the risk of PHP deserialization (object injection) attacks. When PHP calls unserialize(), it may instantiate arbitrary classes and invoke magic methods such as __wakeup(), __destruct(), or __unserialize(). If an attacker can control the serialized payload and a suitable gadget chain exists in the application or its dependencies, this can ultimately lead to arbitrary code execution.

Laravel now defaults to not unserializing arbitrary classes from the cache, and instead requires an explicit allow-list of classes that are safe to restore. (Laravel)

This is not just a theoretical concern. PHP has a long history of deserialization vulnerabilities. For example:

• Pornhub (2016): Researchers discovered two zero-day vulnerabilities in PHP's unserialize() implementation and demonstrated remote code execution against Pornhub.
  While this particular attack exploited bugs in PHP itself (rather than a gadget chain), it is a great example of why deserializing untrusted data is considered dangerous. The original write-up is well worth reading:
  https://www.evonide.com/how-we-broke-php-hacked-pornhub-and-earned-20000-dollar/
• Laravel's own history: Laravel 5.5.42 and 5.6.30 intentionally stopped serializing encrypted cookies because, if an application's APP_KEY were ever compromised, an attacker could forge serialized payloads and exploit PHP object deserialization vulnerabilities. (Laravel)
  The new serializable_classes option follows the same defense-in-depth philosophy. Even if an attacker somehow obtains your APP_KEY, they can no longer deserialize arbitrary objects from the cache. Instead, only explicitly approved classes may be restored, significantly reducing the attack surface. For many use cases, it's even better to cache plain arrays or DTOs instead of complex object graphs. (Laravel)

[marcosalberto1991]

debe añadir el todas las consultas la funcion toArray() si esta dentro de un Cache::remember

$data = Cache::remember('products', 3600, function () {
    
        return Product::latest()->get()->toArray();   // Add toArray() 
});
return $data;