CVE-2026-3844 — Breeze Cache अनधिकृत मनमाना फ़ाइल अपलोड से RCE लैब

CVE-2026-3844 के व्यवहार को WordPress Breeze Cache प्लगइन में पुनरुत्पादित और तुलना करने के लिए स्थानीय-केवल Docker लैब।

यह रिपॉजिटरी Breeze Cache 2.4.4 में कमजोर व्यवहार प्रदर्शित करती है और इसकी तुलना Breeze Cache 2.4.5 में पैच किए गए व्यवहार से करती है। लैब दो अलग-थलग WordPress सेवाओं का उपयोग करती है, एक कमजोर और एक पैच किया गया, साथ ही Docker नेटवर्क के अंदर एक स्थानीय पेलोड सर्वर।

प्रूफ ऑफ कॉन्सेप्ट जानबूझकर न्यूनतम हानिकारक है: यह वेबशेल का उपयोग नहीं करता, कमांड पैरामीटर को उजागर नहीं करता, रिवर्स शेल शुरू नहीं करता, और कंटेनर के अंदर से फ़ाइलों को पढ़ने की आवश्यकता नहीं होती। प्रमाण होस्ट से देखे जा सकने वाले HTTP व्यवहार पर आधारित है।

कार्यकारी सारांश

CVE-2026-3844 Breeze Cache प्लगइन को 2.4.4 संस्करण तक और उस सहित प्रभावित करता है। कमजोर कोड पथ प्लगइन की स्थानीय Gravatar कैशिंग सुविधा से संबंधित है, विशेष रूप से fetch_gravatar_from_remote() प्रवाह।

जब Breeze विकल्प होस्ट फ़ाइल्स स्थानीय रूप से - ग्रेवाटार सक्षम होता है, तो कमजोर संस्करण हमलावर-नियंत्रित रिमोट फ़ाइल ला सकते हैं और इसे सार्वजनिक वेब-सुलभ कैश निर्देशिका में संग्रहीत कर सकते हैं। यदि लाई गई फ़ाइल PHP है, तो जब HTTP के माध्यम से अनुरोध किया जाता है तो फ़ाइल को वेब सर्वर द्वारा निष्पादित किया जा सकता है।

यह लैब उस व्यवहार को स्थानीय रूप से पुनरुत्पादित करती है:

vuln सेवा: WordPress + Breeze Cache 2.4.4
patched सेवा: WordPress + Breeze Cache 2.4.5
payload सेवा: स्थानीय Docker-केवल पेलोड सर्वर
PoC: नियंत्रित srcset स्ट्रिंग का उपयोग करके अनधिकृत टिप्पणी-आधारित ट्रिगर

अपेक्षित परिणाम है:

http://127.0.0.1:8081 / Breeze 2.4.4 → प्रमाण PHP कैश और निष्पादित होता है
http://127.0.0.1:8082 / Breeze 2.4.5 → प्रमाण PHP कैश/पठनीय/निष्पादन योग्य नहीं है

रिपॉजिटरी संरचना

.
├── 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

लैब आर्किटेक्चर

होस्ट मशीन
│
├── 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  -> स्थानीय पेलोड सर्वर

Docker नेटवर्क
│
├── vuln       -> WordPress कमजोर लक्ष्य
├── patched    -> WordPress पैच किया गया लक्ष्य
├── vuln_db    -> कमजोर WordPress के लिए MariaDB
├── patched_db -> पैच किए गए WordPress के लिए MariaDB
└── payload    -> Python स्थिर HTTP सर्वर

WordPress कंटेनर Docker नेटवर्क URL के माध्यम से पेलोड लाते हैं:

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

होस्ट WordPress सेवाओं के लिए सामान्य HTTP अनुरोधों के माध्यम से परिणाम सत्यापित करता है।

प्रभावित घटक

उत्पाद: WordPress के लिए Breeze Cache प्लगइन
इस लैब में कमजोर संस्करण: 2.4.4
इस लैब में पैच किया गया संस्करण: 2.4.5
कमजोर कार्य: fetch_gravatar_from_remote()
प्रासंगिक फ़ाइल: inc/class-breeze-cache-cronjobs.php
आवश्यक पूर्व शर्त: breeze-store-gravatars-locally सक्षम होना चाहिए

कमजोर व्यवहार केवल तभी पहुंच योग्य होता है जब स्थानीय Gravatar कैशिंग सक्षम हो। यह विकल्प सामान्य स्थापनाओं में डिफ़ॉल्ट रूप से अक्षम होता है, लेकिन यह लैब कमजोर कोड पथ को पुनरुत्पादित करने के लिए इसे जानबूझकर सक्षम करता है।

मूल कारण सारांश

Breeze Cache 2.4.4 में, Gravatar स्थानीयकरण प्रवाह अवतार-संबंधित HTML से एक रिमोट URL निकाल सकता है और उस URL को fetch_gravatar_from_remote() में पास कर सकता है।

कमजोर संस्करण में रिमोट फ़ाइल के आसपास पर्याप्त सत्यापन का अभाव है:

Gravatar स्रोतों के लिए कोई सख्त विश्वसनीय-होस्ट सत्यापन नहीं
सहेजने से पहले कोई विश्वसनीय फ़ाइल एक्सटेंशन अनुमति सूची नहीं
फ़ाइल को सार्वजनिक कैश निर्देशिका में रखने से पहले कोई MIME/सामग्री सत्यापन नहीं
लाई गई फ़ाइल .php जैसा खतरनाक एक्सटेंशन रख सकती है

परिणामी फ़ाइल इस प्रकार संग्रहीत की जाती है:

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

जब कोई PHP फ़ाइल वहाँ सहेजी जाती है और फिर Apache/PHP के माध्यम से अनुरोध की जाती है, तो सर्वर इसे निष्पादित करता है।

Breeze Cache 2.4.5 में, पैच किया गया प्रवाह सत्यापन जोड़ता है जो इस लैब पेलोड को निष्पादन योग्य PHP के रूप में कैश होने से रोकता है। स्थानीय पुनरुत्पादन में, वही ट्रिगर 2.4.4 के विरुद्ध काम करता है लेकिन 2.4.5 के विरुद्ध प्रमाण मार्कर को उजागर नहीं करता है।

यह लैब MU प्लगइन हेल्पर का उपयोग क्यों करती है

यह लैब जानबूझकर पेलोड सर्वर को सार्वजनिक पेलोड होस्ट के बजाय स्थानीय रखता है।

WordPress download_url() और WordPress HTTP API डिफ़ॉल्ट रूप से कुछ निजी Docker होस्टनाम और गैर-मानक पोर्ट को अस्वीकार करते हैं। सार्वजनिक शोषण स्क्रिप्ट अक्सर सार्वजनिक HTTPS पेलोड URL का उपयोग करती हैं, जो उस प्रतिबंध से बचती हैं। यह लैब ऐसा नहीं करती है।

पुनरुत्पादन को पूरी तरह से स्थानीय रखने के लिए, सीड स्क्रिप्ट एक छोटा स्थानीय-केवल MU प्लगइन हेल्पर स्थापित करती है जो:

केवल स्थानीय Docker पेलोड होस्टनाम payload और payload.local की अनुमति देता है
केवल लैब पोर्ट 80 और 9100 की अनुमति देता है
लैब टिप्पणियों को स्वतः-अनुमोदित करता है
नियतात्मक स्थानीय परीक्षण के लिए टिप्पणी फ्लड जांच अक्षम करता है

यह हेल्पर Breeze स्रोत कोड को संशोधित नहीं करता है। कमजोर और पैच दोनों सेवाएँ WP-CLI के माध्यम से स्थापित वास्तविक Breeze प्लगइन संस्करणों का उपयोग करती हैं।

हेल्पर केवल Docker लैब को नियतात्मक और स्थानीय-केवल बनाने के लिए मौजूद है।

सुरक्षा मॉडल

यह रिपॉजिटरी केवल स्थानीय सुरक्षा अनुसंधान और पोर्टफोलियो प्रदर्शन के लिए है।

सुरक्षा उपाय:

केवल localhost और Docker नेटवर्क सेवाओं पर चलता है
कोई बाहरी कॉलबैक सर्वर नहीं
कोई सार्वजनिक शोषण लक्ष्य नहीं
कोई रिवर्स शेल नहीं
कोई इंटरैक्टिव शेल नहीं
कोई cmd= वेबशेल व्यवहार नहीं
कोई रहस्य या वास्तविक क्रेडेंशियल नहीं
प्रमाण के लिए कोई कंटेनर फ़ाइल पढ़ना नहीं
HTTP प्रतिक्रिया व्यवहार के माध्यम से प्रमाण देखा जाता है

PoC पेलोड हानिरहित PHP रनटाइम जानकारी प्रिंट करता है:

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

यह शेल कमांड चलाए बिना कोड निष्पादन संदर्भ साबित करता है।

आवश्यकताएँ

Docker Desktop या Docker Engine
Docker Compose v2
Python 3.9+
Python पैकेज: requests

Python निर्भरता स्थापित करें:

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

requirements.txt में यह होना चाहिए:

requests

त्वरित प्रारंभ

लैब बनाएँ और प्रारंभ करें:

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

सेवा स्थिति जाँचें:

docker compose ps

अपेक्षित सेवाएँ:

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

सीड लॉग जाँचें:

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

अपेक्षित लॉग पंक्तियाँ:

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

लैब तत्परता सत्यापित करें

WordPress स्थापना जाँचें:

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

Breeze संस्करण जाँचें:

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

अपेक्षित:

2.4.4
2.4.5

कमजोर पूर्व शर्त जाँचें:

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