Summary

This PR adds allowed_classes => false to all unserialize() calls in the four cache controller get() methods.

Problem

The following files call unserialize() without restricting which PHP classes can be instantiated during deserialization:

• libraries/src/Cache/Controller/OutputController.php
• libraries/src/Cache/Controller/PageController.php
• libraries/src/Cache/Controller/ViewController.php
• libraries/src/Cache/Controller/CallbackController.php

If the cache backend (filesystem, Memcached, Redis, APCu) is accessible to an attacker — either through a poisoned cache entry, a compromised cache server, or a path traversal in the file cache — they can inject a serialized PHP object that will be instantiated during unserialize(). This can trigger __wakeup() / __destruct() magic methods on any class loaded in memory, potentially leading to Remote Code Execution (PHP Object Injection, CWE-502).

Fix

Pass ['allowed_classes' => false] as the second argument to unserialize(). This is safe because:

• OutputController: data is always a plain PHP value (string/array), never an object
• PageController: data is always a structured array of strings (body, head, pathway, modules) — verified by reviewing Cache::setWorkarounds()
• ViewController: data is always a string (rendered view output)
• CallbackController: data is always ['output' => string, 'result' => mixed] — no objects

When allowed_classes => false, unserialize() will return false instead of instantiating a malicious object, preventing the gadget chain from executing.

Testing

Code analysis confirms that in all four controllers, the store() method serializes only arrays of scalars or strings. No PHP object instances are ever stored. Therefore allowed_classes => false cannot cause a regression.

References

• PHP docs: https://www.php.net/manual/en/function.unserialize.php
• CWE-502: Deserialization of Untrusted Data
• OWASP: PHP Object Injection
• Google Patch Rewards Program: https://bughunters.google.com/open-source-security/patch-rewards