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.

[tacoverdo]

Migration fix verified — but write-side bypass is still open

What works now

Migration empty-content bug is fixed. Existing title-only payloads (e.g. <img src=x onerror=alert(1)>) are now correctly removed:

wp eval '(new Progress_Planner\Update\Update_191())->run();'
wp eval 'echo (get_post(262) ? get_post(262)->post_title : "DELETED");'
→ DELETED

What's still broken: WP-CLI / wp_insert_post bypass

rest_pre_insert_prpl_recommendations only fires for REST API inserts. Any call to wp_insert_post() — WP-CLI, custom plugins, scheduled events, programmatic recommendation creation, third-party integrations — bypasses the sanitizer entirely.

Reproduction on the patched branch:

wp post create --post_type=prpl_recommendations \
  --post_title='<img src=x onerror=alert("post-patch-cli")>' \
  --post_status=publish --user=1
# → Created post 286
wp post term set 286 prpl_recommendations_provider 8 --by=id
wp cache flush
wp eval 'echo get_post(286)->post_title;'
# → <img src=x onerror=alert("post-patch-cli")>   (raw, not sanitized)

Loading /wp-admin/admin.php?page=progress-planner&prpl_show_all_recommendations= fires the alert via views/js-templates/suggested-task.html:18 ({{{ data.post.title.rendered }}}).

The <script>…</script> payload doesn't trigger because browsers don't execute <script> inserted via innerHTML (which is what Underscore's {{{ }}} does). Event-handler payloads (<img onerror>, <svg onload>, <iframe srcdoc>) do trigger — so <script> tests give a false sense of safety.

Suggested fix

Move the sanitizer from rest_pre_insert_prpl_recommendations (REST-only) to one of the lower-level chokepoints that catches every write path:

• wp_insert_post_data (filter) — runs on all inserts/updates, lets you mutate the sanitized data array before it hits the DB.
• save_post_prpl_recommendations (action) — fires after save, requires a follow-up wp_update_post if you need to rewrite.

wp_insert_post_data is cleaner — single chokepoint, no recursion concerns:

add_filter( 'wp_insert_post_data', function ( $data, $postarr ) {
    if ( 'prpl_recommendations' !== ( $data['post_type'] ?? '' ) ) {
        return $data;
    }
    $data['post_title'] = sanitize_text_field( wp_strip_all_tags( $data['post_title'] ) );
    return $data;
}, 10, 2 );

This closes both the REST hole and the CLI/programmatic hole with one filter, and obsoletes the existing rest_pre_insert_* hook.

Test coverage gap (still applies)

The current PHPUnit tests plant rows via $wpdb->update after creation, which bypasses all WP filters — so they validate the migration but don't exercise the write-side sanitizer. Adding tests that go through wp_insert_post() directly would catch this regression and any future ones.

[ilicfilip]

@tacoverdo , we discussed this yesterday - are we good?