Հրապարակվել են 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() կանչ են առաջացնում։
- Եթե կատարողականությունը կարևոր չէ, կարող եք սահմանափակել մեկ աշխատանքային պրոցեսի կողմից մշակվող հարցումների քանակը՝ օգտագործելով pm.max_requests=1-ը PHP-FPM-ում և MaxRequestsPerChild-ը Apache httpd-ում։
- Կարգավորումը 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 handler-ում longjmp() կանչը փոխարինել _exit()-ով։
- Բացի այդ, դուք կարող եք նվազեցնել php.ini ֆայլում max_input_nesting_level պարամետրի արժեքը և արգելափակել բազմամաս հարցումները, ինչպես ցույց է տրված նախնական հայտարարության մեջ։
Բաշխումներում խոցելիությունների շտկման կարգավիճակը կարելի է գնահատել այս էջերում՝ 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-ի ներկայացուցիչները նախկինում հայտարարել էին, որ այս խոցելիությունը կապ չունի առաջիկա թարմացումների հետ և իրական խնդիր չէ: Սակայն շահագործման հեղինակը պնդում էր, որ դա բոլորովին այլ խոցելիություն է:
Source: opennet.ru
