Authenticated (Author) Stored XSS in Better Find and Replace (<= 1.7.9): What Site Owners Need to Know

On April 16, 2026 a stored cross-site scripting (XSS) vulnerability affecting the WordPress plugin “Better Find and Replace — AI‑Powered Suggestions” (plugin slug: real-time-auto-find-and-replace) was published and assigned CVE-2026-3369. The issue impacts plugin versions up to and including 1.7.9 and was fixed in version 1.8.0.

As security professionals based in Hong Kong, we provide a concise, pragmatic explanation for site owners, developers and incident responders: what the issue is, plausible attack scenarios, immediate mitigations if you cannot update right away, and durable hardening and detection steps. No sensationalism — just actionable guidance you can apply now.

Résumé exécutif

• Vulnerability: Stored Cross‑Site Scripting (XSS) in the Better Find and Replace plugin (<=1.7.9).
• CVE: CVE‑2026‑3369
• Impact: Attackers with Author-level privileges can store malicious JavaScript in the title of an uploaded image. If that title is later rendered without proper escaping, the script executes in the context of the viewer (admin, editor, etc.).
• Severity: Low (Patch scoring CVSS 5.9); stored XSS can still be chained to escalate privileges, hijack sessions, perform actions, or persist backdoors.
• Privilège requis : Auteur (authentifié)
• Patched: Update to version 1.8.0 or later to resolve the issue.
• Immediate mitigation: Update plugin. If updating is impossible, temporarily revoke upload capability from risky roles, scan attachment titles for suspicious input, and deploy server-side rules to block requests containing script-like payloads in form fields or file metadata.

How this vulnerability works (technical overview — high level)

Stored XSS occurs when user-controlled input is stored and later rendered without proper output encoding. In this case:

1. An authenticated user with Author capability can upload an image (create an attachment post).
2. The plugin allows the attachment’s title (titre_du_poste) to contain unsanitized HTML/JavaScript.
3. When that title is rendered without escaping (admin screens or public pages), the malicious script executes in the viewer’s browser.
4. If the viewer is privileged, the attacker can perform actions in that user’s session, exfiltrate tokens, or persist further payloads.

Important nuance: exploitation requires an authenticated Author (or higher) account to upload the crafted attachment. This lowers the surface compared to a public unauthenticated upload, but many sites allow uploads from contributors or authors, so the risk remains notable.

Scénarios d'attaque réalistes

Stored XSS is a flexible primitive for attackers. Practical misuse cases include:

1. Malicious Author on a compromised account
   If an attacker acquires Author credentials (phishing, credential stuffing, reused passwords), they can upload an image with a crafted title and await privileged staff viewing the media or admin screens.
2. Abuse of collaborative workflows
   Multi-author blogs, external contributors or guest authors can be leveraged to introduce payloads during normal editorial activity.
3. Privilege escalation & persistence
   Executed scripts in an admin’s browser can issue privileged AJAX requests, create admin accounts, install plugins/themes, or inject further backdoors.
4. Front-end exposure
   If a theme outputs attachment titles without escaping on the front end, public visitors may be affected depending on site templates.
5. CSRF chaining
   With XSS you can read CSRF tokens and perform state-changing operations as the victim user.

What to do immediately — short checklist (action now)

1. Update the plugin to v1.8.0 or later (the fastest, definitive fix).
2. Si vous ne pouvez pas mettre à jour immédiatement :
   • Temporarily revoke the télécharger_fichiers capability from the Author role (or other roles that should not upload).
   • Search attachments for suspicious titles and remove or sanitize any malicious entries (detection queries below).
   • Deploy server-side rules to block requests containing <script> or event-handler attributes (e.g., onload=) in uploads or form fields.
   • Force logout of privileged users and rotate passwords for any accounts suspected of compromise.
3. Audit user accounts for unusual Authors or recently created privileged accounts.
4. Inspect file modification times for themes/plugins and investigate unexpected changes.
5. Monitor logs for suspicious admin panel access and unusual POST requests.

Updating remains the recommended action. If you must postpone the update, apply the temporary mitigations above until you can test and deploy the patched version.

Comment détecter si vous avez été ciblé ou exploité

Run these non-destructive checks (take a backup before making mass changes):

Search for suspicious strings in attachment titles in the database:

SELECT ID, post_title, post_date, post_author
FROM wp_posts
WHERE post_type = 'attachment'
  AND (post_title LIKE '%<script%' OR post_title LIKE '%javascript:%' OR post_title LIKE '%onload=%' OR post_title REGEXP '<[^>]*on[a-zA-Z]+=');

Search posts for injected script tags:

SELECT ID, post_title;

Check recently created/modified admin accounts:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);

Audit server logs for suspicious admin page loads that coincide with upload POSTs. Compare timestamps between file upload events and admin GETs that indicate a malicious payload being viewed.

Scan the filesystem for recently changed files and compare to a known-good backup or repository snapshot. Use malware scanners and WAF logs to search for blocked XSS payload patterns.

If you find attachments with XSS payloads in titles, remove or sanitize them and rotate credentials used since the timeframe of exposure. Also check for unexpected admin users and scheduled tasks.

How to safely remediate infected sites (incident response playbook)

1. Contenir
   • Place the site into maintenance mode or isolate the environment.
   • Revoke or rotate credentials for suspected compromised accounts (admins, editors, authors).
2. Éradiquer
   • Remove the malicious attachment(s) or sanitize their titles.
   • Remove unknown plugins or themes and any backdoor files.
   • Revert unauthorized content changes.
   • Reinstall relevant plugins from a clean source and ensure patched versions are used (1.8.0+ for this plugin).
3. Récupérer
   • Restore from clean backups if needed.
   • Reapply patches and hardening measures.
   • Faire tourner les clés API et les jetons qui ont pu être exposés.
4. Leçons apprises
   • Investigate how the account was compromised (weak passwords, reuse, phishing).
   • Reassess roles and capabilities and improve onboarding controls.
   • Preserve forensic logs and document the incident if you suspect targeted activity.

Practical hardening: immediate technical fixes you can apply

Safe, admin-focused changes to reduce similar risks:

1. Remove upload ability from the Author role (temporary mitigation)

Add as a site-specific plugin or mu-plugin to temporarily remove upload capability:

<?php
// Temporarily remove upload capability from 'author' role
add_action('init', function() {
    $role = get_role('author');
    if ($role && $role->has_cap('upload_files')) {
        $role->remove_cap('upload_files');
    }
});
?>

To restore:

$role->add_cap('upload_files');

2. Sanitize attachment titles on save

Sanitize titles at insert/update to prevent stored HTML/JS:

// Use this snippet to sanitize attachment titles on insert/update
add_filter('wp_insert_post_data', function($data, $postarr) {
    if (isset($data['post_type']) && $data['post_type'] === 'attachment') {
        // strip HTML tags and decode entities
        $data['post_title'] = wp_strip_all_tags( $data['post_title'] );
        $data['post_title'] = sanitize_text_field( $data['post_title'] );
    }
    return $data;
}, 10, 2);

3. Block form submissions containing script tags (server-side rule)

Example ModSecurity conceptual rule — adapt and test before deploying:

SecRule REQUEST_BODY "(?i)<script" "id:200001,phase:2,deny,log,msg:'Blocking possible XSS payload in request body'"

Adjust rules to avoid false positives and test on staging.

4. Apply Content Security Policy (CSP)

A CSP can reduce impact by disallowing inline scripts and restricting script sources. Example header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

CSP must be implemented carefully to avoid breaking legitimate admin interfaces; test in report-only mode first.

5. Harden REST/AJAX endpoints

• Ensure nonces are validated and actions are authorized for the role performing them.
• Audit custom plugin endpoints for input validation and authentication.

WAF strategy — recommended rules

For those operating a WAF or server-side request inspection, recommended rule types to mitigate this class of issue:

• Block parameters containing HTML tags or event attributes where not expected (file names, titles).
• Use heuristic scoring combining indicators such as “<script“, “onload=“, “javascript :“, suspicious unicode escapes, URL-encoded script markers, and MIME mismatches.
• Rate-limit suspicious accounts (e.g., rapid multiple uploads by the same Author).
• Virtual patching: if a known plugin is vulnerable and cannot be updated immediately, intercept and sanitize targeted parameters (attachment titles) until a vendor patch is applied.

How to detect suspicious attachment titles from WordPress admin

Temporary admin helper (mu-plugin) to list attachments with suspicious titles. Remove after use; do not leave debugging utilities on production:

<?php
/*
Plugin Name: Find Suspicious Attachments
Description: Admin helper to list attachments with suspicious titles (temporary).
Version: 1.0
*/

add_action('admin_menu', function() {
    add_management_page('Suspicious Attachments', 'Suspicious Attachments', 'manage_options', 'suspicious-attachments', 'suspicious_attachments_page');
});

function suspicious_attachments_page() {
    if (!current_user_can('manage_options')) {
        wp_die('Unauthorized');
    }

    global $wpdb;
    $like_patterns = [
        '%<script%',
        '%javascript:%',
        '%onload=%',
        '%onerror=%',
    ];
    $where_clauses = [];
    foreach ($like_patterns as $p) {
        $where_clauses[] = $wpdb->prepare("post_title LIKE %s", $p);
    }
    $where = implode(' OR ', $where_clauses);

    $results = $wpdb->get_results("SELECT ID, post_title, post_date, post_author FROM {$wpdb->posts} WHERE post_type='attachment' AND ({$where})");

    echo '<div class="wrap"><h1>Suspicious Attachments</h1>';
    if (empty($results)) {
        echo '<p>No suspicious titles found.</p>';
    } else {
        echo '<table class="widefat"><thead><tr><th>ID</th><th>Title</th><th>Date</th><th>Author</th></tr></thead><tbody>';
        foreach ($results as $r) {
            echo '<tr><td>' . esc_html($r->ID) . '</td><td>' . esc_html($r->post_title) . '</td><td>' . esc_html($r->post_date) . '</td><td>' . esc_html($r->post_author) . '</td></tr>';
        }
        echo '</tbody></table>';
    }
    echo '</div>';
}
?>

Why stored XSS remains a high-risk class of bug

Even vulnerabilities labelled “low” can be very impactful: once JavaScript runs in a privileged user’s browser it can read authentication tokens, submit authenticated requests, load second-stage payloads, or persist additional malicious content. On multi-author sites, agencies, publishers or membership platforms, the downstream effects can be severe.

Recommandations finales et liste de contrôle

• Mise à jour : Install Better Find and Replace v1.8.0 or later as soon as possible.
• Limiter les téléchargements : Temporarily remove upload capability from roles that don’t need it.
• Sanitize: Add server-side filtering to sanitize attachment titles until the plugin is updated.
• Scanner : Run the database and file scans outlined above for signs of exploitation.
• WAF / Server rules: Enable rules that block suspicious HTML/JS in form fields and metadata.
• Audit : Review user accounts, recent plugin/theme changes and filesystem modifications.
• Sauvegarde : Ensure you have clean backups and test restores before making major changes.

Closing thoughts from a Hong Kong security team

WordPress’ extensibility is a strength but also its primary attack surface. CVE‑2026‑3369 highlights the need for both preventive controls (timely updates, least privilege, secure coding) and compensating controls (input validation, server-side request inspection, monitoring) to reduce exposure windows. Prioritise the plugin update to 1.8.0+, and if you cannot immediately patch, apply the mitigations and detection procedures in this guide to meaningfully reduce risk.

— Hong Kong Security Team