CVE-2026-16636 is a stored XSS in FluentSMTP where the to.name parameter passed to wp_mail() can contain malicious script that executes when an administrator uses the Prev/Next navigation controls in the email log detail view. The list view escapes this field properly, but the detail view's navigation links do not — creating a surgical bypass that executes only when someone clicks through to a specific log entry.
The critical subtlety here is the trigger condition: the attacker doesn't need admin access. They simply call wp_mail() with a crafted to.name value, and the payload persists in the database. It sits dormant and invisible — the list view shows it safely escaped — until an administrator navigates to that specific record via Prev/Next. This creates a delayed execution model that standard testing often misses: you're testing rendering at injection time or in the immediate context, not in navigation flows that activate stored data later.
The wp_mail() trust model amplifies this significantly. Because any plugin or theme on a WordPress site can invoke wp_mail(), an attacker doesn't need to compromise FluentSMTP directly — they need only trigger an email from anywhere on the site. This makes the blast radius extend well beyond FluentSMTP itself.
For defenders: audit any plugin that logs wp_mail() parameters for similar split sanitization patterns. Check both list/detail views AND all navigation paths (Prev/Next, pagination, sorting links) for the same fields. The fix isn't just adding esc_html() to the detail view — it's ensuring every rendering path for logged data gets sanitized consistently, ideally at the retrieval layer rather than ad hoc per-view. If your plugin has log/detail view patterns, add explicit test coverage that renders every logged field through every available navigation control.