PHP2Shell: വെബ്ബിന്റെ വലിയൊരു ഭാഗത്തെ അപകടത്തിലാക്കിയ 14 വർഷം പഴക്കമുള്ള PHP ബഗ്

2026 ഒക്ടോബർ 21-ന്, PHP2Shell എന്നറിയപ്പെടുന്ന രണ്ട് ഗുരുതര സുരക്ഷാ പിഴവുകൾക്ക് PHP അടിയന്തര പാച്ച് പുറത്തിറക്കി. ഒരൊറ്റ കൃത്രിമ റിക്വസ്റ്റ് കൊണ്ട് ആക്രമണകാരിക്ക് വെബ് സെർവർ കൈയടക്കാൻ ഇവ വഴിയൊരുക്കുന്നു. പാസ്‌വേഡോ ലോഗിനോ പ്ലഗിനോ ആവശ്യമില്ല. നിങ്ങളുടെ വെബ്സൈറ്റ് PHP-യിൽ ആണെങ്കിൽ (WordPress, WooCommerce ഉൾപ്പെടെ), ഇന്നുതന്നെ PHP 8.5.12, 8.4.27, 8.3.36 അല്ലെങ്കിൽ 8.2.35-ലേക്ക് അപ്ഡേറ്റ് ചെയ്യുക.

നമ്മൾ സന്ദർശിക്കുന്ന ഭൂരിഭാഗം വെബ്സൈറ്റുകളും PHP-യിലാണ് പ്രവർത്തിക്കുന്നത്: WordPress, WooCommerce, Joomla, Drupal, Magento, Laravel ആപ്പുകൾ, പിന്നെ എണ്ണമറ്റ കസ്റ്റം സൈറ്റുകളും. 2026 ഒക്ടോബർ 21-ന് PHP-യിൽ തന്നെയുള്ള രണ്ട് പിഴവുകൾക്ക്, CVE-2026-109618, CVE-2026-109619, PHP ടീം അടിയന്തര പരിഹാരം പുറത്തിറക്കി. ഇവ ഇപ്പോൾ PHP2Shell എന്ന പേരിലാണ് അറിയപ്പെടുന്നത്.

രണ്ടും ലോഗിൻ ഇല്ലാതെയുള്ള റിമോട്ട് കോഡ് എക്സിക്യൂഷൻ അനുവദിക്കുന്നു: ആക്രമണകാരിക്ക് നിങ്ങളുടെ സെർവറിൽ സ്വന്തം കോഡ് റൺ ചെയ്യാം, തുടർന്ന് ഡാറ്റ മോഷ്ടിക്കാം, മാൽവെയർ സ്ഥാപിക്കാം, അല്ലെങ്കിൽ സൈറ്റ് കൈയടക്കാം. നിങ്ങളുടെ ബിസിനസിന് വെബ്സൈറ്റ് ഉണ്ടെങ്കിൽ, എന്താണ് സംഭവിച്ചത്, എന്തുകൊണ്ട് ഇത് പ്രധാനമാണ്, ഇന്ന് എന്ത് ചെയ്യണം എന്നിവ താഴെ.

ഓരോ പിഴവിന്റെയും ഗൗരവ സ്കോർ (CVSS v4.0): 9.2/10; ഓരോ പിഴവിന്റെയും ഗൗരവ സ്കോർ (CVSS v4.0)
സെർവർ ഭാഷ അറിയാവുന്ന വെബ്സൈറ്റുകളിൽ PHP ഉപയോഗിക്കുന്നവ: 69%; സെർവർ ഭാഷ അറിയാവുന്ന വെബ്സൈറ്റുകളിൽ PHP ഉപയോഗിക്കുന്നവ
അപകടസാധ്യതയുള്ളതായി കണക്കാക്കുന്ന ഇന്റർനെറ്റ് സെർവറുകൾ: 1.3M+; അപകടസാധ്യതയുള്ളതായി കണക്കാക്കുന്ന ഇന്റർനെറ്റ് സെർവറുകൾ
ആദ്യ ആക്രമണ ശ്രമത്തിനും പരസ്യമായ പാച്ചിനും ഇടയിൽ: 4 ദിവസം; ആദ്യ ആക്രമണ ശ്രമത്തിനും പരസ്യമായ പാച്ചിനും ഇടയിൽ

ചുരുക്കത്തിൽ

എന്താണ്: PHP എൻജിനിലെ രണ്ട് ഗുരുതര പിഴവുകൾ. ഇത് ഏതെങ്കിലും പ്ലഗിനിലോ തീമിലോ ഉള്ള പ്രശ്നമല്ല.
ആഘാതം: ഒരൊറ്റ കൃത്രിമ വെബ് റിക്വസ്റ്റ് കൊണ്ട് ആക്രമണകാരിക്ക് സെർവർ കൈയടക്കാം. ലോഗിൻ വേണ്ട.
ആരെയൊക്കെ ബാധിക്കും: വെബ് പേജുകൾ നൽകുന്ന ഏതാണ്ട് എല്ലാ PHP ഇൻസ്റ്റലേഷനുകളെയും: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed എന്നിവ വഴി പ്രവർത്തിക്കുന്നവ. ഏറ്റവും കൂടുതൽ അപകടം Apache mod_php-ക്കാണ്. പ്രശ്നമുള്ള കോഡ് 2012-ൽ ഇറങ്ങിയ PHP 5.4 മുതൽ ഉള്ളതാണ്.
പരിഹാരം: PHP 8.5.12, 8.4.27, 8.3.36 അല്ലെങ്കിൽ 8.2.35-ലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുക, അല്ലെങ്കിൽ നിങ്ങളുടെ Linux വെണ്ടറുടെ പാച്ച് ചെയ്ത പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യുക.
നിലവിലെ സ്ഥിതി: ആക്രമണ ശ്രമങ്ങൾ ഇതിനകം കണ്ടുകഴിഞ്ഞു. പിഴവുകൾ പരസ്യമാകുന്നതിന് നാല് ദിവസം മുൻപ് Amazon രേഖപ്പെടുത്തിയ ഒരു ശ്രമം ഉൾപ്പെടെ.

കൃത്യമായി എന്താണ് തകരാറ്?

ഓരോ PHP ആപ്ലിക്കേഷന്റെയും അടിയിലുള്ള ലെയറിലാണ് ഈ ബഗുകൾ. അതുകൊണ്ടാണ് കൃത്യമായി കോഡ് ചെയ്ത, പൂർണമായി അപ്ഡേറ്റ് ചെയ്ത ഒരു WordPress സൈറ്റ് പോലും അപകടത്തിലാകുന്നത്.

CVE-2026-109618, ഔട്ട്-ഓഫ്-മെമ്മറി കറപ്ഷൻ. വരുന്ന ഒരു റിക്വസ്റ്റ് വായിച്ചുകൊണ്ടിരിക്കെ PHP-യുടെ മെമ്മറി തീർന്നാൽ, തുടർന്നുള്ള ക്ലീൻ-അപ്പ് പാതി മാത്രം തയ്യാറായ ഡാറ്റയെ ശരിയായ ഡാറ്റയായി കണക്കാക്കിയേക്കാം. സാധാരണ സൈസ് പരിധിക്കുള്ളിൽ നിന്നുകൊണ്ടുതന്നെ, പ്രത്യേകം തയ്യാറാക്കിയ ഒരു ഫയൽ-അപ്‌ലോഡ് രീതിയിലുള്ള റിക്വസ്റ്റ് കൊണ്ട് ഇത് സംഭവിപ്പിക്കാം. പാച്ച് ചെയ്യാത്ത സെർവറിൽ ഈ കറപ്ഷൻ കോഡ് റൺ ചെയ്യാനുള്ള വഴിയായി മാറുന്നു.

CVE-2026-109619, സന്ദർശകർക്കിടയിൽ ബാക്കിയാകുന്ന പഴയ സ്റ്റേറ്റ്. ഒരു PHP വർക്കർ ഒന്നിനുപുറകെ ഒന്നായി നിരവധി റിക്വസ്റ്റുകൾ കൈകാര്യം ചെയ്യുന്നു. ഈ ബഗ് കാരണം, ഒരു റിക്വസ്റ്റിന്റെ മെമ്മറി ഫ്രീ ചെയ്തിട്ടും അതിലേക്കുള്ള റഫറൻസ് ബാക്കിയാകാം, അതിനാൽ ആ വർക്കറിലെ അടുത്ത റിക്വസ്റ്റിന് അതിലേക്ക് എത്താം. PHP-യുടെ session upload-progress സംവിധാനം വഴിയോ, PHP 8.5-ൽ fatal-error back-trace സംവിധാനം വഴിയോ ആക്രമണകാരികൾക്ക് ഇത് ഉണർത്താം. മെമ്മറി ചോരാനും സാധ്യതയുണ്ട്, അതായത് മെമ്മറിയിലുള്ള പാസ്‌വേഡുകൾ, API കീകൾ, ടോക്കണുകൾ പോലുള്ള രഹസ്യങ്ങൾ പുറത്താകാം.

PHP2Shell ആക്രമണം നടക്കുന്നത് ഇങ്ങനെ

01ഒരൊറ്റ കൃത്രിമ റിക്വസ്റ്റ്ആക്രമണകാരി ഒരു അപ്‌ലോഡ് രീതിയിലുള്ള വെബ് റിക്വസ്റ്റ് അയയ്ക്കുന്നു. ലോഗിനോ പാസ്‌വേഡോ വേണ്ട.
ബഗ് ഇവിടെ02PHP റിക്വസ്റ്റ് വായിക്കുന്നുബഗ് ഇവിടെയാണ്, PHP എൻജിനുള്ളിൽ: കേടായ മെമ്മറി, അല്ലെങ്കിൽ മുൻപത്തെ സന്ദർശകന്റെ ബാക്കി ഡാറ്റ.
03ആക്രമണകാരിയുടെ കോഡ് റൺ ആകുന്നുസെർവർ ഇപ്പോൾ ആക്രമണകാരിയുടെ കമാൻഡുകൾ നടപ്പാക്കുന്നു: ഡാറ്റ മോഷണം, മാൽവെയർ, സൈറ്റ് കൈയടക്കൽ.

നിങ്ങളുടെ വെബ്സൈറ്റ് കോഡ്, പ്ലഗിനുകൾ, സുരക്ഷാ പരിശോധനകൾഇവയ്ക്ക് പ്രവർത്തിക്കാൻ അവസരം പോലും കിട്ടുന്നില്ല

ഇത് എങ്ങനെ കണ്ടെത്തി, എങ്ങനെ ചോർന്നു

Wiz Research, Calif, OpenAI-യുടെ Codex Security ടീം എന്നിവിടങ്ങളിലെ ഗവേഷകരാണ് ഈ പിഴവുകൾ കണ്ടെത്തി റിപ്പോർട്ട് ചെയ്തതെന്ന് PHP വ്യക്തമാക്കുന്നു. പരിഹാരം തയ്യാറാക്കാൻ Google-ന്റെ Gemini ടീമും സഹായിച്ചു. പക്ഷേ പിന്നീട് കാര്യങ്ങൾ എല്ലാവരുടെയും നിയന്ത്രണത്തിന് പുറത്തായി.

ഒക്ടോ 17
ആദ്യ ആക്രമണ ശ്രമം
എന്തെങ്കിലും പരസ്യമാകുന്നതിന് നാല് ദിവസം മുൻപ്, Amazon-ന്റെ MadPot ഹണിപോട്ടുകൾ ഒരു PHP2Shell ആക്രമണ ശ്രമം രേഖപ്പെടുത്തുന്നു.
ഒക്ടോ 20
ചോർച്ച
തെറ്റായ 10.0 സ്കോറോടെ CVE നമ്പറുകൾ നേരത്തെ ഓൺലൈനിൽ പ്രത്യക്ഷപ്പെടുന്നു. പ്രവർത്തിക്കുന്ന ഒരു proof of concept-ന്റെ വീഡിയോ അബദ്ധത്തിൽ പോസ്റ്റ് ചെയ്യപ്പെടുന്നു.
ഒക്ടോ 21 · 03:02 UTC
Cloudflare ഫയർവാൾ നിയമങ്ങൾ ഓണാക്കുന്നു
ഒരു പാച്ചും ഇല്ലാത്ത സമയത്ത് താൽക്കാലിക സംരക്ഷണമായി, ഉപഭോക്താക്കൾക്കെല്ലാം സ്വതവേ ഓൺ.
ഒക്ടോ 21 · 14:00 UTC
PHP പരിഹാരം പുറത്തിറക്കുന്നു
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. ചോർച്ച കാരണം ഒരു ദിവസം നേരത്തെ.
ഒക്ടോ 22
ആദ്യം നിശ്ചയിച്ചിരുന്ന തീയതി
പരിഹാരം പുറത്തിറക്കാൻ ഉദ്ദേശിച്ചിരുന്ന ദിവസം.

ഇപ്പോൾ AI ഇരുവശത്തുമുണ്ട്

വർഷങ്ങളായി ഉണ്ടായിരുന്ന ബഗുകളെ, ഒരു ടീം കൈകൊണ്ട് ചെയ്യുന്നതിലും വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്ന exploit-കളാക്കാൻ AI മോഡലുകൾ ഗവേഷകരെ സഹായിച്ചു. ഇതേ വേഗത ആക്രമണകാരികൾക്കും ഗുണം ചെയ്യുന്നു. ഒരു ബഗ് പ്രഖ്യാപിക്കപ്പെടുന്നതിനും അത് ദുരുപയോഗം ചെയ്യപ്പെടുന്നതിനും ഇടയിലുള്ള സമയം ഇപ്പോൾ ആഴ്ചകളല്ല, മണിക്കൂറുകളാണ്.

ഇത് മുഴുവൻ ഇന്റർനെറ്റിനെയും ബാധിക്കുന്നത് എന്തുകൊണ്ട്

Tenable ഉദ്ധരിക്കുന്ന W3Techs കണക്കുകൾ പ്രകാരം, സെർവർ ഭാഷ അറിയാവുന്ന വെബ്സൈറ്റുകളിൽ ഏകദേശം 69%-വും PHP ഉപയോഗിക്കുന്നു. ഇന്റർനെറ്റിൽ തുറന്നിരിക്കുന്ന 13 ലക്ഷത്തിലധികം സെർവറുകൾ അപകടത്തിലായേക്കാമെന്ന് ഒരു ഗവേഷകൻ കണക്കാക്കുന്നു.

ആഘാതം യഥാർത്ഥമായിരുന്നു. മുൻകരുതൽ എന്ന നിലയിൽ BambooHR യുഎസ്, കാനഡ, അയർലൻഡ് എന്നിവിടങ്ങളിൽ സേവനം ഓഫ്‌ലൈനാക്കി. നെതർലൻഡ്‌സിൽ, പാച്ചുകൾ പ്രയോഗിക്കുന്നതിനിടെ DigiD, MijnOverheid ഉൾപ്പെടെയുള്ള സർക്കാർ സേവനങ്ങൾ ഓഫ്‌ലൈനായി. പിഴവ് ദുരുപയോഗം ചെയ്യപ്പെട്ടതായി കണ്ടിട്ടില്ലെന്ന് ഡച്ച് ദേശീയ സൈബർ സുരക്ഷാ കേന്ദ്രം അറിയിച്ചു, എല്ലാവരും പാച്ച് ചെയ്യണമെന്ന് ആവശ്യപ്പെടുകയും ചെയ്തു. തങ്ങളുടെ പുതിയ നിയമങ്ങളെ മറികടക്കാൻ ആക്രമണകാരികൾ payload-കൾ മാറ്റുന്നതായി Cloudflare റിപ്പോർട്ട് ചെയ്തു.

ആദ്യകാല ആക്രമണങ്ങൾ ഉയർന്നുവരുന്നത് ഞങ്ങൾ കാണുന്നുണ്ട്, പുതിയ വഴികൾ കണ്ടെത്തുന്നതിനനുസരിച്ച് പ്രതിരോധ നടപടികൾ പുതുക്കിക്കൊണ്ടിരിക്കുന്നു.
Dane Knecht, CTO, Cloudflare (പരിഭാഷ)

പരിഹാരം, PHP പതിപ്പ് അനുസരിച്ച്

പാച്ച് ചെയ്ത PHP പതിപ്പുകൾ
നിങ്ങളുടെ PHP ബ്രാഞ്ച്	ഇതിന് താഴെയെങ്കിൽ അപകടം	അപ്ഡേറ്റ് ചെയ്യേണ്ടത്
PHP 8.5	8.5.12	8.5.12
PHP 8.4	8.4.27	8.4.27
PHP 8.3	8.3.36	8.3.36
PHP 8.2	8.2.35	8.2.35
PHP 8.1-ഉം പഴയവയും	എല്ലാ പതിപ്പുകളും	പിന്തുണയുള്ള ഒരു 8.x ബ്രാഞ്ച്

Ubuntu, Debian, Red Hat പോലുള്ള വെണ്ടർമാരിൽ നിന്നാണ് നിങ്ങൾ PHP ഇൻസ്റ്റാൾ ചെയ്യുന്നതെങ്കിൽ, അവരുടെ അപ്ഡേറ്റ് പ്രയോഗിക്കുക. 7.4, 8.0, 8.1 എന്നിവയ്ക്കായി PHP ടീം ചെറിയ സോഴ്സ് ബാക്ക്‌പോർട്ടുകളും പുറത്തിറക്കിയിട്ടുണ്ട്, ചില ഹോസ്റ്റുകൾ സ്വന്തം പാച്ചുകളും നൽകുന്നുണ്ട്. അവയെ ഒരു താൽക്കാലിക പാലമായി മാത്രം കാണുക, സ്ഥിരം പരിഹാരമായല്ല.

നിങ്ങൾ ഒരു ബിസിനസ് വെബ്സൈറ്റ് നടത്തുന്നുണ്ടെങ്കിൽ

നിങ്ങളുടെ PHP പതിപ്പ് പരിശോധിക്കുക. ഹോസ്റ്റിംഗ് കൺട്രോൾ പാനലിൽ (hPanel, cPanel, Plesk) കാണാം. WordPress-ൽ Tools, Site Health, Info, Server എന്ന വഴിയിലും കാണാം.
നിങ്ങളുടെ ഹോസ്റ്റിനോട് നേരിട്ട് ചോദിക്കുക: CVE-2026-109618, CVE-2026-109619 എന്നിവയ്ക്ക് നിങ്ങളുടെ PHP പാച്ച് ചെയ്തിട്ടുണ്ടോ? നല്ല ഹോസ്റ്റുകളിൽ മിക്കവരും മണിക്കൂറുകൾക്കുള്ളിൽ ഷെയേർഡ് സെർവറുകൾ പാച്ച് ചെയ്തു, പക്ഷേ ഊഹിച്ച് വിടരുത്.
PHP 8.1-ലോ അതിലും പഴയതിലോ ആണോ? ഹോസ്റ്റിംഗ് പാനലിൽ നിന്ന് 8.4-ലേക്കോ 8.5-ലേക്കോ മാറുക, തുടർന്ന് സൈറ്റ് പരിശോധിക്കുക.
പാസ്‌വേഡുകൾ മാറ്റുക, പാച്ച് ചെയ്യാത്ത പതിപ്പിൽ നിങ്ങളുടെ സെർവർ ഇന്റർനെറ്റിൽ തുറന്നിരുന്നെങ്കിൽ: ഹോസ്റ്റിംഗ്, WordPress അഡ്മിൻ, ഡാറ്റാബേസ്, പേയ്‌മെന്റ്, ഇമെയിൽ API കീകൾ എല്ലാം. മെമ്മറി ചോർച്ച കാരണം രഹസ്യങ്ങൾ വായിക്കപ്പെട്ടിരിക്കാം.

നിങ്ങൾ സെർവറുകൾ കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ

ഉപകരണങ്ങൾക്കും കൺട്രോൾ പാനലുകൾക്കും ഉള്ളിലുള്ളവ ഉൾപ്പെടെ, എല്ലാ PHP ഇൻസ്റ്റലേഷനുകളുടെയും പട്ടിക തയ്യാറാക്കുക. ഇന്റർനെറ്റിലേക്ക് തുറന്നിരിക്കുന്ന സെർവറുകൾ ആദ്യം പാച്ച് ചെയ്യുക, തുടർന്ന് എല്ലാ PHP വർക്കറുകളും റീസ്റ്റാർട്ട് ചെയ്യുക, കാരണം പഴയ വർക്കറുകൾ റീസ്റ്റാർട്ട് ആകുന്നതുവരെ പ്രശ്നമുള്ള കോഡ് തന്നെ റൺ ചെയ്തുകൊണ്ടിരിക്കും. ഈ മണിക്കൂറിൽ പാച്ച് ചെയ്യാൻ കഴിയില്ലെങ്കിൽ, PHP-യുടെ താൽക്കാലിക പ്രതിരോധ നടപടികൾ അപകടം കുറയ്ക്കും, പക്ഷേ പൂർണമായി ഇല്ലാതാക്കില്ല:

php.ini, ഒരു FPM pool, അല്ലെങ്കിൽ സെർവർ കോൺഫിഗറേഷനിൽ session.upload_progress.enabled = 0 എന്ന് സജ്ജമാക്കുക. .user.ini-ലോ ini_set()-ലോ പോരാ.
PHP 8.5-ൽ fatal_error_backtraces = 0 എന്ന് സജ്ജമാക്കുക.
ആപ്ലിക്കേഷനുകൾക്ക് മാറ്റാൻ കഴിയാത്ത അഡ്മിൻ തലത്തിൽ memory_limit = -1 എന്ന് സജ്ജമാക്കുക. post_max_size കുറച്ച് വയ്ക്കുക (8M, അപ്‌ലോഡ് വേണമെങ്കിൽ 32M). വെബ് സെർവറിലോ പ്രോക്സിയിലോ റിക്വസ്റ്റ് സൈസിന് പരിധി വയ്ക്കുക.
RLIMIT_AS, RLIMIT_DATA എന്നിവ ഉപയോഗിക്കരുത്. അവ പ്രശ്നമുള്ള മെമ്മറി അലോക്കേഷൻ പരാജയത്തിന് കാരണമായേക്കാം.

ഒക്ടോബർ 17 മുതലുള്ള ആക്രമണ ലക്ഷണങ്ങൾ പരിശോധിക്കുക

PHP പ്രോസസുകൾ shell, curl, wget, nc പോലുള്ളവ തുറക്കുന്നുണ്ടോ, reverse-shell അടയാളങ്ങൾ, ലോഗുകളിൽ PHP_SESSION_UPLOAD_PROGRESS അടങ്ങിയ അപ്‌ലോഡ് റിക്വസ്റ്റുകൾ, പുതിയതോ മാറ്റം വന്നതോ ആയ ഫയലുകൾ, cron ജോലികൾ, യൂസർ അക്കൗണ്ടുകൾ എന്നിവ നോക്കുക. വൃത്തിയാക്കുന്നതിന് മുൻപ് ലോഗുകൾ സൂക്ഷിച്ചുവയ്ക്കുക. എന്തെങ്കിലും കണ്ടെത്തിയാൽ, സെർവർ ഒറ്റപ്പെടുത്തുക, അതിലുണ്ടായിരുന്ന എല്ലാ ക്രെഡൻഷ്യലുകളും മാറ്റുക, വൃത്തിയുള്ള സോഴ്സിൽ നിന്ന് പുനർനിർമ്മിക്കുക.

2026-ലും അതിനുശേഷവും പാലിക്കേണ്ട പുതിയ ശീലങ്ങൾ

ഇന്റർനെറ്റിലേക്ക് തുറന്നിരിക്കുന്ന ഗുരുതര പിഴവുകൾ ആഴ്ചകളിലല്ല, മണിക്കൂറുകൾക്കുള്ളിൽ പാച്ച് ചെയ്യുക.
പിന്തുണ അവസാനിച്ച സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കരുത്. ഔദ്യോഗിക അപ്ഡേറ്റുകൾ ഇല്ലാത്ത ഓരോ PHP പതിപ്പും ഒരു സ്ഥിരം അപകടമാണ്.
പല തലങ്ങളിലുള്ള പ്രതിരോധം: മുന്നിൽ ഒരു ഫയർവാൾ അല്ലെങ്കിൽ CDN, റിക്വസ്റ്റ് സൈസ് പരിധികൾ, ആവശ്യത്തിന് മാത്രം അനുമതിയുള്ള സെർവറുകൾ, യഥാർത്ഥത്തിൽ പരീക്ഷിച്ചുനോക്കിയ ഓഫ്-സെർവർ ബാക്കപ്പുകൾ.
CVE ലിസ്റ്റുകൾ മാത്രമല്ല, പെരുമാറ്റവും ശ്രദ്ധിക്കുക. ഒരു വെബ് സെർവർ പെട്ടെന്ന് shell തുറക്കുന്നത്, ബഗിന്റെ പേര് എന്തായാലും, സംശയകരമാണ്.
നിങ്ങളുടെ സ്റ്റാക്ക് അറിയുക. റൺ ചെയ്യുന്നതെന്താണെന്ന് അറിയാത്തത് പാച്ച് ചെയ്യാൻ കഴിയില്ല.

ഉറവിടങ്ങൾ

2026 ഒക്ടോബർ 22 വരെയുള്ള വിവരങ്ങൾ. ഇത് വേഗത്തിൽ മാറിക്കൊണ്ടിരിക്കുന്ന വാർത്തയാണ്, പുതിയ വിവരങ്ങൾക്ക് PHP-യുടെ അറിയിപ്പ് പരിശോധിക്കുക.

All insightsWeb