[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