Post cover image

August 30, 2026

Attack and Security Series: Episode 6

When a File Upload Became Remote Code Execution 💀

By Saurabh Pandey

13 min read

When a File Upload Became Remote Code Execution 💀

Understanding PHP Internals Through CVE-2026–32475

Welcome back to the Attack and Security Series.

We've gone from:

DRAM → Bots → DNS → AI → Linux Kernel

And now we're coming back up the stack.

This time we're attacking something much closer to the application.

A website.

More specifically…

PHP.

And if you've ever built a PHP application, WordPress plugin, contact form, or file upload system, this episode is going to be VERY interesting.

Because today's vulnerability starts with something that looks completely harmless: "Please upload your resume."

😭

That's it.

A simple file upload.

But behind that tiny button is an entire chain:

Browser
   ↓
HTTP
   ↓
multipart/form-data
   ↓
Web Server
   ↓
PHP
   ↓
$_FILES
   ↓
WordPress
   ↓
Elementor Pro
   ↓
Validation
   ↓
File Movement
   ↓
Public Directory
   ↓
PHP Interpreter
   ↓
RCE

And somewhere in the middle…

Two pieces of code disagreed.

That disagreement became:

CVE-2026–32475

Let's go inside.

🧠 First Question

What actually happens when I upload a file?

Imagine this HTML:

<form method="POST" enctype="multipart/form-data">
    <input type="file" name="resume">
    <button type="submit">
        Upload
    </button>
</form>

You click:

Choose File
      ↓
resume.pdf
      ↓
Upload

You might think the browser simply sends:

resume.pdf

Nope.

The browser constructs an HTTP request.

Something roughly like:

POST /upload HTTP/1.1
Content-Type: multipart/form-data

And then the body contains multiple parts.

Conceptually:

POST
 │
 ▼
multipart/form-data
 │
 ├── field 1
 ├── field 2
 └── file
       │
       ├── filename
       ├── content-type
       └── binary data

This is important.

Because the vulnerability we're studying abuses something that exists inside this multipart structure.

🧩 What Is multipart/form-data?

Imagine sending a parcel.

Instead of throwing everything into one box:

BOX
└── EVERYTHING

you divide it into sections:

PACKAGE
│
├── SECTION 1
│     name = username
│     value = saurabh
│
├── SECTION 2
│     name = email
│     value = example@email.com
│
└── SECTION 3
      name = resume
      filename = resume.pdf
      data = ........

That's basically what multipart form data does.

The HTTP request has boundaries separating the parts.

------BOUNDARY
field
------BOUNDARY
another field
------BOUNDARY
file
------BOUNDARY--

PHP receives this request and parses it.

And then…

PHP creates something very familiar.

$_FILES

🐘 Welcome to PHP Internals

PHP gives uploaded files to the application through:

$_FILES

For example:

$_FILES['resume']

may contain information conceptually like:

name type tmp_name error size

Something like:

$_FILES['resume']
name     → resume.pdf
type     → application/pdf
tmp_name → /tmp/phpXXXXXX
error    → 0
size     → 123456

And this is where things get interesting.

Because PHP doesn't simply say: "Here's your file."

It gives the application metadata + a temporary file location + an error status.

🔥 The error Field

One of the most important values is:

$_FILES['resume']['error']

For a successful upload, PHP normally gives: UPLOAD_ERR_OK

which is: 0

But there are several possible upload errors.

For example:

UPLOAD_ERR_INI_SIZE
UPLOAD_ERR_FORM_SIZE
UPLOAD_ERR_PARTIAL
UPLOAD_ERR_NO_FILE
UPLOAD_ERR_NO_TMP_DIR
UPLOAD_ERR_CANT_WRITE
UPLOAD_ERR_EXTENSION

The one that matters for today's vulnerability is:

UPLOAD_ERR_NO_FILE

Meaning: There wasn't actually a file uploaded for this particular file input.

So conceptually:

File exists:

name = document.pdf
error = UPLOAD_ERR_OK

versus:

No file:

name = ""
error = UPLOAD_ERR_NO_FILE

And that tiny distinction became extremely important.

🧠 Now Let's Talk About PHP's Temporary File

When PHP receives an uploaded file, it doesn't normally put it directly into:

/var/www/html/

Instead, PHP first stores it in a temporary location.

Think:

Browser
   │
   ▼
HTTP Request
   │
   ▼
PHP
   │
   ▼
Temporary File
   │
   ▼
Application decides where to move it

For example:

/tmp/phpABC123

The application then decides: "Okay, this file is safe. Let's move it to the upload directory."

This separation is actually a good security design.

The problem occurs when the application makes a mistake while deciding whether the file is safe.

🏗️ WordPress Enters The Picture

Now let's add WordPress.

Our architecture becomes:

                INTERNET
                    │
                    ▼
                Web Server
                    │
                    ▼
                   PHP
                    │
                    ▼
               WordPress
                    │
                    ▼
             Elementor Pro
                    │
                    ▼
                Form
                    │
                    ▼
              File Upload

Elementor Pro provides a Forms module.

One of its fields is: File Upload

Perfect for:

Resume ID document Screenshot Support attachment Job application

Completely normal functionality.

And that's what makes vulnerabilities like this dangerous.

They hide inside normal functionality.

📁 What Does Elementor Want To Do?

Imagine the user uploads: resume.pdf

The plugin needs to answer two questions:

Question 1

Is this file allowed?

PDF? YES ✅

Question 2

Where should it be stored?

uploads/elementor/forms/

So conceptually:

             Uploaded File
                   │
          ┌────────┴────────┐
          ▼                 ▼
      Validation          Storage
          │                 │
          ▼                 ▼
       Allowed?         Move File
          │                 │
          └────────┬────────┘
                   ▼
               Final File

Looks perfectly reasonable.

Until we ask: Are those two operations guaranteed to agree about the same file?

💀 And Here Comes The Bug

Elementor Pro's vulnerable code handled uploaded files using two separate loops.

One loop was responsible for validation.

Another handled processing/moving the files.

Simplified:

foreach ($files as $file) {
    validate($file);
}

and later:

foreach ($files as $file) {
    move($file);
}

Again…

Nothing inherently wrong with having two loops.

The problem was:

They didn't treat an empty upload entry the same way.

And THAT is the vulnerability.

🧠 return vs continue

This is one of those tiny programming details that can destroy an entire security boundary.

Let's understand it properly.

Suppose:

foreach ($files as $file) {
    if ($empty) {
        return;
    }
    validate($file);
}

What does:

return;

do?

It exits the function.

Entire function.

Game over.

Now:

foreach ($files as $file) {
    if ($empty) {
        continue;
    }
    move($file);
}

What does:

continue;

do?

It skips this iteration.

Then the loop continues.

So:

return

means:

STOP EVERYTHING

while:

continue

means:

SKIP THIS ONE
NEXT

That difference looks tiny.

But in security…

Tiny differences can become enormous vulnerabilities.

🔥 The Desynchronization

Let's visualize it.

Suppose the submitted file list is conceptually:

FILE LIST

[0] Empty entry
[1] Another file

The validation loop sees:

[0]
 │
 ▼
EMPTY
 │
 ▼
return
 │
 ▼
STOP

So the validator never reaches:

[1]

But the processing loop sees:

[0]
 │
 ▼
EMPTY
 │
 ▼
continue
 │
 ▼
[1]
 │
 ▼
PROCESS

Now we have:

VALIDATOR                 PROCESSOR
[0] Empty                 [0] Empty
   │                         │
   ▼                         ▼
 return                    continue
   │                         │
   ▼                         ▼
 STOP                      [1]
                             │
                             ▼
                          process

And this is the heart of CVE-2026–32475.

The validator and processor have now developed two different realities.

👻 The Security Bug

The security assumption should have been:

IF file passes validation
        ↓
THEN process file

But because of the logic mismatch, we effectively get: Validation

File A
  ↓
STOP
File B
  ↓
NEVER VALIDATED

while:

Processing
File A
  ↓
SKIP
File B
  ↓
PROCESS

Therefore:

UNVALIDATED FILE
        ↓
       MOVED

And THAT is the security failure.

🧪 Why The PHP Extension Matters

Now let's talk about the dangerous part.

Elementor's validation logic correctly blocked dangerous extensions, including PHP-related extensions.

Conceptually:

Allowed?
   │
   ├── pdf  → YES
   ├── jpg  → YES
   ├── png  → YES
   │
   └── php  → NO ❌

The blocklist included PHP and other executable extensions.

Normally:

.php
 ↓
BLOCKED

Perfect.

But the vulnerability wasn't: "The PHP blocklist was wrong."

The blocklist was actually doing its job.

The problem was: The dangerous file could reach the processing stage without the validation stage examining it.

That's a much more interesting bug.

🤯 Think About It Like Airport Security

Imagine an airport.

Every passenger must pass through:

SECURITY CHECK
      ↓
Allowed?
      ↓
BOARD PLANE

Now imagine:

Passenger 1
   ↓
Security
   ↓
"I don't have luggage."
   ↓
Security closes entire process

But boarding says:

Passenger 1
   ↓
No luggage
   ↓
Skip
   ↓
Check Passenger 2
   ↓
BOARD

Passenger 2 never went through security.

Yet they still boarded.

That's exactly the kind of logic mismatch we're dealing with.

😂

The security guard isn't broken.

The boarding system is.

📂 Where Does The File Go?

The dangerous part gets worse.

The processing code places the uploaded file in Elementor's forms upload directory:

wp-content/uploads/elementor/forms/

The directory is web-accessible.

So the chain becomes:

Anonymous Visitor
       │
       ▼
Elementor Form
       │
       ▼
File Upload
       │
       ▼
Validation Bypass
       │
       ▼
PHP File Written
       │
       ▼
Public Directory
       │
       ▼
PHP Interpreter
       │
       ▼
Remote Code Execution

Patchstack describes this as an unauthenticated arbitrary file upload leading to RCE.

🐘 But Wait…

Why does a .php file actually execute?

This is where PHP architecture becomes really important.

A .php file sitting somewhere on disk isn't automatically executed.

There has to be a web server configuration that sends PHP requests to a PHP interpreter.

A simplified architecture looks like:

Browser
   │
   │ GET /something.php
   ▼
Web Server
   │
   │ "This is PHP"
   ▼
PHP Handler
   │
   ▼
PHP Interpreter
   │
   ▼
Execute PHP
   │
   ▼
HTTP Response

Historically this might involve:

Apache + mod_php

or:

Nginx
   ↓
PHP-FPM

Modern deployments commonly use PHP-FPM.

⚙️ PHP-FPM

FPM means:

FastCGI Process Manager

Don't let the name scare you.

Think of it as a group of PHP workers waiting for work.

                 NGINX
                   │
                   │ FastCGI
                   ▼
              ┌──────────┐
              │ PHP-FPM  │
              │ Workers  │
              └────┬─────┘
                   │
                   ▼
             PHP Interpreter

When someone requests a PHP resource:

GET /page.php

the web server can hand it to PHP-FPM.

PHP executes it.

Then the result goes back:

PHP
 ↓
HTML Response
 ↓
Web Server
 ↓
Browser

So if an attacker manages to place executable PHP in a web-accessible directory…

The file isn't merely stored.

It may become code the server executes.

That's the jump from:

File Upload

to: Remote Code Execution

💥 Upload Vulnerability vs RCE

This distinction is important.

A file upload vulnerability does NOT automatically mean RCE.

For RCE, several conditions can line up.

For example:

Arbitrary File Upload
        │
        ▼
Executable File Type
        │
        ▼
File Stored
        │
        ▼
Web Accessible
        │
        ▼
Server Executes File
        │
        ▼
       RCE

If one link breaks:

PHP execution disabled

then:

Upload
 ↓
PHP file
 ↓
No execution

Maybe you still have a serious file-upload vulnerability.

But not necessarily RCE.

This distinction is extremely important during vulnerability analysis.

🔬 Let's Zoom Into The WordPress Layer

Now our stack becomes:

                  Browser
                    │
                    ▼
                   HTTP
                    │
                    ▼
                 Web Server
                    │
                    ▼
                   PHP
                    │
                    ▼
                WordPress
                    │
                    ▼
              Elementor Pro
                    │
                    ▼
              Forms Module
                    │
                    ▼
              Upload Field
                    │
             ┌──────┴──────┐
             ▼             ▼
         Validation     Processing
             │             │
             │             ▼
             │          File Move
             │             │
             └──────X──────┘
                    │
                    ▼
              Public Uploads
                    │
                    ▼
               PHP Handler
                    │
                    ▼
                  RCE

That X is the important part.

The two paths weren't synchronized.

🧠 This Is Called A Desynchronization Bug

Patchstack describes the flaw as a desynchronization between the validation and processing logic.

And I really like this concept because you'll see it everywhere in security.

One component believes: "Everything is validated."

Another believes: "Everything here is ready to process."

But the two components don't agree.

That's dangerous.

You can see the same general class of thinking in:

Parser differentials Authentication inconsistencies Proxy confusion Request smuggling Validation bypasses Canonicalization bugs

Different technology.

Same fundamental idea: Two parts of the system interpret the same input differently.

🧨 The Filename Trick That Doesn't Work

Here's another important lesson.

You might immediately think:

shell.php.jpg

Classic upload bypass.

But in this case, Elementor discards the original filename and constructs its own destination name using the extension.

So something like:

shell.php.jpg

ends up being treated according to the final extension:

something.jpg

not:

shell.php.jpg

Patchstack specifically notes that double extensions and .htaccess tricks don't solve the vulnerability.

This teaches an important lesson:

Don't attack based on assumptions.

First understand the actual code path.

🧬 What About uniqid()?

Elementor generates the stored filename using PHP's:

uniqid()

conceptually:

uniqid() + "." + extension

So:

random-looking-string.php

appears.

But here's an interesting PHP lesson.

uniqid() should NOT be confused with cryptographically secure randomness.

It's primarily time-based.

That means: uniqid()

is not equivalent to: random_bytes()

or a cryptographically secure token generator.

This is another general security lesson: A value looking random does not mean it is random.

Patchstack also discusses how the filename could be recovered because of the time-based nature of uniqid(), including situations where form notification emails reveal the uploaded URL.

🧠 Let's Understand move_uploaded_file()

PHP provides:

move_uploaded_file()

This function is specifically designed for moving uploaded files from PHP's temporary upload location.

Conceptually:

/tmp/phpXXXX
      │
      │ move_uploaded_file()
      ▼
/uploads/document.pdf

This is normal.

But remember:

move_uploaded_file()

doesn't magically determine whether your business logic is secure.

You still need to validate:

Extension MIME Content Permissions Destination Execution Policy

before deciding what happens next.

A secure primitive can still be used inside insecure logic.

🛡️ How Should A Secure Upload System Work?

A better architecture looks like:

                 FILE UPLOAD
                      │
                      ▼
                Authentication
                      │
                      ▼
                 Authorization
                      │
                      ▼
                Size Validation
                      │
                      ▼
                Type Validation
                      │
                      ▼
              Content Validation
                      │
                      ▼
              Filename Generation
                      │
                      ▼
             Non-Public Storage
                      │
                      ▼
             Malware Scanning
                      │
                      ▼
               Store File

And most importantly:

UPLOADS
   │
   ▼
NON-EXECUTABLE DIRECTORY

Don't put user-controlled uploads somewhere where the web server can execute them as application code.

🔐 Defense Layer 1

Allowlist, Don't Blocklist

Bad philosophy:

Block:
.php
.php3
.phtml
.php5
...

Why?

Because executable formats can be complicated.

Better:

Allowed:

.pdf
.png
.jpg
.docx

Everything else: DENY

That's an allowlist.

🔐 Defense Layer 2

Don't Trust the Filename

The user says: resume.pdf

Doesn't mean the content is actually a PDF.

Treat:

filename MIME type extension content

as separate things.

A stronger upload pipeline checks the actual content and uses server-side generated names.

🔐 Defense Layer 3

Store Uploads Outside Executable Web Paths

This is HUGE.

Instead of:

/var/www/html/uploads/

where the server might execute PHP…

prefer an architecture where uploaded content isn't directly executable.

For example:

Application
    │
    ▼
Object Storage
    │
    ├── private
    └── controlled downloads

or configure the web server so uploaded directories cannot execute server-side scripts.

Then even if validation fails:

Attacker uploads PHP
        │
        ▼
File stored
        │
        ▼
PHP execution disabled
        │
        ▼
RCE chain breaks

That's defense in depth.

🔐 Defense Layer 4

Validate Again At The Sink

This is perhaps the biggest lesson from this vulnerability.

Don't assume: validation()

will always happen before: process_field()

If the dangerous operation is: MOVE FILE

then the final processing function should have its own security check.

Conceptually:

                 Upload
                    │
                    ▼
               Validation
                    │
                    ▼
              Business Logic
                    │
                    ▼
             FINAL CHECK 🔐
                    │
                    ▼
                 Move

That way even if an earlier validation layer is accidentally bypassed…

the sink still protects itself.

The patched Elementor version added an additional extension check directly in the processing path, according to Patchstack.

🚨 Defense Layer 5

Patch

Elementor Pro fixed the vulnerability in:

Version 4.2.2

The vulnerable versions are: 4.2.1 and earlier

and the vulnerability is tracked as: CVE-2026–32475

with CVSS: 9.0 — Critical

The patch was released on August 19, 2026.

If you're running Elementor Pro:

UPDATE
      ↓
4.2.2+

And don't stop there.

If the system was vulnerable before patching, investigate whether suspicious files were already uploaded.

🔎 Incident Response

If you're investigating a potentially affected system, look at:

wp-content/uploads/elementor/forms/

and investigate unexpected executable files.

Also review:

Web Server Logs
       │
       ▼
PHP Logs
       │
       ▼
WordPress Logs
       │
       ▼
Form Submission Activity
       │
       ▼
Suspicious Files

The question isn't only: "Did I patch?"

It's: "Was I already compromised before I patched?"

That's the difference between patch management and incident response.

🧠 Let's Reconstruct The Whole Attack Conceptually

Without turning this into a copy-paste exploit, the vulnerability chain looks like this:

             UNAUTHENTICATED USER
                      │
                      ▼
               Public Form
                      │
                      ▼
              Multipart Request
                      │
                      ▼
                 PHP $_FILES
                      │
                      ▼
             Elementor Upload
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
      Validator                Processor
          │                       │
      Empty entry               Empty entry
          │                       │
       return                 continue
          │                       │
          ▼                       ▼
        STOP                  Next file
                                  │
                                  ▼
                            File processed
                                  │
                                  ▼
                            PHP written
                                  │
                                  ▼
                       Public web directory
                                  │
                                  ▼
                            PHP execution
                                  │
                                  ▼
                                 RCE

That's the entire vulnerability in one picture.

🤯 And Look How Small The Actual Bug Is

This is my favorite part.

The entire disaster doesn't require: 10,000 lines of code

Sometimes the difference between secure and vulnerable code is something as small as: return

versus: continue

One means:

STOP THE FUNCTION

The other means:

SKIP THIS ITEM

When you're working with security-sensitive loops…

You better know exactly which one you mean.

😂

🧪 What This Teaches Us About Code Review

When reviewing upload code, don't just ask: "Does it check the extension?"

Ask: Where is the check?

Who calls it?
Can the check return early?
What happens to the next item?
Is processing using the same collection?
Does processing revalidate?
Where is the file written?
Can the destination execute code?
Who can reach the endpoint?
Is authentication required?
Is the uploaded content publicly accessible?

That's a much stronger security review.

🧠 The Real Vulnerability Wasn't "PHP Upload"

This is important.

People might summarize CVE-2026–32475 as: "Elementor lets users upload PHP."

That's technically describing the result.

But it doesn't teach you the vulnerability.

The deeper explanation is:

Two independent processing stages
             │
             ▼
Different handling of empty entries
             │
             ▼
Validation stops early
             │
             ▼
Processing continues
             │
             ▼
Unvalidated file reaches sink
             │
             ▼
Executable file written
             │
             ▼
RCE

That's the actual security lesson.

🧬 From PHP To RCE

Let's connect everything we learned.

BROWSER
                       │
                       ▼
                  HTTP POST
                       │
                       ▼
             multipart/form-data
                       │
                       ▼
                      PHP
                       │
                       ▼
                    $_FILES
                       │
                       ▼
                  WordPress
                       │
                       ▼
                Elementor Pro
                       │
                       ▼
                 Upload Field
                       │
                       ▼
                 Validation
                       │
                       X
             validation bypass
                       │
                       ▼
                  Processing
                       │
                       ▼
             move_uploaded_file()
                       │
                       ▼
             Public Upload Directory
                       │
                       ▼
                    Web Server
                       │
                       ▼
                  PHP-FPM
                       │
                       ▼
                PHP Interpreter
                       │
                       ▼
                      RCE

This is why security researchers don't stop at: "I found a file upload."

They ask: "What can this upload become?"

🏰 The Castle Analogy

Remember our AI episode?

We talked about trust boundaries.

Same thing here.

Imagine:

                    CASTLE
                      │
             ┌────────┴────────┐
             ▼                 ▼
          Security           Storage
           Guard               Room
             │                 │
             ▼                 ▼
         Validation          File
             │
             ▼
          Allowed?

The security guard says: "Everyone has been checked."

But the storage room says:"I'll take whoever comes through."

And the guard accidentally left halfway through.

That's the vulnerability.

The storage room doesn't know: Was this validated?

It simply processes the file.

That's why security checks need to be enforced at security-sensitive boundaries, not merely assumed to have happened somewhere earlier.

🐘 PHP Internals Cheat Sheet

If you're learning PHP for security, remember these:

$_FILES
    ↓
Uploaded file metadata
UPLOAD_ERR_OK
    ↓
Upload succeeded
UPLOAD_ERR_NO_FILE
    ↓
No file uploaded for that entry
tmp_name
    ↓
Temporary uploaded file
name
    ↓
Client-provided filename
type
    ↓
Client/request-reported MIME type
    ↓
Don't blindly trust it
size
    ↓
Reported upload size
move_uploaded_file()
    ↓
Move uploaded file to destination
PHP-FPM
    ↓
PHP process manager
PHP Interpreter
    ↓
Executes PHP code

And the most important one:

User Input
    ↓
NEVER TRUST

😂

⚔️ Attack vs Defense

Let's finish the episode with our usual battle map.

ATTACK                              DEFENSE
Unauthenticated form       →       Authentication where appropriate
Multipart manipulation     →       Robust request parsing
Validation bypass          →       Consistent validation logic
Dangerous extension        →       Strict allowlist
User-controlled filename   →       Server-generated filename
Executable upload          →       Non-executable storage
Public PHP file            →       Block script execution
Single validation layer    →       Validate again at sink
Old plugin version         →       Patch management
Existing compromise       →       File + log investigation

🚀 Final Lesson

This vulnerability taught me something I didn't expect.

I started thinking: "We're going to learn PHP file uploads."

But we ended up learning:

HTTP
 ↓
Multipart Parsing
 ↓
PHP Internals
 ↓
$_FILES
 ↓
WordPress
 ↓
Plugin Architecture
 ↓
Control Flow
 ↓
Validation
 ↓
File Handling
 ↓
Web Server
 ↓
PHP-FPM
 ↓
Code Execution

That's cybersecurity.

An attack rarely belongs to one technology.

A vulnerability can begin in: PHP

cross: WordPress

pass through: Elementor

reach: Filesystem

and finally become: Remote Code Execution

That's why I love looking at attacks as chains.

One bug.

Multiple layers.

One final impact.

👻 Attack and Security Series — Episode 6 Complete

Episode 1: RowHammer — When Memory Itself Becomes the Attack Surface

Episode 2: Bot Attacks — When Automation Becomes a Weapon

Episode 3: DNS Spoofing — When the Internet Lies About Where You're Going

Episode 4: AI Attack Surface — When the Model Is Only the Beginning

Episode 5: SCTPhantom — The 18-Year-Old Linux Kernel Ghost

Episode 6: Elementor Pro — When a File Upload Became Remote Code Execution

And the funny thing is…

The actual vulnerability wasn't some crazy cryptographic failure.

It wasn't quantum computing.

It wasn't AI.

It wasn't even some massive memory corruption bug.

It was basically: return

versus: continue

Two different interpretations of: "There is no file here."

And somewhere between those two interpretations…

the security boundary disappeared.

That's the part of cybersecurity I find scary.

Sometimes the biggest vulnerabilities are hiding inside the smallest lines of code.

🐘🐧💀

And that's exactly why we read the internals.