PHP2Shell: კრიტიკული PHP ხარვეზები – როგორ დააპაჩოთ ახლავე

2026 წლის 21 ოქტომბერი | PHP | IT უსაფრთხოება

2026 წლის 21 ოქტომბერს PHP უსაფრთხოების გუნდმა გამოაქვეყნა განახლებები ყველა ჯერ კიდევ მხარდაჭერილი PHP ვერსიისთვის. ისინი ხურავენ ორ კრიტიკულ მოწყვლადობას, რომლებიც PHP2Shell-ის სახელით გახდა ცნობილი. BSI-მ ამასთან დაკავშირებით გაფრთხილება გამოსცა და მოითხოვს, დაზარალებული სისტემები დაუყოვნებლივ დაპაჩდეს. ვინც PHP-ით ვებსერვერს ამუშავებს, დღესვე უნდა იმოქმედოს. ეს ეხება ასევე ყველას, ვინც „მხოლოდ“ WordPress-ს, Nextcloud-ს ან Joomla-ს ამუშავებს, რადგან ეს აპლიკაციები PHP-ზე მუშაობს.

ეს სტატია აჯამებს, რა მოხდა, რომელი PHP ვერსიებია დაზარალებული, რომელი ვერსია გჭირდებათ ახლა და როგორ შეამოწმოთ რამდენიმე წუთში, არის თუ არა თქვენი სერვერი დაცული.

რა მოხდა? დროითი თანმიმდევრობა

PHP უსაფრთხოების გუნდმა გამოსწორებების გამოქვეყნება წინასწარ გამოაცხადა, რათა ჰოსტერებსა და ადმინისტრატორებს მომზადების დრო ჰქონოდათ. თავად გამოქვეყნება 2026 წლის 21 ოქტომბერს მოხდა. BSI-მ იმავე დღეს გამოსცა თავისი გაფრთხილება (ვერსია 1.1).

• 2026 წლის 20 ოქტომბერი: PHP უსაფრთხოების გუნდის წინასწარი გაფრთხილება, რომ მომდევნო დღეს უსაფრთხოების განახლებები გამოვა.
• 2026 წლის 21 ოქტომბერი, 14:00 UTC (16:00 საათი CEST): გამოქვეყნდება პაჩები PHP 8.5-ის, 8.4-ის, 8.3-ისა და 8.2-ისთვის.
• 2026 წლის 21 ოქტომბერი: BSI აფრთხილებს „კრიტიკული მოწყვლადობების შესახებ, რომლებიც მთელ მსოფლიოში ვებაპლიკაციებს ემუქრება“, და გვირჩევს, დაუყოვნებლივ დავაპაჩოთ. BSI-ის ცნობით, მსხვილმა ჰოსტინგ-პროვაიდერებმა ნაწილობრივ სერვერები სიფრთხილის მიზნით ქსელიდან გამორთეს.

ორივე PHP მოწყვლადობა მოკლედ

ეს ორი განცალკევებული შეცდომაა PHP-ის ბირთვში: CVE-2026-109618 და CVE-2026-109619. ორივეს, PHP უსაფრთხოების გუნდის მონაცემებით, შეუძლია გამოიწვიოს, რომ თავდამსხმელმა სერვერზე პროგრამული კოდი შეასრულოს შესვლის გარეშე (unauthenticated Remote Code Execution). მოწყვლადობები ფასდება CVSS v4.0: 9,2 (კრიტიკული).

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

ვის ეხება?

დაზარალებულია პრინციპულად ყველა სერვერი, რომელზეც PHP მუშაობს, იმისგან დამოუკიდებლად, როგორაა PHP მიერთებული: PHP-FPM, mod_php Apache-ში, php-cgi, FrankenPHP ან LiteSpeed. PHP უსაფრთხოების გუნდის თანახმად, ყველაზე მაღალი რისკი Apache mod_php-ით არის.

BSI პირდაპირ ასახელებს აპლიკაციებს, რომლებიც PHP-ზე არის აგებული და ამიტომ შეიძლება ასევე იყვნენ დაზარალებულნი:

• კონტენტის მართვის სისტემები: WordPress, Drupal, TYPO3, Joomla
• მაღაზიის სისტემები: Magento
• ღრუბელი და ფაილების საცავი: Nextcloud
• ბრანდმაუერის ინტერფეისები: pfSense, OPNsense

თავად აპლიკაცია ამისთვის არ უნდა იყოს მცდარი. ხარვეზი PHP-შია, ამიტომ მხოლოდ WordPress-ის, Nextcloud-ისა & სხვების განახლება არ ეხმარება. სერვერზე PHP ვერსია უნდა განახლდეს. ბრანდმაუერების შემთხვევაში, როგორიცაა pfSense და OPNsense, გამოსწორებული PHP ვერსია მწარმოებლის შესაბამისი firmware განახლებით მოდის.

ეს PHP ვერსიები უსაფრთხოა

მოწყვლადობები გასწორებულია შემდეგ ვერსიებში. ყველაფერი ქვემოთ მოწყვლადად ითვლება.

როგორ შეამოწმოთ და განაახლოთ თქვენი სერვერი

1. დაინსტალირებული PHP ვერსიის დადგენა

სერვერის ბრძანებათა სტრიქონში php -v აჩვენებს ბრძანებათა სტრიქონის PHP-ის ვერსიას. ვებსერვერმა შეიძლება სხვა PHP ვერსია გამოიყენოს. ამიტომ შეამოწმეთ ასევე PHP-FPM-ის ან Apache მოდულის ვერსია, მაგალითად php-fpm8.3 -v-ით ან გვერდის საშუალებით, რომელიც phpinfo()-ს გამოიტანს (ამის შემდეგ მაშინვე წაშალეთ).

2. განახლების ჩადგმა პაკეტების მართვით

Debian-ის, Ubuntu-ს, RHEL-ისა და მონათესავე სისტემების შემთხვევაში გამოსწორებული ვერსია ჩვეულებრივი პაკეტების მართვით მოდის, მაგალითად apt update && apt upgrade ან dnf upgrade. გარე წყაროების, როგორიცაა Sury-PPA ან Remi-Repository, შემთხვევაში ახალი პაკეტები უმეტესად დროულად ჩნდება.

3. PHP სერვისის გადატვირთვა

მხოლოდ პაკეტის განახლება არ კმარა: გაშვებული PHP პროცესები ძველ კოდს მეხსიერებაში ინარჩუნებენ. გადატვირთეთ PHP-FPM (systemctl restart php8.3-fpm) ან Apache (systemctl restart apache2) და შემდეგ შეამოწმეთ, განახლების შემდეგ დაიწყო თუ არა პროცესები.

4. ჰოსტირებული ვებგვერდები

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

PHP 8.1 და უფრო ძველი: ოფიციალური განახლება არ არსებობს

PHP 8.1-ისა და უფრო ძველისთვის ოფიციალური უსაფრთხოების განახლებები აღარ არსებობს. ასეთი სისტემების ოპერატორებს ორი შესაძლებლობა აქვთ:

• მხარდაჭერილ ვერსიაზე გადასვლა (რეკომენდებული). რაც უფრო ძველია ვერსია, მით უფრო დიდია აპლიკაციისა და გაფართოებების ადაპტაციის ხარჯი, ამიტომ გადასვლა წინასწარ უნდა გამოიცადოს.
• გამოსწორებების უკან გადატანა. PHP უსაფრთხოების გუნდმა გამოსწორებები GitHub-ზე განვითარების განშტოებებში გამოაქვეყნა. ვინც PHP-ს თავად აკომპილირებს, შეუძლია ეს ცვლილებები უფრო ძველ ვერსიებში გადაიტანოს. ეს გარდამავალი გადაწყვეტაა და სპეციალურ ცოდნას მოითხოვს.

PHP 8.2-იც მხოლოდ 2026 წლის 31 დეკემბრამდეა მხარდაჭერილი. დაგეგმეთ ამიტომ გადასვლა PHP 8.4-ზე ან 8.5-ზე ახლავე და არ გადადოთ წლის ბოლომდე.

დროებითი ზომები და კითხვა „სერვერი გამოვრთოთ ქსელიდან?“

PHP უსაფრთხოების გუნდმა განცხადებასთან ერთად აღწერა ასევე დროებითი დამცავი ზომები. ისინი რისკს ამცირებენ, მაგრამ ხარვეზებს სრულად არ ხურავენ. ისინი განახლებას არ ანაცვლებენ და განკუთვნილია მხოლოდ იმისთვის, რომ განახლებამდე დრო გადაიფარონ.

უნდა გამოირთოს თუ არა სერვერი ქსელიდან განახლებამდე, დამოკიდებულია მის მნიშვნელობასა და ხელმისაწვდომობაზე. BSI განმარტავს, რომ დიდმა პროვაიდერებმა ეს ნაბიჯი გადადგეს. ცერის წესი ასეთია:

• საჯაროდ ხელმისაწვდომი სერვერი, განახლება ახლა შესაძლებელია: დაუყოვნებლივ დააპაჩეთ, გამორთვა საჭირო არ არის.
• საჯაროდ ხელმისაწვდომი სერვერი, განახლება მოკლე ვადაში შეუძლებელია: შეზღუდეთ წვდომა (მაგალითად ბრანდმაუერით მხოლოდ ცნობილი მისამართებისთვის) ან სერვისი დროებით გამორთეთ, განსაკუთრებით mod_php-ის შემთხვევაში.
• მხოლოდ შიგნიდან ხელმისაწვდომი სერვერი: დროულად დააპაჩეთ, სასწრაფოობა უფრო დაბალია.

ხშირი კითხვები

უნდა განვაახლო თუ არა WordPress, Joomla ან Nextcloud?

ამ მოწყვლადობის გამო — არა. ის PHP-შია და არა აპლიკაციაში. განაახლეთ PHP-ის ვერსია სერვერზე. აპლიკაციის განახლებაც, მიუხედავად ამისა, მაინც მიზანშეწონილია.

როგორ ვიცი, უკვე გამოიყენა თუ არა ვინმემ ეს მოწყვლადობა?

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

საკმარისია თუ არა Web Application Firewall?

ფაიერვოლს შეუძლია ცნობილი თავდასხმის ნიმუშების შეჩერება, მაგრამ ის არ ცვლის განახლებას. დაცვის რამდენიმე ფენის ურთიერთქმედების შესახებ მეტი წაიკითხეთ ჩვენს სტატიაში Odoo 19-ის დაცვა: ფაიერვოლი, 2FA & Web RBL. ეს პრინციპები ნებისმიერ ვებ-აპლიკაციაზე მოქმედებს.

ეხება თუ არა ეს Odoo-ს?

არა. Odoo დაწერილია Python-ზე და PHP-ზე არ მუშაობს. ეს შეეხებოდა მხოლოდ იმ PHP-აპლიკაციებს, რომლებიც იმავე სერვერზე მუშაობს.

სად ვიპოვო ოფიციალური ინფორმაცია?

PHP-ის უსაფრთხოების გუნდის განცხადება იხილეთ php.net-ის სიახლეების არქივში (ჩანაწერი 2026 წლის 20 ოქტომბრიდან), ვერსიები კი მისამართზე php.net/downloads. BSI-ის გაფრთხილების ნომერია 2026-297981-1032 და საიტზე bsi.bund.de გამოქვეყნებულია.

მხარდაჭერა Biricon IT Services-ისგან

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

დაგვიკავშირდით ახლავე

მდგომარეობა: 2026 წლის 21 ოქტომბერი. სიტუაცია მოკლე ვადაში შეიძლება შეიცვალოს; გადამწყვეტია PHP-ის უსაფრთხოების გუნდისა და BSI-ის პუბლიკაციები.