Unauthenticated Arbitrary File Upload in Breeze Cache for WordPress

Repository contains 3 files: two Python scripts and one README. The main purpose is exploitation of CVE-2026-3844, an unauthenticated arbitrary file upload in the WordPress Breeze Cache plugin <= 2.4.4 that can lead to remote code execution. The exploit abuses WordPress comment submission so that Breeze fetches an attacker-controlled remote file from a crafted srcset value and stores it in the publicly reachable gravatar cache directory. CVE-2026-3844.py is the offensive exploit. From the visible code, it prints a banner, checks target version by requesting /wp-content/plugins/breeze/readme.txt, derives a payload extension from a supplied payload URL, and uses pycurl helpers for GET/POST requests. The truncated tail clearly shows it attempts exploitation, reports a resulting webshell URL, and supports post-exploitation interaction. Its usage examples indicate the intended payload is a PHP webshell accepting a cmd parameter, enabling arbitrary command execution, file reads, and reverse-shell style commands. poc.py is a safer proof-of-concept intended for a local Docker lab. It generates a unique benign PHP payload under ./payload, hosts or expects it at a configurable payload base (default http://payload:9100), posts a single crafted comment to /wp-comments-post.php, triggers page rendering at /?p=1, waits for Breeze caching behavior, and then checks the expected cached PHP path under /wp-content/cache/breeze-extra/gravatars/. It verifies success by looking for a unique proof marker in the HTTP response rather than trusting status code alone. This script demonstrates code execution but intentionally avoids command execution, shells, file writes, or interactive behavior. README.md documents the vulnerability, prerequisites, exploitation flow, and mitigation. It explicitly states the key prerequisite: Breeze's 'Host Files Locally – Gravatars' option must be enabled. Overall, this is a real exploit repository, not merely detection logic. It includes both a weaponizable exploit path (attacker-supplied PHP webshell) and a least-harm lab PoC for controlled validation.

Single-file Python exploit targeting CVE-2026-3844 in the Breeze Cache WordPress plugin. The repository contains one code file, `CVE-2026-3844.py`, which defines a `BaseCVE`-derived exploit class implementing three unauthenticated web exploitation paths that all aim to achieve arbitrary PHP file write and web-shell access. Structure and purpose: - `fingerprint()` checks for Breeze by requesting `/wp-content/plugins/breeze/readme.txt`. - `_find_post_id()` uses the WordPress REST API `/wp-json/wp/v2/posts` to locate a published post with comments enabled, falling back to post ID 1. - `_shell_urls()` and `_probe_shell()` generate and test likely shell locations under Breeze cache directories. - `exploit()` tries the vectors in order: direct AJAX file fetch/write, comment `srcset` injection, then older-version path traversal. Main exploit capabilities: 1. Vector 1 (`_exploit_v1`): sends a POST to `/wp-admin/admin-ajax.php` with action `breeze_fetch_avatar` and `gravatar_url` pointing to a remote PHP shell on GitHub. The vulnerable plugin fetches the file server-side and stores it under `wp-content/cache/breeze-extra/gravatars/` without extension validation, enabling immediate PHP execution. 2. Vector 2 (`_exploit_v2`): posts a crafted comment to `/wp-comments-post.php` where the `author` field contains a `srcset` reference to the same remote shell URL. Breeze later parses and downloads that URL during avatar caching/cron processing. The exploit then triggers `/?p={post_id}` and `/wp-cron.php` and polls for the shell. 3. Vector 3 (`_exploit_v3`): for older Breeze versions, abuses unsanitized comment email handling with a traversal string like `../../../uploads/{rand}.php` so plugin cache-writing logic stores attacker-controlled PHP content into `/wp-content/uploads/{rand}.php`. Payload behavior: - Vectors 1 and 2 use the public `p0wny-shell` PHP web shell from GitHub and verify success by checking for the marker `p0wny@shell`. - Vector 3 writes `self.shell_content` directly and accepts either `p0wny@shell` or `File Manager` as success markers. Overall, this is a real exploit, not just a detector. It is operational rather than framework-integrated, and its end goal is unauthenticated remote code execution via a web-accessible PHP shell on vulnerable WordPress+Breeze installations.

This repository is a self-contained local Docker lab and exploit PoC for CVE-2026-3844 affecting the Breeze Cache WordPress plugin. It is not tied to a common exploit framework. The repo contains: two Dockerfiles for vulnerable and patched WordPress containers, a docker-compose stack with MariaDB backends and a local Python payload server, a Bash seed script that installs/configures WordPress and Breeze, two benign PHP proof payloads, and a Python PoC (poc/poc.py) that automates exploitation and verification. The main exploit capability is unauthenticated web exploitation via WordPress comments. The Python PoC posts a crafted comment to wp-comments-post.php where the author field embeds an attacker-controlled srcset value pointing to a remote PHP file hosted on the local payload server. When Breeze 2.4.4 processes avatars with local gravatar caching enabled, WordPress/Breeze fetches that remote file and stores it under /wp-content/cache/breeze-extra/gravatars/. The PoC then requests the expected cached PHP path and verifies exploitation by checking for a unique proof marker in the HTTP response. This demonstrates arbitrary file upload leading to remote code execution. Against Breeze 2.4.5, the same flow should fail to expose the marker. Repository structure and purpose: README.md documents the vulnerability, lab architecture, and expected behavior; docker-compose.yml defines the vulnerable service on 8081, patched service on 8082, and payload server on 9100; scripts/seed-wordpress.sh provisions WordPress, installs the specified Breeze version, enables the required gravatar-localization setting, creates the cache directory, and installs a local MU plugin helper to permit Docker-local payload fetching and deterministic comment approval; payload/*.php are least-harm proof scripts that only print environment details; poc/poc.py is the operational exploit driver. Overall, this is a realistic but constrained lab-grade exploit demonstrating remote file fetch to executable PHP cache placement and subsequent HTTP-triggered code execution.

Repository contains a small exploit PoC for CVE-2026-3844 targeting the WordPress Breeze Cache plugin <= 2.4.4. There are three files: a Python exploit script, a Nuclei template, and a README. Because the repository includes a framework artifact, the main exploit-relevant files are the Python PoC and the Nuclei template. The Python script is the operational exploit: it checks plugin version by requesting /wp-content/plugins/breeze/readme.txt, then submits an unauthenticated POST to /wp-comments-post.php with a crafted author field containing a srcset reference to an attacker-hosted payload URL. The intended abuse is that Breeze's gravatar caching logic fetches and stores the remote file into /wp-content/cache/breeze-extra/gravatars/, where it may become web-accessible as a PHP file. The script then verifies whether the uploaded file is reachable and presents it as a webshell URL, with examples showing command execution through a cmd parameter. The Nuclei YAML is primarily a detection/validation template: it posts a crafted comment referencing oast.me, follows the redirect path, checks for reflected srcset content, and finally probes the expected gravatar cache path for the uploaded marker PHP file. Overall, the repository's purpose is to demonstrate and validate unauthenticated arbitrary file upload leading to potential RCE on vulnerable WordPress sites running Breeze with gravatar local hosting enabled.

This repository is a small standalone Python proof-of-concept exploit for CVE-2026-3844 affecting the Cloudways Breeze Cache WordPress plugin up to version 2.4.4. The repo contains five files: a README with vulnerability description and lab instructions, a docker-compose file for spinning up a local WordPress/MariaDB test environment, the main exploit script exploit.py, a minimal requirements.txt listing requests, and a standard Python .gitignore. The exploit’s core capability is unauthenticated arbitrary file upload leading to remote code execution. It abuses Breeze’s gravatar-local-caching behavior by posting a crafted comment to /wp-comments-post.php where the author field includes a srcset injection pointing to a remote PHP payload. The script first checks the plugin version by requesting /wp-content/plugins/breeze/readme.txt, then optionally discovers a commentable post through the WordPress REST API at /wp-json/wp/v2/posts. After posting the malicious comment, it triggers page rendering and WordPress cron via /?p=<post_id> and /wp-cron.php so the vulnerable Breeze functionality fetches the attacker-supplied remote file. It then probes for the uploaded shell at wp-content/cache/breeze-extra/gravatars/shell.php. The payload is hardcoded to the public p0wny-shell PHP web shell hosted on raw.githubusercontent.com, making this more than a pure detection script. It is operational but not highly modular: the payload URL and expected shell path are fixed constants, though the target URL, post ID, retry count, and check-only mode are configurable via CLI arguments. The exploit includes basic resilience features such as random user agents, retry logic, and handling for HTTP 429 rate limiting. The included docker-compose.yml is for local testing only and provisions MariaDB and WordPress, exposing port 80 and mounting a local Breeze plugin directory into the WordPress plugin path. Overall, the repository’s purpose is to demonstrate and validate real-world exploitation of the Breeze Cache arbitrary file upload flaw by achieving a reachable PHP web shell on a vulnerable WordPress instance.

This repository is a working proof-of-concept for CVE-2026-3844 affecting the Cloudways Breeze Cache WordPress plugin up to version 2.4.4. The exploit abuses Breeze's gravatar-local-caching behavior: an unauthenticated attacker posts a comment with a crafted author field containing a malicious srcset URL pointing to an attacker-hosted PHP file. When a page renders the comment avatar, Breeze fetches the remote file and stores it in a web-accessible cache directory without MIME or extension validation, enabling arbitrary PHP upload and subsequent remote code execution. Repository structure is small and purpose-built. The main exploit logic is in poc/exploit.py, a Python script using requests to: check the Breeze version via /wp-content/plugins/breeze/readme.txt, enumerate posts through /wp-json/wp/v2/posts, submit a malicious comment to /wp-comments-post.php, trigger rendering by visiting /?p=<id>, and then probe the expected uploaded payload path under /wp-content/cache/breeze-extra/gravatars/. If the uploaded file returns the embedded verification token, the script marks RCE as confirmed and can further validate command execution with ?cmd=id. The script is operational rather than just demonstrative because it automates the full chain end-to-end. The payload in payloads/shell.php is a simple PHP command-execution stub controlled by the cmd GET parameter. It is described as a harmless PoC marker, but functionally it is a basic webshell. The repository also includes poc/validate.sh, a Bash harness that builds the Docker lab, runs the exploit, validates the uploaded shell URL, and inspects the vulnerable plugin source inside the container. The docker/ directory provides a reproducible lab: a custom WordPress image installs WP-CLI and Breeze 2.4.4, docker-compose.yml launches MariaDB, WordPress on localhost:8088, and a Python HTTP payload server on port 9999, and entrypoint-custom.sh auto-installs WordPress, opens comments, disables moderation, activates Breeze, and enables the required "Host Files Locally - Gravatars" setting. Overall, this is a genuine exploit repository with a complete local test environment demonstrating unauthenticated arbitrary file upload leading to PHP execution/RCE against misconfigured vulnerable Breeze installations.

Repository contains a Python exploit and a Nuclei template for CVE-2026-3844, an unauthenticated arbitrary file upload in the WordPress Breeze Cache plugin <= 2.4.4. The Python script is the operational exploit: it checks plugin version by requesting /wp-content/plugins/breeze/readme.txt, then abuses comment submission to make Breeze fetch an attacker-controlled remote file via a crafted srcset value and store it under /wp-content/cache/breeze-extra/gravatars/. The script appears designed to verify successful upload and then interact with the resulting webshell URL, with README examples showing command execution through ?cmd=. The included YAML is a Nuclei template that performs a similar workflow for detection/verification using /wp-comments-post.php and a remote oast.me payload URL, then checks for the uploaded file in the gravatar cache path. Repository structure is minimal: one main Python exploit, one Nuclei template, README documentation, license, and .gitignore. Overall purpose is exploitation and verification of arbitrary file upload leading to potential RCE on vulnerable WordPress sites where Breeze's local gravatar hosting is enabled.

This repository is a small standalone Python PoC for CVE-2026-3844 targeting the Cloudways Breeze WordPress plugin. The repo contains one executable script (CVE-2026-3844.py), a README, and a license. The Python script is the sole operational component and is not part of a larger exploit framework. The exploit workflow is: normalize a supplied target URL (or read multiple targets from a .txt file), fingerprint the Breeze plugin version by requesting /wp-content/plugins/breeze/readme.txt or /wp-content/plugins/breeze/breeze.php, and if considered vulnerable, attempt unauthenticated file upload by POSTing multipart data with action=breeze_fetch_gravatar to several WordPress/Breeze-related endpoints. The uploaded content is a hardcoded PHP file uploader webshell saved locally as shell.php and sent as gravatar_file with MIME type image/jpeg. After delivery, the script probes several likely web paths for the uploaded shell and reports success if the shell content is reachable. Main capability: unauthenticated web-based arbitrary file upload leading to likely RCE through deployment of a PHP uploader shell. Secondary capability: basic version detection/fingerprinting of the Breeze plugin. The script suppresses TLS verification warnings and uses requests with verify=False, indicating it will operate against HTTPS targets without validating certificates. Notable implementation detail: the code's version gate only treats versions <= 2.1.19 as definitively vulnerable, despite constants/comments and README text claiming the CVE affects versions up to 2.4.4. That mismatch may cause false negatives against versions between 2.1.20 and 2.4.4. Overall, this is a real exploit PoC with a bundled payload, making it operational rather than a mere detector.

This repository is a small standalone Python exploit for CVE-2026-3844 targeting the Breeze Cache WordPress plugin. The repo contains one primary code file (CVE-2026-3844.py), a README, requirements.txt, license, and .gitignore. The exploit is not part of a larger framework. The Python script is a mass-exploitation utility built around pycurl and multiprocessing. It accepts either a single URL or a list of targets, then concurrently submits crafted POST requests to each target’s /wp-comments-post.php endpoint. The crafted form data abuses the author field with an injected srcset pointing to an attacker-controlled remote payload URL. After waiting 10 seconds, the script attempts to retrieve the expected uploaded file from /wp-content/cache/breeze-extra/gravatars/{random_marker}{ext}. If the default payload is used, it verifies success by checking for a hardcoded marker string in the response body. Core capabilities: - Mass targeting with multiprocessing - Unauthenticated exploitation via WordPress comment submission - Remote arbitrary file upload by causing the target to fetch attacker-hosted content - Verification of uploaded file accessibility - Logging of successful uploads to successful_uploads.txt The exploit’s default payload is a remote PHP file hosted on GitHub Gist, indicating likely intent to place a PHP web shell or similar executable content on vulnerable WordPress servers. SSL verification is disabled, redirects are followed for POST requests, and a browser-like User-Agent is used. Overall, this is a real operational exploit script rather than a detector or README-only repository.