---
title: "PHP2Shell: لاملونه او د درملنې لارښود"
description: "د PHP2Shell د ژوند دورې نیمګړتیاوې درک کړئ، د چلولو وخت اپ گریڈونه، لنډمهاله کمول، پیچ انتخاب، او تایید د ژوندی Web غوښتنې لارې له لارې."
language: "ps"
url: "https://keendigit.com/ps/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: لاملونه او د درملنې لارښود

د PHP2Shell د ژوند دورې نیمګړتیاوې درک کړئ، د چلولو وخت اپ گریڈونه، لنډمهاله کمول، پیچ انتخاب، او تایید د ژوندی Web غوښتنې لارې له لارې.

**سرچینې د اکتوبر 22، 2026 پورې چک شوي.** **اوریدونکي: PHP غوښتنلیک چلونکي، امنیتي ځواب ورکوونکي، او انجنیران چې د دودیز PHP جوړونه ساتي.**

دا مقاله د PHP2Shell زیان منونکي لاملونه، د اغیزو ساحه، د ترمیم رسمي پروسه، لنډمهاله کمولو اقدامات او رسمي پیچ پلي کول لنډیز کوي. اصلي متن د شمیرو په کارولو سره حواله شوی لکه [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)؛ ټولې سرچینې لینکونه د متن په پای کې ضمیمه کې لیست شوي دي. د ترتیب کولو ټوټه د ځای پرځای کولو ټیمپلیټ دی، کوم چې د اصلي نسخې، سوداګرۍ ظرفیت، او د ترتیب میراث اړیکو پراساس سمون ته اړتیا لري.

## TL؛ DR: د ترمیم مرحلې او وړاندیزونه

1. **لوړ کړئ PHP منډې وخت** : لږ ترلږه اړونده څانګه لوړه کړئ **8.2.35 , 8.3.36 , 8.4.27 یا 8.5.12** . د توزیع کڅوړو لپاره، د بشپړ کڅوړې نسخه وکاروئ چې پلورونکی تاییدوي چې دواړه CVEs حل کوي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1) [S10](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-10)
2. **ټول زاړه پروسې بدل کړئ**: د هر PHP worker، کوربه توب خدمت، او کانټینر له لوړولو وروسته بیا پیل کړئ یا رول کړئ، او تایید کړئ چې زاړه مثالونه وتلي دي.
3. **د حقیقي Web غوښتنې path** له لارې تایید کړئ: Web SAPI، بشپړ بسته نسخه، او د چلولو مثال وګورئ. یوازې د `php -v` چک کول دا ندي رامینځته کوي چې ژوندی خدمت ثابت دی.
4. **Run د سوداګرۍ ریګریشن چیک او د عادي سرچینو بودیجه بحال کړئ**: ازموینه ننوتنه ، سیشن اداره کول ، اپلوډونه ، واردات ، او د خطا اداره کول. که چیرې د PHP حافظې محدودیت په لنډمهاله توګه لیرې شي، د پیچ ​​کولو وروسته مناسب محدود بودیجه بحال کړئ.
5. **I که سمدستي اپ گریڈ ناممکن وي**: مخکې له دې چې PHP ته ورسیږي بې اعتباره ترافیک محدود کړئ. لکه څنګه چې په 5 برخه کې تشریح شوي د اپلوډ پرمختګ او PHP 8.5 وژونکي بیکټریس غیر فعال کولو ارزونه وکړئ. د ترتیب کمول او د WAF قواعد محدود پوښښ لري او نشي کولی د نوي کولو ځای ونیسي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

## 1. د زیان مننې عمومي کتنه او د خطر قضاوت

په دې مقاله کې PHP2Shell دوه Critical کچې زیانمننې ته اشاره کوي چې په رسمي ډول د PHP لخوا د اکتوبر په 21، 2026 کې افشا شوي. دواړه د حافظې سره تړاو لري او د PHP انجن د ژوند دورې مدیریت غوښتنه کوي، چې د کوډونو د بیرته راګرځیدو خطر رامینځته کوي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

| پروژه                   | CVE-2026-109618                                                                                   | CVE-2026-109619                                                    |
| ----------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| رسمي نوم                | RCE via OOM corruption                                                                            | RCE via stale global state                                         |
| اصلي مسلې               | ناکافي حافظه د غیر معمولي کود لامل کیږي، یو داسې حالت پریږدي چې لا تر اوسه یې پیل نه دی بشپړ کړی. | په کارګر کې پاتې نړیوال حالت د خوشې شوي غوښتنې حافظې ته اشاره کوي. |
| د عادي پیښې وخت         | د اوسنۍ غوښتنې پیل کولو، اجرا کولو یا پاکولو پروسه                                                | پخوانۍ غوښتنه حالت پریږدي، او وروسته غوښتنې دا دمخه مصرفوي.        |
| ایا OOM یو اړین شرط دی؟ | د زیان مننې اصلي محرک میکانیزم پورې اړه لري                                                       | نه; نورې وژونکې تېروتنې او د تشخیص وروسته پاکول ممکن هم دخیل وي    |
| د ترمیم بنسټیز لارښوونه | په خوندي ډول د تخصیص ناکامۍ اداره کړئ او د پای ته رسیدو غوښتنه وکړئ                               | د دولت ملکیت، د پاکولو وخت او ژر پیل کول سم کړئ                    |
| د ضایع کولو اړتیاوې     | باید ترمیم شي                                                                                     | باید په ورته وخت کې ترمیم شي                                       |

اساس: دوه رسمي امنیتي خبرتیاوې او فکس سپارښتنې. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-4)

### 1.1 د اغیزمنو ګمارلو پوهیدل

PHP په رسمي توګه غور کوي **ټول PHP ګمارنې اداره کول Web غوښتنې** په خطر کې، په شمول PHP-FPM , Apache mod\_php , php-cgi , FrankenPHP ، او LiteSpeed . مظاهره وکړه mod\_php برید د غوښتنلیک کوډ چلولو دمخه پیښ کیدی شي ، نو د ننوتلو چیکونه ، د چوکاټ مینځګړیتوب ، او د غوښتنلیک اپلوډ اعتبار نشي کولی دا لاره پوښي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)

دا اړینه ده چې د "ګمارنې اړتیاوې سمې وي" او "د یو ځانګړي برید سلسله په بشپړه توګه ثابته شوې" ترمنځ توپیر وشي. د CVE-2026-109618 اعلان: FPM به د ماشوم پروسې څخه وځي وروسته له دې چې د غوښتنې پیل ناکام شي ، د پیل له ناکامۍ وروسته د mod\_php اړوند پاکولو لاره بندوي؛ په هرصورت، د بریالي پیل څخه وروسته د OOM لاره لاهم په خطر کې ده. اعلان دا هم یادونه کوي چې د دې CVE لپاره بشپړ FPM استخراج لا تراوسه نه دی ښودل شوی. دا محدودیت د دې معلومولو لپاره نشي کارول کیدی چې FPM خوندي دی، په ځانګړې توګه CVE-2026-109619 له پامه غورځول کیدی نشي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

د بریالي استخراج لپاره د سمدستي اجازې حدود د PHP کوربه توب پروسې او هغه سرچینو پورې اړه لري چې ورته لاسرسی لري. عموما، د ویب پاڼې کوډ، اپلوډ ډایرکټر، ډیټابیس اسناد، د خدماتو نښه او د داخلي شبکې لاسرسي وړتیاوو ته باید پاملرنه وشي؛ "د ریموټ کوډ اجرا کول" پدې معنی ندي چې په طبیعي ډول د روټ اجازې ترلاسه کول. دلته د پایلو قضاوت د پروسې د اجازې ماډل پراساس دی، او حقیقي اغیزه باید د ځای پرځای کولو اجازې سره په ګډه ارزول شي.

عادي یو ځل CLI سکریپټونه ورته HTTP ننوتل نه لري؛ مګر هغه پروسې چې په CLI یا سرایت شوي حالت کې د اوږدې مودې لپاره بهرنۍ دندې اداره کوي باید لاهم د چلولو وخت او د ژوند دورې لیست کې شامل شي. یوازې CMS، چوکاټ یا Composer انحصارونه تازه شوي او د PHP لاندې انجن په اوتومات ډول نه بدلیږي.

## 2. د لامل تحلیل

### 2.1 لومړی د ژوند دوه دورې درک کړئ

PHP worker ډیری وختونه په پرله پسې ډول ډیری غوښتنې اداره کوي. د غوښتنې په جریان کې تخصیص شوی حافظه د غوښتنې په پای کې په مساوي ډول خوشې کیدی شي ، پداسې حال کې چې کارګر پخپله او د هغې ځینې نړیوال ساحې شتون ته دوام ورکوي.

نو ځکه، انجن باید دوه محدودیتونه وساتي:

- **د پیل کولو محدودیت**: نورو کوډونو ته ښکاره شوي معلومات باید په داسې حالت کې وي چې په خوندي توګه لوستل کیدی شي، تیریږي، او ویجاړ کیدی شي.
- **Lifecycle محدودیت**: یوځل چې غوښتنه حافظه آزاده شي، د اوږدې مودې ساحې باید د دې حافظې دننه پتې ته د اعتباري حالت په توګه دوام ورنکړي.

دا دوه خنډونه د زیان منونکو دوو ډلو اصلي ناکامي طریقې سره مطابقت لري. لاندې پروسه د میکانیزم توضیحات دي چې اعلانونه او پیچ تالیف سره یوځای کوي. دا پدې معنی نه ده چې هره ګمارنه په سمه توګه ورته د لاسرسي وړ لاره لري. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618: OOM د نامکمل حالت تازه کولو مخه ونیوله

زوړ تطبیق د OOM اداره کولو لپاره د `longjmp()` ډول غیر محلي کود کاروي، او اړونده لاره د `zend_bailout()` له لارې د اوسني اجرا کولو شرایطو څخه وځي. خطر دا دی چې د C کوډ یوه ټوټه کیدای شي یو نوی اعتراض، سري، یا بل کوډ ته د غوښتنې حالت خپور کړي، مګر تر اوسه یې د ساحې پیل بشپړ نه دی کړی؛ په دې وخت کې، په اړونده وخت کې د تخصیص ناکامي کیدای شي د عادي تړلو مرحلو د پریښودلو سبب شي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

د ناکامۍ پروسه په څلورو مرحلو ویشل کیدی شي:

1. د غوښتنې داخلي جوړښت رامینځته کړئ یا تازه کړئ او د لاسرسي وړ یې کړئ.
2. ورپسې د حافظې تخصیص ناکام شو او OOM پیل شو.
3. د اجرا کولو جریان د اوسني فعالیت څخه لیرې ځي، او کوډ په اصل کې د پیل کولو بشپړولو یا حالت بحالولو لپاره کارول کیږي نه اجرا کیږي.
4. د پاکولو غوښتنه د دې جوړښتونو پروسس کولو ته دوام ورکوي او ناسم مینځپانګې د باوري ساحو یا ادرسونو په توګه چلند کوي.

مسله دا نده چې د حافظې ختمیدل تل د RCE لامل کیږي. بلکه، د **میموري ستړیا د کنټرول جریان بدلوي او د باوري جوړښتونو په اړه د انجن انګیرنې سرغړونه کوي**. ناکامه تخصیص ته اړتیا نلري په مستقیم ډول هغه جوړښت شامل کړي چې بالاخره په غلط ډول لوستل کیږي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

#### ولې کوچنۍ غوښتنې هم د حافظې څخه تیریږي

د غوښتنې په بدن کې د بایټس شمیر او د پارس کولو وروسته د هپ کارول یو شی ندي. د A ساحه کیدای شي د PHP دننه ډیری تارونو، سري عناصرو او میټاډاټا شیانو سره مطابقت ولري؛ د داخلي جوړښت پیچلتیا به د حافظې لوړولو درجې اغیزه وکړي.

په رسمي اعالن کې لیست شوي ملټي پارټ مسلې شاملې دي: د لومړني اندازې چیک خلا کله چې شتون ولري د اعلامیې اوږدوالی ورک وي ، د یوې برخې لپاره د سرلیکونو شمیر په کافي اندازه محدود نه وي ، او د خالي فایل کنټرول لاهم میټاډاټا تولیدوي ، د نیست شوي نومونو سره د سرې کاري بار نور هم زیاتوي. د اپلیکیشن خپل خلاصول، کوډ کول، یا د ننوتلو بیا ځای پرځای کول ممکن د OOM سرچینه وي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

له دې څخه دوه محافظتي پایلې ترلاسه کیدی شي:

- د غوښتنې د بدن محدودیتونه باید د PHP ته د ننوتلو دمخه د امکان تر حده پلي شي، او د اصلي لوستلو اوږدوالی او ساختماني پیچلتیا باید په پام کې ونیول شي.
- په انفرادي ډول د فایل اندازه محدودول، د فایلونو شمیر، یا یوازې د یو اپلوډ پورټل بندول د OOM ټولې سرچینې پوښلی نشي.

#### ولې د غوښتنلیک تصدیق ممکن ډیر ناوخته وي

په mod\_php کې، د غوښتنې بدن ممکن د غوښتنې پیل کولو مرحلې په جریان کې په اتوماتيک ډول تجزیه شي؛ حتی که چیرې پیل ناکام شي، د اړونده غوښتنې پاکول به لاهم ترسره شي. د تایید شوي برید لارې له همدې امله د غوښتنلیک کوډ دمخه پیښ کیدی شي. په دې مرحله کې د افشا کیدو کمولو لپاره، محدودیتونه باید په ریورس پراکسي، Web سرور، یا بل حد کې ځای په ځای شي چې د PHP غوښتنې پروسس کولو دمخه وي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619: د غوښتنې حافظه خوشې شوې ، نړیواله حواله لاهم ژوندۍ ده

پدې مسله کې تېروتنه، ناسته، اعتراض، یا د تمدید حالت شامل دی: ساحه د کارګر اوږد مهاله لاسرسي ځای کې زیرمه شوې، مګر د ساحې لخوا راجع شوي ډاټا د یوې غوښتنې سره تړاو لري. تر هغه وخته پورې چې د غوښتنې ډډې خوشې کیدو دمخه حوالې په سمه توګه پاکې شوې نه وي ، ورپسې غوښتنې ممکن له یو پیچلي حالت سره مخ شي ، چې د کارولو وروسته وړیا رامینځته کوي. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

رسمي تحلیل د استخراج شرایط په "تولیدونکو" او "مصرف کونکو" ویشي:

| رول یا حالت       | معنی                                                                                     | د ساتنې لپاره اغیزې                                                      |
| ----------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| دولتي تولید کونکی | د دې غوښتنې ملکیت دولت په داسې ځای کې واچوئ چې بیا هم وروسته لاسرسی کیدی شي              | د دې لپاره چې وګوري چې ایا اړوند پاکول د غیر معمولي وتلو وروسته بشپړ شوي |
| حالت پاتې دی      | دا پاک شوی نه و، یا دا پاک شوی او بیا د ناوخته عملیاتو په واسطه ډک شوی.                  | په مخکینۍ بند مرحله کې یوازې یو ځل پاکول ممکن کافي نه وي                 |
| کارګر بیا کارول   | ورته کارګر د راتلونکو غوښتنو پروسس ته دوام ورکوي                                         | ډیری کارګر یوازې د مهالویش توپیر دی ، نه د حافظې خوندیتوب تضمین          |
| مخکښ مصرف کونکی   | مخکې لدې چې اړوند حالت په نورمال ډول پیل شي د پاتې کیدو ارزښت ولولئ ، خوشې کړئ یا وټاکئ. | باید د پیل کولو دمخه INI، سیشن او نورې لارې چیک کړئ                      |

دا شرایط باید په ترکیب کې پوره شي؛ د کومې تېروتنې لاګ پخپله دا نه ثابتوي چې زیانمنتیا په بریالیتوب سره کارول شوې ده. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

#### دا د اړین شرط په توګه OOM ته اړتیا نلري

وژونکي تېروتنې کولی شي د جوړه دولتي خپرونو او بیا رغولو مخه ونیسي. د تالیف یا تجزیه کولو ناکامۍ، ناڅرګندې تېروتنې، د `require` ناکامۍ، او د اجرا کولو مهال ویش کولی شي ځانګړي حالتونه شاته پریږدي. په پاکولو کې ناوخته غیر وژونکي تشخیص کولی شي د غلطو معلوماتو بیا تکرار کړي چې دمخه پاک شوي و. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

له همدې امله، د `memory_limit` لامحدود ته بدلول د زیانونو دا ټولګه نه پوښي.

#### "د پیل کولو دمخه" باید په جلا توګه درملنه وشي

د دوه ډوله تایید شویو پیرودونکو وخت توپیر لري:

- **Early INI تشخیص**: ځینې تشکیلات چې د غوښتنې مسلې خبرتیا ، خبرتیا یا تخریب دمخه د نورمال اجرا کونکي پیل کولو دمخه پلي شوي ، او د تشخیص پروسس کول ممکن زاړه غلط حالت ته لاسرسی ومومي.
- **سیشن اپلوډ پرمختګ**: سیشن ممکن د غوښتنې بدن پارس کولو پروسې په جریان کې دمخه پروسس شي ، مګر منظم ماډل `RINIT` لاهم بشپړ شوی نه دی؛ دا نشي اټکل کیدی چې لاره شتون نلري ځکه چې غوښتنلیک په څرګنده توګه `session_start()` نه بولي. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

ټول نه INI تشکیلات ورته د خطر وخت لري. د ډایرکټر په کچه ترتیب mod\_php او د `PHP_VALUE` / `PHP_ADMIN_VALUE` لخوا تیر شو FPM مخکینۍ پای باید له عادي څخه توپیر شي `php.ini` , FPM pool د پیل ترتیب او FPM `.user.ini` . وروستنۍ د ترتیب کولو مختلف وخت لري او په ټولیز ډول ورته لومړني مصرف کونکي نشي ویل کیدی. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

د `display_errors`، `log_errors` بندول، د `error_reporting` کمول، یا د `@` کارول یوازې د تشخیص لید اغیزه کوي؛ اړونده داخلي حالت ته د ننوتلو دمخه د دې پریکړې کولو دمخه لاسرسی موندلی وي چې ایا د لاګ تولید کړئ. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

## 3. د ترمیم نسخه او پیچ انتخاب

### 3.1 رسمي اپ سټریم فکس بیس لاین

| اوسنی PHP څانګه    | لومړۍ نسخه چې پدې رسمي فکس کې شامله ده | وړاندیزونه                                                                                  |
| ------------------ | -------------------------------------- | ------------------------------------------------------------------------------------------- |
| 8.2                | 8.2.35                                 | دې نسخې یا بلې نسخې ته لوړ کړئ چې ورته اصلاحات لري                                          |
| 8.3                | 8.3.36                                 | د پورته په څیر ورته                                                                         |
| 8.4                | 8.4.27                                 | د پورته په څیر ورته                                                                         |
| 8.5                | 8.5.12                                 | د پورته په څیر ورته                                                                         |
| 8.1 او پخوانۍ نسخې | پورته عمومي ملاتړ پای ته رسیدلی        | ملاتړ شوي څانګو ته مهاجرت ته لومړیتوب ورکړئ؛ د لنډ مهاله چک خوشې کول یا LTS جوړونکي بیکپورټ |

نسخه او د ملاتړ حالت د PHP رسمي اعلان پراساس دی، او د وخت اساسی کرښه د اکتوبر 22، 2026 ده. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)

دا د **برانچ ځانګړي فکس حد** دي. دوی نشي کولی د داسې بیان سره بدل شي چې د 8.5.12 لاندې هره نسخه زیانمنونکې ده: نسخې لکه 8.2.35 او 8.4.27 په نورو څانګو کې لا دمخه اصلاحات لري.

### 3.2 د بشپړ توزیع کڅوړې نسخه چیک کړئ

ډیسټرو اکثرا د زړو اپ سټریم نسخو پراساس امنیتي اصلاحات اضافه کوي. منل باید د خوشې کولو نسخه، د ذخیره کولو سرچینه، د بشپړ کڅوړې نسخه او امنیتي بلیټین هم وګوري.

د مثال په توګه، د Ubuntu 24.04 LTS فکس بسته نسخه د Ubuntu USN-8948-1 لپاره لیست شوی دی:

```text
8.3.6-0ubuntu0.24.04.13
```

د دې پورته برخه لاهم `8.3.6` ده ، مګر د دې توزیع بشپړ بسته نسخه پدې فکس اعلان کې شامله ده. دا پایله یوازې د اړونده توزیع او بسته بندۍ سرچینې باندې پلي کیږي، او هیڅ ډول جوړونې ته عمومي نه شي کیدی چې `8.3.6` هم ښکاره کوي. [S10](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-10)

### 3.3 د سم پیچ غوره کول

| صحنه                                           | د لومړیتوب پلان                                                                              | د منلو لپاره کلیدي ټکي                                            |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| د توزیع PHP کڅوړه کارول                        | د جوړونکي لخوا خپاره شوي امنیتي تازه معلومات نصب کړئ                                         | اعلان دواړه CVE پوښي؛ د بشپړ بسته نسخه سمه ده                     |
| د رسمي PHP کانټینر یا پخپله جوړ شوی عکس وکاروئ | د بیس چلولو وخت تازه کړئ، بیا جوړ کړئ او ځای په ځای کړئ                                      | روان مثال نوی عکس کاروي؛ ټول زاړه نقلونه بهر شوي دي               |
| د ځان تالیف شوي ملاتړ شوي څانګې                | د دې څانګې رسمي امنیتي نسخه یا بشپړ رسمي پیچ سیټ وکاروئ                                      | د څانګې سمون، د انحصار بشپړول، د تمدید مطابقت او د ریګریشن تیریدل |
| موضوع 7.4, 8.0, 8.1                            | د پلورونکي بیک پورټ ته لومړیتوب ورکړئ؛ که اړتیا وي د رسمي بیړني سرچینې کوډ څانګه ارزونه وکړئ | د چلند بدلونونه وپیژنئ او ملاتړ شوي نسخو ته د مهاجرت مهالویش وکړئ |

رسمي پیچونه خپاره شوي، او حقیقي اصلاحات باید له دې پیچونو څخه پیل شي. په 6 برخه کې د کوډ ټوټې د ډیزاین او بیاکتنې عالي توضیحاتو روښانه کولو لپاره دي او یو بشپړ پیچ نه جوړوي چې په خپلواکه توګه پلي کیدی شي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-6)

## 4. د ترمیم رسمي پروسه

### 4.1 د رن ټایم لیست چې واقعیا غوښتنې اداره کوي

دا سپارښتنه کیږي چې لږ تر لږه د ثبت کولو لپاره یو لنډ لیجر جوړ کړئ:

- د ننوتلو ډومین نوم یا خدمت، ریورس پراکسي بیکینډ، PHP SAPI.
- PHP څانګه، د بشپړ پیکج نسخه یا د عکس هضم، سرچینه جوړ کړئ.
- FPM pool، د حقیقي خدماتو واحد، کانټینر یا Pod، د نقلونو شمیر.
- تمدیدونه، اصلي ترتیب او اضافي ترتیب فایلونه پورته شوي.
- ایا د PHP نورې نسخې، زاړه ځای پرځای کولو کاپي، یا اصلي پورټل شتون لري چې مستقیم لاسرسی کیدی شي؟

دا د پلي کولو وړاندیزونه دي ترڅو "پرمختللي" د هر ریښتیني ترافیک ننوتلو سره مطابقت ولري. په ځانګړې توګه وګورئ چې ایا د کمانډ لاین PHP او Web PHP مختلف نسخې کاروي، عکس جوړ شوی مګر زوړ کانټینر لاهم روان دی، د حوض یوه برخه یا کاپي نه بدلیږي، او داسې نور.

### 4.2 سم اوسمهال وټاکئ او ځای په ځای کړئ

د 3 برخې سره سم د فکس نسخه تایید کړئ، په غوره توګه د موجوده باوري کڅوړې سرچینې یا کنټرول شوي ساختماني سلسلې په کارولو سره. د تازه کولو ساحه کې باید هغه برخه شامله وي چې په حقیقت کې غوښتنه کوربه کوي، لکه د FPM بسته، د Apache PHP ماډل، CGI بائنری، یا د خدماتو جوړښت چې په کې PHP ځای پرځای شوي.

د لوړولو دمخه، د ترتیب او بسته بندي لیست وساتئ، او د تولید په څیر چاپیریال کې د پیل او کلیدي خدماتو تصدیق وکړئ. د ځان ساتل شوي توسیعونو لپاره ، د PHP نسخې سره مطابقت لرونکی جوړ او چلول چیک کړئ. یوازې د بلې څانګې څخه د ښکاري اړونده ژمنې غوره کول دا تضمین نه کوي چې د اصلاحاتو ټوله سیټ پلي شوي.

### 4.3 د چلولو مثالونو بیا پیل یا رول اوور کړئ

د فایل نصب کول او په پروسه کې د نوي کوډ پورته کول دوه مختلف شیان دي. اړوند خدمت باید بیا پیل شي، یا د رولینګ بدیل باید بشپړ شي، او زاړه کارګر او زاړه کانټینر باید د وتلو تصدیق شي.

د mod\_php لپاره، د ماډل کوربه کولو Apache پروسې بیا پیل کړئ. هغه خدمتونه چې PHP ځای په ځای کوي د دوی د کوربه توب پروسې ته اړتیا لري. د FPM لپاره، د OPcache پاکول د چلولو وخت تازه کول او د زاړه کارمندانو تقاعد نه بدلوي.

کله چې د زړه راښکونکي سویچنګ کارول ، تاسو اړتیا لرئ وګورئ چې ایا د زاړه نسل پروسه لاهم اوږدې اړیکې یا پاتې غوښتنې اداره کوي. د منلو ریکارډ کې باید اصلي خدمت، د ځای پرځای کولو نسخه، د بشپړولو وخت بدلول، او د زاړه مثال څخه د وتلو پایلې شامل وي.

### 4.4 د اصلي Web غوښتنو له لارې تایید کړئ

دا سپارښتنه کیږي چې د شواهدو لاندې برخې یوځای کړئ د دې پرځای چې یوازې د یوې نسخې کمانډ باندې تکیه وکړئ:

| شواهد                                             | څه ثابت کیدی شي                | یوازې هیڅ شی نشي ثابتولی              |
| ------------------------------------------------- | ------------------------------ | ------------------------------------- |
| د بسته بندي مدیر یا د عکس میټاډاټا                | د نصب سرچینې او بشپړ جوړونه    | ټرافیک په دې حالت کې بدل شوی دی       |
| د پروسې او پلي کولو حالت                          | کارګر یا کانټینر بدیل بشپړوي   | بهرنۍ دروازه باید ورته واستول شي      |
| د ریښتیني پورټل له لارې لاسرسي محدود تشخیصي پایلې | اصلي Web SAPI او د چلولو ترتیب | ایا د خوشې کولو بیک پورټ دوه CVE پوښي |
| د پلورونکي اعلان یا بشپړ پیچ ریکارډ               | دا بګ فکس پدې جوړښت کې شامل دی | ټول نقلونه ځای پر ځای شوي دي          |

`PHP_VERSION`، `PHP_SAPI`، بار شوي ترتیب شوي فایلونه، او بیړني تشکیلات د موجوده داخلي تشخیصي وړتیاوو، یا لنډمهاله او لاسرسي کنټرول تشخیصي پورټلونو له لارې معاینه کیدی شي. ډاډ ترلاسه کړئ چې غوښتنه په مستقیم ډول د CDN یا د پاڼې کیچ لخوا نه راستنیږي؛ کله چې بشپړ شي لنډمهاله تشخیصي ننوتل لرې کړئ.

`php -v` معمولا یوازې د CLI بائنری په ګوته کوي چې اوس مهال د شیل لخوا غوره شوی؛ کمانډونه لکه `php-fpm -i` د موجوده کارکونکي تصدیق کولو سره مساوي ندي چې ترافیک ترلاسه کوي. بشپړ `phpinfo()` پاڼه عامه شبکې ته د اوږدې مودې لپاره مه ښکاره کوئ.

### 4.5 د سوداګرۍ ریګریشن چکونه او د بیړني ترتیباتو لرې کول

د دې بدلون لخوا اغیزمن شوي دندو په شاوخوا کې نورمال ننوتل ، د ناستې لوستل او لیکل ، فورمه او اپلوډ ، واردول ، د غلطۍ اداره کول او د کارګر ثبات تایید کړئ. وګورئ چې ایا د خطا کچه، د غبرګون ځنډ، د حافظې چوکۍ، د پروسې وتلو او بیا جوړونې فریکونسۍ غیر معمولي دي.

که چیرې `memory_limit=-1` په لنډمهاله توګه تنظیم شي، د سوداګرۍ ظرفیت سره سمون لرونکې محدوده بودیجه به د رسمي پیچ اغیزمن کیدو وروسته بیرته راستانه شي؛ که `pm.max_requests=1` ترتیب شوی وي، د ظرفیت ارزول شوي د ژوند دورې ترتیب به د ترمیم تایید وروسته بیرته راستانه شي. د ننوتلو اندازې محدودیتونه او سرچینې ته د لاسرسي کنټرول ساتل کیدی شي ځکه چې د سوداګرۍ اړتیاوې حکم کوي.

که د اپ گریڈ په جریان کې د مطابقت مسلې رامینځته شي ، لومړیتوب باید د اغیزمن پورټل ځنډولو ، د هغې بهرني لاسرسي محدودولو ، یا د بیرته راستنیدو دمخه د غوښتنلیک تنظیم کولو ته ورکړل شي. په مستقیم ډول د عامه شبکې ته د خدمت کولو لپاره غیر منظم شوي وخت ته اجازه ورکول به اصلي خطر بیا پرانیزي.

## 5. د کمولو اقدامات کله چې سمدستي پرمختګ ممکن نه وي

دا برخه د لنډمهاله افشا کیدو کمولو یا د شتون ښه کولو لپاره جوړه شوې ده. هر اندازه یوازې یوه ځانګړې لاره پوښي، او د ډیری اقداماتو ترکیب د بشپړ ترمیم سره برابر ندی. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

### 5.1 د PHP دمخه د ترافیک کنټرول ته لومړیتوب ورکړئ

که خدمت ورته اجازه ورکړي، په لنډمهاله توګه د اعتبار وړ سرچینو ته حساس پای ټکي محدود کړئ یا د PHP دمخه د لاسرسي کنټرول پلي کړئ. د اپلوډ کاري بارونو لپاره، د غوښتنې - د بدن اندازه، د ساحې شمیرې، د برخې شمیرې، د هرې برخې سرلیکونه، او د ځنځیر ژوروالی محدود کړئ. هغه خدمتونه چې ملټي پارټ ته اړتیا نلري کولی شي دا په مخکني پای کې رد کړي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

دا محدودیتونه د PHP ته د ټولو ننوتلو پوښښ دي. یوازې د "اپلوډ" په نوم د URL مداخله به نورې ننوتنې له لاسه ورکړي چې لاهم د غوښتنې په بدن کې د PHP لخوا په اتوماتيک ډول تجزیه کیږي. د قضیو لپاره لکه ټوټه شوي لیږدونه، د موجود اعلان شوي اوږدوالي نشتوالی، او داسې نور، حد باید د اصلي لوستلو اندازې پر بنسټ وي؛ غوښتنلیک باید د خپل محصول اندازې بودیجه هم ولري کله چې مینځپانګه بیا ډیمپریس یا پراخوي.

### 5.2 FPM pool ترتیب کونډۍ

لاندې ترتیبات د **FPM pool ترتیب برخه کې ځای په ځای کړئ چې په حقیقت کې د** غوښتنې خدمت کوي، نه په `php.ini` کې لفظي. د 8M او 4M ارزښتونه د کار بار لپاره د تنظیم کولو مثالونه دي. د فارم ساحو او څو اړخیزو حدودو لپاره خونه پریږدئ کله چې د POST ټولې غوښتنې محدودې کړئ. [S11](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-12)

```ini
; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
```

**PHP 8.5** یوازې، جمع:

```ini
php_admin_flag[fatal_error_backtraces] = off
```

د هر یو دندې او حدود په لاندې ډول دي:

| ترتیب                                 | متوقع اغیز                                                    | د محدودیتونو توضیحات چې باید وساتل شي                                                                          |
| ------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `memory_limit=-1`                     | د وړاندوینې وړ PHP غوښتنه د حافظې پورتنۍ حد محرک حالت لرې کړئ | دا د اصلي تخصیص ناکامۍ مخه نه نیسي؛ د اصلي بودیجې لغوه کول ممکن د حافظې ستړیا او د خدماتو مداخلې خطر زیات کړي. |
| کوچنی `post_max_size`                 | د پارس کولو پروسې ته د ننوتلو معلوماتو اندازه کم کړئ          | نه ثابت شوی پارسر پیژندل شوی تشه لري؛ د حافظې لوړوالی په خپلواک ډول نشي مخنیوی کیدی                            |
| `upload_max_filesize < post_max_size` | د واحد فایل اندازه محدود کړئ او د غوښتنې سر ځای خوندي کړئ     | ټولې ساحې، میټاډاټا، یا د اپلیکیشن تخصیص نه محدودوي                                                            |
| د اپلوډ پرمختګ بند کړئ                | د تایید شوې ناستې اړوند لاره بنده کړئ                         | د نورو نړیوالو دولتي ډولونو پوښښ نه کوي                                                                        |
| PHP 8.5 وژونکي بیکټریس نږدې           | د اړونده حالت تولید کونکي بلاک کړئ                            | نورې لارې نه پوښي لکه سیشن                                                                                     |

د اندازه کولو حدود د رسمي اعلان څخه راځي؛ د حوض ترکیب او مدیریت کچې ترتیب کولو سیمانټیکونو لپاره ، د PHP لارښود وګورئ. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-11)

د مدیریت کچې `php_admin_*` ترتیبات نشي کولی د غوښتنلیکونو لخوا د `ini_set()` له لارې تکرار شي. ټول حوض، د ډایرکټر کچه او د مخکینۍ پای راتلونکی تشکیلات باید لاهم بیاکتنه وشي ترڅو دا تایید کړي چې د حقیقي غوښتنو ارزښتونه لکه څنګه چې تمه کیږي. د ترمیم وروسته، ټول کارګر بیا جوړ کړئ ترڅو د موجوده پروسو مخه ونیسي چې زاړه حالت ته دوام ورکړي.

که تاسو په مستقیم ډول د `php.ini` تعدیل غوره کړئ، ترکیب باید بدل شي:

```ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off
```

په حوض کې د `php_admin_value` برعکس، یوازې په `php.ini` کې د `memory_limit=-1` ترتیب کول د ایپ د بیا ترمیم کولو مخه نه نیسي. چوکاټ، د غوښتنلیک کوډ، او نور تشکیلات باید وڅیړل شي ترڅو وګوري چې ایا دوی محدود ارزښت بیا تنظیم کړی؛ کله چې تطبیق ته اړتیا وي، د اوسني SAPI لپاره مناسب مدیریت کچې ترتیبات وکاروئ او ریښتیني اغیزمن ارزښت چیک کړئ. [S11](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-12)

`fatal_error_backtraces = Off` یوازې د PHP 8.5 لپاره اضافه کړئ. د اپلوډ پرمختګ غیر فعال کولو لپاره د کار په توګه د اپلیکیشن کچې `ini_set()` مه کاروئ، او په FPM `.user.ini` باندې تکیه مه کوئ ترڅو دا د پارس کولو غوښتنه کولو دمخه اغیزمن کړي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)

### 5.3 د PHP حافظې محدودیتونو لرې کولو لګښت اداره کړئ

`memory_limit=-1` د غیر ثابت چاپیریال لپاره د لنډمهاله لارې تخفیف دی او باید د اوږدې مودې ډیفالټ ترتیب په توګه کاپي نشي. کله چې یو غوښتنلیک یا غوښتنه له کنټرول څخه بهر شي، دا کولی شي د کوربه حافظه وکاروي. له همدې امله، د کارولو دمخه، تاسو باید د موافقت شمیره، د واحد واحد کارکونکي، او د خدماتو ټول ظرفیت ارزونه وکړئ، او د مخکینۍ پای ان پټ محدودیتونه ځای په ځای کړئ. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

د کانټینر یا cgroup حافظې محدودیتونه کولی شي د شتون حدود چمتو کړي مګر تضمین نه کوي چې تخصیص به هیڅکله ناکام نشي؛ ټول کانټینر، ماسټر، او ټول کارګر ممکن هم لغوه شي کله چې حد پیل شي. د جلا کولو ګرانولریت او د ختمولو ستراتیژیو ته اړتیا ده چې د ځای په ځای کولو سره ارزونه وشي او د دې دوه CVE لپاره بشپړ محافظت نشي ویل کیدی. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

پورتنۍ ستراتیژۍ د `RLIMIT_AS`، `RLIMIT_DATA`، یا اړونده پروسې پته ځای محدودیتونو سره مه بدلوئ؛ دوی ممکن په مستقیم ډول د اصلي تخصیص لامل شي چې لاهم ستونزې لرونکي OOM لاره کې ناکام شي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)

### 5.4 Nginx د ترتیب بیلګه

د پلي کولو لپاره چیرې چې Nginx PHP-FPM ته غوښتنې وړاندې کوي. دا د اصلي کوربه توب خدمت ترتیب کولو کچه کې تنظیم کیدی شي:

```nginx
client_max_body_size 8m;
fastcgi_request_buffering on;
```

`client_max_body_size` د غوښتنې بدن اندازه محدودوي؛ `fastcgi_request_buffering on` اجازه ورکوي Nginx لومړی د غوښتنې بشپړ متن ولولي او بیا یې FastCGI بیکینډ ته واستوي. ایا دا په یو مشخص `server` یا `location` کې اغیزمن کیږي باید د موجوده میراث او پوښښ اړیکو سره په ګډه وڅیړل شي. [S13](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-14)

**یوازې کله چې سوداګرۍ multipart** ته اړتیا نلري، تاسو کولی شئ د اړوند خدماتو ننوتلو ته د رد کولو قاعده اضافه کړئ:

```nginx
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}
```

دا د ننوتلو یو ساده محدودیت دی چې د `if` او `return` په کارولو سره د پارسر زیانونو لپاره د فلټر کولو عمومي اصول ندي. د ګمارنې دمخه د ترتیب ترکیب او نورمال غوښتنې تایید کړئ ، او وګورئ چې ایا دودیز `error_page` 403 غوښتنې PHP ته لیږدوي. د سټینګ میچنګ د ټولو تحلیلي توپیرونو بشپړ تضمین نه وړاندې کوي. [S15](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-15)

سربیره پردې ، دا تشکیلات په اوتومات ډول د ډیټا مقدار ، د ساحو شمیر ، یا د PHP شیانو شمیر محدود نه کوي چې د غوښتنلیک لخوا ډیمپریس کیدی شي؛ هغه سوداګرۍ چې اپلوډ کولو ته اړتیا لري باید اضافي محدودیتونه وکاروي چې د دوی غوښتنو جوړښت پوهیږي.

### 5.5 اختیاري تخفیف: د هر FPM کارګر یوه غوښتنه

د FPM ګمارلو لپاره چې د سر لګښت کولی شي، لنډ مهاله تنظیمات ارزول کیدی شي:

```ini
pm.max_requests = 1
```

او شته کارکونکي بیا جوړ کړي. دا د کارګر د بیا کارونې په کچه د بیان شوي کراس غوښتنې سلسله بندوي، مګر د پروسې رامینځته کول او پیل کول به ډیر کړي؛ په ورته وخت کې، دا نشي کولی ورته غوښتنه OOM ترمیم کړي او د CVE-2026-109618 پاکولو مسلې. کله چې ارزښت کوچنی وي مګر د 1 څخه ډیر وي، بیا هم د بیا کارولو غوښتنه کړکۍ شتون لري. [S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-11)

### 5.6 WAF او Cloudflare د پوښښ حدود

Cloudflare د PHP2Shell په وړاندې د ساتنې لپاره د ګمارنې ترتیبات اعلان کړي، په شمول د Free پلان. کله چې د دې خدمتونه وکاروئ، تاسو باید وګورئ چې ایا ریښتیني ترافیک د پراکسي له لارې تیریږي ، ایا د محافظت مقررات په عمل کې دي ، او ایا د اصلي سایټ مستقیم تیر کیدی شي؛ د تادیه شوي پلانونو لپاره ، تاسو اړتیا لرئ د اړونده مدیریت شوي مقرراتو ترتیب او استثناوې هم چیک کړئ. [S16](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-16)

د پلورونکي لخوا تشریح شوي ځینې کشفونه د غبرګون سیګنالونه کاروي ، نو ټول محافظت نشي تشریح کیدی ځکه چې "هر برید PHP ته رسیدو دمخه بند شوی دی". WAF کولی شي د افشا کولو کمولو کې مرسته وکړي او مشاهده معلومات چمتو کړي، مګر PHP ته دوامدار اپ گریڈونه لاهم اړین دي. [S16](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-16)

### 5.7 ولې عام اقدامات ناکافي دي

| اقدامات او قضاوت                                      | نیمګړتیاوې                                                                                                                     |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| یوازې `file_uploads` بند کړئ                          | نشي کولی ټول ملټي پارټ پروسس پوښ کړي او خپله OOM لاره پلي کړي                                                                  |
| د `enable_post_data_reading=Off` ترتیب کول            | په اتوماتيک ډول د POST/FILES ډکولو چلند بدل کړئ؛ د غوښتنې بدن لاهم د غوښتنلیک لخوا لوستل کیدی شي او ممکن عادي سوداګرۍ ګډوډ کړي |
| د تېروتنې ښودنه بنده کړئ، لاګ یا `@` وکاروئ           | د داخلي تشخیصي پروسس کول ممکن لاهم د خړ حالت ته لاسرسی ومومي                                                                   |
| د کارکونکو شمیر زیات کړئ                              | د خوندي دولت پاکولو میکانیزم مه رامینځته کوئ ، او نه هم د واحد کارګر بیا کارول له مینځه وړئ                                    |
| یوازې `disable_functions` یا `open_basedir` تنظیم کړئ | دا محدودیتونه د C انجن پرت حافظه فساد نه حل کوي                                                                                |
| یوازې یو ځل یوه نسخه یا یوه کاپي وګورئ                | دا نشي ثابت کیدی چې ټولې ننوتلو او چلولو مثالونه بدل شوي                                                                       |
| هیڅ استثنایی لاګونه نه لیدل کیږي                      | دا نشي ثابتولی چې زیانمنتیا شتون نلري یا دا چې دمخه یې ګټه نه ده اخیستې.                                                       |

د دوی په منځ کې، د PHP ترتیب او د زیان مننې میکانیزم اساس په [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-12) کې موندل کیدی شي؛ د پوښښ، منلو او اجازې د حدودو په اړه قضاوت د دې میکانیزمونو لخوا وړاندې شوي د پلي کولو وړاندیزونو پراساس دي.

## 6. د رسمي پیچ د پلي کولو نظریات او بیاکتنې ټکي

### 6.1 د سمې څانګې لپاره بشپړ اصلاحات وکاروئ

د PHP 8.5 لپاره د نمایندګۍ رسمي سپارنه دا ده:

```text
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout
```

ژمنه په ښکاره ډول دوه CVEs سره شریکوي ، دواړه د OOM وتلو میکانیزم تنظیم کولو او د نړیوال حالت تنظیم کولو لپاره چې ممکن د پیل کولو مرحلې په جریان کې لاسرسی ومومي. د بشپړ توپیر سره پاڼه وړاندې کړئ [S4](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5) وګورئ. نورې څانګې باید خپل رسمي امنیتي ریلیزونه یا مطابقت لرونکي پیچونه وکاروي، او داسې انګیرل نشي چې 8.5 ته بدلونونه په مستقیم ډول په هر زاړه نسخه کې پلي کیدی شي.

### 6.2 OOM ترمیم: لومړی د پروسس وړ حالت بحال کړئ ، او بیا غوښتنه پای ته ورسوئ

رسمي تطبیق د نرم او سخت OOM پروسس کولو دوه درجې معرفي کوي: کله چې نرم حد ته ورسیږي، د پاتې کیدو حالت ثبت کیږي، او کنټرول شوی وتل په خوندي ځای کې ترسره کیږي لکه VM؛ د ناکامه تخصیص انٹرفیس زنګ وهونکي ته اجازه ورکوي چې په څرګند ډول ناکامي اداره کړي. د تخصیصونو لپاره چې نشي کولی مستقیم ناکامي بیرته راستانه کړي، که چیرې د لوړ سخت حد څخه د تیریدو تمه کیږي، پروسه به په مستقیم ډول پای ته ورسیږي ترڅو په ناامنه منځګړیتوب حالت کې د غوښتنو پروسې ته دوام ورکولو څخه مخنیوی وشي. [S2](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

لاندې د 8.5 توپیر کې د کلیدي کوډ یوه اقتباس دی چې د OOM پاتې کیدو نښه کولو لپاره کارول کیږي:

```c
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);
```

VM مداخله اداره کول او نور خوندي ځایونه بیا وروسته `zend_handle_delayed_oom()` ته زنګ ووهي. د دې د کارونکي کوډ اجرا کولو شرایط د کنټرول شوي ناڅاپه لاره کاروي؛ سخت OOM لاره `_exit(137)` بولي. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

د ډیزاین له نظره، مهم بدلونونه دا دي: **avoids په خپله خوښه د C کال سټیک څخه تیریږي کله چې جوړښت په منځني حالت کې وي، او د وتلو ځای په** کې ځای پرځای کوي چې کولی شي د دولت خنډونه وساتي. وروسته له دې چې نرم حد پیل شي، د پروسې بشپړولو لپاره اضافي حافظې ته اړتیا لیدل کیدی شي، نو د نوي نرم حد حد د پروسې د ټولې حافظې لپاره د مطلق پورتنۍ حد په توګه نشي پیژندل کیدی.

او نه هم دا لنډیز کیدی شي لکه "PHP ټول `zend_bailout()` حذف کړي". پیچ لاهم په ځانګړو شرایطو کې اړوند میکانیزمونه کاروي؛ هغه څه چې ټاکل شوي د وتلو خطرناک وخت او ورسره ملګری دولت مدیریت دی. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

### 6.3 د تخصیص زنګ وهونکي او ملټي پارټ پارس کول یوځای تازه کړئ

که تاسو یوازې د تخصیص فعالیت بدل کړئ ترڅو "په ناکامۍ NULL بیرته راشئ" او اصلي زنګ وهونکی لاهم داسې انګیري چې یو باوري پوائنټر تل بیرته راستون شوی ، تاسو به نوي نول پوینټر لاسرسی یا نامکمل پاکول معرفي کړئ. په پیچ کې د تخصیص ناکامه انٹرفیس باید د زنګ وهونکي چیک کولو او استثنا تبلیغاتو سره یوځای بیاکتنه وشي. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

د ملټي پارټ اړوند فکسونو کې د ریښتیني لوستلو حجم پراساس د مجموعي چکونو ترسره کول ، د بې ګټې یا نقل سرلیکونو پروسس کمول ، او د دوامداره وتلو او پاکولو منطق غوره کول شامل دي کله چې OOM پاتې وي. دا بدلونونه دواړه د سرچینو پراخول کموي او پارسر د نوي OOM پروتوکول سره مطابقت کوي. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

د هغو ټیمونو لپاره چې خپلې څانګې ساتي، دا سپارښتنه کیږي چې لاندې مسلې د کوډ بیاکتنې تمرکز وي:

- ایا دولت بهرنۍ نړۍ ته د بشپړ پیل کیدو دمخه لیدل کیږي؟
- د تخصیص ناکامۍ یا د کال بیک استثنا وروسته ، ایا ملکیت لاهم ځانګړی او مبهم دی؟
- ایا تاسو کولی شئ د پاکولو متحد وتلو ته ورسیږئ که تاسو په مینځ کې ناکام شئ؟
- ایا د پاکولو فعالیت غیر پیل شوي یا آزاد شوي ساحې پیژني؟
- ایا د تجزیې بودیجه د اصلي پروسس کولو حجم پراساس ده ، نه یوازې د باور غوښتنې ادعا؟
- ایا د نوي ناکامۍ بیرته ستنیدو ارزښت د ټولو زنګ وهونکو لخوا اداره شوی؟

دا د بیاکتنې پوښتنې دي چې د فکس میکانیزم پراساس لنډیز شوي، او د یوې پلټنې پایله نه ده چې د نه چمتو شوي کوډ بیس لپاره بشپړه شوې.

### 6.4 د کراس غوښتنې حل: دمخه پیل کول ، وروسته وروستی پاکول

د CVE-2026-109619 سره مطابقت لري، پیچ په ورته وخت کې د ډیری ژوند دورې حدود تنظیموي. لاندې لست شوي فایلونه او عملیات د مثال په توګه د PHP 8.5 رسمي توپیر اخلي. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

| ځای                                        | سمت بدلول                                                                       | ستونزه حل شوه                                                                                     |
| ------------------------------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c` etc.             | د اجرا کونکي حالت بیا تنظیم کړئ لکه تېروتنې، استثناوې، سمبالونکي، توکي، او نور. | د غوښتنې پای ته رسیدو وروسته ، لاهم زاړه حوالې شتون لري چې د راتلونکي غوښتنې لخوا لاسرسی کیدی شي. |
| د `main/main.c` د پیل لاره                 | مخکې له دې چې SAPI فعال شي `php_basic_early_rinit()` ته زنګ ووهئ                | کله چې یو ابتدايي پیرودونکي واقع کیږي، اړونده اصلي حالت لا تر اوسه نه دی پیل شوی.                 |
| د `main/main.c` لاره تړل                   | HTTP globals له منځه یوسي او د نه تعریف شوي په توګه یې په نښه کړئ               | خپور شوی ارزښت لاهم یو باوري څیز ګڼل کیږي                                                         |
| مخکې لدې چې د غوښتنې ډنډ په پای کې خلاص شي | وروستی خطا پیغام بیا پاک کړئ                                                    | د ناوخته پاکولو تشخیص د تېروتنې حالت تکراروي                                                      |
| `ext/session/session.c`                    | د اپلوډ پرمختګ د پیل لاره د لومړي سیشن نړیوال پیل شوی                           | منظم ماډل RINIT پخوا زاړه حالت ته لاسرسی وموند                                                    |
| د سریال کولو اړوند کوډ                     | په لومړني پروسس کې د ټولګي پارس کولو او د کارونکي کال بیکونه محدود کړئ          | د کارن اضافي کوډ اجرا کړئ کله چې پیل بشپړ شوی نه وي                                               |

د مثال په توګه، د پیل کولو لړۍ کې شامل دي:

```c
zend_activate();
php_basic_early_rinit();
sapi_activate();
```

وروسته له دې چې HTTP globals ویجاړ شو، د وضعیت ناکامۍ نښه اضافه کړئ:

```c
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);
```

دا اقتباسات دوه اصول بیانوي: **د لومړني احتمالي مصرف کونکي څخه دمخه پیل کړئ ، او د وروستي عملیاتو وروسته وروستی پاکول ترسره کړئ چې ممکن حالت بیا رامینځته کړي.** یوازې په نورمال حالت کې د اشارې بیا تنظیم کول RINIT یا د مخکینۍ بندیدو مرحله ممکن دمخه یا وروسته لاسرسي له لاسه ورکړي. [S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

### 6.5 ولې دا سپارښتنه نه کیږي چې خپل "یو لاین ترمیم" جوړ کړئ؟

د ټولو ځای پر ځای کول `zend_bailout()` سره `_exit()` ، یا یوازې په یو ټاکلي ننوتلو کې د نول پوائنټر چیک اضافه کول به د مختلف اجرا کولو شرایطو لوی شمیر پراخه کړي. دوی ممکن د وضعیت نورې ساحې پریږدي، یا دوی ممکن ویجاړتیا، پراخ شوي کال بیکونه، د پروسې کوربه کول، او د پای سیمانټیک غوښتنه وکړي.

د ملاتړ شوي نسخو لپاره، بشپړ اصلاحات چې دمخه خپاره شوي لومړیتوب لري. د خپلو څانګو مهاجرت باید د پیچونو سرچینه ثبت کړي، د تطبیق وړ اساسات، د شخړو اداره کول او د چلند بدلونونه، او د اړونده اپ سټریم ریګریشن کارولو قضیې او د دې سوداګرۍ پروسې تصدیق کارول. دلته وړاندیزونه د تخصیص کونکي ، VM ، ناستې او د ژوند دورې بدلونونو غوښتنه کولو کې د پیچ ​​ساحې تحلیل څخه راځي. [S4](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-5)

## 7. د PHP 7.4، 8.0، 8.1 بیړني بیک پورټ

PHP په رسمي ډول د شدت پراساس د دریو پخوانیو څانګو لږترلږه سرچینې کوډ بیک پورټ چمتو کوي. د څانګو نومونه دا دي:

```text
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619
```

د څانګې لینکونو لپاره، [S7](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-9) وګورئ. دا د دې زیان مننې لپاره بیړني تحویلي دي او د زاړه څانګې لپاره منظم اپ سټریم مالتړ ته بیرته راستنیدو استازیتوب نه کوي ، او نه یې نور امنیتي تازه معلومات ځای په ځای کوي. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)

### 7.1 د مثال په توګه PHP 8.1 بیک پورټ واخلئ

د PHP 8.1 لپاره اړونده سپارښتنې دي:

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

د دې ستراتیژي په چټکۍ سره د ناکامۍ سره مرسته کوي: د OOM په اړونده لاره کې د تشخیص د تولید وروسته د `_exit(1)` زنګ وهل، او د نړیوال وضعیت او نورو اړوندو سمونونو په شمول؛ پداسې حال کې چې په داخلي توګه د سیشن اپلوډ پرمختګ اړوند پروسس غیر فعالوي. د اړونده سرچینې کوډ سپارلو لپاره، [S6](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-6) وګورئ.

دا په ملاتړ شوي څانګه کې د ډیر بشپړ ځنډ شوي OOM ډیزاین څخه د چلند توپیر دی. یوازې د دې لپاره چې ترتیب لاهم ښیي چې د اپلوډ پرمختګ روان دی، دا پدې معنی ندي چې د دې بیکپورټ وروسته د داخلي پروسس کولو چلند به بدل نشي.

### 7.2 هغه قیمت چې تاسو یې د پلي کولو پرمهال منلو ته اړتیا لرئ

د پروسې څخه په مستقیم ډول وتل ممکن د اوسني غوښتنې د ناکامۍ لامل شي، د عادي PHP بند کولو کال بیکونه پریږدي او د غوښتنلیک بندولو برخه؛ که کوربه د تار ماډل غوره کړي، نو دا هم اړینه ده چې په نورو همغږي کارونو باندې د ټول کوربه پروسې د وتلو اغیز و ارزول شي. ایا د پروسې مدیر کولی شي د وخت په تیریدو سره د بدیل پروسه پرمخ بوځي باید په تایید کې هم شامل شي.

نو ځکه، د پخوانیو نسخو کاروونکي باید په ترتیب سره په پام کې ونیسي:

1. ملاتړ شوي PHP څانګې او د هغې ثابت نسخه ته مهاجرت وکړئ.
2. یو ریلیز وکاروئ چې په ښکاره ډول دواړه CVE یا LTS جوړونکي تازه پوښي.
3. که دا په حقیقت کې د سرچینې کوډ د زاړه نسخې تابع وي، د بشپړ بدلونونو او مطابقت تصدیق کولو لپاره د سمون نسخه رسمي بیړني بیکپورټ وکاروئ، او د راتلونکي مهاجرت تنظیم کړئ.

"لږترلږه بیک پورټ" دلته د مطابقت او پلي کولو ساحه تشریح کوي چې د چارواکو لخوا غوره شوی، او باید په اتوماتيک ډول د "معلوم شوي نامکمل زیانمننې اصلاحات" په توګه تشریح نشي. تاسو باید د اړوندې څانګې د سرچینې کوډ او د تولید کونکي اعلان پراساس قضاوت وکړئ ، او پخپله ملاتړ کونکي بدلونونه حذف مه کوئ. [S1](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/ps/insights/php2shell-remediation-guide#source-6)

## 8. د منلو معیارونه او تعقیبي معاینات

دا سپارښتنه کیږي چې لاندې پایلې د دې ترمیم بشپړولو لپاره د اساس په توګه وکارول شي:

| د منلو وړ توکي          | د بشپړولو معیارونه                                                                                               |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------- |
| د زیان مننې پوښښ        | د جوړولو یا پلورونکي اعلان په واضح ډول د CVE-2026-109618 او CVE-2026-109619 حل کوي                               |
| د ځای پرځای کولو پوښښ   | ټول پورټلونه، حوض، خدمات او نقلونه د ترمیم شوي وخت وخت کاروي                                                     |
| پروسه اغیزمن کیږي       | زوړ کارګر، زوړ کوربه بهیر او زاړه کانټینر ټول وځي                                                                |
| د مستند غوښتنې تایید    | تایید شوی SAPI، د اصلي Web لینک سره جوړ او ترتیب شوی ترڅو د کیچ غلط لارښوونې له منځه یوسي                        |
| د سوداګرۍ شتون          | کلیدي دندې لکه سیشن، اپلوډ کول، واردول، او د خطا اداره کول په نورمال ډول بیرته راستانه شوي.                      |
| د لنډمهاله اقداماتو پای | لامحدود حافظه او د خورا کارګر ریسایکل کولو ترتیبات د ظرفیت پلان سره سم بحال شوي یا د ساتلو لپاره روښانه دلیل لري |
| د بدلون ثبوت            | د بسته بندۍ نسخه یا د عکس هضم ثبت کړئ ، ساحه تازه کړئ ، د بشپړیدو وخت او د تایید پایلې                           |

پورته د پلي کولو لپاره وړاندیزونه دي. که تاسو د OOM چلند، غیر معمولي وتلو، یا دودیز پیچونو تصدیق کولو ته اړتیا لرئ، تاسو باید په جلا چاپیریال کې د اپسټریم ریګریشن ټیسټ یا کنټرول شوي غلط انجیکشن وکاروئ ترڅو د منلو میتود په توګه د تولید چاپیریال کې د بار بار حافظې ستړیا رامینځته کولو مخه ونیسئ.

همدا رنګه د PHP وژونکي، د کارګر حادثه، غیر معمولي بیا پیل، د غوښتنې اندازه او د تازه کولو دمخه او وروسته د WAF پیښې وګورئ. لاګز کولی شي یوازې د تحقیقاتو نښې وړاندې کړي: د OOM واقع کیدل پدې معنی ندي چې دا استخراج شوی دی، او د الارم نشتوالی دا نه ثابتوي چې هیڅ استحصال نه دی شوی. اپ گریڈ د زیان مننې لارې حل کوي چې په راتلونکي کې ورته رسیدلی شي؛ که ګډوډي لکه د فایل لاسوهنه یا د اسنادو لیک وموندل شي، د پیښې جلا تحقیقات باید ترسره شي.

## ضمیمه: حواله شوي سرچینې او لینکونه

ټولې سرچینې لینکونه لاندې راټول شوي. مشورې، پیچونه، او د پلورونکي لارښود د **October 22، 2026** چکونه منعکس کوي؛ ورپسې ګمارنې باید د پلورونکي تازه معلومات وګوري. په متن کې شمیرل شوي حوالې دې ننوتلو ته اشاره کوي.

### S1 - PHP رسمي امنیتي خبرتیا او ترمیم نسخه

- سرچینه: پروژه PHP، د اکتوبر 21، 2026.
- موخه: د خطر ساحه، د ترمیم څلور رسمي نسخې، رسمي لنډمهاله اقدامات او د زړو څانګو لپاره د بیړني بیک پورټ لارښوونې.
- سرچینه: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) په کلنۍ بلټین آرشیف کې دی

### S2 — CVE-2026-109618 رسمي تخنیکي خبرتیا

- سرچینه: php/php-src GitHub Security Advisory، د اکتوبر 21، 2026.
- پیژندنه: GHSA-w8hw-w9fx-j79w.
- موخه: د OOM لپاره د پوښښ حد، څو اړخیز امپلیفیکیشن، SAPI توپیر او کمول.
- سرچینه: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

### S3 — CVE-2026-109619 رسمي تخنیکي خبرتیا

- سرچینه: php/php-src GitHub Security Advisory، د اکتوبر 21، 2026.
- پیژندنه: GHSA-6wmf-4rv5-p3rp.
- موخه: د کراس غوښتنې ډانګلینګ حالت، تولیدونکي او مصرف کونکي، د پیل پیل، د ترتیب کمول.
- سرچینه: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### S4 — PHP 8.5 رسمي فکس سپارل

- سرچینه: php/php-src.
- سپارل: `31c0ea7d7ff1d1fccb6492e52dab544011628065`.
- موخه: په ورته وخت کې د دوه زیانونو د حل کولو لپاره رسمي سپارل تایید کړئ، او د عمومي بدلون سمت تشریح کړئ.
- سرچینه: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065)

### S5 - PHP 8.5 په رسمي ډول بحال او بشپړ توپیر

- سرچینه: د ورته رسمي سپارښتنې څخه توپیر لري.
- موخه: د تخصیص ځانګړي تطبیق چیک کړئ، VM، HTTP globals، سیشن، سیریل کولو او د ژوند دورې غوښتنه وکړئ.
- سرچینه: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff)

### S6 - PHP 8.1 رسمي بیړني بیک پورټ سپارل

- سرچینه: php/php-src.
- سپارل: `1d7dec178a094e6e75b229ce22754045f8c6070a`.
- موخه: د زړو څانګو ګړندۍ وتل وګورئ او د پرمختګ چلند بدلونونه اپلوډ کړئ.
- سرچینه: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a)
- سرچینه: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff)

### S7 - PHP 7.4 رسمي بیړني بیرته پورټ څانګه

- سرچینه: php/php-src، PHP د سرچینې کوډ څانګې په رسمي امنیتي بلټین کې لیست شوي.
- سرچینه: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)

### S8 - PHP 8.0 رسمي بیړني بیرته پورټ څانګه

- سرچینه: php/php-src، PHP د سرچینې کوډ څانګې په رسمي امنیتي بلټین کې لیست شوي.
- سرچینه: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)

### S9 - PHP 8.1 رسمي بیړني بیرته پورټ څانګه

- سرچینه: php/php-src، PHP د سرچینې کوډ څانګې په رسمي امنیتي بلټین کې لیست شوي.
- سرچینه: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)

### S10 — Ubuntu امنیتي خبرتیا USN-8948-1

- سرچینه: Canonical / Ubuntu، د اکتوبر 21، 2026.
- هدف: د بیک پورټ خوشې کول او د بسته بندۍ بشپړ نسخه مثالونه.
- سرچینه: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)

### S11 — PHP-FPM Configuration لارښود

- سرچینه: PHP رسمي سند.
- موخه: د ترتیب سیمانټیکونه لکه `php_admin_value`، `php_admin_flag`، `pm.max_requests`، او داسې نور.
- سرچینه: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php)

### S12 — PHP اصلي INI ترتیب لارښود

- سرچینه: PHP رسمي سند.
- موخه: د غوښتنې بدن، اپلوډ، حافظې او اتوماتیک POST لوستلو ترتیب تعریف او ساحه.
- سرچینه: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php)

### S13 - Nginx د بدن د اندازې حد غوښتنه کوي

- سرچینه: Nginx رسمي سند.
- موخه: د `client_max_body_size` معنی او د موجودو تشکیلاتو کچه.
- سرچینه: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

### S14 — Nginx FastCGI غوښتنه بفر

- سرچینه: Nginx رسمي سند.
- موخه: د پروسس ترتیب او د `fastcgi_request_buffering` فعالیت.
- سرچینه: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering)

### S15 - Nginx حالت او د راستنیدو لارښوونې

- سرچینه: Nginx رسمي سند.
- موخه: د `if` او `return` ترتیب ترکیب.
- سرچینه: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

### S16 - Cloudflare PHP2Shell د ساتنې لارښوونې

- سرچینه: Cloudflare رسمي بلاګ.
- موخه: د دې WAF د ځای پرځای کولو ساحه، د Free پلان ترتیب او د کشف میکانیزم تشریح.
- سرچینه: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

## د امنیت ساتنې مشورې

ستاسو د PHP سیسټمونو تازه کولو کې مرستې ته اړتیا لرئ؟ موږ کولی شو د افشا کیدو ارزونه وکړو ، تازه پلان جوړ کړو او روان غوښتنلیک تصدیق کړو.

[د امنیتي تازه معلوماتو په اړه بحث وکړئ](<https://keendigit.com/ps/contact?service=security-remediation#form>)

[اصلي پاڼه](<https://keendigit.com/ps/insights/php2shell-remediation-guide>) · [د منځپانګې شاخص](<https://keendigit.com/ps/llms.txt>)

KeenDigit LLC · د وومینګ فایل کولو ID: 2026-002106155

[د وومینګ د بهرنیو چارو وزیر سره تایید کړئ](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Sheridan, Wyoming, د امريکا متحده ايالات · ټول حقونه خوندي دي.