PHP2Shell: Dobësi kritike të PHP – si t’i patchoni tani

21 tetor 2026 | PHP | Siguria e IT-së

Më 21 tetor 2026 ekipi i sigurisë së PHP publikoi përditësime për të gjitha versionet e PHP që mbështeten ende. Ato mbyllin dy dobësi kritike që janë bërë të njohura si PHP2Shell. BSI ka dhënë për këtë një paralajmërim dhe kërkon që sistemet e prekura të patchohen pa vonesë. Kush operon një server uebi me PHP, duhet të veprojë që sot. Kjo vlen edhe për të gjithë ata që operojnë „vetëm“ një WordPress, Nextcloud ose Joomla, sepse këto aplikacione funksionojnë mbi PHP.

Ky artikull përmbledh çfarë ka ndodhur, cilat versione të PHP janë të prekura, cilin version ju duhet tani dhe si mund të kontrolloni brenda pak minutash nëse serveri juaj është i siguruar.

Çfarë ndodhi? Rrjedha kohore

Ekipi i sigurisë së PHP e njoftoi paraprakisht publikimin e korrigjimeve, që ofruesit e hosting-ut dhe administratorët të kishin kohë të përgatiteshin. Vetë publikimi u zhvillua më 21 tetor 2026. BSI e dha paralajmërimin e vet (versioni 1.1) po atë ditë.

• 20 tetor 2026: Paralajmërim nga ekipi i sigurisë së PHP se ditën tjetër do të dalin përditësime sigurie.
• 21 tetor 2026, 14:00 UTC (16:00 sipas orës MESZ): Publikohen patch-et për PHP 8.5, 8.4, 8.3 dhe 8.2.
• 21 tetor 2026: BSI paralajmëron për „dobësitë kritike që kërcënojnë aplikacionet e uebit në mbarë botën“ dhe rekomandon të patchohet pa vonesë. Sipas të dhënave të BSI, ofrues të mëdhenj hosting-u i kanë hequr pjesërisht serverët nga rrjeti si masë paraprake.

Dy dobësitë e PHP në përmbledhje

Bëhet fjalë për dy gabime të veçanta në bërthamën e PHP: CVE-2026-109618 dhe CVE-2026-109619. Të dyja mund, sipas të dhënave të ekipit të sigurisë së PHP, të bëjnë që një sulmues të ekzekutojë kod programi në server pa u identifikuar (unauthenticated Remote Code Execution). Dobësitë vlerësohen me CVSS v4.0: 9,2 (kritike).

Sipas vlerësimit të BSI, në kohën e publikimit nuk kishte sulme të konfirmuara, por kishte shenja të pakonfirmuara tentativash shfrytëzimi. Te dobësitë kritike në një softuer kaq të përhapur, sipas përvojës duhet llogaritur që sulmuesit i analizojnë korrigjimet dhe përgatisin sulme të automatizuara. Dritarja kohore për patchim është prandaj e shkurtër.

Kush preket?

Në parim preket çdo server ku funksionon PHP, pavarësisht si lidhet PHP: PHP-FPM, mod_php në Apache, php-cgi, FrankenPHP ose LiteSpeed. Rreziku është më i lartë sipas ekipit të sigurisë së PHP te Apache me mod_php.

BSI përmend shprehimisht aplikacione që ndërtohen mbi PHP dhe prandaj mund të preken bashkë:

• Sisteme menaxhimi përmbajtjeje: WordPress, Drupal, TYPO3, Joomla
• Sisteme dyqanesh: Magento
• Ruajtje në re dhe skedarësh: Nextcloud
• Ndërfaqe firewall-i: pfSense, OPNsense

Aplikacioni vetë nuk duhet të jetë i gabuar për këtë. Dobësia ndodhet në PHP, prandaj një përditësim i WordPress, Nextcloud & të tjerëve vetëm nuk ndihmon. Duhet përditësuar versioni i PHP në server. Te firewall-et si pfSense dhe OPNsense, versioni i korrigjuar i PHP vjen me përditësimin përkatës të firmware-it nga prodhuesi.

Këto versione të PHP janë të sigurta

Dobësitë janë korrigjuar në versionet në vijim. Çdo gjë poshtë tyre konsiderohet e cenueshme.

Si ta kontrolloni dhe përditësoni serverin tuaj

1. Përcaktimi i versionit të instaluar të PHP

Në vijën e komandës të serverit, php -v tregon versionin e PHP-së së vijës së komandës. Serveri i uebit mund të përdorë një version tjetër të PHP. Kontrolloni prandaj edhe versionin e PHP-FPM përkatësisht të modulit Apache, për shembull me php-fpm8.3 -v ose nëpërmjet një faqeje që jep phpinfo() (pastaj hiqeni menjëherë).

2. Vendosja e përditësimit nëpërmjet menaxhimit të paketave

Te Debian, Ubuntu, RHEL dhe të ngjashmit, versioni i korrigjuar vjen nëpërmjet menaxhimit normal të paketave, për shembull apt update && apt upgrade ose dnf upgrade. Te burimet e jashtme si Sury-PPA ose Remi-Repository paketat e reja shfaqen zakonisht shpejt.

3. Rinisja e shërbimit PHP

Një përditësim paketash vetëm nuk mjafton: proceset PHP që po funksionojnë e mbajnë kodin e vjetër në kujtesë. Rinisni PHP-FPM (systemctl restart php8.3-fpm) përkatësisht Apache (systemctl restart apache2), dhe kontrolloni pastaj nëse proceset u nisën pas përditësimit.

4. Faqe të hostuara

Te shared hosting përditëson zakonisht ofruesi. Në menunë e klientit zakonisht mund të vendoset versioni i PHP për çdo faqe. Zgjidhni atje një nga versionet e sigurta të përmendura më sipër, ose pyesni ofruesin për gjendjen e patch-eve. Sipas të dhënave të BSI, disa ofrues i kanë hequr serverët nga rrjeti si masë paraprake. Nëse faqja juaj nuk arrihet për pak kohë, kjo mund të jetë shkaku.

PHP 8.1 dhe më të vjetër: pa përditësim zyrtar

Për PHP 8.1 dhe më të vjetër nuk ka më përditësime zyrtare sigurie. Operatorët e sistemeve të tilla kanë dy mundësi:

• Kalim në një version të mbështetur (e rekomanduar). Sa më i vjetër versioni, aq më i madh është përpjekja e përshtatjes për aplikacionin dhe zgjerimet, prandaj kalimi duhet testuar paraprakisht.
• Portimi mbrapsht i korrigjimeve. Ekipi i sigurisë së PHP i ka vënë korrigjimet në dispozicion në degë zhvillimi në GitHub. Kush e kompilon vetë PHP, mund t’i marrë këto ndryshime në versione më të vjetra. Ky është një zgjidhje kalimtare dhe kërkon njohuri të specializuara.

Edhe PHP 8.2 mbështetet vetëm deri më 31 dhjetor 2026. Planifikoni prandaj kalimin në PHP 8.4 ose 8.5 tani, dhe mos e shtyni për kthesën e vitit.

Masa kalimtare dhe pyetja „Të hiqet serveri nga rrjeti?“

Ekipi i sigurisë së PHP ka përshkruar me njoftimin edhe masa mbrojtëse të përkohshme. Këto e zvogëlojnë rrezikun, por nuk i mbyllin plotësisht dobësitë. Ato nuk e zëvendësojnë përditësimin dhe janë menduar vetëm për ta mbuluar kohën deri te përditësimi.

Nëse një server duhet të hiqet nga rrjeti deri te përditësimi, varet nga rëndësia dhe arritshmëria e tij. BSI shpjegon se ofruesit e mëdhenj e kanë ndërmarrë këtë hap. Si rregull themelor vlen:

• Server i arritshëm publikisht, përditësimi i mundshëm tani: patchoni menjëherë, nuk nevojitet fikja.
• Server i arritshëm publikisht, përditësimi nuk është i mundshëm shpejt: kufizoni qasjen (për shembull me firewall vetëm për adresa të njohura) ose çaktivizoni përkohësisht shërbimin, veçanërisht te mod_php.
• Server i arritshëm vetëm brenda: patchoni sa më shpejt, urgjenca është më e vogël.

Pyetje të shpeshta

A duhet të përditësoj WordPress, Joomla ose Nextcloud?

Jo për shkak të kësaj cenueshmërie. Ajo ndodhet te PHP, jo te aplikacioni. Përditësoni versionin e PHP në server. Një përditësim i aplikacionit është megjithatë i arsyeshëm, i pavarur nga kjo.

Si mund ta kuptoj nëse dikush e ka shfrytëzuar tashmë cenueshmërinë?

Një përgjigje e sigurt është e vështirë. Dyshime ngjall prania e skedarëve PHP të panjohur në dosjen e uebit, procese të pazakonta nën përdoruesin e serverit të uebit, llogari të reja përdoruesish ose cronjobs dhe trafik dalës i pazakontë. Në rast dyshimi konkret, sistemi duhet të kontrollohet në mënyrë forenzike dhe, në rast dyshimi, të ngrihet nga e para.

A mjafton një Web Application Firewall?

Një firewall mund të ndalojë modele sulmesh të njohura, por nuk e zëvendëson përditësimin. Më shumë për bashkëveprimin e shtresave të shumta mbrojtëse mund të lexoni në shkrimin tonë Sigurimi i Odoo 19: Firewall, 2FA & Web RBL. Parimet vlejnë për çdo aplikacion uebi.

A preket Odoo?

Jo. Odoo është shkruar në Python dhe nuk punon mbi PHP. Do të preheshin vetëm aplikacionet PHP që punojnë në të njëjtin server.

Ku i gjej informacionet zyrtare?

Njoftimin e ekipit të sigurisë së PHP e gjeni te arkivat e lajmeve në php.net (shënimi i 20 tetorit 2026), versionet te php.net/downloads. Paralajmërimi i BSI mban numrin 2026-297981-1032 dhe është publikuar te bsi.bund.de .

Mbështetje nga Biricon IT Services

Nëse nuk jeni të sigurt se cila version PHP punon në serverin tuaj ose ju duhet ndihmë me përditësimin, na vjen mirë t'ju mbështesim: me inventarizimin e të gjitha sistemeve PHP, me instalimin e përditësimeve, me kalimin te një version PHP i mbështetur dhe me kontrollin për kompromentim. Si ofrues shërbimesh IT, ne mirëmbajmë serverë, firewalls dhe aplikacione uebi për ndërmarrje të vogla dhe të mesme.

Na kontaktoni tani

Gjendja: 21 tetor 2026. Situata mund të ndryshojë shpejt; vendimtare janë publikimet e ekipit të sigurisë së PHP dhe të BSI.