Կայքը թարմացրել եք, ադմինի հաշիվն էլ պաշտպանել եք։ Թվում է՝ ամեն ինչ կարգին է։ Բայց կայքի աշխատանքը կախված է նաև PHP-ից՝ ծրագրից, որը սերվերի վրա կատարում է ձեր կայքի կոդը։ Եթե խնդիրը հենց PHP-ի մեջ է, միայն կայքը թարմացնելը կարող է չօգնել։

Հենց այսպիսի խնդիր է PHP2Shell-ը։ Այս անունով հայտնի են PHP-ի երկու վտանգավոր խոցելիություններ՝ CVE-2026-109618 և CVE-2026-109619։ Դրանք կարող են հարձակվողին թույլ տալ սերվերի վրա իր կոդը գործարկել՝ առանց կայքում հաշիվ ունենալու կամ մուտք գործելու։

Ըստ Huntress-ի՝ դրանց մասին տեղեկությունը տարածվել էր հոկտեմբերի 20-ին՝ նախատեսված հրապարակումից և թարմացումներից առաջ։ Հոկտեմբերի 21-ին PHP-ի թիմն արդեն թողարկեց ուղղումներն ու բացատրեց՝ ինչն էր սխալ։

​

Ինչն է վտանգավոր այս խոցելիությունների մեջ

Երբ կայքում ինչ-որ բան եք որոնում կամ ֆորմա եք լրացնում, ձեր բրաուզերը հարցում է ուղարկում սերվերին։ PHP-ն մշակում է այդ հարցումը և կատարում կայքի ծրագրավորողի գրած կոդը։

Այս խոցելիությունների դեպքում հարձակվողը կարող է հասնել նրան, որ սերվերը կատարի նաև իր կոդը։ Սա կոչվում է հեռակա կոդի կատարում՝ Remote Code Execution կամ RCE։

Օրինակ՝ սովորական այցելուն առցանց խանութում կարող է ապրանքներ դիտել ու պատվեր տալ։ Իսկ հաջող հարձակման դեպքում նա կարող է կարդալ կայքի որոշ ֆայլեր, ձեռք բերել դրանցում պահված գաղտնաբառերը կամ փոխել տվյալները։

flowchart TD
    R["Հարձակվողի կոդը կատարվում է սերվերի վրա"] --> F["Կայքի հասանելի ֆայլերի ընթերցում կամ փոփոխություն"]
    R --> S["Գաղտնաբառերի և API բանալիների գողություն"]
    R --> W["Տվյալների փոփոխություն կամ կայքի խափանում"]

Սխեման ցույց է տալիս RCE-ի հնարավոր հետևանքները։ Կոնկրետ վնասը կախված է սերվերի կարգավորումներից ու հավելվածին տրված իրավունքներից։

Սա դեռ չի նշանակում, որ հարձակվողը միանգամից ստանում է սերվերի ամբողջ կառավարումը՝ root իրավունքներ։ Սկզբում նա գործում է այն իրավունքներով, որոնք ունի կայքը սպասարկող ծրագիրը։

Բայց դա էլ կարող է բավական լինել լուրջ վնաս հասցնելու համար։ Եթե կայքը կարող է կարդալ տվյալների բազայի գաղտնաբառը, հարձակվողը ևս կարող է նույնն անել։ Եթե ծրագիրը կարող է փոխել կայքի ֆայլերը, այդ հնարավորությունն էլ կարող է անցնել հարձակվողին։ Այդ պատճառով կարևոր է, թե հավելվածին ինչ իրավունքներ են տրված։

​

Իսկ PHP-ի մեջ կոնկրետ ինչն էր սխալ

Երկու խնդիրն էլ կապված են հիշողության հետ, բայց առաջանում են տարբեր ձևերով։

Առաջինը՝ ինչ է տեղի ունենում, երբ հիշողությունը չի բավականացնում։ Հարցումը մշակելիս PHP-ն հիշողության մեջ պատրաստում է իրեն անհրաժեշտ տվյալները։ Եթե այդ աշխատանքը դեռ կիսատ է, իսկ հիշողությունն արդեն սպառվել է, PHP-ն ընդհատում է հարցման մշակումը։

Սխալը հաջորդ քայլում է․ հարցումն ավարտելիս PHP-ն կարող է օգտագործել այդ կիսատ պատրաստված տվյալները՝ կարծելով, թե դրանք նորմալ են։ Որոշ պայմաններում սա թույլ է տալիս հարձակվողին իր կոդը գործարկել։ Սա CVE-2026-109618-ն է։ Պաշտոնական բացատրությունը՝ այստեղ։

Երկրորդը՝ նախորդ հարցումից մնացած տվյալների հետքն է։ PHP-ի նույն աշխատող գործընթացը՝ worker-ը, կարող է հերթով սպասարկել բազմաթիվ հարցումներ։ Մեկ հարցումն ավարտելուց հետո դրա հիշողությունն ազատվում է։ Բայց որոշ դեպքերում PHP-ի մեջ մնում են հղումներ դեպի արդեն ազատված հիշողությունը։

Հաջորդ հարցման ժամանակ ծրագիրը կարող է օգտվել այդ հին հղումներից։ Սա կոչվում է use-after-free՝ արդեն ազատված հիշողության օգտագործում։

Պատկերացրեք՝ մարդը հյուրանոցից դուրս է եկել, սենյակն արդեն ուրիշին են տվել, բայց աշխատակիցը շարունակում է օգտվել հին գրառումից։ Գրառումը մնացել է, իսկ այն, ինչին վերաբերում էր, արդեն փոխվել է։ PHP-ի դեպքում նման սխալը լինում է հիշողության մեջ և կարող է բերել կոդի կատարման։ Սա CVE-2026-109619-ն է։ Մանրամասները՝ PHP-ի հաղորդագրությունում։

Apache-ի mod_php տարբերակի համար արդեն ցուցադրվել է հարձակում, որը կարող է սկսվել նույնիսկ մինչև կայքի սեփական կոդը գործարկվելը։ Այլ միջավայրերում հարձակման պայմանները կարող են տարբերվել։

​

Որ տարբերակներն են արդեն ուղղված

PHP-ի թիմը թողարկել է հետևյալ թարմացումները․

Եթե օգտագործում եք

Անցեք այս կամ ավելի նոր ուղղված տարբերակին

PHP 8.2

8.2.35

PHP 8.3

8.3.36

PHP 8.4

8.4.27

PHP 8.5

8.5.12

Երկու խոցելիությունն էլ ստացել է 9.2 գնահատական՝ CVSS v4.0 սանդղակով։ Սա նշանակում է, որ խնդիրը կրիտիկական է։ Թիվը նկարագրում է վտանգի աստիճանը, ոչ թե ձեր կայքը կոտրելու հավանականությունը։

Եթե PHP-ն տեղադրել եք Linux-ի Դիստրիբյուտիվի փաթեթներից, ստուգեք նաև դրա անվտանգության թարմացումները։ Օրինակ՝ Ubuntu-ն հրապարակել է ուղղված փաթեթների իր ցանկը։ Դրանց համարները կարող են տարբերվել աղյուսակում նշվածներից․ Դիստրիբյուտիվը կարող է ուղղումը ավելացնել իր օգտագործած ավելի հին տարբերակին։

PHP-ի թիմի խոսքով՝ որոշ կարգավորումներ կարող են դժվարացնել հարձակումը, բայց խնդիրը լիարժեք լուծելու համար պետք է թարմացնել PHP-ն։

​

Ինչու միայն WordPress-ը թարմացնելը չի օգնի

WordPress-ը ձեր կայքի ծրագիրն է։ PHP-ն այն գործարկող ծրագիրն է։ Դրանք տարբեր բաներ են և կարող են առանձին թարմացվել։

flowchart TD
    A["WordPress, Drupal կամ ձեր կայքը"] --> P["PHP-ն կատարում է կայքի կոդը"]
    P --> H["Սերվեր"]
    U["Կայքի թարմացում"] --> A
    V["PHP-ի առանձին թարմացում"] --> P

Պատկերացրեք՝ այսօր թարմացրել եք WordPress-ն ու բոլոր հավելումները։ Կառավարման էջում ամեն ինչ թարմ է երևում, բայց հոսթինգը դեռ հին PHP-ն է օգտագործում։ Այս դեպքում PHP-ի խնդիրը մնում է։

Միայն PHP օգտագործելու փաստը չի ասում՝ ձեր կայքի վրա կոնկրետ որ հարձակումն է հնարավոր։ Բայց այն բավարար պատճառ է տարբերակը ստուգելու և ուղղումները տեղադրելու համար։

​

Ինչպես ստուգել ձեր PHP-ն

Սկսեք պարզ հարցից՝ ո՞ր սերվերների ու կայքերի վրա եք PHP օգտագործում։ Մի մոռացեք նաև հին ենթադոմենները, ներքին գործիքներն ու փորձնական կայքերը։

Սերվերի տերմինալում կարող եք գործարկել․

php -v
php --ini

Առաջին հրամանը ցույց է տալիս PHP-ի տարբերակը։ Երկրորդը՝ դրա կարգավորումների ֆայլերը։ PHP-ի ձեռնարկում նկարագրված են երկուսն էլ։

Բայց մի կարևոր բան կա․ տերմինալում աշխատող PHP-ն և կայքը սպասարկող PHP-ն կարող են տարբեր լինել։ Նույն սերվերի վրա հնարավոր է մի քանի տարբերակ տեղադրված լինի։

Կայքի օգտագործած տարբերակը ստուգելու համար կարելի է ժամանակավոր էջ ստեղծել հետևյալ կոդով։ Էջը պետք է հասանելի լինի միայն ձեզ․

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP: ', PHP_VERSION, PHP_EOL;
echo 'SAPI: ', PHP_SAPI, PHP_EOL;

PHP_VERSION-ը ցույց կտա աշխատող PHP-ի տարբերակը։ PHP_SAPI-ն՝ դրա աշխատանքի ձևը, օրինակ՝ cli կամ fpm-fcgi։ Դրա մասին ավելի մանրամասն կարելի է կարդալ պաշտոնական ձեռնարկում։

Ստուգելուց հետո ժամանակավոր էջը հեռացրեք։

​

Ինչպես համոզվել, որ թարմացումն աշխատել է

PHP-ի նոր փաթեթը տեղադրելը դեռ աշխատանքի ավարտը չէ։ Հնարավոր է՝ հին գործընթացները շարունակում են աշխատել նախկին տարբերակով։

Գործնական քայլերն այսպիսին են․

  1. Ստուգեք՝ ձեր PHP-ի համար որ թարմացումն է նախատեսված։

  2. Տեղադրեք այն՝ հոսթինգի կամ ձեր Դիստրիբյուտիվի ցուցումներով։

  3. Վերագործարկեք կայքը սպասարկող PHP-FPM կամ Apache ծառայությունը։

  4. Նորից ստուգեք հենց կայքի օգտագործած PHP-ի տարբերակը։

  5. Փորձեք կայքի հիմնական գործողությունները՝ մուտք գործել, էջ բացել, ֆայլ վերբեռնել կամ պատվեր ձևակերպել։

Կարևորն այն է, որ կայքն արդեն աշխատի ուղղված PHP-ով։ Միայն տեղադրված փաթեթների ցանկում նոր տարբերակ տեսնելը բավարար չէ։

​

Իսկ եթե արդեն հարձակվել են

watchTowr-ը հայտնել է, որ հոկտեմբերի 21-ից հարձակման դեպքեր է տեսել իր դիտարկման ցանցում։ Այդ ցանցում հատուկ համակարգեր կան, որոնք նախատեսված են հարձակումներ որսալու և ուսումնասիրելու համար։

Եթե կասկածում եք, որ ձեր կայքի վրա հարձակվել են, ստուգեք՝

  • հայտնվե՞լ են անծանոթ ֆայլեր,

  • փոխվե՞լ է կոդը՝ առանց ձեր կատարած փոփոխության,

  • սերվերը կապվո՞ւմ է անծանոթ հասցեների հետ,

  • PHP-ն կամ վեբ սերվերը գործարկո՞ւմ է անսպասելի ծրագրեր։

Այս նշանները միայն PHP2Shell-ին չեն վերաբերում։ Դրանք ընդհանուր պատճառներ են՝ կատարվածն ավելի մանրամասն ուսումնասիրելու համար։

Թարմացումը չի վերացնում արդեն հասցված վնասը։ Եթե հարձակվողը հասցրել է վնասակար կոդ տեղադրել կամ գաղտնաբառ գողանալ, PHP-ն թարմացնելուց հետո դրանք չեն անհետանա։

Այդ դեպքում պետք է պահպանել լոգերը՝ համակարգի աշխատանքի գրանցումները, պարզել՝ ինչ է փոխվել և ինչ տվյալներ կարող էին արտահոսել։ Դրանից հետո՝ հեռացնել վնասակար կոդը կամ վերականգնել մաքուր տարբերակից, իսկ գողացված գաղտնաբառերն ու բանալիները փոխել։

​

Ինչ անել հիմա

PHP2Shell-ի ուղղումներն արդեն կան։ Հիմա ամենակարևորը պարզելն է՝ ձեր կայքը ինչ PHP-ով է աշխատում, ով է այն թարմացնում, և արդյոք թարմացումն արդեն տեղադրված է։

Եթե սրանք գիտեք, հաջորդ քայլը պարզ է՝ թարմացնել և ստուգել կայքը։ Իսկ եթե չգիտեք, սկսեք հոսթինգի մատակարարից կամ սերվերի պատասխանատուից։