WordPress: बिना प्रमाणीकरण वाला path traversal जो conditional RCE तक ले जाता है

मूल लेख ↗ Hacker News चर्चा ↗

एक newly disclosed WordPress vulnerability बिना प्रमाणीकरण वाला path traversal संभव बनाती है, जो कुछ configurations में remote code execution तक ले जा सकती है, खासकर common theme structures और official Docker images जैसी insecure PHP setups के साथ। Commenters इस जोखिम की वास्तविक व्यापकता पर बहस करते हैं, यह बताते हुए कि कई themes WordPress की अपनी directory recommendations का पालन करती हैं और core patches अब पुराने versions तक backport किए जा चुके हैं। यह घटना WordPress के security model, plugin ecosystem, और CVSS base scores पर व्यापक आलोचना को फिर से भड़काती है; कुछ लोग तर्क देते हैं कि organizations को WordPress को isolate या पूरी तरह replace करना चाहिए, जबकि अन्य मानते हैं कि careful configuration और hardening से इसे काफ़ी सुरक्षित रखा जा सकता है।

कमज़ोरी & प्रभाव

  • मुख्य समस्या: get_page_template / locate_template का unsanitized उपयोग, जिससे path traversal के ज़रिए सर्वर पर पहले से मौजूद arbitrary PHP फ़ाइलें include हो सकती हैं।
  • मुख्य पूर्वशर्त: थीम में top-level page-* directory हो (जैसे page-templates/), जिसे WordPress documentation स्पष्ट रूप से सुझाती है। कई commenters का तर्क है कि इससे “कुछ” नहीं, बल्कि बड़ी संख्या में themes vulnerable हैं।
  • नई install पर random users PHP upload नहीं कर सकते, लेकिन attackers सिस्टम पर मौजूद किसी भी “commands चलाने वाली PHP” का दुरुपयोग कर सकते हैं।

शर्तें और exploit chains

  • उदाहरण chain: इस flaw को plugins में मौजूद कई unauthenticated file-upload bugs में से किसी एक के साथ जोड़कर conditional RCE तक पहुँचा जा सकता है; hardened configs और logging से बचने के लिए attackers साधारण webshell uploads की बजाय इसे तरजीह दे सकते हैं।
  • official PHP Docker image में ऐतिहासिक रूप से register_argc_argv enabled के साथ pearcmd.php और बिना open_basedir के shipping होता था, जो path traversal हासिल होने पर एक शक्तिशाली target देता है।
  • कुछ लोग कहते हैं कि लोकप्रिय themes के साथ default Docker या shared hosting setups पर यह effectively “drive-by exploitable” है।

Patch status & deployment

  • WordPress 7.1.2 में fixed, और branches back to 4.7 तक “as a courtesy” backports किए गए, एक broken auto-update version को छोड़कर।
  • एक commenter शुरू में सोचता है कि patch के बाद भी themes का audit करना पड़ेगा या नहीं, लेकिन अंततः निष्कर्ष निकालता है कि core fix theme behavior को neutralize कर देना चाहिए।
  • WordPress में true LTS नहीं है; पुराने branches selective backports पर निर्भर रहते हैं, जिससे unknown bugs unpatched रह जाते हैं।

CVSS scoring debate

  • एक पक्ष: CVSS scores “Ouija board” numbers हैं, आसानी से manipulate किए जा सकते हैं और अक्सर वास्तविक जोखिम से मेल नहीं खाते; triage के लिए इन्हें पढ़ना खतरनाक है।
  • दूसरा पक्ष: base CVSS तकनीकी impact का useful first-pass माप है; organizations को calculators और compensating controls का उपयोग करके अपने environment के अनुसार re-score करना चाहिए।
  • उदाहरण contrast: यह WordPress RCE (9.x) बनाम Hugo tooling vulns (भी 9.3) — same numeric severity लेकिन practical exposure बहुत अलग।

WordPress security पर आकलन

  • कड़ी आलोचना: “RCE-as-a-Service,” “piece of garbage,” messy, poorly typed code, बहुत सारे undocumented APIs, insecure default model (site अपना code खुद लिख सकती है; uploads अक्सर executable होते हैं; plugins attack surface को बहुत बढ़ा देते हैं)।
  • जवाबी तर्क: यह बेहद लोकप्रिय है, high-value sites सहित; expertise, hardening, और disciplined plugin use के साथ इसे सुरक्षित चलाया जा सकता है। समस्याएँ अक्सर low-cost contractors और non-experts से आती हैं जो plugins और themes को “lego-mount” करते हैं।
  • कुछ लोग कहते हैं कि popularity और extensibility स्वाभाविक रूप से attackers को आकर्षित करती हैं; अन्य लोग कहते हैं कि सिर्फ popularity WordPress के exploit history को पूरी तरह नहीं समझाती।

Alternatives & migrations

  • कई participants रिपोर्ट करते हैं कि उन्होंने WordPress से static generators (Hugo, Astro) या mostly-static custom PHP में migration किया, और बताते हैं कि:
    • operational complexity और security चिंता में भारी कमी आई।
    • plugin cruft, black-box behavior, और fragile upgrades से मुक्ति मिली।
  • हालांकि, static tooling में भी high-CVSS bugs हो सकते हैं (Hugo example); फर्क यह है कि generated sites static HTML होते हैं, इसलिए runtime exposure बहुत कम होता है।
  • Static sites के लिए comment systems एक अटकी हुई समस्या बने रहते हैं; third-party services और self-hosted minimal systems के सुझाव दिए जाते हैं।

व्यापक security observations

  • Path traversal को poor filesystem abstractions से प्रेरित bug class के रूप में बार-बार देखा जाता है; एक commenter इसे कम करने के लिए library support का समर्थन करता है।
  • Public servers के logs में PHP exploits की निरंतर scanning दिखती है, जिसमें WordPress paths और leaked .env files अक्सर probe की जाती हैं।
  • कुछ लोग अनुमान लगाते हैं कि AI-driven code analysis सभी ecosystems में discovered vulnerabilities को बहुत बढ़ा सकता है, जिससे इस धारणा को चुनौती मिलेगी कि कौन सा software “सबसे exploitable” है।