v1.9.1

[ilicfilip]

No description provided.

[github-actions]

Test on Playground
Test this pull request on the Playground
or download the zip

[tacoverdo]

When trying to reproduce the bug and fix, I ran into the following:

Update_191::sanitize_recommendation_titles() calls wp_update_post() with the stripped title. When the original was pure markup (e.g., ), wp_strip_all_tags() returns ''. If the post also has
empty content + excerpt, WordPress rejects the update with empty_content. update_recommendation() returns false, the migration silently moves on, and the malicious row stays in the DB — still exploitable
when rendered.

Repro on the PR branch:

wp post create --post_type=prpl_recommendations --post_title='<img src=x onerror=alert(1)>' --user=1
  wp post term set <ID> prpl_recommendations_provider <non-user-term> --by=id
  wp option delete progress_planner_version
  # trigger migration (e.g., load any admin page)
  wp eval 'echo get_post(<ID>)->post_title;'   # still raw markup

Suggested fix (in order of preference):

1. Trash the row when sanitized title is empty — the recommendation was junk anyway:>

if ( '' === $sanitized ) {
     wp_delete_post( $recommendation->ID, true );
     continue;
 }

2. Direct $wpdb update to bypass WP's empty-content guard:

$wpdb->update( $wpdb->posts, [ 'post_title' => $sanitized ], [ 'ID' => $recommendation->ID ] );
clean_post_cache( $recommendation->ID );

3. Placeholder fallback — preserves the row but with a safe stub.

Also worth flagging: rest_pre_insert_prpl_recommendations only covers REST writes. wp_insert_post/CLI/programmatic creates bypass it. Moving the sanitizer to wp_insert_post_data (or
save_post_prpl_recommendations) would close that gap too — which is the same WP-CLI bypass we used to plant post 262 in the first place.