PHP-ის კრიტიკული დაუცველობების დეტალები გამჟღავნდა და პატჩები გამოქვეყნდა.

გამოქვეყნდა PHP 8.5.12, 8.4.27, 8.3.36 და 8.2.35 ვერსიების კორექტირების ვერსიები, ასევე გამოქვეყნდა პატჩები PHP 7.4, PHP 8.0 და PHP 8.1 შტოებისთვის, რომლებიც აღარ არის მხარდაჭერილი (დაუზიანებელი ვერსიები 5.4-დან 7.3-მდე კვლავ დაუპატჩებელია), რომლებიც ასწორებს ორ კრიტიკულ დაუცველობას:

• CVE-2026-109618 — კოდის დისტანციური შესრულება არის დაუცველობა, რომელიც გამოწვეულია მეხსიერების ამოწურვისას longjmp() ფუნქციის შესრულებით, როდესაც პროცესს მეხსიერება ამოეწურება. ამ დაუცველობამ შეიძლება გამოიწვიოს PHP ინტერპრეტატორის შეწყვეტა, როდესაც ინიციალიზებულია მხოლოდ მოთხოვნის დამუშავებასთან დაკავშირებული შიდა სტრუქტურების ნაწილი. შემდეგ მოთხოვნის დასრულების ფუნქცია იღებს წვდომას ამ სტრუქტურებზე ისე, თითქოს ისინი უკვე ინიციალიზებული იყოს, მიუხედავად იმისა, რომ მათთვის მეხსიერება არ არის გამოყოფილი.

  ძირითადი შეტევის ვექტორია მრავალნაწილიანი მოთხოვნების მანიპულირება პროცესის ხელმისაწვდომი მეხსიერების ამოსაწურად. post_max_size ლიმიტის გვერდის ავლით, შესაძლებელია Content-Length სათაურის გამოტოვება და HTTP სათაურის დიდი რაოდენობის გადაცემა. ასევე შესაძლებელია მიზნობრივი შეტევები PHP აპლიკაციებში კონკრეტულ ოპერაციებზე, რომლებიც ზედმეტ მეხსიერებას მოიხმარენ. ექსპლოიტი დადასტურებულია mod_php-სთვის, რადგან ის იწვევს shutdown() ფუნქციას წარუმატებლობის შემთხვევაშიც კი. PHP-FPM შეწყვეტს შვილობილ პროცესს წარუმატებლობის შემთხვევაში, რაც შეტევას ართულებს, მაგრამ თეორიულად შეუძლებელს არ ხდის.

• CVE-2026-109619 – კოდის დისტანციური შესრულება გამოწვეულია „გამოყენების შემდეგ თავისუფალი“ დაუცველობით, რაც გამოწვეულია კონკრეტულ მოთხოვნასთან დაკავშირებული გლობალური მდგომარეობის არასათანადო გაწმენდით. თუ მოთხოვნა შეწყდება ფატალური შეცდომის, ვადის ამოწურვის ან მეხსიერების ამოწურვის გამო, გლობალური მდგომარეობა შეიძლება არ გადაყენდეს და მაჩვენებლები შეიძლება აქტიური დარჩეს, მიუხედავად იმისა, რომ მათ მიერ მითითებული მეხსიერება გათავისუფლდა. იმავე პროცესში შემდგომი მოთხოვნის დამუშავებისას, დარჩენილ მაჩვენებელზე წვდომა შესაძლებელია ძველ გლობალურ მდგომარეობაზე.

  ექსპლუატაციის მიღწევა შესაძლებელია ატვირთვის პროგრესის ინდიკატორის კოდში (session.upload_progress) მრავალნაწილიანი მოთხოვნის დამუშავების დროს მეხსიერების ამოწურვის პირობების შექმნით. პირველადი და დადასტურებული შეტევის ვექტორი არის PHP 8.5-ის fatal_error_backtraces დამმუშავებელი, რომელიც არ აღადგენს ტრასირების მდგომარეობას დასრულების შემდეგ. პირველ შემთხვევაში, შეტევა შესაძლებელია mod_php-სა და PHP-FPM-ზე, ხოლო მეორე შემთხვევაში, ის მხოლოდ mod_php-ზეა შესაძლებელი. დაუდასტურებელი შეტევა ასევე ნახსენებია კონფიგურაციებში, რომლებიც შეიცავს დირექტივებს, რომლებიც იწვევენ გაფრთხილებებს მოთხოვნის დამუშავების ადრეულ ეტაპზე (მაგალითად, გაფრთხილებები მოძველებული პარამეტრების გამოყენების შესახებ).

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

• php.ini ფაილში „memory_limit=-1“ პარამეტრის დაყენება თავდამსხმელისთვის მეხსიერების ლიმიტების ამოწურვის კონტროლს ართულებს.
• თუ დიდი ფაილების ატვირთვა არ გჭირდებათ, დააყენეთ პარამეტრი „post_max_size = 8M“. პარამეტრი „upload_max_filesize“ უნდა იყოს „post_max_size“ პარამეტრზე ნაკლები.
• სისტემის დონეზე მისაღები მეხსიერების მოხმარების ლიმიტის დაწესება, cgroup memory.max-ის ან კონტეინერის მეხსიერების მოხმარების პარამეტრების მეშვეობით, მაგრამ არა სისტემური RLIMIT_AS-ის და RLIMIT_DATA-ს ლიმიტების მეშვეობით, რაც მხოლოდ პრობლემურ longjmp() გამოძახებას იწვევს.
• თუ შესრულება მნიშვნელოვანი არ არის, შეგიძლიათ შეზღუდოთ ერთი მუშა პროცესის მიერ დამუშავებული მოთხოვნების რაოდენობა PHP-FPM-ში pm.max_requests=1-ის და Apache httpd-ში MaxRequestsPerChild-ის გამოყენებით.
• php.ini-ზე ან კონფიგურაციის დონეზე დაყენება სერვერი (არა ini_set() ან FPM .user.ini-ს მეშვეობით, რადგან პარამეტრი უნდა იყოს ძალაში მოთხოვნის დამუშავებამდე) პარამეტრი "session.upload_progress.enabled=0".
• PHP 8.5 ვერსიის გამოყენებისას, უნდა დაყენდეს პარამეტრი "fatal_error_backtraces=0".
• წაიშალა მოთხოვნისთვის განკუთვნილი მოძველებული ან მცდარი პარამეტრები (მაგალითად, assert.* და open_basedir-ში არასწორი ბილიკები), რომლებიც იწვევდა დიაგნოსტიკური შეტყობინებების გამოტანას ინიციალიზაციამდე.
• PHP კოდის პრობლემების გამოსწორება, რამაც შეიძლება გამოიწვიოს ვადის ამოწურვა და ფატალური შეცდომები, მაგალითად, უკუკავშირის დამმუშავებლებთან და ჩამოტვირთვის დამუშავების ჩავარდნებთან დაკავშირებული პრობლემები.
• PHP-ის ძველი ვერსიების კოდში პირველი დაუცველობის დასაბლოკად, შეგიძლიათ out-of-memory დამმუშავებელში longjmp() გამოძახება _exit()-ით შეცვალოთ.
• გარდა ამისა, შეგიძლიათ შეამციროთ max_input_nesting_level პარამეტრის მნიშვნელობა php.ini ფაილში და დაბლოკოთ მრავალნაწილიანი მოთხოვნები, როგორც ეს ნაჩვენებია წინასწარ განცხადებაში.

დისტრიბუციებში დაუცველობის გამოსწორების სტატუსის შეფასება შესაძლებელია ამ გვერდებზე: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

დანართი 1: დაუცველობები გამოვლინდა GPT-5.6 და Gemini 4 Argon AI მოდელების გამოყენებით. OpenAI-მ გამოაქვეყნა php2shell-checker პროგრამა ვებსაიტებისა და ლოკალური შესრულებადი ფაილების დაუცველობაზე შესამოწმებლად, თუმცა ეს პროგრამა მხოლოდ HTTP სერვერის ან "php -v" ბრძანების მიერ დაბრუნებულ PHP ვერსიის ნომერს ამოწმებს, დეტალური ანალიზის გარეშე.

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

წყარო: opennet.ru