PHP 8.2.35

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

PHP 8.2–8.5 के लिए आपातकालीन security releases दो गंभीर “PHP2Shell” कमजोरियों को ठीक करने का प्रयास करती हैं, जो लगभग किसी भी PHP-संचालित web server पर, WordPress और shared hosting platforms जैसे लोकप्रिय stacks सहित, unauthenticated remote code execution की अनुमति देती हैं। Commenters अल्पकालिक mitigation tactics (upload progress disable करना, multipart form data block करना, memory limits कड़े करना, workers को aggressively restart करना) साझा करते हैं, जबकि distros, cloud providers, और third‑party repos से patched packages और Docker images का इंतज़ार होता है। यह घटना AI-assisted vulnerability hunting के युग में coordinated disclosure, कुछ vendors की धीमी patch rollout, और web के बड़े हिस्से को चलाने वाली unsupported PHP 5/7 installations की लंबी पूँछ को लेकर व्यापक चिंता भी पैदा करती है।

नई रिलीज़ और कमजोरियाँ

  • सुरक्षा रिलीज़: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12; साथ ही 7.4, 8.0, 8.1 के लिए न्यूनतम स्रोत बैकपोर्ट भी।
  • दो गंभीर कमजोरियाँ (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) आउट‑ऑफ़‑मेमोरी हैंडलिंग और multipart पार्सिंग के जरिए RCE की अनुमति देती हैं; कहा गया है कि सभी web SAPIs जोखिम में हैं (FPM, mod_php, CGI, आदि)।
  • कमजोरियाँ request initialization के दौरान OOM, longjmp-आधारित error handling, और multipart/form-data parsing से संबंधित हैं; कोडबेस में OOM के लिए कई defensive checks जोड़े गए।

निवारण और संचालनात्मक प्रतिक्रियाएँ

  • सामान्य अस्थायी निवारण:
    • session.upload_progress.enabled को disable करें।
    • web server पर multipart/form-data requests को block करें, यह स्वीकार करते हुए कि इससे file uploads टूट जाएँगी।
    • stale state reuse से बचने के लिए FPM में pm.max_requests=1 सेट करें।
    • post_max_size और max_input_nesting_level को कम करें।
    • सुनिश्चित करें कि uploads से कोई .php serve न हो और phpinfo.php हटा दें।
  • कुछ operators ने patches उपलब्ध होने तक PHP sites को offline कर दिया या front-end web servers बंद कर दिए; others ने web server और FPM के बीच अस्थायी reverse proxies/filters लगाए।
  • इस पर बहस रही कि क्या CGI/classic one-request-per-process व्यावहारिक रूप से exploitable है; official advisory सभी SAPIs को जोखिमपूर्ण मानता है।

Distro, PPA, और Docker patch lag

  • Debian (oldstable और कुछ PHP 7 backports सहित) तथा Gentoo ने तेज़ी से update किया; Ubuntu security updates में देरी हुई और LTS releases में असंगतता रही, लेकिन अंततः वे आ गए।
  • Ondřej Surý के Debian/Ubuntu repos और अन्य third‑party repos (PHP 5.6/7.4 सहित) ने patched builds जल्दी ship किए; Launchpad और PECL पर load बहुत अधिक था।
  • PHP के official Docker images और लोकप्रिय apps (WordPress, Matomo, Nextcloud) के images उल्लेखनीय रूप से धीमे थे या कुछ समय के लिए अभी भी vulnerable PHP वाले images प्रकाशित हुए, जिससे कई लोगों ने खुद images rebuild कीं या इसके बजाय distro packages का उपयोग किया।

पुराने PHP versions और shared hosting

  • ecosystem के बड़े हिस्से में अभी भी PHP 5/7 चलता है; कुछ distros और community maintainers ने fixes backport किए, लेकिन official PHP ने 7.4 तक ही minimal patches दिए।
  • Managed WordPress और shared hosting providers अलग-अलग रहे: कुछ ने सभी PHP sites को जबरन disable कर दिया; others ने कुछ घंटों बाद patched versions roll out किए, जिससे users निराश हुए।

AI की भूमिका और disclosure प्रक्रिया

  • vulnerability chain को security firms द्वारा LLMs का उपयोग करके किए गए कार्य से जोड़ा गया; इस बात पर कड़ी बहस है कि coordination और embargo को mishandle किया गया और क्या वह अत्यधिक PR-driven था।
  • कुछ लोगों का तर्क है कि पहले, अधिक शांत fixes या leak के बाद तेज़ release से chaos कम होता; दूसरों का कहना है कि AI युग में कोई भी public patch bug को तुरंत उजागर कर देता है।
  • टिप्पणियों में “AI slop” पर significant meta‑discussion हुई, जिसमें आलोचना (कम trust, noisy writeups) और प्रशंसा (तेज़ mitigations, tooling, उत्पन्न audits) दोनों शामिल थीं।

तकनीकी और सांस्कृतिक प्रतिक्रियाएँ

  • Longjmp, manual OOM handling, और बिखरे हुए goto-style checks को असुरक्षित C patterns कहा गया; अन्य लोगों का कहना है कि ऐसे तरीके interpreters में आम हैं।
  • कुछ लोगों ने इसे इस बात का एक और संकेत माना कि PHP एक “fractal of bad design” है और PHP से migrate करने की वकालत की, खासकर अब जब AI code port करने में मदद कर सकता है।
  • दूसरों ने कहा कि सभी प्रमुख runtimes (JVM, V8, आदि) में critical bugs आते हैं; PHP की ubiquity उसके failures को अधिक visible बनाती है, न कि उसे uniquely bad।