CVE-2026-13001: Podlove Podcast Publisher RCE Vulnerability

CVE-2026-13001 Overview

CVE-2026-13001 is an arbitrary file upload vulnerability in the Podlove Podcast Publisher plugin for WordPress. The flaw affects all versions up to and including 4.5.1. It resides in the podlove_handle_cache_files function, which fails to validate uploaded file types before writing them to the server's cache directory.

Unauthenticated attackers can upload arbitrary files to the affected site, which can lead to remote code execution (RCE). The issue is categorized as improper input validation [CWE-20] and stems from image cache extension confusion in the plugin's caching helper functions.

Critical Impact
Unauthenticated remote attackers can upload arbitrary files and potentially execute code on WordPress sites running the Podlove Podcast Publisher plugin version 4.5.1 or earlier.

Affected Products

Podlove Podcast Publisher plugin for WordPress — all versions through 4.5.1
WordPress sites with the plugin active and reachable over the network
Cached podcast media assets served from the plugin's cache/podlove/ directory

Discovery Timeline

2026-07-14 - CVE-2026-13001 published to the National Vulnerability Database (NVD)
2026-07-14 - Last updated in NVD database

Technical Details for CVE-2026-13001

Vulnerability Analysis

The vulnerability lives in the plugin's image handling and cache pipeline. The podlove_handle_cache_files function accepts remote files for local caching without verifying the MIME type or true image content. Because the plugin trusts filename extensions and does not confirm the file is an actual image, attackers can supply files with executable payloads disguised as images.

Once cached, files land inside a web-accessible directory under content_url('cache/podlove/'). If the server executes PHP within that path — or if the file extension is later resolved to an executable handler — an attacker can achieve remote code execution. The exploit requires no authentication and no user interaction.

Root Cause

The root cause is missing file type validation in the is_image() helper defined in lib/helper.php. The pre-patch function returned true based on partial checks and did not reject files whose MIME type failed to begin with image. Combined with attacker-controlled extensions in the cached filename, this produced an extension confusion condition tracked as [CWE-20].

Attack Vector

An unauthenticated attacker sends a network request that triggers the plugin's cache routine against an attacker-controlled URL. The plugin downloads the file, skips proper content validation, and stores it under the cache directory with an attacker-influenced extension. The attacker then requests the cached file directly, invoking the malicious payload on the server.

php

// Security patch in lib/helper.php
// fix: prevent RCE via image cache extension confusion

-function is_image($file, $filename = '')
+function image_file_extension($file, $filename = '')
 {
     // simple PHP based checks
     $type = get_image_type($file);
     $mime = get_image_mime_type($type);
     $mime_is_image = substr($mime, 0, 5) == 'image';

+    if (!$mime_is_image) {
+        return false;
+    }
+
     // more checks using WP helpers
     if (!$filename) {
         $filename = basename($file);

Source: GitHub Commit 5b32468

The patch renames the helper and adds an early return when the detected MIME type is not an image, breaking the extension confusion chain in lib/model/image.php.

Detection Methods for CVE-2026-13001

Indicators of Compromise

Unexpected files with non-image extensions such as .php, .phtml, or .phar inside wp-content/cache/podlove/
HTTP requests to plugin cache endpoints originating from unauthenticated sources followed by direct GETs to newly created cache files
Web server processes spawning shells or outbound connections after requests to /wp-content/cache/podlove/ paths
New administrative WordPress users or modified wp-config.php timestamps following plugin cache activity

Detection Strategies

Inventory WordPress sites and identify installations of podlove-podcasting-plugin-for-wordpress at version 4.5.1 or earlier
Alert on file writes to the plugin cache directory where the file extension does not match a known image type (.jpg, .jpeg, .png, .gif, .webp)
Correlate web access logs for POST requests hitting Podlove cache endpoints followed by GET requests to the newly created files

Monitoring Recommendations

Enable file integrity monitoring on wp-content/plugins/podlove-podcasting-plugin-for-wordpress/ and wp-content/cache/podlove/
Ship WordPress and web server logs to a centralized SIEM or data lake for retention and correlation
Monitor PHP-FPM and web server child processes for anomalous command execution originating from cache paths

How to Mitigate CVE-2026-13001

Immediate Actions Required

Update the Podlove Podcast Publisher plugin to the version containing the fix in changeset 3597461 (post-4.5.1 release)
If patching is not immediately possible, deactivate and remove the plugin until the update can be applied
Audit the wp-content/cache/podlove/ directory for suspicious files and remove any that are not valid images
Rotate WordPress administrator credentials and review installed plugins, themes, and users for unauthorized changes

Patch Information

The maintainers addressed the issue in WordPress Plugin Changeset 3597461 and GitHub Commit 5b32468. The patch replaces the boolean is_image() helper with image_file_extension(), enforces a MIME type check, and calls load_cached_file_extension() when constructing cached image models. Additional context is available in the Wordfence Vulnerability Report and the pre-patch code in the WordPress Plugin Code Review.

Workarounds

Configure the web server to deny execution of PHP inside wp-content/cache/podlove/ and other upload paths
Restrict access to the plugin's cache endpoints at the WAF or reverse proxy layer until patching is complete
Enforce strict MIME type allowlists on any upload directory served under wp-content/

bash

# Apache: block PHP execution inside the Podlove cache directory
# Place in wp-content/cache/podlove/.htaccess
<FilesMatch "\.(php|phtml|phar|php[0-9]+)$">
    Require all denied
</FilesMatch>

# Nginx equivalent (server or location block)
location ~* ^/wp-content/cache/podlove/.*\.(php|phtml|phar|php[0-9]+)$ {
    deny all;
    return 403;
}