Urgent Security Advisory: Cloudflare Image Resizing (cf-image-resizing) <= 1.5.6 — Unauthenticated RCE via rest_pre_dispatch (CVE-2025-8723)

Date: 18 August 2025
Severity: Critical (CVSS 10.0) — Remote Code Execution (RCE)
Affected plugin: Cloudflare Image Resizing (plugin slug: cf-image-resizing)
Vulnerable versions: <= 1.5.6
Fixed in: 1.5.7
CVE: CVE-2025-8723

Summary (Hong Kong security expert perspective)

This is a critical, unauthenticated remote code execution vulnerability in the Cloudflare Image Resizing WordPress plugin (versions ≤ 1.5.6) that abuses the WordPress REST API pre-dispatch hook (rest_pre_dispatch) without proper authentication. The vulnerability was assigned CVE-2025-8723 and is fixed in version 1.5.7. Treat this as an emergency — attackers are likely to automate exploitation attempts. If you manage sites in Hong Kong or the APAC region, act immediately to patch or contain the risk and perform forensic checks if there is any sign of unusual activity.

Executive summary

An attacker can trigger unauthenticated code paths via rest_pre_dispatch that lead to execution of attacker-supplied input or inclusion of unsafe content, enabling full RCE on vulnerable sites. Consequences include site takeover, backdoors, data theft, spam/SEO blacklist, and potential lateral movement on shared hosting. Update to 1.5.7 immediately. If immediate patching is not possible, apply server-level restrictions or virtual patching and conduct incident response steps below.

What went wrong (technical background)

• The plugin hooks into rest_pre_dispatch, which runs early in REST request handling and can short-circuit normal routing.
• In affected versions, code reachable from that hook accepted unauthenticated input and executed logic without verifying authenticity or capability, enabling RCE.
• The root cause: missing authentication/authorization checks combined with unsafe handling of user-controlled input in an execution context on the server.

Because rest_pre_dispatch executes before standard REST authentication, failing to validate requests allows unauthenticated access to privileged operations. Exploitation requires only an HTTP request to the REST endpoint(s) targeted by the plugin.

Impact

• Full site compromise (RCE → backdoor → admin creation → data theft).
• Potential server-level access if the PHP process and host allow privilege escalation.
• Data exfiltration, content defacement, spam distribution, cryptomining, or botnet/carrier activity.
• Search engine blacklisting and reputational damage.

Given the unauthenticated nature and CVSS 10.0, rapid automated scans and exploitation can be expected.

Immediate actions (what to do right now)

1. Update the plugin to 1.5.7 or later immediately.
   From WP Admin: Plugins → Installed Plugins → Update Cloudflare Image Resizing.
   Or via WP-CLI:

   wp plugin list --format=table
   wp plugin update cf-image-resizing

2. If you cannot update immediately, block access to the plugin’s REST endpoints at the server or WAF layer. Deny or restrict traffic to /wp-json/… paths for the plugin and block suspicious payloads.
3. If you suspect exploitation:
   • Place the site into maintenance mode or block external traffic temporarily.
   • Create a full file and database backup, preserve logs (write-protected).
   • Rotate WordPress admin passwords, database credentials, hosting control panel passwords, and any API keys or SSH keys potentially exposed.
   • Search for indicators of compromise (IoCs) — see Detection section.
4. Disable the plugin temporarily if you cannot apply a reliable virtual patch:

   wp plugin deactivate cf-image-resizing

   Note: this may affect image resizing functionality if you rely on the plugin.

5. Increase monitoring — watch webserver access logs, error logs, and any WAF or IDS alerts for spikes or suspicious requests.

WAF / virtual patching guidance

If patching is delayed for testing or maintenance, use virtual patching as an emergency measure. The goal is to block unauthenticated requests to the plugin namespace and to detect/deny payloads consistent with RCE (encoded PHP, PHP wrappers, suspicious function names).

Apply a layered approach:

• Block REST API requests targeting the plugin namespace or endpoints.
• Block payload patterns commonly used for RCE (base64-encoded PHP, php://, system(, exec(, backticks, serialized PHP with unexpected class names).
• Restrict access to sensitive REST paths at server-level (nginx/Apache) to trusted IPs if feasible.

ModSecurity example (illustrative)

SecRule REQUEST_URI "@beginsWith /wp-json/cf-image-resizing" "id:100001,phase:1,deny,log,status:403,msg:'Blocked suspicious REST request to cf-image-resizing',severity:2"
SecRule REQUEST_URI "@beginsWith /wp-json" "chain,phase:1,deny,log,status:403,msg:'Block unauthenticated POST to REST API with suspicious body'"
    SecRule REQUEST_METHOD "POST"
    SecRule REQUEST_HEADERS:Content-Type "application/json" "chain"
        SecRule ARGS_NAMES|REQUEST_BODY "(?:system\(|exec\(|passthru\(|popen\(|`.*`|base64_decode\(|php://input|gzinflate\()" "t:none,deny,log,status:403,msg:'Possible RCE payload in REST request'"

Nginx snippet — restrict plugin REST endpoint

location ~* ^/wp-json/cf-image-resizing/ {
    return 403;
}

Or allow only trusted IP ranges:

location ~* ^/wp-json/cf-image-resizing/ {
    allow 203.0.113.0/24;
    allow 198.51.100.17;
    deny all;
}

Apache (.htaccess) — deny access to plugin REST path

<If "%{REQUEST_URI} =~ m#^/wp-json/cf-image-resizing/#">
    Require all denied
</If>

WordPress-level filter (temporary mu-plugin)

Create wp-content/mu-plugins/block-cf-rest.php to deny unauthenticated access to the plugin namespace:

<?php
add_filter('rest_authentication_errors', function($result) {
    if ( ! empty($result) ) {
        return $result;
    }

    $request = rest_get_server()->get_request();
    $route = $request->get_route();

    if (strpos($route, '/cf-image-resizing/') === 0) {
        return new WP_Error('rest_forbidden', 'Access to this endpoint is temporarily disabled', array('status' => 403));
    }

    return $result;
}, 90);

Remove this temporary filter after updating the plugin and verifying site functionality.

Detection: indicators of compromise (IoCs) and log patterns

Look for these signs that may indicate exploitation:

• Requests to /wp-json/cf-image-resizing/* from unusual IPs or a large number of distinct IPs in short timeframes.
• POST requests with JSON bodies containing encoded/obfuscated payloads (base64, gzinflate, php://input).
• New or modified PHP files in writable directories (uploads, wp-content/uploads, wp-includes, plugins) — files masquerading as media but containing PHP code.
• Unauthorized admin user creation.
• New cron jobs or unexpected scheduled tasks.
• Outbound connections from the webserver to suspicious IPs or domains.
• Elevated error logs showing eval(), include() with unexpected paths, or traces of shell commands.

Suggested log queries

# find REST hits to plugin path in last 7 days
zgrep "/wp-json/cf-image-resizing" /var/log/nginx/access.log* | tail -n 200

# search for base64 strings or php wrappers in request bodies
zgrep -E "base64_decode|gzinflate|php://input|system\(|exec\(|passthru\(" /var/log/nginx/access.log*

# check for modified files in uploads in the last 14 days
find wp-content/uploads -type f -mtime -14 -print

# list recently modified files across site
find . -type f -mtime -14 -not -path "./.git/*" -print

# WP-CLI: admin users created recently
wp user list --role=administrator --fields=ID,user_registered,user_email,user_login --format=csv | awk -F, '$2 > "2025-08-01" {print}'

# search for webshell signatures
grep -R --exclude-dir=vendor -nE "eval\(|assert\(|base64_decode\(" .

Forensic checklist (if you suspect compromise)

1. Preserve evidence: snapshot disk and database, preserve full logs (write-protected copies).
2. Isolate the site: take offline or block untrusted traffic.
3. Identify scope: which files and users were changed; timeline of activity.
4. Remove backdoors and malicious files: inspect and remove webshells and unknown PHP files.
5. Rotate credentials: WordPress admin, database, hosting control panel, SSH keys, API tokens.
6. Scan and clean: use multiple tools and manual verification.
7. Restore from known-good backup if necessary.
8. Apply patch (1.5.7+), harden the environment, and monitor for recurrence.
9. Follow legal/regulatory disclosure procedures if sensitive data was exposed.

If you lack in-house incident response capability, engage a trusted security professional immediately — time is critical.

Hardening recommendations (post-update)

• Keep WordPress core, themes, and plugins updated. Enable automatic minor updates and schedule controlled maintenance for major changes.
• Limit plugin installations to trusted, actively maintained plugins. Remove unused plugins and themes.
• Restrict filesystem permissions — avoid broad write permissions for the web server user.
• Limit REST API access: block endpoints that do not need to be public.
• Implement least-privilege for WordPress users; avoid daily use of the administrator account.
• Maintain monitoring and incident detection (log aggregation, alerts for suspicious activity).
• Regularly back up code and database and test restoration procedures.

Recommended mitigation approach (typical response)

Adopt a layered defence strategy:

• Emergency containment: update plugin or apply server-level deny rules for the vulnerable REST paths.
• Virtual patching: temporary WAF or server rules to block exploitation patterns.
• Detection and cleanup: scan for webshells, remove backdoors, rotate credentials.
• Post-incident hardening: permissions, monitoring, restricted REST exposure.

Threat hunting & monitoring rules to add now

• Alert on POST requests to /wp-json/cf-image-resizing/ with bodies containing base64_decode, eval, gzinflate, php://input, <?php, system(, exec(.
• Flag new admin user creation outside scheduled change windows.
• Correlate spikes of 403/5xx responses on REST endpoints — often seen during scanning/exploitation.
• Watch for new PHP files in wp-content/uploads or files with double extensions (e.g., image.jpg.php).
• Monitor outgoing connections from the web server to new external IPs and domains.

Recovery & post-incident actions

1. Restore from a clean backup or fully clean the site and host.
2. Replace any compromised credentials (DB, WordPress, hosting, API keys).
3. Patch the plugin to 1.5.7 or later.
4. Perform comprehensive scans across the environment: containers, host OS, cron jobs, and database for backdoors.
5. Reissue TLS certificates if private keys may have been exposed.
6. Notify hosting provider and affected parties per local compliance requirements.
7. Improve monitoring and protections to detect re-infection attempts.

Quick detection commands and checks

# Check plugin version
wp plugin status cf-image-resizing --field=version

# Deactivate plugin quickly
wp plugin deactivate cf-image-resizing

# List files modified in last 7 days
find . -type f -mtime -7 -print

# Check for webshells in uploads
grep -R --exclude-dir=plugin-folder -nE "<?php|eval\(|base64_decode\(" wp-content/uploads || true

# List admin users
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

FAQ

Q: I updated to 1.5.7 — am I safe?
A: Updating to 1.5.7 fixes the underlying vulnerability. However, if your site was already compromised prior to the update, backdoors and unauthorized changes may persist. Follow the forensic checklist and scan the site.

Q: What if I can’t update (custom code dependency)?
A: Apply virtual patching (server/WAF rules) to block access to the plugin’s REST endpoints or deactivate the plugin temporarily while you test and plan an update.

Q: Will blocking REST requests break legitimate image functionality?
A: Aggressive blocking can impact legitimate functionality. Aim to block unauthenticated calls to plugin-specific REST paths and clearly test rules in detection-only mode before full blocking when possible.

Final checklist (copyable)

• [ ] Immediately update cf-image-resizing to 1.5.7 (or later).
• [ ] If update not possible, apply server-level or WAF rules to block /wp-json/cf-image-resizing/ and suspicious payloads.
• [ ] Check logs for REST API hits and suspicious request bodies.
• [ ] Search for newly created admin users, modified files, and unexpected cron jobs.
• [ ] Backup and preserve evidence if compromise is suspected.
• [ ] Rotate credentials and harden your environment.
• [ ] Implement monitoring and detection rules to spot re-infection attempts.

If you need assistance implementing these containment measures, performing forensic checks, or conducting recovery, engage a qualified incident response or security professional immediately. In Hong Kong and the wider APAC region, timely containment and evidence preservation are essential to limit damage and meet regulatory obligations.

Stay vigilant — patch now and verify your environment.