Summary: A stored Cross‑Site Scripting (XSS) vulnerability affecting the “Contact List” WordPress plugin (versions <= 3.0.18) allows an authenticated user with Contributor privileges to submit HTML/iframe input that may be rendered unsafely, leading to stored XSS (CVE-2026-3516). A patch was released in version 3.0.19 on 20 Mar 2026. This advisory explains impact, detection, remediation, short-term virtual patching using a WAF, and long-term hardening.

Table of contents

• Quick facts
• How the vulnerability works (overview, exploitation chain)
• Real-world impact and attack scenarios
• How to detect if your site is affected (searches, WP-CLI, DB queries, logs)
• Immediate remediation steps (update, patch, remove malicious entries)
• Short-term mitigation with a Web Application Firewall (virtual patching)
• Recommended secure coding and configuration changes for plugin authors and site owners
• Cleanup and incident response checklist
• Prevention and long-term hardening checklist
• FAQ
• How to get professional help (neutral guidance)

Quick facts

• Affected software: Contact List WordPress plugin — versions <= 3.0.18
• Vulnerability type: Stored Cross‑Site Scripting (XSS)
• Vector: Unsanitized/unsafe output of the _cl_map_iframe parameter (user-supplied iframe/html)
• Required privilege: Contributor (authenticated)
• User interaction required: Yes (attacker stores payload; execution requires a privileged user or a particular action/view)
• CVE: CVE-2026-3516
• CVSS (as reported): 6.5 (medium)
• Patched in: Contact List v3.0.19 (released 20 Mar 2026)

How the vulnerability works (high level)

Stored XSS occurs when attacker-supplied input is persisted by the application and later rendered without proper escaping or sanitisation. The Contact List plugin accepted a parameter named _cl_map_iframe that could contain HTML (for example, an iframe), stored it, and later output that value into a view without sufficient filtering.

Why this matters:

• Contributors are authenticated users. Although they typically cannot publish directly, they can submit content that may be viewed by Editors or Admins. If that content includes a stored script, it executes in the context of whoever views the rendered content.
• A stored XSS payload can run in the browser of an admin/editor or site visitor, enabling session theft, account takeover, or unauthorized actions performed with the victim’s privileges.

Exploitation chain

1. Attacker authenticates as a Contributor.
2. Attacker submits a contact or a setting including a crafted _cl_map_iframe payload.
3. The plugin stores the payload without adequate sanitisation/escaping.
4. When a privileged user (or any page that renders the stored value) loads the content, the malicious script executes.

Note: The report indicates exploitation requires user interaction — a privileged user must view or interact with the page that contains the stored payload.

Real-world impact and attack scenarios

Stored XSS is a persistent problem: a single malicious submission can affect many users over time. Typical impacts include:

• Admin session theft — exfiltrated cookies or tokens can lead to account takeover.
• Browser-based actions — injected JavaScript can change settings, create users, upload files, or plant backdoors.
• Phishing and social engineering — malicious content can trick privileged users into revealing credentials or approving harmful actions.
• Defacement and ad injection — persistent content can alter the site for visitors.
• Supply-chain impact — compromised agency or publishing sites can be used to deliver malware to downstream clients.

How to check if your site is affected (detection)

Assume any site running Contact List <= 3.0.18 is potentially affected until verified. Key checks:

1. Confirm the plugin version.
2. Search the database for suspect _cl_map_iframe values and other stored HTML.
3. Look for unusual admin activity, new users, or modified files.
4. Scan with an integrity/malware scanner.

1) Confirm plugin version in WordPress Admin or filesystem

• WordPress Admin: Plugins → Installed Plugins → Contact List → note the version.
• Filesystem: Check the readme.txt or plugin header in /wp-content/plugins/contact-list/contact-list.php for the version string.

2) Search the database for the _cl_map_iframe parameter

The plugin may store values in postmeta, options, or a plugin table. Backup your DB before changes.

WP-CLI examples:

# Search postmeta
wp db query "SELECT meta_id, post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE '%_cl_map_iframe%' OR meta_value LIKE '%_cl_map_iframe%' LIMIT 100;"

# Search options (if plugin stores config in options table)
wp db query "SELECT option_id, option_name, option_value FROM wp_options WHERE option_name LIKE '%contact_list%' OR option_value LIKE '%_cl_map_iframe%' LIMIT 100;"

# Generic scan for suspicious iframe/script HTML (may return many rows; inspect carefully)
wp db query "SELECT table_name, column_name FROM information_schema.columns WHERE table_schema = DATABASE() AND data_type IN ('text', 'longtext', 'varchar');"
# then search likely columns for "3) Search plugin tables and post content
If the plugin uses custom tables (for example, wp_cl_records), search those tables' columns for  or .

4) Inspect plugin files for unsafe output
Developers/sites can grep for raw echoes of the vulnerable parameter:
grep -R --line-number "echo .*_cl_map_iframe" wp-content/plugins/contact-list || true

Review whether outputs use esc_attr(), esc_html(), wp_kses(), etc.
5) Server logs and admin activity

Check access logs for POSTs from contributor accounts including iframe payloads.
Review audit logs for recent changes around the disclosure date.

6) Malware and integrity scans
Run a file integrity/malware scan and compare plugin files to a clean copy. Look for unexpected PHP files or modifications.