allowed_classes_callback option for unserialize()
| From: | Casper Langemeijer | Date: | Tue, 05 Aug 2025 09:14:26 +0000 |
| Subject: | allowed_classes_callback option for unserialize() | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-128395@lists.php.net to get a copy of this message | ||
I'm writing a this email to propose adding allowed_classes_callback option to unserialize().
The class name as parsed from the serialized string is passed as a parameter to the callback, it
should return a boolean. true would allow the class, false would block it. This blocks classes the
same way 'allowed_classes' would, but by callback instead. The callback will be triggered
*after* allowed_classes is evaluated (if present). Blocking will have the same effect as
allowed_classes, using __PHP_Incomplete_Class.
This callback would solve a few problems where allowed_classes is not sufficient:
- This would also allow for fixing legacy applications where it is not exactly clear what is being
unserialized. In my use-case the callable returns a true value but a E_USER_DEPRECATION is
triggered. This way data can be collected about what classes to allow through monitoring these
deprecations, providing a non-disrupting way to secure unserialize calls. This is especially helpful
in very generic unserialize usages like caches.
- It would allow for an is_subclass_of() check where for example an interface can be added to
classes that are safe to get unserialized. Current allowed_classes array only matches the exact
class, not it's children.
Note that these problems are not resolvable by using unserialize_callback_func because that call
only happens for unloaded classes, where the PHP Object Injection vulnerability https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection
affects classes that might already have been loaded.
In de pull request Jakub wrote:
> Personally I don't see any issue here and it seems quite self contained and small so I
> wouldn't mind to get it merged without RFC. It might be worth to email internals first to
> double check that there are no objections first.
Out of scope: I understand that __PHP_Incomplete_Class is not very 2025. Adding an option
throw_for_unknown_classes has been suggested on this list. I'm happy to implement that, but for
now I'd like to keep it at allowed_classes_callback.
Feedback is very much appreciated.
The change and some more details live here: https://github.com/php/php-src/pull/19087