CVE-2026-16542

Executive Summary

CVE-2026-16542 is a Server-Side Request Forgery (SSRF) vulnerability in the WordPress plugin "Import and export users and customers" affecting all versions prior to 2.4.5. An authenticated user with high privileges (e.g., administrator) can supply a crafted URL during a CSV import that the server then requests server-side without validation, allowing access to internal network resources and cloud metadata endpoints. Because exploitation requires high privileges, this is primarily a post-compromise or privileged-insider threat vector rather than an unauthenticated remote attack.

Technical Analysis

The vulnerability is a canonical Server-Side Request Forgery (SSRF), classified under the CWE-918 family. According to the NVD description, the plugin "does not validate a user-supplied URL before requesting it server-side during a CSV import." The essential mechanism is straightforward: a user-controllable input (a URL) is passed into a server-side HTTP request routine without host/IP allow-listing, protocol restriction, or redirect handling. The result is that the WordPress server itself — not the attacker's machine — initiates the outbound request.

CSV import workflows typically involve the server fetching a remote file (for example, a hosted CSV export from a third-party system) that is expected to contain user and customer records. When the plugin implements "import from URL" functionality, that URL parameter becomes the attack surface. In the absence of validation, the attacker can specify any scheme/host the server can reach:

• Internal HTTP services on 127.0.0.1, RFC1918 ranges, or the Kubernetes/link-local ranges.
• Cloud instance metadata endpoints (e.g., the HTTP metadata service on port 80) that may expose temporary credentials or configuration data.
• Non-HTTP schemes if the underlying client supports them, which would broaden the exploit surface (e.g., file access, protocol smuggling).

The data provided does not include the specific parameter name, function name, or handling code from the plugin, so no code-level identifiers are asserted here. What is derivable from the description alone is: the vulnerable input is a URL, the sink is a server-side HTTP request, the trigger is a CSV import action, and the missing control is URL validation. The trust boundary is the boundary between untrusted user input and the server's own network position.

Notably, the NVD description explicitly scopes the attacker to "high-privileged users." This means the vulnerability is a privilege-escalation / network-pivoting primitive rather than an unauthenticated attack. In practice, the plugin's import capability is gated behind capability checks (typically manage_options or an equivalent administrative capability), so an attacker must first hold a valid account with that capability. This should not be dismissed: many WordPress deployments grant administrator roles to more people than they should, and compromised credentials or plugin-level CSRF chaining can supply the necessary privilege.

Exploitation Scenarios

The attack chain is inferred from the vulnerability class and the NVD description; no public PoC exists.

1. Reconnaissance / target identification. The attacker identifies a WordPress site running the plugin at a version below 2.4.5. This is observable via passive fingerprinting (plugin assets under wp-content/plugins/), known plugin enumeration techniques, or authenticated inspection of the installed plugin list. The attacker must confirm they hold, or can obtain, an account with the high privilege required to reach the import function.

2. Triggering the flaw class. With an authenticated high-privileged session, the attacker navigates to the plugin's CSV import workflow and locates the URL field used to specify a remote CSV source. Instead of a legitimate external URL, the attacker supplies a URL pointing at a resource not intended to be reachable by the web server — for example, a loopback address, an internal hostname, or a link-local metadata address. Because the plugin does not validate the URL, the input is accepted.

3. Payload/execution at the vulnerability-class level. The server performs an outbound HTTP request to the attacker-controlled URL. This is the SSRF primitive. The attacker observes the server's response or its side effects. Depending on whether the response body is rendered back to the attacker (a "full-read" SSRF) or only its success/failure is observable (a "blind" SSRF), the attacker either reads the internal resource directly or infers its contents through timing, error codes, and response artifacts. No specific endpoint paths, parameters, or response-handling behavior are asserted here because the description does not provide them.

4. Post-exploitation impact. Successful SSRF yields internal-network reachability from the WordPress host: probing internal services, port-scanning internal ranges, and, where an instance metadata service is reachable, potential retrieval of cloud credentials that could pivot to the broader cloud environment. On shared or containerized hosting, the target set includes the container's own internal APIs and the orchestration metadata endpoint. Direct code execution is not part of this CVE's described mechanism; the impact is information disclosure and network pivot.

Impact Assessment

The CVSS v3.1 base score is not assigned in the source data (NVD lists N/A) and no EPSS score has been published by FIRST.org. The vector presented in METADATA above (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) reflects the vulnerability class and the described high-privilege requirement: network-reachable, low attack complexity, high privileges required, no user interaction, unchanged scope, high confidentiality impact, and no direct integrity or availability impact. Apply vendor/NVD scoring when published; this vector is an analytical estimate consistent with the description and should not be treated as authoritative.

Business impact centers on confidential data exposure rather than service disruption. An SSRF on a WordPress host can reveal internal service banners, admin panels, and cloud IAM credentials, which in turn may enable lateral movement and cloud account compromise. The blast radius is therefore the hosting network segment and, in cloud deployments, the IAM role attached to the instance.

Affected systems are WordPress installations with the "Import and export users and customers" plugin below 2.4.5. The affected version range is documented in the NVD description only as "before 2.4.5"; no separate vendor product/package mapping was provided. CISA has not added this CVE to the KEV catalog, and no exploit code, PoC, or Nuclei template is publicly tracked at time of writing.

Detection Guidance

Sigma Rule

title: WordPress Import/Export Users Plugin SSRF via CSV Import URL
id: 3f2c8d10-9a4b-4c7e-b0d2-1e5f7a9c4b21
status: experimental
description: Detects high-privilege use of the Import and export users and customers plugin CSV import feature referencing internal or metadata URLs, consistent with CVE-2026-16542 SSRF.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-16542
logsource:
  category: webserver
detection:
  selection_path:
    cs-uri-query|contains:
      - 'import-users-from-csv'
      - 'import_users'
      - 'csv_import'
  selection_url_value:
    cs-uri-query|contains:
      - '127.0.0.1'
      - 'localhost'
      - '169.254.169.254'
      - 'metadata.google.internal'
      - '10.'
      - '192.168.'
      - '172.16.'
      - 'file://'
      - 'gopher://'
  condition: selection_path and selection_url_value
falsepositives:
  - Legitimate administrator importing from an internal file server hostname
level: high

YARA Rule

rule WP_Import_Export_Users_SSRF_CVE_2026_16542
{
    meta:
        author = "valtersit.com"
        description = "Detects references to SSRF-prone URL handling in the Import and export users and customers WordPress plugin versions prior to 2.4.5 (CVE-2026-16542)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-16542"
        date = "2026-01-01"
        severity = "high"
    strings:
        $plugin = "import-users-from-csv-with-meta" ascii wide nocase
        $csv = "csv" ascii wide nocase
        $url = "url" ascii wide nocase
        $md = "169.254.169.254" ascii wide
        $loopback = "127.0.0.1" ascii wide
    condition:
        $plugin and filesize < 5MB and (any of ($md, $loopback) or (all of ($csv, $url)))
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-16542 WordPress Import/Export Users SSRF Attempt via CSV URL"; flow:to_server,established; http.uri; content:"import-users-from-csv"; nocase; http.uri; content:"url="; nocase; pcre:"/(127\.0\.0\.1|localhost|169\.254\.169\.254|metadata\.google\.internal|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|172\.(1[6-9]|2[0-9]|3[01])\.\d+\.\d+)/i"; classtype:attempted-recon; sid:202616542; rev:1; metadata:created_at 2026_01_01, cve CVE-2026-16542;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ http where http.request.method == "POST" and
      wildcard(http.request.body, "*import-users-from-csv*") and
      wildcard(http.request.body, "*csv*") ]
  [ http where
      (wildcard(url.full, "*127.0.0.1*") or
       wildcard(url.full, "*169.254.169.254*") or
       wildcard(url.full, "*localhost*") or
       wildcard(url.full, "*metadata.google.internal*") or
       wildcard(url.full, "*10.*") or
       wildcard(url.full, "*192.168.*")) ]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=nginx:access
| eval is_import = if(match(uri, "(?i)import-users-from-csv|import_users|csv_import"), 1, 0)
| eval is_internal = if(match(uri, "(?i)(127\.0\.0\.1|localhost|169\.254\.169\.254|metadata\.google\.internal|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|172\.(1[6-9]|2[0-9]|3[01])\.\d+\.\d+)"), 1, 0)
| where is_import=1 AND is_internal=1
| stats count values(uri) as target_uris by src_ip, user, status
| sort - count

Wazuh OSSEC Rule

<group name="web,wordpress,cve-2026-16542">
  <rule id="100642" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <id>^import-users-from-csv</id>
    <match>127\.0\.0\.1|localhost|169\.254\.169\.254|metadata\.google\.internal|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+</match>
    <description>CVE-2026-16542: Possible SSRF via WordPress Import and export users and customers CSV import (internal URL requested)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source. The NVD description names version 2.4.5 as the release in which the validation issue is addressed, but no vendor advisory, commit, or changelog has been confirmed in tracked sources; treat 2.4.5 as the reference fixed version and verify against the vendor's release notes.

1. Immediate mitigations

• Restrict the plugin's import functionality to the smallest possible set of trusted accounts; audit which users hold the capability required to run CSV imports.
• Where feasible, block outbound HTTP from the WordPress host to RFC1918 ranges, loopback, and link-local/metadata addresses at the network or host firewall level (egress filtering). This breaks the SSRF primitive regardless of plugin state.
• Put the WordPress host behind a proxy that enforces destination allow-lists for outbound requests.
• If the plugin's import-from-URL feature is not required, disable or restrict that capability.

2. Patch/upgrade steps

• Upgrade "Import and export users and customers" to version 2.4.5 or later. Validate the fixed version against the vendor's release notes and your distribution/hosting channel.
• Because the source data records no vendor fix or version list, confirm the actual fixed release directly with the plugin maintainer before relying on the upgrade for closure.

3. Long-term hardening

• Enforce server-side URL validation patterns in any custom or third-party import code: allow-list schemes (HTTPS only), resolve and block private/loopback/link-local IP ranges, and re-validate after redirects.
• Adopt network egress policy for all web application hosts, especially in cloud environments where instance metadata is reachable.
• Apply least privilege to WordPress roles and integrate administrator access with centralized identity and MFA where possible.
• Continuously inventory third-party plugins and track their fixed versions; subscribe to the NVD entry for CVE-2026-16542 for patch publication.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-16542
• WordPress Plugin Directory (product page for "Import and export users and customers"): https://wordpress.org/plugins/import-users-from-csv-with-meta/
• FIRST EPSS (not yet scored): https://www.first.org/epss/
• CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• OWASP SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

No threat actor campaigns or exploit-in-the-wild evidence have been identified for this CVE. CISA KEV does not list CVE-2026-16542, and no public PoC, exploit code, or Nuclei template is available at time of publication. Detection content above is derived from the vulnerability class and the description provided; it should be tuned to the deployed plugin version, request parameter naming, and web server log format.