[wp-trac] [WordPress Trac] #52738: Use of get_object_vars() in sanitize_post() and WP_Post constructor does not handle null byte
WordPress Trac
noreply at wordpress.org
Sat Jul 1 13:37:58 UTC 2023
#52738: Use of get_object_vars() in sanitize_post() and WP_Post constructor does
not handle null byte
----------------------------------------------------+---------------------
Reporter: bitcomplex | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.3
Component: Posts, Post Types | Version: 5.6.2
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests needs-testing | Focuses:
----------------------------------------------------+---------------------
Comment (by bitcomplex):
As the reporter of the bug; I'm still convinced this is a serious bug in
core. It still affect us every release and we have to patch it manually.
The real issue is when you serialize objects and later change the
visibility of a property in the class the object belongs too. Since you've
decided that it is a good idea to store serialized objects you should also
handle changes of classes in a way that do not cause fatals.
It is impossible to fix the old objects that are permanently stored in the
database, but fixing this by ignoring null bytes upon reading, handles the
issue perfectly.
Replying to [comment:13 costdev]:
> Thanks for the ping @oglekler! I meant to get a closer look at this
sooner but only ever had a cursory look during scrubs or when taking a
look at test failures on the `map_deep()` ticket.
>
> Sergey was able to
[https://core.trac.wordpress.org/ticket/47164#comment:3 reproduce the
issue] on the `map_deep()` ticket, and [https://3v4l.org/ScIk3 here's a
3v4l] that might help to visualise the issue and the proposed patch.
>
> My thoughts on whether to patch this:
>
> - Is the value containing `NUL` bytes produced by Core?
> - If the answer is no, then this is an `enhancement` request to add
support for `NUL` bytes, not a `defect (bug)` report, and should be moved
out of the 6.3 milestone as we're now in Beta. (Note: A Fatal Error
doesn't necessarily mean a bug in Core, it could just mean that PHP says
"no" to something extenders are trying to do with Core)
> - Is the use case valid?
> - If so, we should continue.
> - If not, we should consider closing this as `invalid` as the issue
should be rectified where the value is generated and/or stored.
>
> Without more information, it's hard to classify this ticket before
deciding the right course of action. I'd suggest adding `reporter-
feedback` so we have the information necessary to move forward.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/52738#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list