Overview
CVE-2026-62071 is a critical, unauthenticated SQL injection vulnerability (CVSS 9.3) in WordPress File Upload (also distributed as "Iptanus File Upload", plugin slug wp-file-upload), affecting all versions ≤ 5.1.10. The flaw requires no authentication, no user interaction, and is reachable over the network — the combination that puts it at the top of the patch queue for any site running the plugin. It is fixed in version 5.2.0, released by the vendor in the days before this advisory was published.
Technical Details
| Field | Value |
|---|---|
| CVE ID | CVE-2026-62071 |
| Severity | Critical (9.3 / CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L) |
| CWE | CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') |
| Attack Vector | Network, unauthenticated, low attack complexity, no privileges or user interaction required |
| Affected Version | WordPress File Upload (nickboss / Iptanus) ≤ 5.1.10 |
| Fix Status | Patched in version 5.2.0 |
Exploitation status: Not currently listed in CISA's Known Exploited Vulnerabilities catalog, and no confirmed in-the-wild exploitation has been reported as of publication. That said, the plugin has roughly 10,000 active installations per the WordPress.org directory, and the vulnerability's unauthenticated, network-reachable nature makes it an attractive target for mass automated scanning once a working proof-of-concept circulates — the pattern seen with this plugin's two earlier 2026 SQL injection disclosures.
How It Works
The vendor's own changelog for the fixing release (5.2.0) describes the patch as having "fixed an SQL injection security issue reported through Patchstack, affecting an upload identifier that was not fully sanitized." That confirms the root cause class (CWE-89, unparameterized use of a client-supplied value in a SQL statement) and the general area of the plugin (an upload-identifier value, of the kind passed to the plugin's AJAX handlers to track or query an individual upload), but the specific endpoint, parameter name, and exact query context have not been published by the researcher or Patchstack at the time of writing.
This is notable because it is the third disclosed SQL injection in this plugin during 2026 tied to the same general weakness: both CVE-2026-17044 ("WordPress File Upload ≤ 5.1.7 — Unauthenticated SQL Injection via uniqueuploadid") and CVE-2026-66447 (≤ 5.1.7, also CVSS 9.3) were fixed in version 5.1.8 and involved an insufficiently sanitized upload-identifier parameter reaching a SQL query. CVE-2026-62071 affecting versions through 5.1.10 — two releases after that fix — strongly suggests the 5.1.8 patch was incomplete rather than a wholly unrelated bug, though the vendor has not published a root-cause comparison confirming that link.
In general terms, unauthenticated SQL injection in a WordPress upload-tracking parameter typically works by the plugin accepting an identifier (often a GUID-like string) from an unauthenticated AJAX request, then concatenating it directly into a SELECT, UPDATE, or DELETE statement against the plugin's own tracking tables without using prepared statements or $wpdb->prepare(). Because the WordPress database user is frequently granted broad privileges across the whole wp_ schema (not just the plugin's own tables), a successful injection can typically read far beyond the plugin's own data — most importantly wp_users (password hashes, emails) and wp_usermeta (session tokens, capability data).
Impact Assessment
Who Is At Risk
- Any WordPress site with the WordPress File Upload / Iptanus File Upload plugin active at version 5.1.10 or earlier.
- Sites are at risk regardless of who can log in — the vulnerability requires no authentication, so public-facing sites with the plugin's upload forms or AJAX endpoints exposed (the plugin's normal operating mode) are directly exploitable from the internet.
- Risk is compounded for sites that skipped the 5.1.8 update (which closed the two earlier 2026 SQLi flaws in the same plugin) — those sites are exposed to three stacked unauthenticated SQLi issues at once.
Potential Attack Chains
- Database extraction — An attacker sends a crafted request containing a malicious upload-identifier value to the vulnerable AJAX action, using UNION-based or boolean/time-based blind techniques to extract
wp_userspassword hashes and email addresses without any prior access. - Credential reuse / account takeover — Extracted password hashes are cracked offline or reused directly (if WordPress session tokens or API keys are also exposed via
wp_usermeta), giving the attacker an administrator session. - Escalation to code execution — Where the database account backing WordPress has write privileges and the driver permits it, the same injection point could be abused for stacked
INSERT/UPDATEqueries — for example planting a rogue administrator user or a malicious option value — followed by use of the File Upload plugin's own legitimate upload functionality (or other plugins) to drop a web shell, converting the SQLi into full remote code execution. - Chaining with plugin history — This plugin has a documented history of arbitrary file upload, path traversal, and a prior critical RCE (CVE-2024-8856, CVSS 9.8), so an attacker who gains partial access via SQLi has other known weaknesses in the same codebase to pivot toward full compromise on unpatched installs.
Mitigation
Immediate Actions
- Update WordPress File Upload to version 5.2.0 or later immediately. Verify the installed version from Plugins → Installed Plugins rather than trusting cached dashboard state.
- If immediate patching is not possible, deactivate the plugin until it can be updated, since the vulnerability requires no authentication to reach.
- Rotate WordPress administrator passwords and any API keys/secrets stored in the database, and audit the
wp_userstable for unexpected administrator accounts created after the plugin was installed. - Review the uploads directory and recently modified files for unexpected PHP files or web shells, given this plugin's history of file-upload-related flaws.
Detection Opportunities
- Search web server access logs for requests to
/wp-admin/admin-ajax.phpreferencing this plugin's actions (commonly prefixedwfu_) that contain SQL metacharacters,UNION SELECT,SLEEP(, or boolean-injection patterns likeOR 1=1. - Review database slow-query or general logs for anomalous queries touching
wp_users/wp_usermetathat originate from the plugin's query patterns rather than core WordPress code. - Watch for new WAF/IDS signatures from Wordfence, Patchstack, or your hosting provider — once a proof-of-concept becomes public, signature coverage typically follows quickly given this CVE's severity.
Defence-in-Depth
- Run the WordPress database user with the minimum privileges necessary; disabling multi-statement execution and restricting write access where feasible limits how far a SQLi can be escalated.
- Deploy a WordPress-aware WAF (e.g., Wordfence or Patchstack's firewall) capable of virtual-patching known plugin CVEs ahead of a manual update cycle.
- Given this plugin's recurring SQL injection history (three unauthenticated SQLi CVEs in 2026 alone), treat it as a priority candidate for automatic minor-version updates rather than manual, calendar-based patching.
Background
WordPress File Upload (slug wp-file-upload, also marketed as "Iptanus File Upload", developed by nickboss) is installed on roughly 10,000 active WordPress sites according to the WordPress.org plugin directory. WPScan's vulnerability database lists over 30 historical security issues for this plugin, including a critical unauthenticated remote code execution flaw (CVE-2024-8856, CVSS 9.8), arbitrary file read via path traversal (CVE-2024-9047), and stored XSS (CVE-2024-6494).
2026 has been a particularly rough year for the plugin's SQL injection surface specifically: CVE-2026-17044 and CVE-2026-66447 — both tied to an unsanitized uniqueuploadid-style parameter — were patched in version 5.1.8, only for CVE-2026-62071 to surface against versions through 5.1.10 and require a further fix in 5.2.0. The vendor's own changelog language for 5.2.0 ("an upload identifier that was not fully sanitized") closely mirrors the description of the earlier fixes, suggesting the underlying sanitization gap in this code path has been patched incompletely more than once. The vulnerability was reported through Patchstack's bug bounty program by researcher Andy Urlep.