21 հոկտեմբերի 2026 | PHP | ՏՏ անվտանգություն
2026 թվականի հոկտեմբերի 21-ին PHP անվտանգության թիմը հրապարակեց թարմացումներ բոլոր դեռ աջակցվող PHP տարբերակների համար։ Դրանք փակում են երկու կրիտիկական խոցելիություն, որոնք հայտնի են դարձել որպես PHP2Shell։ BSI-ն այս կապակցությամբ զգուշացում է հրապարակել և պահանջում է ազդված համակարգերը անհապաղ թարմացնել։ Ով PHP-ով վեբ սերվեր է շահագործում, պետք է գործի այսօր։ Դա վերաբերում է նաև բոլոր նրանց, ովքեր «միայն» WordPress, Nextcloud կամ Joomla են շահագործում, քանի որ այս հավելվածները աշխատում են PHP-ի վրա։
Այս հոդվածը ամփոփում է, թե ինչ է պատահել, որ PHP տարբերակներն են ազդված, որ տարբերակն է ձեզ հիմա պետք և ինչպես մի քանի րոպեում ստուգել՝ արդյոք ձեր սերվերը պաշտպանված է։
Այս հոդվածի բովանդակությունը
- Ի՞նչ է պատահել։ Ժամանակագրությունը
- PHP-ի երկու խոցելիությունները՝ ակնարկ
- Ո՞վ է ազդված
- Այս PHP տարբերակները անվտանգ են
- Ինչպես ստուգել և թարմացնել ձեր սերվերը
- PHP 8.1 և ավելի հին. պաշտոնական թարմացում չկա
- Անցումային միջոցառումներ և «Սերվերն անջատե՞լ ցանցից» հարցը
- Հաճախ տրվող հարցեր
- Biricon IT Services-ի աջակցությունը
Ի՞նչ է պատահել։ Ժամանակագրությունը
PHP անվտանգության թիմը կանխավ հայտարարել է շտկումների հրապարակման մասին, որպեսզի հոսթինգ մատակարարներն ու ադմինիստրատորները ժամանակ ունենային նախապատրաստվելու համար։ Հրապարակումն ինքնին տեղի ունեցավ 2026 թվականի հոկտեմբերի 21-ին։ BSI-ն նույն օրը հրապարակեց իր զգուշացումը (տարբերակ 1.1)։
- 2026 թվականի հոկտեմբերի 20. PHP անվտանգության թիմի կանխազգուշացում, որ հաջորդ օրը կհրապարակվեն անվտանգության թարմացումներ։
- 2026 թվականի հոկտեմբերի 21, 14:00 UTC (16:00 MESZ). Հրապարակվում են շտկումները 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 (կրիտիկական)։
| Հատկանիշ | Նշանակություն |
|---|---|
| Նույնացուցիչներ | CVE-2026-109618 և CVE-2026-109619 |
| Գնահատական | CVSS v4.0. 9,2 — կրիտիկական |
| Ազդեցություն | Կոդի կատարում սերվերի վրա (Remote Code Execution)՝ առանց մուտքի |
| Պատճառ 1 | Վնասված հիշողություն, երբ PHP-ն մշակման ընթացքում այլևս օպերատիվ հիշողություն չի ստանում (Out-of-Memory) |
| Պատճառ 2 | Հնացած գլոբալ վիճակ, որը հարցումների միջև մնում է հիշողության մեջ |
| Հատկապես վտանգված | Apache՝ mod_php-ով |
BSI-ի գնահատմամբ՝ հրապարակման պահին հաստատված հարձակումներ չկային, սակայն կային չհաստատված ցուցումներ շահագործման փորձերի մասին։ Այսքան լայն տարածված ծրագրակազմի կրիտիկական խոցելիությունների դեպքում, ըստ փորձի, պետք է հաշվի առնել, որ հարձակվողները կվերլուծեն շտկումները և կպատրաստեն ավտոմատացված հարձակումներ։ Ուստի թարմացման ժամանակային պատուհանը կարճ է։
Ո՞վ է ազդված
Սկզբունքորեն ազդված է PHP աշխատող յուրաքանչյուր սերվեր՝ անկախ այն բանից, թե ինչպես է PHP-ն միացված. PHP-FPM, mod_php Apache-ում, php-cgi, FrankenPHP կամ LiteSpeed։ Ըստ PHP անվտանգության թիմի՝ ռիսկը ամենաբարձրն է Apache-ի՝ mod_php-ով դեպքում։
BSI-ն հստակորեն նշում է PHP-ի վրա կառուցված հավելվածները, որոնք այդ պատճառով կարող են նույնպես ազդված լինել.
- Բովանդակության կառավարման համակարգեր. WordPress, Drupal, TYPO3, Joomla
- Առցանց խանութի համակարգեր. Magento
- Ամպային և ֆայլային պահոց. Nextcloud
- Firewall-ի միջերեսներ. pfSense, OPNsense
Դրա համար հավելվածն ինքը պարտադիր չէ սխալ լինի։ Խոցելիությունը PHP-ում է, ուստի WordPress-ի, Nextcloud-ի & Co. թարմացումը միայնակ չի օգնում։ Պետք է թարմացնել սերվերի PHP տարբերակը։ pfSense-ի և OPNsense-ի նման firewall-ների դեպքում շտկված PHP տարբերակը գալիս է արտադրողի համապատասխան firmware թարմացմամբ։
Այս PHP տարբերակները անվտանգ են
Խոցելիությունները շտկված են հետևյալ տարբերակներում։ Դրանցից ցածրը համարվում է խոցելի։
| PHP ճյուղ | Նվազագույն պահանջվող | Նշում |
|---|---|---|
| PHP 8.5 | 8.5.12 | ընթացիկ ճյուղ |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Աջակցությունն ավարտվում է 2026 թվականի դեկտեմբերի 31-ին |
| PHP 8.1 և ավելի հին | պաշտոնական թարմացում չկա, տե՛ս ներքև | |
Ինչպես ստուգել և թարմացնել ձեր սերվերը
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-ն, նոր փաթեթները սովորաբար հայտնվում են շուտով։
apt changelog php8.3-fpm կամ rpm -q --changelog php | grep CVE-2026-1096-ով)։
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-ի և ավելի հինի համար պաշտոնական անվտանգության թարմացումներ այլևս չկան։ Նման համակարգերի շահագործողներն ունեն երկու հնարավորություն.
- Անցնել աջակցվող տարբերակի (խորհուրդ է տրվում)։ Որքան հին է տարբերակը, այնքան մեծ է հավելվածի և ընդլայնումների հարմարեցման ծավալը, ուստի անցումը պետք է նախապես փորձարկել։
- Շտկումները հետ տեղափոխել (backport): PHP անվտանգության թիմը շտկումները տրամադրել է GitHub-ի մշակման ճյուղերում։ Ով PHP-ն ինքն է կոմպիլյացնում, կարող է այդ փոփոխությունները տեղափոխել ավելի հին տարբերակների մեջ։ Սա անցումային լուծում է և պահանջում է մասնագիտական գիտելիք։
PHP 8.2-ն էլ աջակցվում է միայն մինչև 2026 թվականի դեկտեմբերի 31-ը։ Ուստի պլանավորեք անցումը PHP 8.4-ի կամ 8.5-ի հիմա, և այն չհետաձգեք տարեվերջի։
Անցումային միջոցառումներ և «Սերվերն անջատե՞լ ցանցից» հարցը
PHP անվտանգության թիմը հայտարարության հետ նաև նկարագրել է ժամանակավոր պաշտպանական միջոցառումներ։ Դրանք նվազեցնում են ռիսկը, սակայն խոցելիությունները լիովին չեն փակում։ Դրանք չեն փոխարինում թարմացմանը և նախատեսված են միայն թարմացման պահը կամրջելու համար։
Արդյոք սերվերը մինչև թարմացումը պետք է անջատել ցանցից, կախված է դրա կարևորությունից և հասանելիությունից։ BSI-ն նշում է, որ խոշոր մատակարարները այդ քայլին գնացել են։ Որպես մատչելի կանոն.
- Հանրությանը հասանելի սերվեր, թարմացումն այժմ հնարավոր է. անհապաղ թարմացնել, անջատումն անհրաժեշտ չէ։
- Հանրությանը հասանելի սերվեր, թարմացումը կարճ ժամկետում հնարավոր չէ. սահմանափակել հասանելիությունը (օրինակ՝ firewall-ով միայն հայտնի հասցեների համար) կամ ծառայությունը ժամանակավորապես անջատել, հատկապես
mod_php-ի դեպքում։ - Միայն ներսից հասանելի սերվեր. թարմացնել շուտով, հրատապությունը ավելի ցածր է։
Հաճախ տրվող հարցեր
Արդյո՞ք պետք է թարմացնեմ WordPress-ը, Joomla-ն կամ Nextcloud-ը։
Ոչ այս խոցելիության պատճառով։ Այն PHP-ի մեջ է, այլ ոչ թե հավելվածի։ Թարմացրեք սերվերի PHP տարբերակը։ Հավելվածի թարմացումը, այնուամենայնիվ, նպատակահարմար է անկախ դրանից։
Ինչպե՞ս իմանալ՝ արդյոք որևէ մեկն արդեն օգտագործել է այս խոցելիությունը։
Հաստատ պնդում անելը դժվար է։ Կասկածելի են վեբ-գրացուցակում անծանոթ PHP ֆայլերը, վեբ-սերվերի օգտատիրոջ անունից աշխատող անսովոր պրոցեսները, նոր օգտատերերի հաշիվները կամ cron առաջադրանքները, ինչպես նաև անսովոր ելքային տվյալների հոսքը։ Կոնկրետ կասկածի դեպքում համակարգը պետք է ենթարկել դատաբժշկական (ֆորենզիկ) ստուգման, իսկ կասկածի դեպքում՝ նորից տեղադրել։
Բավարա՞ր է Web Application Firewall-ը։
Firewall-ը կարող է կասեցնել հայտնի հարձակման ձևերը, սակայն չի փոխարինում թարմացմանը։ Պաշտպանության մի քանի շերտերի փոխազդեցության մասին ավելին կարդացեք մեր հոդվածում՝ Odoo 19-ի պաշտպանություն՝ firewall, 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 տարբերակն է աշխատում ձեր սերվերի վրա, կամ օգնություն է պետք patch-երի տեղադրման հարցում, ուրախությամբ կօգնենք՝ բոլոր PHP համակարգերի գույքագրման, թարմացումների տեղադրման, աջակցվող PHP տարբերակին անցնելու և կոմպրոմետացիայի ստուգման հարցերում։ Որպես IT ծառայություններ մատուցող ընկերություն՝ մենք սպասարկում ենք փոքր և միջին ձեռնարկությունների սերվերները, firewall-ները և վեբ-հավելվածները։
Վիճակը՝ 2026 թվականի հոկտեմբերի 21։ Իրավիճակը կարող է կարճ ժամկետում փոխվել․ վճռորոշ են PHP անվտանգության թիմի և BSI-ի հրապարակումները։