[wp-trac] [WordPress Trac] #37757: Add `allowed_classes` to `maybe_unserialize` When WordPress is running on PHP 7+
WordPress Trac
noreply at wordpress.org
Fri Feb 21 11:59:37 UTC 2025
#37757: Add `allowed_classes` to `maybe_unserialize` When WordPress is running on
PHP 7+
-------------------------------------------------+-------------------------
Reporter: chrisguitarguy | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting
| Review
Component: Security | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests 2nd- | Focuses:
opinion |
-------------------------------------------------+-------------------------
Comment (by siliconforks):
Replying to [comment:13 FrancescoCarlucci]:
> Are there serialized classes in WP core passed to maybe_unserialize? I
can't find any: https://github.com/search?q=repo%3AWordPress%2Fwordpress-
develop%20maybe_unserialize&type=code
Everything in the `wp_options` table and metadata tables gets passed to
`maybe_unserialize`. WordPress core sometimes stores objects of type
`stdClass` here (I'm not sure if there are other classes).
> > the original patch on this ticket proposes adding an $options argument
to maybe_unserialize() instead
>
> As far as I understand, the original patch is pretty much similar, but
gives you flexibility on the options to pass, which is good. unserialize()
at the moment only takes `allowed_classes ` and `max_depth`, but maybe in
the future there may be more, so I agree on making the filter act on
$options.
I believe that @johnbillion is talking about
[https://core.trac.wordpress.org/attachment/ticket/37757/ticket-37757.patch
this patch] which added another parameter to `maybe_unserialize` without
adding a filter.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37757#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list