WordPress file upload flaws enable repeated remote code execution

At a glance

What this is: TXOne Networks says WordPress upload-handling plugin weaknesses are being exploited persistently, with arbitrary file upload leading to remote code execution.

Why it matters: This matters because upload paths often sit outside identity governance reviews, yet they can become the easiest route from a public web form to system-level compromise.

By the numbers:

• Gravity Forms core was affected up to and including version 2.9.20, with a CVSS v3.1 score of 9.8.
• Exploit attempts have been detected consistently since August 2024.

Context

WordPress plugin ecosystems expand functionality, but they also expand the attack surface whenever file upload handling is weak. In practice, arbitrary file upload flaws are especially dangerous because they can move directly from a user-controlled form to server-side code execution when validation is incomplete or bypassable. This is a web application security problem with downstream identity and access implications when the compromised server is then used to pivot into adjacent systems.

The article is about a specific exploitation pattern, not a one-off defect. The repeated targeting of upload endpoints shows that attackers reuse working paths long after disclosure, so patch state, execution controls, and detection around upload traffic matter as much as initial vulnerability discovery.

Key questions

Q: What breaks when a web application lets uploaded files execute on the server?

A: The application turns a normal content workflow into an execution path. If the server stores untrusted uploads in a web-accessible directory and allows script execution there, an attacker can move from a file upload to remote code execution without needing a separate authentication bypass. That is why upload handling must be controlled as a code-execution boundary, not just a data-input feature.

Q: Why do upload-handling vulnerabilities keep getting exploited after disclosure?

A: Because many internet-facing sites patch slowly, miss vulnerable plugins in inventory, or leave execution permissions unchanged after remediation. Attackers can reuse the same request shape and payload against every unpatched instance, so disclosure does not end the risk. Persistent exploitation is usually a sign of weak lifecycle governance around plugins, patch SLAs, and server configuration.

Q: What are the signs that a file upload exploit is under way?

A: Look for multipart requests to upload endpoints, directory traversal strings, unusual executable extensions such as .phtml, and tiny payloads that resemble webshells rather than normal user content. A sudden burst of similar requests from multiple regions is another strong indicator that the same exploit pattern is being reused at scale.

Q: Should organisations prioritise patching upload flaws before broader hardening work?

A: Yes, when the upload flaw is internet-facing and can lead to remote code execution. Those vulnerabilities create an immediate compromise path that can outweigh lower-severity issues elsewhere in the stack. Patch first, then verify that the affected endpoint is no longer reachable, execution is blocked in upload locations, and detections are in place for repeat attempts.

Technical breakdown

How upload endpoints become code execution paths

File upload workflows become dangerous when the server trusts client-supplied filenames, MIME types, or extensions without validating content and storage handling. In this case, the attack path centres on a multipart/form-data request that delivers a crafted payload to an upload endpoint, often disguised as an image but containing executable code. If the application stores that file in a web-accessible location and the server allows script execution there, the uploaded object can be invoked as code. Practical implication: treat upload handling as an execution boundary, not a convenience feature. See the File Upload Security Guide.

Practical implication: Lock down upload directories so untrusted files cannot execute as server-side code.

Why recurring exploitation persists after disclosure

Publicly known upload flaws remain attractive because many exposed sites patch slowly, misconfigure servers, or leave vulnerable plugins active across long-lived deployments. Attackers do not need novelty when the same endpoint, same request shape, and same malformed file still work against unpatched versions. The article’s telemetry also shows recurring activity over time, which is typical of opportunistic exploitation against internet-facing CMS plugins. Practical implication: vulnerability management must include plugin inventories, version enforcement, and exposure-aware prioritisation. See the Vulnerability Management Guide.

Practical implication: Track plugin versions continuously and prioritise internet-facing upload flaws for immediate remediation.

What detection should look for in upload abuse

Detection should focus on the request and payload characteristics that distinguish benign uploads from exploit attempts. That includes suspicious gf_page=upload targeting, multipart bodies carrying directory traversal sequences, unusual .phtml extensions, and small webshell-sized payloads that do not match normal user content. Security teams should also look for sudden spikes from geographically diverse sources, because mass exploitation campaigns often reuse the same payload pattern across many targets. Practical implication: tune web and network detections to the upload workflow, not just generic malware signatures. See the Web Application Security Testing Guide.

Practical implication: Correlate request patterns, file types, and payload size to flag exploit attempts early.

Threat narrative

Attacker objective: The attacker wants remote code execution on an exposed WordPress server by turning file upload handling into an execution path.

1. Entry occurs through a crafted multipart/form-data request to the vulnerable WordPress upload endpoint.
2. The attacker places a malicious file that bypasses weak validation and is stored where it can be interpreted as code.
3. Execution follows when the uploaded payload is invoked, giving the attacker remote code execution on the server.
4. Impact is server compromise and the ability to extend access beyond the original upload workflow.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Persistent file upload abuse is a governance problem, not just a patching problem. The article shows that attackers keep returning to the same upload endpoints because many environments leave a working execution path in place after disclosure. That means the real failure is lifecycle control over plugins, upload directories, and exposed content workflows, not only missing a single update. Practitioners should treat internet-facing upload paths as governed attack surfaces.

Upload validation fails when the server accepts user-controlled content as if it were data, not code. A file upload control that checks extension but not content, storage location, and execution rights still leaves a direct route from web form to RCE. File Upload Security Guide is the relevant control baseline here because the weakness is architectural, not cosmetic. Practitioners should harden the entire upload chain, not one validation step.

Standing exposure on CMS plugins creates a long-tail compromise window. The article’s repeated exploitation telemetry shows that once a vulnerable plugin is installed on a public site, the attack remains viable for months unless inventory, patching, and server-side restrictions are coordinated. That is a strong example of security debt in web platforms: the exploit persists because governance is fragmented across application owners, platform teams, and operations. Practitioners should collapse those ownership gaps before attackers do.

Operational resilience depends on assuming exploit traffic will recur, not disappear. The diverse source regions and periodic spikes described in the article point to campaign-style scanning rather than a single threat actor. That shifts the programme question from whether an exploit will be seen to whether detections, patch SLAs, and containment controls are already tuned for repeat attempts. Practitioners should build for recurring abuse, not isolated incident handling.

What this signals

Upload workflow security is a distinct control domain: organisations often secure authentication and admin access while leaving file transfer paths under-governed. In WordPress-style environments, the control boundary sits at content ingestion, storage placement, and execution rights, so the programme needs explicit ownership for those mechanics, not just general web app oversight.

Attackers use the same exploit shape repeatedly because it remains profitable against unpatched CMS instances. That means defensive maturity is less about discovering a new class of flaw and more about reducing the dwell time of known upload risks across the full plugin estate.

For practitioners

• Enforce immediate patch discipline for exposed upload plugins Remove or upgrade any internet-facing WordPress plugin that handles file uploads as soon as a critical upload flaw is disclosed, and verify versions across all environments, not just production.
• Disable script execution in upload directories Prevent PHP or other server-side code from executing in any directory that stores untrusted uploads, and confirm the restriction on every web tier and storage mount.
• Validate file content, not just file extensions Reject uploads that fail MIME checks, content inspection, or server-side allowlists, because extension-only checks are too easy to bypass with disguised webshells.
• Tune detection for exploit-shaped multipart requests Alert on multipart/form-data posts to upload endpoints that include directory traversal strings, suspicious .phtml files, or payload sizes that resemble lightweight webshells.
• Review exposure after patching Re-scan affected systems after remediation to confirm the vulnerable endpoint is gone, the plugin is updated, and no uploaded payloads remain executable.

Key takeaways

• The core issue is not only a plugin bug but a broken trust boundary between uploaded content and executable code.
• The article reports persistent exploitation attempts since August 2024 and a second critical Gravity Forms flaw that also leads to remote code execution.
• The most effective limiter is to combine rapid patching with upload-directory execution blocking and request-level detection for exploit-shaped multipart traffic.

Related NHI Mgmt Group resources: File Upload Security Guide · Vulnerability Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Web Application Security Testing Guide

Key terms

• Arbitrary File Upload: A vulnerability that lets an attacker submit a file the application should have rejected. When the server stores that file in a reachable location, the upload can become a stepping stone to code execution, data theft, or persistence rather than a harmless form submission.
• Multipart Form Data: Multipart form data is an HTTP request format used to send multiple fields, often including files, in a single submission. In security-sensitive parsers, each part can become an attack surface if the application treats field names, boundaries, or embedded references as trusted input during deserialisation.
• Remote Code Execution (RCE): Remote Code Execution (RCE) is a vulnerability or exploit condition that lets an attacker run commands or code on a target system from afar. It is often the end result of input handling flaws, deserialisation bugs or unsafe file processing, so defenders prioritise patching, isolation and least privilege.
• Web shell: A web shell is a script placed on a server that accepts commands over HTTP and executes them on demand. It creates persistent server-side access, which means defenders may remove the original exploit path while the attacker still retains a reusable foothold.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need a stronger identity security baseline. It helps security teams connect identity controls to the broader risk decisions their programmes depend on.