CVE-2026-3844 — Breeze Cache Unauthenticated Arbitrary File Upload to RCE Lab

Local-only Docker lab for reproducing and comparing CVE-2026-3844 behavior in the WordPress Breeze Cache plugin.

This repository demonstrates the vulnerable behavior in Breeze Cache 2.4.4 and compares it with the patched behavior in Breeze Cache 2.4.5. The lab uses two isolated WordPress services, one vulnerable and one patched, plus a local payload server inside the Docker network.

The proof of concept is intentionally least-harm: it does not use a webshell, does not expose a command parameter, does not start a reverse shell, and does not require reading files from inside the container. The proof is based on observable HTTP behavior from the host.

Executive Summary

CVE-2026-3844 affects the Breeze Cache plugin for WordPress up to and including version 2.4.4. The vulnerable code path is related to the plugin’s local Gravatar caching feature, specifically the fetch_gravatar_from_remote() flow.

When the Breeze option Host Files Locally - Gravatars is enabled, vulnerable versions can fetch an attacker-controlled remote file and store it under a public web-accessible cache directory. If the fetched file is PHP, the file may be executed by the web server when requested over HTTP.

This lab reproduces that behavior locally:

vuln service: WordPress + Breeze Cache 2.4.4
patched service: WordPress + Breeze Cache 2.4.5
payload service: local Docker-only payload server
PoC: unauthenticated comment-based trigger using a controlled srcset string

The expected result is:

http://127.0.0.1:8081 / Breeze 2.4.4 → proof PHP is cached and executed
http://127.0.0.1:8082 / Breeze 2.4.5 → proof PHP is not cached/readable/executable

Repository Structure

.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── scripts/
│   └── seed-wordpress.sh
├── payload/
│   └── manual-proof.php
│   └── proof-cve3844.php
├── poc/
│   └── poc.py
│   └── requirements.txt
├── .gitignore
├── README.md

Lab Architecture

Host machine
│
├── http://127.0.0.1:8081  -> vuln WordPress + Breeze 2.4.4
├── http://127.0.0.1:8082  -> patched WordPress + Breeze 2.4.5
└── http://127.0.0.1:9100  -> local payload server

Docker network
│
├── vuln       -> WordPress vulnerable target
├── patched    -> WordPress patched target
├── vuln_db    -> MariaDB for vulnerable WordPress
├── patched_db -> MariaDB for patched WordPress
└── payload    -> Python static HTTP server

The WordPress containers fetch the payload through the Docker network URL:

http://payload:9100/<payload-file>.php

The host verifies the result through normal HTTP requests to the WordPress services.

Affected Component

Product: Breeze Cache plugin for WordPress
Vulnerable version in this lab: 2.4.4
Patched version in this lab: 2.4.5
Vulnerable function: fetch_gravatar_from_remote()
Relevant file: inc/class-breeze-cache-cronjobs.php
Required precondition: breeze-store-gravatars-locally must be enabled

The vulnerable behavior is only reachable when local Gravatar caching is enabled. This option is disabled by default in typical installations, but this lab enables it intentionally to reproduce the vulnerable code path.

Root Cause Summary

In Breeze Cache 2.4.4, the Gravatar localization flow can extract a remote URL from avatar-related HTML and pass that URL into fetch_gravatar_from_remote().

The vulnerable version lacks sufficient validation around the remote file:

no strict trusted-host validation for Gravatar sources
no reliable file extension allowlist before saving
no MIME/content validation before placing the file into a public cache directory
fetched file may keep a dangerous extension such as .php

The resulting file is stored under:

/wp-content/cache/breeze-extra/gravatars/

When a PHP file is saved there and then requested through Apache/PHP, the server executes it.

In Breeze Cache 2.4.5, the patched flow adds validation that prevents this lab payload from being cached as executable PHP. In the local reproduction, the same trigger works against 2.4.4 but does not expose the proof marker against 2.4.5.

Why This Lab Uses a MU Plugin Helper

This lab intentionally keeps the payload server local instead of using a public payload host.

WordPress download_url() and the WordPress HTTP API reject some private Docker hostnames and non-standard ports by default. Public exploit scripts often use public HTTPS payload URLs, which avoid that restriction. This lab does not do that.

To keep the reproduction fully local, the seed script installs a small local-only MU plugin helper that:

allows only the local Docker payload hostnames payload and payload.local
allows only the lab ports 80 and 9100
auto-approves lab comments
disables comment flood checks for deterministic local testing

This helper does not modify Breeze source code. Both the vulnerable and patched services use real Breeze plugin versions installed through WP-CLI.

The helper exists only to make the Docker lab deterministic and local-only.

Safety Model

This repository is intended for local security research and portfolio demonstration only.

Guardrails:

runs only on localhost and Docker network services
no external callback server
no public exploit target
no reverse shell
no interactive shell
no cmd= webshell behavior
no secrets or real credentials
no container file reads for proof
proof is observed through HTTP response behavior

The PoC payload prints benign PHP runtime information:

CVE-2026-3844_LEAST_HARM_PHP_EXEC_PROOF_<nonce>
php_sapi=apache2handler
user=www-data
uid=33
pid=<process id>
host=<container hostname>

This proves code execution context without spawning shell commands.

Requirements

Docker Desktop or Docker Engine
Docker Compose v2
Python 3.9+
Python package: requests

Install Python dependency:

python3 -m venv .venv
source .venv/bin/activate
pip install -r poc/requirements.txt

requirements.txt should contain:

requests

Quick Start

Build and start the lab:

docker compose down -v --remove-orphans
docker compose up -d --build

Check service status:

docker compose ps

Expected services:

vuln        healthy    http://127.0.0.1:8081
patched     healthy    http://127.0.0.1:8082
payload     running    http://127.0.0.1:9100
vuln_db     healthy
patched_db  healthy

Check seed logs:

docker compose logs --tail=120 vuln
docker compose logs --tail=120 patched

Expected log lines:

[seed] WordPress ready at http://localhost:8081 with Breeze 2.4.4
[seed] WordPress ready at http://localhost:8082 with Breeze 2.4.5

Verify Lab Readiness

Check WordPress installation:

docker compose exec vuln wp core is-installed --allow-root --path=/var/www/html
docker compose exec patched wp core is-installed --allow-root --path=/var/www/html

Check Breeze versions:

docker compose exec vuln wp plugin get breeze --field=version --allow-root --path=/var/www/html
docker compose exec patched wp plugin get breeze --field=version --allow-root --path=/var/www/html

Expected:

2.4.4
2.4.5

Check the vulnerable precondition:

docker compose exec vuln wp option pluck breeze_advanced_settings breeze-store-gravatars-locally --allow-root --path=/var/www/html
docker compose exec patched wp option pluck breeze_advanced_settings breeze-store-gravatars-locally --allow-root --path=/var/www/html