---
title: "PHP2Shell: ਕਾਰਨ ਅਤੇ ਉਪਚਾਰ ਗਾਈਡ"
description: "PHP2Shell ਜੀਵਨ ਚੱਕਰ ਦੀਆਂ ਖਾਮੀਆਂ, ਰਨਟਾਈਮ ਅੱਪਗਰੇਡਾਂ, ਅਸਥਾਈ ਕਮੀਆਂ, ਪੈਚ ਚੋਣ, ਅਤੇ ਲਾਈਵ Web ਬੇਨਤੀ ਮਾਰਗ ਰਾਹੀਂ ਪੁਸ਼ਟੀਕਰਨ ਨੂੰ ਸਮਝੋ।"
language: "pa"
url: "https://keendigit.com/pa/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: ਕਾਰਨ ਅਤੇ ਉਪਚਾਰ ਗਾਈਡ

PHP2Shell ਜੀਵਨ ਚੱਕਰ ਦੀਆਂ ਖਾਮੀਆਂ, ਰਨਟਾਈਮ ਅੱਪਗਰੇਡਾਂ, ਅਸਥਾਈ ਕਮੀਆਂ, ਪੈਚ ਚੋਣ, ਅਤੇ ਲਾਈਵ Web ਬੇਨਤੀ ਮਾਰਗ ਰਾਹੀਂ ਪੁਸ਼ਟੀਕਰਨ ਨੂੰ ਸਮਝੋ।

**ਸਰੋਤਾਂ ਦੀ 22 ਅਕਤੂਬਰ 2026 ਤੱਕ ਜਾਂਚ ਕੀਤੀ ਗਈ।** **Audience: PHP ਐਪਲੀਕੇਸ਼ਨ ਆਪਰੇਟਰ, ਸੁਰੱਖਿਆ ਜਵਾਬ ਦੇਣ ਵਾਲੇ, ਅਤੇ ਕਸਟਮ PHP ਬਿਲਡਸ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਵਾਲੇ ਇੰਜੀਨੀਅਰ।**

ਇਹ ਲੇਖ PHP2Shell ਕਮਜ਼ੋਰੀ ਦੇ ਕਾਰਨ, ਪ੍ਰਭਾਵ ਦੀ ਗੁੰਜਾਇਸ਼, ਰਸਮੀ ਮੁਰੰਮਤ ਪ੍ਰਕਿਰਿਆ, ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਘਟਾਉਣ ਦੇ ਉਪਾਅ ਅਤੇ ਅਧਿਕਾਰਤ ਪੈਚ ਲਾਗੂ ਕਰਨ ਦਾ ਸਾਰ ਦਿੰਦਾ ਹੈ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1) ਵਰਗੇ ਨੰਬਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੁੱਖ ਟੈਕਸਟ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ; ਸਾਰੇ ਸਰੋਤ ਲਿੰਕ ਟੈਕਸਟ ਦੇ ਅੰਤ ਵਿੱਚ ਅੰਤਿਕਾ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕੀਤੇ ਗਏ ਹਨ। ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਰੈਗਮੈਂਟ ਇੱਕ ਤੈਨਾਤੀ ਟੈਂਪਲੇਟ ਹੈ, ਜਿਸ ਨੂੰ ਅਸਲ ਸੰਸਕਰਣ, ਕਾਰੋਬਾਰੀ ਸਮਰੱਥਾ, ਅਤੇ ਸੰਰਚਨਾ ਵਿਰਾਸਤ ਸਬੰਧਾਂ ਦੇ ਅਧਾਰ ਤੇ ਐਡਜਸਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

## TL;DR: ਮੁਰੰਮਤ ਦੇ ਕਦਮ ਅਤੇ ਸੁਝਾਅ

1. **ਨੂੰ ਅੱਪਗਰੇਡ ਕਰੋ PHP ਰਨਟਾਈਮ** : ਸਬੰਧਤ ਸ਼ਾਖਾ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਅਪਗ੍ਰੇਡ ਕਰੋ **8.2.35 , 8.3.36 , 8.4.27 ਜਾਂ 8.5.12** . ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਪੈਕੇਜਾਂ ਲਈ, ਪੂਰੇ ਪੈਕੇਜ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਸਦੀ ਵਿਕਰੇਤਾ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ CVE ਫਿਕਸ ਕੀਤੇ ਗਏ ਹਨ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1) [S10](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-10)
2. **ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਬਦਲੋ** : ਹਰ ਇੱਕ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ ਜਾਂ ਰੋਲ ਕਰੋ PHP worker , ਅਪਗ੍ਰੇਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੋਸਟਿੰਗ ਸੇਵਾ, ਅਤੇ ਕੰਟੇਨਰ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੁਰਾਣੀਆਂ ਉਦਾਹਰਣਾਂ ਬੰਦ ਹੋ ਗਈਆਂ ਹਨ।
3. **ਅਸਲ Web ਬੇਨਤੀ path** ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕਰੋ: Web SAPI, ਪੂਰੇ ਪੈਕੇਜ ਸੰਸਕਰਣ, ਅਤੇ ਚੱਲ ਰਹੇ ਉਦਾਹਰਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਕੱਲੇ `php -v` ਦੀ ਜਾਂਚ ਕਰਨਾ ਇਹ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਲਾਈਵ ਸੇਵਾ ਸਥਿਰ ਹੈ।
4. **ਕਾਰੋਬਾਰੀ ਰਿਗਰੈਸ਼ਨ ਜਾਂਚ ਚਲਾਓ ਅਤੇ ਆਮ ਸਰੋਤ ਬਜਟ ਨੂੰ ਬਹਾਲ ਕਰੋ** : ਟੈਸਟ ਲੌਗਇਨ, ਸੈਸ਼ਨ ਹੈਂਡਲਿੰਗ, ਅੱਪਲੋਡ, ਆਯਾਤ, ਅਤੇ ਗਲਤੀ ਹੈਂਡਲਿੰਗ। ਜੇਕਰ ਦ PHP ਮੈਮੋਰੀ ਸੀਮਾ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਹਟਾ ਦਿੱਤੀ ਗਈ ਸੀ, ਪੈਚਿੰਗ ਤੋਂ ਬਾਅਦ ਇੱਕ ਢੁਕਵੇਂ ਸੀਮਤ ਬਜਟ ਨੂੰ ਬਹਾਲ ਕਰੋ।
5. **Iਜੇ ਤੁਰੰਤ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਅਸੰਭਵ ਹੈ**: PHP ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੀਮਤ ਕਰੋ। ਸੈਕਸ਼ਨ 5 ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਅਨੁਸਾਰ ਅਪਲੋਡ ਪ੍ਰਗਤੀ ਅਤੇ PHP 8.5 ਘਾਤਕ ਬੈਕਟਰੇਸ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। ਸੰਰਚਨਾ ਘਟਾਉਣ ਅਤੇ WAF ਨਿਯਮਾਂ ਦੀ ਸੀਮਤ ਕਵਰੇਜ ਹੈ ਅਤੇ ਅੱਪਗਰੇਡ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦੇ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

## 1. ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਅਤੇ ਜੋਖਮ ਨਿਰਣਾ

ਇਸ ਲੇਖ ਵਿੱਚ PHP2Shell ਦੋ Critical ਪੱਧਰ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਜੋ 21 ਅਕਤੂਬਰ, 2026 ਨੂੰ PHP ਦੁਆਰਾ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਪ੍ਰਗਟ ਕੀਤੇ ਗਏ ਸਨ। ਦੋਵੇਂ ਹੀ PHP ਇੰਜਣ ਦੀ ਮੈਮੋਰੀ ਅਤੇ ਬੇਨਤੀ ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਬੰਧਨ ਨਾਲ ਸਬੰਧਤ ਹਨ, ਜੋ ਕਿ ਰੀਕਿਊਟ ਕੋਡ ਦੇ ਐਕਸਗੈਕਸ ਕੋਡ ਦੇ ਜੋਖਮ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-1)

"ਤੈਨਾਤੀ ਨੂੰ ਸਥਿਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ" ਅਤੇ "ਇੱਕ ਖਾਸ ਹਮਲੇ ਦੀ ਲੜੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਾਬਤ ਹੋ ਗਈ ਹੈ" ਵਿਚਕਾਰ ਫਰਕ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। CVE-2026-109618 ਦੀ ਘੋਸ਼ਣਾ: FPM ਬੇਨਤੀ ਦੇ ਸ਼ੁਰੂਆਤੀ ਅਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਹਰ ਆ ਜਾਵੇਗਾ, ਸ਼ੁਰੂਆਤੀ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ mod\_php ਦੇ ਅਨੁਸਾਰੀ ਸਫਾਈ ਮਾਰਗ ਨੂੰ ਰੋਕਦਾ ਹੈ; ਹਾਲਾਂਕਿ, ਸਫਲ ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਾਅਦ OOM ਮਾਰਗ ਅਜੇ ਵੀ ਖਤਰੇ ਵਿੱਚ ਹੈ। ਘੋਸ਼ਣਾ ਇਹ ਵੀ ਨੋਟ ਕਰਦੀ ਹੈ ਕਿ ਇਸ CVE ਲਈ ਪੂਰਾ FPM ਸ਼ੋਸ਼ਣ ਅਜੇ ਤੱਕ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਪਾਬੰਦੀ ਦੀ ਵਰਤੋਂ ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲਈ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਕਿ FPM ਸੁਰੱਖਿਅਤ ਹੈ, ਖਾਸ ਕਰਕੇ CVE-2026-109619 ਨੂੰ ਅਣਡਿੱਠ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

ਸਫਲ ਸ਼ੋਸ਼ਣ ਲਈ ਤੁਰੰਤ ਅਨੁਮਤੀ ਦੀਆਂ ਸੀਮਾਵਾਂ PHP ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਛਾਣ ਅਤੇ ਇਸਦੀ ਪਹੁੰਚ ਵਾਲੇ ਸਰੋਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਵੈਬਸਾਈਟ ਕੋਡ, ਅਪਲੋਡ ਡਾਇਰੈਕਟਰੀ, ਡੇਟਾਬੇਸ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਸੇਵਾ ਟੋਕਨਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਨੈਟਵਰਕ ਪਹੁੰਚ ਸਮਰੱਥਾਵਾਂ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; "ਰਿਮੋਟ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ" ਦਾ ਮਤਲਬ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਰੂਟ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇੱਥੇ ਨਤੀਜਾ ਨਿਰਣਾ ਪ੍ਰਕਿਰਿਆ ਅਨੁਮਤੀ ਮਾਡਲ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਅਤੇ ਅਸਲ ਪ੍ਰਭਾਵ ਨੂੰ ਤੈਨਾਤੀ ਅਨੁਮਤੀਆਂ ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਆਮ ਇੱਕ-ਵਾਰ CLI ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀ HTTP ਐਂਟਰੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ; ਪਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜੋ CLI ਜਾਂ ਏਮਬੈਡਡ ਮੋਡ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਲਈ ਬਾਹਰੀ ਕਾਰਜਾਂ ਨੂੰ ਸੰਭਾਲਦੀਆਂ ਹਨ ਅਜੇ ਵੀ ਰਨਟਾਈਮ ਅਤੇ ਜੀਵਨ ਚੱਕਰ ਵਸਤੂ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਿਰਫ਼ CMS, ਫਰੇਮਵਰਕ ਜਾਂ Composer ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅੰਡਰਲਾਈੰਗ PHP ਇੰਜਣ ਨੂੰ ਆਪਣੇ ਆਪ ਬਦਲਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ।

## 2. ਕਾਰਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

### 2.1 ਪਹਿਲਾਂ ਦੋ ਜੀਵਨ ਚੱਕਰਾਂ ਨੂੰ ਸਮਝੋ

PHP worker ਅਕਸਰ ਲਗਾਤਾਰ ਕਈ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਬੇਨਤੀ ਦੇ ਦੌਰਾਨ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਬੇਨਤੀ ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕਸਾਰ ਰੂਪ ਵਿੱਚ ਜਾਰੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਵਰਕਰ ਖੁਦ ਅਤੇ ਇਸਦੇ ਕੁਝ ਗਲੋਬਲ ਖੇਤਰਾਂ ਦੀ ਮੌਜੂਦਗੀ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ।

ਇਸ ਲਈ, ਇੰਜਣ ਨੂੰ ਦੋ ਰੁਕਾਵਟਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ:

- **ਸ਼ੁਰੂਆਤੀ ਪਾਬੰਦੀ**: ਹੋਰ ਕੋਡਾਂ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਡੇਟਾ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਲੰਘਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਨਸ਼ਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
- **Lifecycle Constraint**: ਇੱਕ ਵਾਰ ਬੇਨਤੀ ਮੈਮੋਰੀ ਨੂੰ ਖਾਲੀ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹਿਣ ਵਾਲੇ ਖੇਤਰਾਂ ਨੂੰ ਉਸ ਮੈਮੋਰੀ ਦੇ ਅੰਦਰਲੇ ਪਤਿਆਂ ਨੂੰ ਵੈਧ ਸਥਿਤੀ ਵਜੋਂ ਮੰਨਣਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਦੋ ਰੁਕਾਵਟਾਂ ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਦੋ ਸਮੂਹਾਂ ਦੇ ਮੁੱਖ ਅਸਫਲ ਮੋਡਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਹੇਠ ਦਿੱਤੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਵਿਧੀ ਦਾ ਵਰਣਨ ਹੈ ਜੋ ਘੋਸ਼ਣਾਵਾਂ ਅਤੇ ਪੈਚ ਸੰਕਲਨ ਨੂੰ ਜੋੜਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਹਰ ਤੈਨਾਤੀ ਦਾ ਬਿਲਕੁਲ ਉਹੀ ਪਹੁੰਚਯੋਗ ਮਾਰਗ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618: OOM ਨੇ ਇੱਕ ਅਧੂਰੀ ਸਥਿਤੀ ਅੱਪਡੇਟ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਈ

ਪੁਰਾਣਾ ਲਾਗੂਕਰਨ OOM ਨੂੰ ਸੰਭਾਲਣ ਲਈ `longjmp()` ਕਿਸਮ ਦੀ ਗੈਰ-ਸਥਾਨਕ ਛਾਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੰਬੰਧਿਤ ਮਾਰਗ `zend_bailout()` ਦੁਆਰਾ ਮੌਜੂਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪ੍ਰਸੰਗ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ C ਕੋਡ ਦੇ ਇੱਕ ਟੁਕੜੇ ਨੇ ਇੱਕ ਨਵਾਂ ਆਬਜੈਕਟ, ਐਰੇ, ਜਾਂ ਦੂਜੇ ਕੋਡ ਲਈ ਬੇਨਤੀ ਸਥਿਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਅਜੇ ਤੱਕ ਸਾਰੇ ਫੀਲਡ ਅਰੰਭਕਰਨ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਹੈ; ਇਸ ਸਮੇਂ, ਸੰਬੰਧਿਤ ਸਮੇਂ 'ਤੇ ਕਿਸੇ ਵੀ ਵੰਡ ਦੀ ਅਸਫਲਤਾ ਕਾਰਨ ਆਮ ਬੰਦ ਹੋਣ ਦੇ ਕਦਮਾਂ ਨੂੰ ਛੱਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

ਅਸਫਲਤਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚਾਰ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

1. ਬੇਨਤੀ ਦੇ ਅੰਦਰੂਨੀ ਢਾਂਚੇ ਨੂੰ ਬਣਾਓ ਜਾਂ ਅੱਪਡੇਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਓ।
2. ਬਾਅਦ ਦੀ ਮੈਮੋਰੀ ਵੰਡ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ OOM ਚਾਲੂ ਹੋ ਜਾਂਦਾ ਹੈ।
3. ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਫਲੋ ਮੌਜੂਦਾ ਫੰਕਸ਼ਨ ਤੋਂ ਦੂਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਜਾਂ ਰੀਸਟੋਰ ਸਟੇਟ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਕੋਡ ਚਲਾਇਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ।
4. ਬੇਨਤੀ ਸਫਾਈ ਇਹਨਾਂ ਢਾਂਚਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਦੀ ਹੈ ਅਤੇ ਅਵੈਧ ਸਮੱਗਰੀ ਨੂੰ ਵੈਧ ਖੇਤਰਾਂ ਜਾਂ ਪਤਿਆਂ ਵਜੋਂ ਮੰਨਦੀ ਹੈ।

ਮੁੱਦਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਨਾਲ ਹਮੇਸ਼ਾਂ RCE ਹੁੰਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, **ਮੈਮੋਰੀ ਥਕਾਵਟ ਕੰਟਰੋਲ ਪ੍ਰਵਾਹ ਨੂੰ ਬਦਲਦੀ ਹੈ ਅਤੇ ਵੈਧ ਢਾਂਚੇ** ਬਾਰੇ ਇੰਜਣ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦੀ ਹੈ। ਅਸਫ਼ਲ ਵੰਡ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਸ ਢਾਂਚੇ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਜੋ ਆਖਰਕਾਰ ਗਲਤ ਢੰਗ ਨਾਲ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

#### ਕਿਉਂ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਵੀ ਮੈਮੋਰੀ ਖਤਮ ਹੋ ਸਕਦੀਆਂ ਹਨ

ਬੇਨਤੀ ਬਾਡੀ ਵਿੱਚ ਬਾਈਟਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਪਾਰਸ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀਪ ਦੀ ਵਰਤੋਂ ਇੱਕੋ ਚੀਜ਼ ਨਹੀਂ ਹੈ। A ਖੇਤਰ PHP ਦੇ ਅੰਦਰ ਮਲਟੀਪਲ ਸਤਰ, ਐਰੇ ਐਲੀਮੈਂਟਸ ਅਤੇ ਮੈਟਾਡੇਟਾ ਵਸਤੂਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋ ਸਕਦਾ ਹੈ; ਇੰਪੁੱਟ ਢਾਂਚਾਗਤ ਜਟਿਲਤਾ ਮੈਮੋਰੀ ਐਂਪਲੀਫਿਕੇਸ਼ਨ ਦੀ ਡਿਗਰੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰੇਗੀ।

ਅਧਿਕਾਰਤ ਘੋਸ਼ਣਾ ਵਿੱਚ ਸੂਚੀਬੱਧ ਮਲਟੀਪਾਰਟ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਸ਼ੁਰੂਆਤੀ ਆਕਾਰ ਚੈਕ ਗੈਪ ਜਦੋਂ ਉਪਲਬਧ ਘੋਸ਼ਣਾ ਦੀ ਲੰਬਾਈ ਗੁੰਮ ਹੈ, ਇੱਕ ਹਿੱਸੇ ਲਈ ਸਿਰਲੇਖਾਂ ਦੀ ਸੰਖਿਆ ਕਾਫ਼ੀ ਸੀਮਿਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਖਾਲੀ ਫਾਈਲ ਨਿਯੰਤਰਣ ਅਜੇ ਵੀ ਮੈਟਾਡੇਟਾ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਨੇਸਟਡ ਨਾਮਾਂ ਨਾਲ ਐਰੇ ਵਰਕਲੋਡ ਨੂੰ ਹੋਰ ਵਧਾਉਂਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਅਨਵਾਈਂਡਿੰਗ, ਡੀਕੋਡਿੰਗ, ਜਾਂ ਇਨਪੁਟ ਦੀ ਮੁੜ-ਸਾਈਨਮੈਂਟ ਵੀ OOM ਦਾ ਸਰੋਤ ਹੋ ਸਕਦੀ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

ਇਸ ਤੋਂ ਦੋ ਸੁਰੱਖਿਆਤਮਕ ਸਿੱਟੇ ਕੱਢੇ ਜਾ ਸਕਦੇ ਹਨ:

- ਬੇਨਤੀ ਬਾਡੀ ਪਾਬੰਦੀਆਂ ਨੂੰ PHP ਦਾਖਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਪੜ੍ਹਨ ਦੀ ਲੰਬਾਈ ਅਤੇ ਢਾਂਚਾਗਤ ਗੁੰਝਲਤਾ ਨੂੰ ਵਿਚਾਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਫਾਈਲ ਦੇ ਆਕਾਰ, ਫਾਈਲਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ, ਜਾਂ ਸਿਰਫ ਇੱਕ ਅਪਲੋਡ ਪੋਰਟਲ ਨੂੰ ਬੰਦ ਕਰਨਾ ਸਾਰੇ OOM ਸਰੋਤਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

#### ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿੱਚ ਬਹੁਤ ਦੇਰ ਕਿਉਂ ਹੋ ਸਕਦੀ ਹੈ

mod\_php ਵਿੱਚ, ਬੇਨਤੀ ਦੀ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਦੌਰਾਨ ਬੇਨਤੀ ਬਾਡੀ ਨੂੰ ਆਪਣੇ ਆਪ ਪਾਰਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਭਾਵੇਂ ਸਟਾਰਟਅਪ ਫੇਲ ਹੋ ਜਾਵੇ, ਸੰਬੰਧਿਤ ਬੇਨਤੀ ਸਫਾਈ ਅਜੇ ਵੀ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਸ ਲਈ ਪੁਸ਼ਟੀ ਕੀਤੇ ਹਮਲੇ ਦੇ ਮਾਰਗ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਪੜਾਅ 'ਤੇ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ, Web ਸਰਵਰ, ਜਾਂ PHP ਬੇਨਤੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲੀ ਹੋਰ ਸੀਮਾ 'ਤੇ ਪਾਬੰਦੀਆਂ ਲਗਾਉਣ ਦੀ ਲੋੜ ਹੈ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619: ਬੇਨਤੀ ਮੈਮੋਰੀ ਜਾਰੀ ਕੀਤੀ ਗਈ ਹੈ, ਗਲੋਬਲ ਹਵਾਲਾ ਅਜੇ ਵੀ ਜ਼ਿੰਦਾ ਹੈ

ਇਸ ਮੁੱਦੇ ਵਿੱਚ ਗਲਤੀ, ਸੈਸ਼ਨ, ਆਬਜੈਕਟ, ਜਾਂ ਐਕਸਟੈਂਸ਼ਨ ਸਥਿਤੀ ਸ਼ਾਮਲ ਹੈ: ਫੀਲਡ ਇੱਕ ਵਰਕਰ ਦੇ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਪਹੁੰਚ ਸਥਾਨ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਫੀਲਡ ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਡੇਟਾ ਇੱਕ ਸਿੰਗਲ ਬੇਨਤੀ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਜਦੋਂ ਤੱਕ ਬੇਨਤੀ ਹੀਪ ਜਾਰੀ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹਵਾਲਾ ਸਹੀ ਢੰਗ ਨਾਲ ਸਾਫ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਬਾਅਦ ਦੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕ ਲਟਕਣ ਵਾਲੀ ਸਥਿਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਵਰਤੋਂ-ਬਾਅਦ-ਮੁਫ਼ਤ ਬਣਾਉਂਦੀਆਂ ਹਨ। [S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

ਅਧਿਕਾਰਤ ਵਿਸ਼ਲੇਸ਼ਣ ਸ਼ੋਸ਼ਣ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ "ਉਤਪਾਦਕਾਂ" ਅਤੇ "ਖਪਤਕਾਰਾਂ" ਵਿੱਚ ਵੰਡਦਾ ਹੈ:

| ਭੂਮਿਕਾ ਜਾਂ ਸਥਿਤੀ    | ਮਤਲਬ                                                                                                  | ਸੁਰੱਖਿਆ ਲਈ ਪ੍ਰਭਾਵ                                                       |
| ------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| ਰਾਜ ਉਤਪਾਦਕ          | ਇਸ ਬੇਨਤੀ ਦੀ ਮਲਕੀਅਤ ਵਾਲੇ ਰਾਜ ਨੂੰ ਇੱਕ ਟਿਕਾਣੇ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਤੱਕ ਅਜੇ ਵੀ ਬਾਅਦ ਵਿੱਚ ਪਹੁੰਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ   | ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਕਿ ਕੀ ਅਸਧਾਰਨ ਨਿਕਾਸ ਤੋਂ ਬਾਅਦ ਅਨੁਸਾਰੀ ਸਫਾਈ ਪੂਰੀ ਹੋਈ ਹੈ     |
| ਸਥਿਤੀ ਬਣੀ ਰਹਿੰਦੀ ਹੈ | ਇਹ ਸਾਫ਼ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਾਂ ਇਸ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਫਿਰ ਦੇਰ ਨਾਲ ਕਾਰਵਾਈ ਕਰਕੇ ਦੁਬਾਰਾ ਭਰਿਆ ਗਿਆ ਸੀ। | ਪਹਿਲੇ ਬੰਦ ਪੜਾਅ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਸਾਫ਼ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋ ਸਕਦਾ           |
| ਵਰਕਰ ਮੁੜ ਵਰਤੋਂ      | ਉਹੀ ਕਰਮਚਾਰੀ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ                                              | ਮਲਟੀਪਲ ਵਰਕਰ ਸਿਰਫ਼ ਇੱਕ ਸਮਾਂ-ਸਾਰਣੀ ਅੰਤਰ ਹੈ, ਨਾ ਕਿ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਦੀ ਗਰੰਟੀ |
| ਪੇਸ਼ਗੀ ਖਪਤਕਾਰ       | ਸੰਬੰਧਿਤ ਸਥਿਤੀ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਚੇ ਹੋਏ ਮੁੱਲ ਨੂੰ ਪੜ੍ਹੋ, ਜਾਰੀ ਕਰੋ ਜਾਂ ਨਿਰਧਾਰਤ ਕਰੋ।   | ਸ਼ੁਰੂਆਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ INI, ਸੈਸ਼ਨ ਅਤੇ ਹੋਰ ਮਾਰਗਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ |

ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਸੁਮੇਲ ਵਿੱਚ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ; ਕੋਈ ਵੀ ਗਲਤੀ ਲੌਗ ਆਪਣੇ ਆਪ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਕਮਜ਼ੋਰੀ ਦਾ ਸਫਲਤਾਪੂਰਵਕ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਗਿਆ ਹੈ। [S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

#### ਇਸ ਨੂੰ ਜ਼ਰੂਰੀ ਸ਼ਰਤ ਵਜੋਂ OOM ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ

ਘਾਤਕ ਤਰੁੱਟੀਆਂ ਪੇਅਰਡ ਸਟੇਟ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਬਹਾਲੀ ਵਿੱਚ ਵਿਘਨ ਪਾ ਸਕਦੀਆਂ ਹਨ। ਸੰਕਲਨ ਜਾਂ ਪਾਰਸਿੰਗ ਅਸਫਲਤਾਵਾਂ, ਅਣਪਛਾਤੀਆਂ ਗਲਤੀਆਂ, `require` ਅਸਫਲਤਾਵਾਂ, ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮਆਉਟ ਖਾਸ ਰਾਜਾਂ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਸਕਦੇ ਹਨ। ਸਫਾਈ ਵਿੱਚ ਦੇਰ ਨਾਲ ਗੈਰ-ਘਾਤਕ ਡਾਇਗਨੌਸਟਿਕਸ ਵੀ ਗਲਤੀ ਜਾਣਕਾਰੀ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸਾਫ਼ ਕੀਤੀ ਗਈ ਸੀ। [S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

ਇਸ ਲਈ, `memory_limit` ਨੂੰ ਅਸੀਮਤ ਵਿੱਚ ਬਦਲਣਾ ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਇਸ ਸਮੂਹ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ ਹੈ।

#### "ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ" ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਇਲਾਜ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਦੋ ਕਿਸਮ ਦੇ ਪੁਸ਼ਟੀ ਕੀਤੇ ਖਪਤਕਾਰਾਂ ਦਾ ਸਮਾਂ ਵੱਖਰਾ ਹੈ:

- **Early INI diagnostics**: ਬੇਨਤੀ ਮੁੱਦੇ ਦੀ ਚੇਤਾਵਨੀ, ਨੋਟਿਸ ਜਾਂ ਆਮ ਐਗਜ਼ੀਕਿਊਟਰ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ ਬਰਤਰਫ਼ ਕਰਨ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਕੁਝ ਸੰਰਚਨਾਵਾਂ, ਅਤੇ ਡਾਇਗਨੌਸਟਿਕ ਪ੍ਰੋਸੈਸਿੰਗ ਪੁਰਾਣੀ ਗਲਤੀ ਸਥਿਤੀ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੀ ਹੈ।
- **ਸੈਸ਼ਨ ਅੱਪਲੋਡ ਤਰੱਕੀ**: ਅਨੁਰੋਧ ਬਾਡੀ ਪਾਰਸਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਸੈਸ਼ਨ ਪਹਿਲਾਂ ਤੋਂ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਨਿਯਮਤ ਮੋਡੀਊਲ `RINIT` ਅਜੇ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ ਹੈ; ਇਹ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਮਾਰਗ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ `session_start()` ਨੂੰ ਕਾਲ ਨਹੀਂ ਕਰਦੀ ਹੈ। [S3](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-3)

`display_errors`, `log_errors` ਨੂੰ ਬੰਦ ਕਰਨਾ, `error_reporting` ਨੂੰ ਘਟਾਉਣਾ, ਜਾਂ `@` ਦੀ ਵਰਤੋਂ ਸਿਰਫ ਨਿਦਾਨ ਦੀ ਦਿੱਖ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ; ਲਾਗ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਬੰਧਿਤ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। [S3](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-1)

ਇਹ **ਬ੍ਰਾਂਚ-ਵਿਸ਼ੇਸ਼ ਫਿਕਸ ਥ੍ਰੈਸ਼ਹੋਲਡਜ਼** ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਕਥਨ ਨਾਲ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ ਕਿ 8.5.12 ਤੋਂ ਹੇਠਾਂ ਹਰ ਸੰਸਕਰਣ ਕਮਜ਼ੋਰ ਹੈ: ਹੋਰ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ 8.2.35 ਅਤੇ 8.4.27 ਵਰਗੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਫਿਕਸ ਸ਼ਾਮਲ ਹਨ।

### 3.2 ਪੂਰੇ ਵੰਡ ਪੈਕੇਜ ਸੰਸਕਰਣ ਦੀ ਜਾਂਚ ਕਰੋ

ਡਿਸਟ੍ਰੋਜ਼ ਅਕਸਰ ਪੁਰਾਣੇ ਅੱਪਸਟ੍ਰੀਮ ਸੰਸਕਰਣਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸੁਰੱਖਿਆ ਫਿਕਸ ਜੋੜਦੇ ਹਨ। ਸਵੀਕ੍ਰਿਤੀ ਨੂੰ ਰੀਲੀਜ਼ ਸੰਸਕਰਣ, ਰਿਪੋਜ਼ਟਰੀ ਸਰੋਤ, ਪੂਰਾ ਪੈਕੇਜ ਸੰਸਕਰਣ ਅਤੇ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ ਦੀ ਵੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, Ubuntu USN-8948-1 ਲਈ ਸੂਚੀਬੱਧ Ubuntu 24.04 LTS ਫਿਕਸ ਪੈਕੇਜ ਸੰਸਕਰਣ ਹੈ:

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

ਇਸਦਾ ਅੱਪਸਟਰੀਮ ਹਿੱਸਾ ਅਜੇ ਵੀ `8.3.6` ਹੈ, ਪਰ ਉਸ ਵੰਡ ਦਾ ਪੂਰਾ ਪੈਕੇਜ ਸੰਸਕਰਣ ਇਸ ਫਿਕਸ ਘੋਸ਼ਣਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਸਿੱਟਾ ਸਿਰਫ਼ ਸੰਬੰਧਿਤ ਵੰਡ ਅਤੇ ਪੈਕੇਜ ਸਰੋਤ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਬਿਲਡ ਲਈ ਸਧਾਰਣ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ `8.3.6` ਵੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। [S10](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-10)

### 3.3 ਸਹੀ ਪੈਚ ਚੁਣਨਾ

| ਦ੍ਰਿਸ਼                                               | ਤਰਜੀਹੀ ਯੋਜਨਾ                                                                                | ਸਵੀਕ੍ਰਿਤੀ ਲਈ ਮੁੱਖ ਨੁਕਤੇ                                                           |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| ਵੰਡ PHP ਪੈਕੇਜ ਦੀ ਵਰਤੋਂ ਕਰਨਾ                          | ਨਿਰਮਾਤਾ ਦੁਆਰਾ ਜਾਰੀ ਸੁਰੱਖਿਆ ਅੱਪਡੇਟਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ                                          | ਘੋਸ਼ਣਾ CVE ਦੋਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ; ਪੂਰਾ ਪੈਕੇਜ ਸੰਸਕਰਣ ਸਹੀ ਹੈ                        |
| ਅਧਿਕਾਰਤ PHP ਕੰਟੇਨਰ ਜਾਂ ਸਵੈ-ਨਿਰਮਿਤ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰੋ | ਬੇਸ ਰਨਟਾਈਮ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ, ਦੁਬਾਰਾ ਬਣਾਓ ਅਤੇ ਤੈਨਾਤ ਕਰੋ                                        | ਚੱਲ ਰਹੀ ਉਦਾਹਰਣ ਨਵੀਂ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ; ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਕਾਪੀਆਂ ਬੰਦ ਹੋ ਗਈਆਂ ਹਨ |
| ਸਵੈ-ਕੰਪਾਈਲ ਸਮਰਥਿਤ ਸ਼ਾਖਾਵਾਂ                           | ਇਸ ਸ਼ਾਖਾ ਦੇ ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਸੰਸਕਰਣ ਜਾਂ ਪੂਰੇ ਅਧਿਕਾਰਤ ਪੈਚ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰੋ                   | ਬ੍ਰਾਂਚ ਮੈਚਿੰਗ, ਨਿਰਭਰਤਾ ਸੰਪੂਰਨਤਾ, ਐਕਸਟੈਂਸ਼ਨ ਅਨੁਕੂਲਤਾ ਅਤੇ ਰਿਗਰੈਸ਼ਨ ਪਾਸਿੰਗ           |
| 7.4, 8.0, 8.1 ਦੇ ਅਧੀਨ                                | ਵਿਕਰੇਤਾ ਬੈਕਪੋਰਟ ਨੂੰ ਤਰਜੀਹ; ਜੇਕਰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਅਧਿਕਾਰਤ ਐਮਰਜੈਂਸੀ ਸਰੋਤ ਕੋਡ ਸ਼ਾਖਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ | ਵਿਹਾਰਕ ਤਬਦੀਲੀਆਂ ਦੀ ਪਛਾਣ ਕਰੋ ਅਤੇ ਸਮਰਥਿਤ ਸੰਸਕਰਣਾਂ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਅਨੁਸੂਚਿਤ ਕਰੋ    |

ਅਧਿਕਾਰਤ ਪੈਚ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਅਸਲ ਫਿਕਸ ਇਹਨਾਂ ਪੈਚਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਸੈਕਸ਼ਨ 6 ਵਿੱਚ ਕੋਡ ਦੇ ਸਨਿੱਪਟ ਡਿਜ਼ਾਈਨ ਨੂੰ ਦਰਸਾਉਣ ਅਤੇ ਹਾਈਲਾਈਟਸ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਦਾ ਇਰਾਦਾ ਰੱਖਦੇ ਹਨ ਅਤੇ ਇੱਕ ਪੂਰਾ ਪੈਚ ਨਹੀਂ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

### 5.1 PHP ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰੈਫਿਕ ਨਿਯੰਤਰਣ ਨੂੰ ਤਰਜੀਹ ਦਿਓ

ਜੇਕਰ ਸੇਵਾ ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਸਰੋਤਾਂ ਤੱਕ ਸੰਵੇਦਨਸ਼ੀਲ ਅੰਤ ਬਿੰਦੂਆਂ ਨੂੰ ਸੀਮਤ ਕਰੋ ਜਾਂ PHP ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਅੱਪਲੋਡ ਵਰਕਲੋਡ ਲਈ, ਬੇਨਤੀ-ਸਰੀਰ ਦਾ ਆਕਾਰ, ਖੇਤਰ ਦੀ ਗਿਣਤੀ, ਭਾਗਾਂ ਦੀ ਗਿਣਤੀ, ਪ੍ਰਤੀ ਭਾਗ ਸਿਰਲੇਖ, ਅਤੇ ਆਲ੍ਹਣੇ ਦੀ ਡੂੰਘਾਈ ਨੂੰ ਸੀਮਤ ਕਰੋ। ਸੇਵਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਲਟੀਪਾਰਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਉਹ ਇਸ ਨੂੰ ਫਰੰਟਐਂਡ 'ਤੇ ਰੱਦ ਕਰ ਸਕਦੀਆਂ ਹਨ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

ਇਹ ਪਾਬੰਦੀਆਂ PHP ਦੇ ਸਾਰੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਹਨ। ਸਿਰਫ਼ "ਅੱਪਲੋਡ" ਨਾਮ ਦੇ URL ਨੂੰ ਰੋਕਣ ਨਾਲ ਹੋਰ ਐਂਟਰੀਆਂ ਖੁੰਝ ਜਾਣਗੀਆਂ ਜੋ ਅਜੇ ਵੀ ਬੇਨਤੀ ਬਾਡੀ ਵਿੱਚ PHP ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਪਾਰਸ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਲਈ ਜਿਵੇਂ ਕਿ ਚੰਕਡ ਟ੍ਰਾਂਸਫਰ, ਉਪਲਬਧ ਘੋਸ਼ਿਤ ਲੰਬਾਈ ਦੀ ਘਾਟ, ਆਦਿ, ਸੀਮਾ ਅਸਲ ਪੜ੍ਹਨ ਦੇ ਆਕਾਰ 'ਤੇ ਅਧਾਰਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ; ਸਮੱਗਰੀ ਨੂੰ ਦੁਬਾਰਾ ਡੀਕੰਪ੍ਰੈਸ ਜਾਂ ਵਿਸਤਾਰ ਕਰਨ ਵੇਲੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਪਣਾ ਆਉਟਪੁੱਟ ਆਕਾਰ ਦਾ ਬਜਟ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

### 5.2 FPM pool ਸੰਰਚਨਾ ਟੈਮਪਲੇਟ

ਹੇਠ ਲਿਖੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ **FPM pool ਸੰਰਚਨਾ ਭਾਗ ਵਿੱਚ ਰੱਖੋ ਜੋ ਅਸਲ ਵਿੱਚ** ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ `php.ini` ਵਿੱਚ ਜ਼ੁਬਾਨੀ। 8M ਅਤੇ 4M ਮੁੱਲ ਵਰਕਲੋਡ ਲਈ ਐਡਜਸਟ ਕਰਨ ਲਈ ਉਦਾਹਰਣ ਹਨ। ਪੂਰੀ POST ਬੇਨਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਸਮੇਂ ਫਾਰਮ ਖੇਤਰਾਂ ਅਤੇ ਮਲਟੀਪਾਰਟ ਸੀਮਾਵਾਂ ਲਈ ਜਗ੍ਹਾ ਛੱਡੋ। [S11](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-12)

`fatal_error_backtraces = Off` ਸਿਰਫ਼ PHP 8.5 ਲਈ ਸ਼ਾਮਲ ਕਰੋ। ਅਪਲੋਡ ਪ੍ਰਗਤੀ ਨੂੰ ਅਯੋਗ ਕਰਨ ਲਈ ਕਾਰਜ-ਪੱਧਰ ਦੇ `ini_set()` ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ, ਅਤੇ ਬੇਨਤੀ ਪਾਰਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਪ੍ਰਭਾਵੀ ਬਣਾਉਣ ਲਈ FPM `.user.ini` 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)

### 5.3 PHP ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲਾਗਤ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ

`memory_limit=-1` ਅਸਥਿਰ ਵਾਤਾਵਰਣਾਂ ਲਈ ਇੱਕ ਅਸਥਾਈ ਪਾਥ ਮਿਟਿਗੇਸ਼ਨ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਡਿਫੌਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੇ ਤੌਰ ਤੇ ਨਕਲ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਬੇਨਤੀ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਹੋਸਟ ਦੀ ਮੈਮੋਰੀ ਦੀ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ। ਇਸਲਈ, ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਕਨਕਰੰਸੀ ਦੀ ਸੰਖਿਆ, ਪੀਕ ਸਿੰਗਲ ਵਰਕਰ, ਅਤੇ ਕੁੱਲ ਸੇਵਾ ਸਮਰੱਥਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਫਰੰਟ-ਐਂਡ ਇਨਪੁਟ ਸੀਮਾਵਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

ਕੰਟੇਨਰ ਜਾਂ cgroup ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਉਪਲਬਧਤਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀਆਂ ਹਨ ਪਰ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀਆਂ ਕਿ ਵੰਡ ਕਦੇ ਅਸਫਲ ਨਹੀਂ ਹੋਵੇਗੀ; ਪੂਰੇ ਕੰਟੇਨਰ, ਮਾਸਟਰ, ਅਤੇ ਸਾਰੇ ਵਰਕਰ ਨੂੰ ਵੀ ਬੰਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਸੀਮਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ। ਆਈਸੋਲੇਸ਼ਨ ਗ੍ਰੈਨਿਊਲਰਿਟੀ ਅਤੇ ਸਮਾਪਤੀ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਨੂੰ ਤੈਨਾਤੀ ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇਹਨਾਂ ਦੋਨਾਂ CVE ਲਈ ਪੂਰੀ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)

ਉਪਰੋਕਤ ਰਣਨੀਤੀਆਂ ਨੂੰ `RLIMIT_AS`, `RLIMIT_DATA`, ਜਾਂ ਸੰਬੰਧਿਤ ਪ੍ਰਕਿਰਿਆ ਐਡਰੈੱਸ ਸਪੇਸ ਪਾਬੰਦੀਆਂ ਨਾਲ ਨਾ ਬਦਲੋ; ਉਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅਜੇ ਵੀ ਸਮੱਸਿਆ ਵਾਲੇ OOM ਮਾਰਗ ਵਿੱਚ ਅੰਡਰਲਾਈੰਗ ਵੰਡ ਨੂੰ ਅਸਫਲ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ। [S2](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-14)

**ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਕਾਰੋਬਾਰ ਨੂੰ ਮਲਟੀਪਾਰਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ** , ਤੁਸੀਂ ਸੰਬੰਧਿਤ ਸੇਵਾ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਵਿੱਚ ਇੱਕ ਅਸਵੀਕਾਰ ਨਿਯਮ ਜੋੜ ਸਕਦੇ ਹੋ:

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

ਇਹ `if` ਅਤੇ `return` ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਵੇਸ਼ ਪਾਬੰਦੀ ਟੈਮਪਲੇਟ ਹੈ, ਪਾਰਸਰ ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਇੱਕ ਆਮ ਫਿਲਟਰਿੰਗ ਨਿਯਮ ਨਹੀਂ ਹੈ। ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਿੰਟੈਕਸ ਅਤੇ ਆਮ ਬੇਨਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਕਸਟਮ `error_page` 403 ਬੇਨਤੀਆਂ ਨੂੰ PHP 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ। ਸਟ੍ਰਿੰਗ ਮੈਚਿੰਗ ਸਾਰੇ ਪਾਰਸਿੰਗ ਅੰਤਰਾਂ 'ਤੇ ਪੂਰੀ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ ਹੈ। [S15](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-11)

### 5.6 WAF ਅਤੇ Cloudflare ਕਵਰੇਜ ਸੀਮਾਵਾਂ

Cloudflare ਨੇ PHP2Shell ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਲਈ ਤੈਨਾਤੀ ਪ੍ਰਬੰਧਾਂ ਦਾ ਐਲਾਨ ਕੀਤਾ ਹੈ, ਜਿਸ ਵਿੱਚ Free ਯੋਜਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਇਸਦੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕੀ ਅਸਲ ਟ੍ਰੈਫਿਕ ਪ੍ਰੌਕਸੀ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਕੀ ਸੁਰੱਖਿਆ ਨਿਯਮ ਪ੍ਰਭਾਵ ਵਿੱਚ ਹਨ, ਅਤੇ ਕੀ ਮੂਲ ਸਾਈਟ ਨੂੰ ਸਿੱਧੇ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਅਦਾਇਗੀ ਯੋਜਨਾਵਾਂ ਲਈ, ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮਾਂ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਅਪਵਾਦਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। [S16](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-16)

ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਵਰਣਿਤ ਕੁਝ ਖੋਜਾਂ ਪ੍ਰਤੀਕਿਰਿਆ ਸਿਗਨਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਇਸਲਈ ਸਾਰੀਆਂ ਸੁਰੱਖਿਆਵਾਂ ਨੂੰ "PHP ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਹਮਲੇ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ" ਵਜੋਂ ਨਹੀਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ। WAF ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਘਟਾਉਣ ਅਤੇ ਨਿਰੀਖਣ ਸੰਬੰਧੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ PHP ਲਈ ਲਗਾਤਾਰ ਅੱਪਗਰੇਡ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹਨ। [S16](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5) ਦੇਖੋ। ਹੋਰ ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਆਪਣੇ ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਰੀਲੀਜ਼ਾਂ ਜਾਂ ਮੇਲ ਖਾਂਦੇ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ 8.5 ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਿਸੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

### 6.2 OOM ਮੁਰੰਮਤ: ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆਯੋਗ ਸਥਿਤੀ ਨੂੰ ਬਹਾਲ ਕਰੋ, ਅਤੇ ਫਿਰ ਬੇਨਤੀ ਨੂੰ ਖਤਮ ਕਰੋ

ਰਸਮੀ ਲਾਗੂਕਰਨ ਨਰਮ ਅਤੇ ਸਖ਼ਤ OOM ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਦੋ ਪੱਧਰਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਨਰਮ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ, ਲੰਬਿਤ ਸਥਿਤੀ ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਨਿਯੰਤਰਿਤ ਨਿਕਾਸ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸਥਾਨ ਜਿਵੇਂ ਕਿ VM 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਅਸਫਲ ਅਲੋਕੇਸ਼ਨ ਇੰਟਰਫੇਸ ਕਾਲਰ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸਫਲਤਾ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਅਲਾਟਮੈਂਟਾਂ ਲਈ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅਸਫਲਤਾ ਵਾਪਸ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਜੇਕਰ ਇੱਕ ਉੱਚ ਸਖ਼ਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪਾਰ ਕਰਨ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਵਿਚਕਾਰਲੀ ਸਥਿਤੀ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਤੋਂ ਬਚਣ ਲਈ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਮਾਪਤ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ। [S2](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-5)

ਡਿਜ਼ਾਇਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਹਨ: **avoids ਆਪਹੁਦਰੇ ਢੰਗ ਨਾਲ C ਕਾਲ ਸਟੈਕ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹਨ ਜਦੋਂ ਢਾਂਚਾ ਇੱਕ ਵਿਚਕਾਰਲੀ ਸਥਿਤੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਥਾਨ** 'ਤੇ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ ਜੋ ਰਾਜ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦਾ ਹੈ। ਨਰਮ ਸੀਮਾ ਦੇ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਵਾਧੂ ਮੈਮੋਰੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਇਸਲਈ ਨਵੀਂ ਸਾਫਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਕੁੱਲ ਮੈਮੋਰੀ ਲਈ ਇੱਕ ਪੂਰਨ ਉਪਰਲੀ ਸੀਮਾ ਵਜੋਂ ਨਹੀਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਨਾ ਹੀ ਇਸ ਨੂੰ "PHP ਨੇ ਸਾਰੇ `zend_bailout()` ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਹੈ" ਵਜੋਂ ਸੰਖੇਪ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪੈਚ ਅਜੇ ਵੀ ਖਾਸ ਸੰਦਰਭਾਂ ਵਿੱਚ ਸੰਬੰਧਿਤ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ; ਜੋ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਉਹ ਹੈ ਖਤਰਨਾਕ ਨਿਕਾਸ ਦਾ ਸਮਾਂ ਅਤੇ ਇਸਦੇ ਨਾਲ ਰਾਜ ਪ੍ਰਬੰਧਨ। [S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

### 6.3 ਅਲੋਕੇਸ਼ਨ ਕਾਲਰਾਂ ਅਤੇ ਮਲਟੀਪਾਰਟ ਪਾਰਸਿੰਗ ਨੂੰ ਇਕੱਠੇ ਅੱਪਡੇਟ ਕਰੋ

ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਅਲੋਕੇਸ਼ਨ ਫੰਕਸ਼ਨ ਨੂੰ "ਫੇਲ ਹੋਣ 'ਤੇ NULL ਵਾਪਸ ਕਰੋ" ਲਈ ਬਦਲਦੇ ਹੋ ਅਤੇ ਅਸਲ ਕਾਲਰ ਅਜੇ ਵੀ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਇੱਕ ਵੈਧ ਪੁਆਇੰਟਰ ਹਮੇਸ਼ਾ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਵੇਂ ਨਲ ਪੁਆਇੰਟਰ ਐਕਸੈਸ ਜਾਂ ਅਧੂਰੀ ਸਫਾਈ ਪੇਸ਼ ਕਰੋਗੇ। ਪੈਚ ਵਿੱਚ ਅਸਫਲ ਅਲੋਕੇਸ਼ਨ ਇੰਟਰਫੇਸ ਦੀ ਕਾਲਰ ਜਾਂਚ ਅਤੇ ਅਪਵਾਦ ਪ੍ਰਸਾਰ ਦੇ ਨਾਲ ਸਮੀਖਿਆ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। [S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

ਮਲਟੀਪਾਰਟ ਸਬੰਧਿਤ ਫਿਕਸਾਂ ਵਿੱਚ ਅਸਲ ਰੀਡ ਵਾਲੀਅਮ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਚਤ ਜਾਂਚਾਂ ਕਰਨਾ, ਬੇਕਾਰ ਜਾਂ ਡੁਪਲੀਕੇਟ ਸਿਰਲੇਖਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਘਟਾਉਣਾ, ਅਤੇ OOM ਲੰਬਿਤ ਹੋਣ 'ਤੇ ਨਿਰੰਤਰ ਨਿਕਾਸ ਅਤੇ ਸਫਾਈ ਤਰਕ ਨੂੰ ਅਪਣਾਉਣਾ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਤਬਦੀਲੀਆਂ ਸਰੋਤ ਪ੍ਰਸਾਰ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਪਾਰਸਰ ਨੂੰ ਨਵੇਂ OOM ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ। [S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

ਆਪਣੀਆਂ ਬ੍ਰਾਂਚਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਮੁੱਦਿਆਂ ਨੂੰ ਕੋਡ ਸਮੀਖਿਆ ਦਾ ਕੇਂਦਰ ਬਣਾਇਆ ਜਾਵੇ:

- ਕੀ ਰਾਜ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰੀ ਸੰਸਾਰ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ?
- ਵੰਡ ਅਸਫਲਤਾ ਜਾਂ ਕਾਲਬੈਕ ਅਪਵਾਦ ਤੋਂ ਬਾਅਦ, ਕੀ ਮਲਕੀਅਤ ਅਜੇ ਵੀ ਵਿਲੱਖਣ ਅਤੇ ਅਸਪਸ਼ਟ ਹੈ?
- ਜੇਕਰ ਤੁਸੀਂ ਅੱਧ ਵਿਚਕਾਰ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹੋ ਤਾਂ ਕੀ ਤੁਸੀਂ ਯੂਨੀਫਾਈਡ ਕਲੀਨਅੱਪ ਐਗਜ਼ਿਟ 'ਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ?
- ਕੀ ਕਲੀਨਅਪ ਫੰਕਸ਼ਨ ਅਣ-ਸ਼ੁਰੂ ਜਾਂ ਖਾਲੀ ਖੇਤਰਾਂ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹੈ?
- ਕੀ ਪਾਰਸਿੰਗ ਬਜਟ ਅਸਲ ਪ੍ਰੋਸੈਸਿੰਗ ਵਾਲੀਅਮ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਬੇਨਤੀ ਦਾਅਵਿਆਂ 'ਤੇ ਭਰੋਸਾ ਹੈ?
- ਕੀ ਨਵੀਂ ਅਸਫਲਤਾ ਵਾਪਸੀ ਮੁੱਲ ਨੂੰ ਸਾਰੇ ਕਾਲਰਾਂ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਗਿਆ ਹੈ?

ਇਹ ਫਿਕਸ ਮਕੈਨਿਜ਼ਮ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਖੇਪ ਕੀਤੇ ਸਮੀਖਿਆ ਸਵਾਲ ਹਨ, ਅਤੇ ਇਹ ਕਿਸੇ ਆਡਿਟ ਦਾ ਸਿੱਟਾ ਨਹੀਂ ਹਨ ਜੋ ਕਿਸੇ ਗੈਰ-ਪ੍ਰਦਾਨ ਕੀਤੇ ਕੋਡ ਬੇਸ ਲਈ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਹੈ।

### 6.4 ਕ੍ਰਾਸ-ਬੇਨਤੀ ਫਿਕਸ: ਸ਼ੁਰੂਆਤੀ ਪਹਿਲਾਂ, ਅੰਤਮ ਸਫਾਈ ਬਾਅਦ ਵਿੱਚ

CVE-2026-109619 ਦੇ ਅਨੁਸਾਰੀ, ਪੈਚ ਇੱਕੋ ਸਮੇਂ ਕਈ ਜੀਵਨ ਚੱਕਰ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ। ਹੇਠਾਂ ਸੂਚੀਬੱਧ ਫਾਈਲਾਂ ਅਤੇ ਓਪਰੇਸ਼ਨ PHP 8.5 ਅਧਿਕਾਰਤ ਅੰਤਰ ਨੂੰ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ ਲੈਂਦੇ ਹਨ। [S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

| ਟਿਕਾਣਾ                                        | ਦਿਸ਼ਾ ਬਦਲੋ                                                                    | ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ ਗਈ                                                                        |
| --------------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c` ਆਦਿ                 | ਐਗਜ਼ੀਕਿਊਟਰ ਸਥਿਤੀ ਨੂੰ ਰੀਸੈਟ ਕਰੋ ਜਿਵੇਂ ਕਿ ਤਰੁੱਟੀਆਂ, ਅਪਵਾਦ, ਹੈਂਡਲਰ, ਵਸਤੂਆਂ, ਆਦਿ। | ਬੇਨਤੀ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਹਵਾਲੇ ਹਨ ਜੋ ਅਗਲੀ ਬੇਨਤੀ ਦੁਆਰਾ ਐਕਸੈਸ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। |
| `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]);
```

ਇਹ ਅੰਸ਼ ਦੋ ਸਿਧਾਂਤਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ: **Zinitialize ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸੰਭਵ ਖਪਤਕਾਰ ਤੋਂ ਪਹਿਲਾਂ, ਅਤੇ ਆਖਰੀ ਓਪਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਅੰਤਮ ਸਫਾਈ ਕਰੋ ਜੋ ਰਾਜ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾ ਸਕਦਾ ਹੈ।** ਸਿਰਫ ਆਮ RINIT ਦੌਰਾਨ ਪੁਆਇੰਟਰ ਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਜਾਂ ਪਹਿਲਾਂ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਪਹਿਲਾਂ ਬੰਦ ਕਰਨ ਦੇ ਪੜਾਅ ਤੋਂ ਖੁੰਝ ਸਕਦਾ ਹੈ। [S5](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-5)

### 6.5 ਆਪਣੀ ਖੁਦ ਦੀ "ਇੱਕ-ਲਾਈਨ ਮੁਰੰਮਤ" ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ?

ਸਾਰੇ `zend_bailout()` ਨੂੰ `_exit()` ਨਾਲ ਬਦਲਣਾ, ਜਾਂ ਕਿਸੇ ਖਾਸ ਐਂਟਰੀ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਨਲ ਪੁਆਇੰਟਰ ਚੈੱਕ ਜੋੜਨਾ, ਵੱਖ-ਵੱਖ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪ੍ਰਸੰਗਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਫੈਲੇਗਾ। ਉਹ ਹੋਰ ਸਥਿਤੀ ਖੇਤਰਾਂ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਨ, ਜਾਂ ਉਹ ਵਿਨਾਸ਼, ਵਿਸਤ੍ਰਿਤ ਕਾਲਬੈਕ, ਪ੍ਰਕਿਰਿਆ ਹੋਸਟਿੰਗ, ਅਤੇ ਅੰਤ ਦੇ ਅਰਥ-ਵਿਗਿਆਨ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ।

ਸਮਰਥਿਤ ਸੰਸਕਰਣਾਂ ਲਈ, ਪੂਰੇ ਫਿਕਸ ਜੋ ਪਹਿਲਾਂ ਹੀ ਜਾਰੀ ਕੀਤੇ ਜਾ ਚੁੱਕੇ ਹਨ, ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਆਪਣੀਆਂ ਬ੍ਰਾਂਚਾਂ ਦੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਪੈਚ ਦੇ ਸਰੋਤ, ਲਾਗੂ ਬੇਸਲਾਈਨਾਂ, ਅਪਵਾਦ ਹੈਂਡਲਿੰਗ ਅਤੇ ਵਿਵਹਾਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅਨੁਸਾਰੀ ਅਪਸਟ੍ਰੀਮ ਰਿਗਰੈਸ਼ਨ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਅਤੇ ਤਸਦੀਕ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਥੇ ਸੁਝਾਅ ਅਲੋਕੇਟਰ, VM, ਸੈਸ਼ਨ ਅਤੇ ਬੇਨਤੀ ਜੀਵਨ ਚੱਕਰ ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਪੈਚ ਦੇ ਦਾਇਰੇ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਆਏ ਹਨ। [S4](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/pa/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/pa/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-9) ਦੇਖੋ। ਇਹ ਇਸ ਕਮਜ਼ੋਰੀ ਲਈ ਐਮਰਜੈਂਸੀ ਡਿਲੀਵਰੀ ਹਨ ਅਤੇ ਪੁਰਾਣੀ ਬ੍ਰਾਂਚ ਲਈ ਨਿਯਮਤ ਅੱਪਸਟ੍ਰੀਮ ਸਹਾਇਤਾ 'ਤੇ ਵਾਪਸੀ ਦੀ ਪ੍ਰਤੀਨਿਧਤਾ ਨਹੀਂ ਕਰਦੀਆਂ, ਨਾ ਹੀ ਇਹ ਹੋਰ ਸੁਰੱਖਿਆ ਅਪਡੇਟਾਂ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)

### 7.1 ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ PHP 8.1 ਬੈਕਪੋਰਟ ਲਓ

PHP 8.1 ਲਈ ਸੰਬੰਧਿਤ ਬੇਨਤੀਆਂ ਹਨ:

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

ਇਸਦੀ ਰਣਨੀਤੀ ਫੇਲ-ਫਾਸਟ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ: ਅਨੁਸਾਰੀ OOM ਮਾਰਗ ਵਿੱਚ ਡਾਇਗਨੌਸਟਿਕਸ ਨੂੰ ਆਊਟਪੁੱਟ ਕਰਨ ਤੋਂ ਬਾਅਦ `_exit(1)` ਨੂੰ ਕਾਲ ਕਰਨਾ, ਅਤੇ ਗਲੋਬਲ ਸਥਿਤੀ ਅਤੇ ਹੋਰ ਸੰਬੰਧਿਤ ਸੁਧਾਰਾਂ ਸਮੇਤ; ਸੈਸ਼ਨ ਅੱਪਲੋਡ ਪ੍ਰਗਤੀ ਦੀ ਅਨੁਸਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ ਕਰਦੇ ਹੋਏ। ਸੰਬੰਧਿਤ ਸਰੋਤ ਕੋਡ ਸਬਮਿਸ਼ਨ ਲਈ, [S6](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-6) ਦੇਖੋ।

ਇਹ ਸਮਰਥਿਤ ਸ਼ਾਖਾ ਵਿੱਚ ਵਧੇਰੇ ਸੰਪੂਰਨ ਦੇਰੀ ਵਾਲੇ OOM ਡਿਜ਼ਾਈਨ ਤੋਂ ਇੱਕ ਵਿਵਹਾਰਿਕ ਅੰਤਰ ਹੈ। ਬਸ ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਅਜੇ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅੱਪਲੋਡ ਪ੍ਰਗਤੀ ਚਾਲੂ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਬੈਕਪੋਰਟ ਤੋਂ ਬਾਅਦ ਅੰਦਰੂਨੀ ਪ੍ਰੋਸੈਸਿੰਗ ਵਿਵਹਾਰ ਬਦਲਿਆ ਨਹੀਂ ਰਹੇਗਾ।

### 7.2 ਤੈਨਾਤ ਕਰਨ ਵੇਲੇ ਤੁਹਾਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰਨ ਨਾਲ ਮੌਜੂਦਾ ਬੇਨਤੀ ਨੂੰ ਅਸਫਲ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਆਮ PHP ਸ਼ੱਟਡਾਊਨ ਕਾਲਬੈਕ ਨੂੰ ਛੱਡਣਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬੰਦ ਕਰਨ ਦਾ ਹਿੱਸਾ; ਜੇਕਰ ਮੇਜ਼ਬਾਨ ਇੱਕ ਥਰਿੱਡ ਮਾਡਲ ਨੂੰ ਅਪਣਾ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਹੋਰ ਸਮਕਾਲੀ ਕੰਮ 'ਤੇ ਪੂਰੀ ਹੋਸਟ ਪ੍ਰਕਿਰਿਆ ਦੇ ਐਗਜ਼ਿਟ ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ। ਕੀ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ ਸਮੇਂ ਸਿਰ ਬਦਲਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਵੀ ਪੁਸ਼ਟੀਕਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਲਈ, ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

1. ਸਮਰਥਿਤ PHP ਸ਼ਾਖਾ ਅਤੇ ਇਸਦੇ ਸਥਿਰ ਸੰਸਕਰਣ ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰੋ।
2. ਇੱਕ ਰੀਲੀਜ਼ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ CVE ਜਾਂ LTS ਨਿਰਮਾਤਾ ਅੱਪਡੇਟ ਦੋਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।
3. ਜੇਕਰ ਇਹ ਅਸਲ ਵਿੱਚ ਸਰੋਤ ਕੋਡ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਦੇ ਅਧੀਨ ਹੈ, ਤਾਂ ਸੰਪੂਰਨ ਤਬਦੀਲੀਆਂ ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਮੇਲ ਖਾਂਦੇ ਸੰਸਕਰਣ ਦੇ ਅਧਿਕਾਰਤ ਐਮਰਜੈਂਸੀ ਬੈਕਪੋਰਟ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ।

ਇੱਥੇ "ਘੱਟੋ-ਘੱਟ ਬੈਕਪੋਰਟ" ਅਧਿਕਾਰੀ ਦੁਆਰਾ ਚੁਣੀ ਗਈ ਅਨੁਕੂਲਤਾ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੇ ਦਾਇਰੇ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ "ਜਾਣੀਆਂ ਅਧੂਰੀਆਂ ਕਮਜ਼ੋਰੀ ਫਿਕਸ" ਵਜੋਂ ਨਹੀਂ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਸ਼ਾਖਾ ਦੇ ਸਰੋਤ ਕੋਡ ਅਤੇ ਨਿਰਮਾਤਾ ਦੀ ਘੋਸ਼ਣਾ ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਰਣਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਆਪਣੇ ਆਪ ਸਮਰਥਿਤ ਤਬਦੀਲੀਆਂ ਨੂੰ ਨਾ ਮਿਟਾਓ। [S1](https://keendigit.com/pa/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/pa/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/pa/contact?service=security-remediation#form>)

[ਮੂਲ ਪੰਨਾ](<https://keendigit.com/pa/insights/php2shell-remediation-guide>) · [ਸਮੱਗਰੀ ਸੂਚਕਾਂਕ](<https://keendigit.com/pa/llms.txt>)

KeenDigit LLC · ਵਾਇਮਿੰਗ ਫਾਈਲਿੰਗ ਆਈ.ਡੀ: 2026-002106155

[ਵਾਇਮਿੰਗ ਸੈਕਟਰੀ ਆਫ਼ ਸਟੇਟ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Sheridan, Wyoming, USA · ਸਾਰੇ ਅਧਿਕਾਰ ਰਾਖਵੇਂ ਹਨ।