PHP კვლავ საფრთხეში: ახალი დაუხურავი ხარვეზი PHP2Shell-ის პაჩებიდან ორ დღეში და რას ნიშნავს ეს ინტერნეტის 70%-ისთვის

ორი დღეც არ იყო გასული მას შემდეგ, რაც PHP-მ კრიტიკული PHP2Shell ხარვეზებისთვის სასწრაფო განახლებები გამოუშვა, რომ პროექტმა კიდევ ერთი გაფრთხილება გამოაქვეყნა. ახალი ხარვეზი, CVE-2026-115560, ჯერ დახურული არ არის. საფრთხე ამჯერად ვიწროა, მაგრამ კონტექსტი ძალიან სერიოზული: საუბარია ენაზე, რომელზეც ინტერნეტის საიტების დიდი უმრავლესობა მუშაობს.

TechCrush-ში შევეცადეთ, გაგვერკვია, რეალურად რამდენად დიდია პრობლემა, ვის ეხება და რა შეიძლება მოხდეს, თუ ასეთი ტალღა გაგრძელდა.

რა მოხდა

PHP2Shell: ხარვეზი, რომელმაც ყველა შეაშფოთა

21 ოქტომბერს PHP-მ ორი კრიტიკული ხარვეზი, CVE-2026-109618 და CVE-2026-109619, დახურა. ერთად მათ PHP2Shell უწოდეს. ორივე ავტორიზაციის გარეშე სერვერზე კოდის დისტანციურად გაშვების (RCE) საშუალებას იძლევა. პირველი დაკავშირებულია მეხსიერების დაზიანებასთან, როცა მოთხოვნის დამუშავებისას PHP-ს მეხსიერება ეწურება, მეორე კი წინა მოთხოვნიდან დარჩენილ, უკვე გათავისუფლებულ მდგომარეობას იყენებს. Datadog-ის მკვლევრებმა ორივე დამოუკიდებლად გაიმეორეს და ორივეს CVSS v4.0 სკალით 9.2 ქულა აქვს. მთავარი დეტალი ისაა, რომ მავნე მოთხოვნა მუშავდება მანამდე, სანამ თავად საიტის კოდი გაეშვება, ამიტომ საიტის ავტორიზაცია ვერაფერს შველის.

ხარვეზები დახურულია ვერსიებში PHP 8.5.12, 8.4.27, 8.3.36 და 8.2.35. ჰოლანდიის კიბერუსაფრთხოების ცენტრის (NCSC-NL) თანახმად, საფრთხის ქვეშ იყო ვებ მოთხოვნების მომსახურე ყველა ინსტალაცია: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP და LiteSpeed, ყველაზე მაღალი რისკით mod_php-ზე. Docker-ის ცნობით, ხარვეზები PHP-ს 5.4 ვერსიიდან მოყოლებულ პაკეტებშია. აშშ-ის CISA-მ ორგანიზაციებს სასწრაფო განახლებისკენ მოუწოდა, ხოლო ვინც PHP 8.1-ს ან უფრო ძველს იყენებს და ვერ ანახლებს, ურჩია, სისტემა ინტერნეტიდან გათიშოს.

თავდასხმებმაც არ დააყოვნა. The Hacker News-ის ცნობით, Amazon-ის ჰანიპოტებმა ექსპლოიტის მცდელობა 17 ოქტომბერს, ანუ გასაჯაროებამდე ოთხი დღით ადრე, დააფიქსირეს. Cloudflare-ის მონაცემებით, გასაჯაროებიდან 45 წუთში მცდელობები ათეულ ათასებს აღწევდა, 22 ოქტომბრის დილისთვის კი მილიონებს. Sophos-ისა და Arctic Wolf-ის თქმით, თავდამსხმელები Mirai ბოტნეტის ვარიანტის დაყენებას ცდილობდნენ. ჯერჯერობით ეს მცდელობები წარუმატებელია: Wordfence და სხვები სკანირებას და ზონდირებას ხედავენ, კოდის დადასტურებული გაშვების გარეშე.

ახალი ხარვეზი: CVE-2026-115560

23 ოქტომბერს PHP-მ მოკლე საინფორმაციო გაფრთხილება გამოაქვეყნა. ახალი ხარვეზი PHP2Shell-ისგან განცალკევებულია და 21 ოქტომბრის განახლებები მას არ ხურავს. პროექტი საგანგებო პაჩს არ უშვებს და შესწორებას მომდევნო რიგით გამოშვებაში, სრულ ადვაიზორისთან ერთად აპირებს.

საფრთხე მხოლოდ მაშინ ჩნდება, როცა ვებ აპლიკაცია ერთდროულად ყველა ამ პირობას აკმაყოფილებს:

• კონფიგურაციაში session.serialize_handler დაყენებულია php_binary ან php_serialize მნიშვნელობაზე;
• მუშაობისას აპლიკაცია ამ პარამეტრს ini_set() ფუნქციით php-ზე ცვლის;
• ეს ცვლილება session_start()-მდე ხდება;
• ჩართულია session upload progress ფუნქცია, რომელიც ნაგულისხმევად ჩართულია.

აპლიკაცია, რომელიც serialize handler-ს მუშაობისას არ ცვლის, ამ გზით დაუცველი არ არის. PHP ამ კონფიგურაციას პრაქტიკაში ნაკლებად სავარაუდოდ მიიჩნევს. პროექტს ჯერ არ დაუსახელებია დაზიანებული ვერსიები, შესწორების ვერსიები, სიმძიმის ქულა და ისიც, აქვს თუ არა ახალ ხარვეზს CVE-2026-109619-თან საერთო ფესვი. CVE-2026-115560-ის ექსპლუატაცია ჯერ არ დაფიქსირებულა.

რეკომენდაცია ერთი ხაზია: session.upload_progress.enabled=0. ეს იგივე პარამეტრია, რომელიც PHP-მ 21 ოქტომბერს CVE-2026-109619-ის დროებით გამოსავლად დაასახელა. ვინც მაშინ გათიშა და ასე დატოვა, დამატებით არაფერი სჭირდება. მნიშვნელოვანია: Datadog-ის თქმით, ეს პარამეტრი PHP2Shell-ისგან სრულად არ იცავს, იქ ერთადერთი რეალური გამოსავალი განახლებაა.

რამდენად დიდია პრობლემა

W3Techs-ის 23 ოქტომბრის მონაცემებით, PHP-ს იყენებს იმ საიტების 69.3%, რომელთა სერვერულ ენასაც სერვისი ადგენს. ტოპ მილიონ საიტს შორის ეს მაჩვენებელი 64.4%-ია. შედარებისთვის, მეორე ადგილზე მყოფ JavaScript-ს 8.2% აქვს. PHP-ს გამოყენებელ საიტებს შორის მერვე ვერსიაზე 65.3% მუშაობს, მეშვიდეზე 26.9%, მეხუთეზე კი 7.7%. ეს ნიშნავს, რომ PHP საიტების დაახლოებით მესამედზე მეტი ისეთ ვერსიებზეა, რომლებსაც PHP პროექტი ოფიციალურად აღარ უჭერს მხარს.

PHP მხოლოდ საიტები არ არის. NCSC-NL ხაზს უსვამს, რომ ის ჩაშენებულია მოწყობილობებში, ქსელურ აპარატურაში და მართვის პანელებში, სადაც ადმინისტრატორს PHP-ს დამოუკიდებლად განახლება ხშირად არც შეუძლია. CISA-ც აფრთხილებს, რომ PHP ხშირად სხვა პროგრამის ნაწილია და მისი არსებობა ერთი შეხედვით არც ჩანს.

ამ ფონზე CVE-2026-115560 თავისთავად მცირე რისკია. მისი რეალური მნიშვნელობა სხვაგანაა: ის აჩვენებს, რომ PHP-ს სესიების და მეხსიერების მართვის ნაწილს ახლა მკვლევრები და თავდამსხმელები ერთდროულად ჩხრეკენ.

თუ ეს გაგრძელდა: სცენარები

ქვემოთ მოცემული სცენარები TechCrush-ის ანალიზია და არა დადასტურებული ფაქტები ან პროგნოზი.

სცენარი 1. სიმშვიდე. CVE-2026-115560 მართლაც იშვიათი რჩება, შესწორება რიგით გამოშვებაში შემოდის, PHP2Shell-ის საიმედო ექსპლოიტი კი ვერავინ ააწყო. ზარალი შეზღუდული რჩება, ძირითადად ავარიული შეჩერებებით და სამუშაო საათებით.

სცენარი 2. ჯაჭვი. მკვლევრები სესიების იმავე უბანში ახალ ვარიანტებს პოულობენ, ზოგი კი უფრო ფართო კონფიგურაციას ეხება. ადმინისტრატორები კვირაში რამდენჯერმე ანახლებენ, მცირე ჰოსტინგები ვეღარ ეწევიან და დაუცველი სერვერების „კუდი“ თვეობით რჩება.

სცენარი 3. კრიტიკული ზღვარი. ჩვენი შეფასებით, ზღვარი გადაილახება, თუ PHP2Shell-ისთვის საიმედო, საჯარო ექსპლოიტი გამოჩნდება, სანამ დაუცველი სერვერების დიდი ნაწილი განახლდება. მაშინ მილიონობით ავტომატური მცდელობა, რომელსაც Cloudflare უკვე ხედავს, რეალურ შეღწევებად გადაიქცევა: ბოტნეტებში ჩართული სერვერები, ვებ შელები, მონაცემთა გაჟონვა და გამოსასყიდის პროგრამები. განსაკუთრებით მოწყვლადი იქნება მხარდაჭერის გარეშე დარჩენილი ვერსიები და მოწყობილობებში ჩაშენებული PHP.

ფინანსური ზეგავლენა

IBM-ის 2025 წლის Cost of a Data Breach ანგარიშის მიხედვით, მონაცემთა გაჟონვის საშუალო ღირებულება მსოფლიოში 4.44 მილიონი აშშ დოლარია, აშშ-ში კი რეკორდული 10.22 მილიონი. გაჟონვის აღმოჩენას და შეკავებას საშუალოდ 241 დღე სჭირდება. გამოძალვის ან გამოსასყიდის პროგრამის ინციდენტი, რომელიც თავად თავდამსხმელმა გაამხილა, საშუალოდ 5.08 მილიონი ჯდება. ორგანიზაციების 63%-მა გამოსასყიდის გადახდაზე უარი თქვა.

ეს ციფრები ძირითადად საშუალო და დიდ ორგანიზაციებს ეხება, მაგრამ ლოგიკა ყველასთვის ერთია: ხარჯი შედგება გამოძიებისგან, აღდგენისგან, მომხმარებლების ინფორმირებისგან და, რაც ყველაზე მტკივნეულია, დაკარგული ბიზნესისგან. მცირე ონლაინ მაღაზიისთვის რამდენიმედღიანი გათიშვაც კი შეიძლება სეზონის შემოსავლის დაკარგვას ნიშნავდეს. ამას ემატება ფარული ხარჯი: ინჟინრების საათები განუწყვეტელი პაჩებისთვის, ჰოსტინგის მხარდაჭერის დატვირთვა და WAF სერვისების საფასური.

სხვა ზეგავლენები

ჰოსტინგი და WordPress ეკოსისტემა. WordPress, Drupal და სხვა პოპულარული CMS-ები PHP-ზე მუშაობს. Shared ჰოსტინგზე ერთი სერვერი ასობით საიტს ემსახურება, ამიტომ განახლება პროვაიდერის საქმეა და საიტის მფლობელს ხშირად წარმოდგენაც არ აქვს, რომელ ვერსიაზეა. სწორედ აქ Wordfence-ის მსგავსი სერვისები უკვე ხედავენ ზონდირებას.

მონაცემთა გაჟონვა და გამოსასყიდის პროგრამები. კოდის გაშვება სერვერზე ნიშნავს წვდომას მონაცემთა ბაზებზე, მომხმარებლების პირად მონაცემებზე და ხშირად შიდა ქსელზეც. Mirai-ს მცდელობები აჩვენებს, რომ პირველი ტალღა ბოტნეტებისკენაა მიმართული, შემდეგი ეტაპი კი ტრადიციულად მონაცემების მოპარვაა.

ნდობა ღია კოდისადმი. პარადოქსულად, ეს ამბავი ღია კოდის ძლიერ მხარესაც აჩვენებს: PHP გამჭვირვალედ აცხადებს ახალ რისკსაც კი, რომელსაც თავად „ნაკლებად სავარაუდოს“ უწოდებს. თუმცა ისიც ცხადია, რომ ინტერნეტის ორი მესამედის საფუძველი შედარებით მცირე გუნდის რესურსზეა დამოკიდებული.

პაჩების დაღლილობა. ორ დღეში ორი გაფრთხილება ადმინისტრატორებს ღლის. საფრთხე ისაა, რომ ვინმემ ახალი, ნაკლებად სახიფათო გაფრთხილება წაიკითხოს და ჩათვალოს, რომ PHP2Shell-ის განახლებაც შეიძლება გადადოს. ეს შეცდომა იქნება.

ქართული ბიზნესი და სახელმწიფო საიტები. საქართველოში მცირე ბიზნესის, მედიის, საგანმანათლებლო და მუნიციპალური საიტების დიდი ნაწილი ტიპურად WordPress-ზე ან სხვა PHP სისტემაზე და ადგილობრივ ან იაფ shared ჰოსტინგზეა აწყობილი. ბევრი მათგანი წლების წინ შექმნეს და მას შემდეგ არავის განუახლებია. ზუსტი სტატისტიკა ქართული საიტებისთვის არ გაგვაჩნია, მაგრამ ასეთი საიტები ჩვეულებრივ ყველაზე ბოლოს ახლდება და ავტომატური სკანერებისთვის ყველაზე მარტივი სამიზნეა.

რა უნდა გააკეთონ ადმინისტრატორებმა ახლავე

1. გაარკვიეთ, სად გაქვთ PHP. შეადგინეთ სია საიტების, კონტეინერების, მოწყობილობების და მართვის პანელების, მათ შორის მესამე მხარის პროდუქტების.
2. განაახლეთ PHP2Shell-ის გამო. გადადით 8.5.12, 8.4.27, 8.3.36 ან 8.2.35 ვერსიაზე, პირველ რიგში ინტერნეტში გამოჩენილ სისტემებზე. Docker-ის მომხმარებლებმა განაახლეთ ოფიციალური იმიჯები.
3. ძველი ვერსიები. PHP 8.1 და უფრო ძველისთვის გამოიყენეთ დისტრიბუტივის ან LTS მომწოდებლის პაჩები ან გადადით მხარდაჭერილ ვერსიაზე. CISA-ს რეკომენდაციით, თუ ეს შეუძლებელია, სისტემა ინტერნეტიდან გათიშეთ.
4. CVE-2026-115560-სთვის php.ini-ში დააყენეთ session.upload_progress.enabled=0 და გადატვირთეთ PHP worker-ები.
5. შეამოწმეთ კოდი: მოძებნეთ ini_set('session.serialize_handler' გამოძახებები, განსაკუთრებით session_start()-მდე.
6. დროებითი დაცვა: WAF ან reverse proxy დიდ multipart მოთხოვნებს და session upload progress ველს გაფილტრავს. AWS-მა და სხვებმა მზა წესები გამოაქვეყნეს. გახსოვდეთ, რომ ეს განახლებას არ ცვლის.
7. მონიტორინგი: ადევნეთ თვალი PHP პროცესებს, რომლებიც shell-ს უშვებენ ან ფაილებს წერენ, მეხსიერების ამოწურვის შეცდომებს და უცნაურ დიდ ფორმებს.
8. shared ჰოსტინგზე მისწერეთ პროვაიდერს და პირდაპირ ჰკითხეთ, რომელ PHP ვერსიაზეა თქვენი საიტი და დაყენებულია თუ არა 21 ოქტომბრის განახლებები.

TechCrush-ის დასკვნა მარტივია: ახალი ხარვეზი პანიკის მიზეზი არ არის, მაგრამ შეხსენებაა. ნამდვილი საფრთხე განუახლებელ სერვერებზე დარჩენილი PHP2Shell-ია, და ვინც დღეს არ განახლდება, შეიძლება ხვალ სწორედ იმ მილიონობით მცდელობიდან ერთ-ერთის მსხვერპლი გახდეს.

იხილეთ ასევე: PHP2Shell: ინტერნეტის 70%-ის ძრავაში, PHP-ში, ორი საშიში ხარვეზი იპოვეს

წყაროები

• The Hacker News: PHP Warns of Another Unpatched RCE Two Days After Emergency PHP2Shell Patches
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC-NL: php2shell operational information
• Datadog Security Labs: PHP2Shell analysis
• Docker: Security Update on PHP2Shell
• AWS Security Blog: AWS WAF mitigations for PHP2Shell
• W3Techs: Usage statistics of PHP
• IBM: Cost of a Data Breach Report 2025
• CyberNews: Millions of PHP attacks recorded as new unpatched vulnerability discovered

ეს სტატია შეიქმნა AI ხელსაწყოებით, პროცესში ადამიანის ჩართულობა დაახლოებით 10%-ია.