[wp-trac] [WordPress Trac] #61489: 6.1.7 and 6.2.6 Updates Cause Critical Error

[WordPress Trac]

#61489: 6.1.7 and 6.2.6 Updates Cause Critical Error
-------------------------------+------------------------------
 Reporter:  mping001           |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Upgrade/Install    |     Version:  6.1
 Severity:  critical           |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by jelmerverkleij):

 @benoitchantre With the help of another customer who provided us debugging
 information, the root cause was identified.

 The situation here is that this patch is part of a set of patches applied
 to older versions of WordPress to address an XSS vulnerability in the
 footnotes block. This patch was released alongside one that introduces the
 referenced function in blocks.php. The patches were released on 19 October
 2023 and never caused any problems.

 However, with the release of these newer patch versions, the default-
 filters.php was left untouched while blocks.php was overwritten. This
 caused the reference to remain but the referenced function to disappear.
 The same would happen in case Patchman newly detected files in this new
 version with partial matching: we match by file contents, not by
 installation version (this has proven to be significantly less error-prone
 in the past) and because of this, the file default-filters.php matching
 our expected contents for 6.1 - 6.1.6 means the patch was applicable by
 extrapolation.

 Patchman as a product functions because updates are almost universally
 executed with full file overwrites, and the fixes we introduce are based
 on official updates towards the version that website owners usually update
 to. Partial updates generally involve all the files we touch. This
 particular flow is different because:
 a) this is a partial update
 b) the update in question didn't in fact cover a vulnerability that was
 previously considered a vulnerability by the WordPress team in a different
 release
 c) the update was introduced long after our patches were developed and
 tested (and proven to be safe with every WordPress version released at
 that stage), thus circumventing our standard QA procedure

 The odd set of circumstances has also meant that our debugging flow had to
 start from scratch, removing every single experience we've had with
 patching websites in well over a decade, in order to find out how our
 changes relate to the problems seen. Unfortunately, that has slowed down
 our ability to respond accurately to your very real problem of websites
 being broken. However, with help provided to us through various channels,
 we were able to piece together the order of events and - most importantly
 - what steps we can take to remediate this.

 We are currently working on modifications to our vulnerability patches
 that will address this particular problem in a way that is safe for every
 installation, regardless of its upgrade path, and expect to publish those
 through our software within the next several hours. In order to get this
 executed as quickly as possible upon that release, please refer to the way
 your hosting provider has configured Patchman for your website, as this
 can be configured as your provider sees fit.

 We shall also work on monitoring these partial updates as they are
 released in the future to better respond in cases where such partial
 rollouts cause problems as this one does.

 For any specific questions about particular cases, please feel free to
 refer to our customer support portal as referenced in my previous post.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61489#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform