PHP2ShellMAGYAR TÁJÉKOZTATÓ
Mit tegyek?
KRITIKUS SÉRÜLÉKENYSÉGEK2026. OKTÓBER 21.

PHP2SHELL, ÉRTHETŐEN.

Két kritikus hiba.
Egy sürgős teendő.

A PHP2Shell hibái lehetővé tehetik, hogy egy támadó bejelentkezés nélkül kódot futtasson a webszerveren. A biztonsági frissítések már elérhetők.

Mutasd a teendőket Érintett a weboldalam?

Weboldal-tulajdonosoknak és üzemeltetőknek. Elsődleges források alapján.

php / security update

$ php --version

Frissítés szükségesAz első javított kiadások
PHP 8.28.2.35 ↗
PHP 8.38.3.36 ↗
PHP 8.48.4.27 ↗
PHP 8.58.5.12 ↗

A JAVÍTÁS ELÉRHETŐ

CVSS v4.09.2/10KRITIKUS
MI A KOCKÁZAT?Távoli kódfuttatás ↗
HOL VAN A HIBA?A PHP futtatókörnyezetében
MI A MEGOLDÁS?Javított PHP telepítése

A javítás már megjelent. A 2026. október 21-i kiadások megszüntetik a két hibát. A teljes védelemhez frissítés szükséges.

Javított verziók
01 / A PROBLÉMA

Mi az a PHP2Shell?

Két kritikus hiba a weboldalakat kiszolgáló PHP-ban.
A kockázat a weboldal alkalmazáskódja alatt jelentkezik.

Bejelentkezés nélkül is támadható.

A PHP2Shell két, memóriakezeléshez kapcsolódó PHP-sérülékenység közös elnevezése. Sikeres kihasználásukkal a támadó a PHP-folyamat jogosultságaival futtathat kódot. A Wiz kutatói érzékeny folyamatmemória kiolvasását is bemutatták; így például tokenek és API-kulcsok is veszélybe kerülhetnek. [8]

A tényleges kihasználhatóság a futtatási módtól és a konfigurációtól is függ. A PHP csapata az Apache mod_php használatánál jelzi a legnagyobb kockázatot; a PHP-FPM használata sem indokolja a frissítés elhagyását. [1]

01 · MEMÓRIAKIMERÜLÉSKRITIKUS

CVE-2026-109618

Memóriahiány esetén a kérés feldolgozása hibás belső állapotot hagyhat maga után. A kérés lezárásakor ez kódfuttatáshoz vezethet. [2]

02 · ELAVULT BELSŐ ÁLLAPOTKRITIKUS

CVE-2026-109619

Egy feldolgozófolyamat már felszabadított memóriára hivatkozhat egy későbbi kérésnél. A hibás hozzáférés szintén kódfuttatást tehet lehetővé. [3]

02 / ÉRINTETTSÉG

Ha PHP-t használ a weboldalad,
ellenőrizd a verzióját.

WordPress, Drupal, Joomla vagy egyedi PHP-alkalmazás: a futtatókörnyezet javítottsága számít. Az alkalmazás frissítése önmagában nem javítja a PHP-t.

CMS és webáruházA kiszolgáló PHP-ját is frissíteni kell.

Egyedi alkalmazásA saját kód sem zárja ki az érintettséget.

Tárhely és saját szerverA javítást a szolgáltató vagy az üzemeltető telepíti.

Érintett és javított verziók

UPSTREAM PHP · 2026. 10. 21.
A PHP2Shell javítását elsőként tartalmazó támogatott PHP-kiadások
PHP-ágJavítás előtti verziókElső javított kiadásTeendő
PHP 8.58.5.0 – 8.5.11✓ 8.5.12Frissítés a javított kiadásra
PHP 8.48.4.0 – 8.4.26✓ 8.4.27Frissítés a javított kiadásra
PHP 8.38.3.0 – 8.3.35✓ 8.3.36Frissítés a javított kiadásra
PHP 8.28.2.0 – 8.2.34✓ 8.2.35Frissítés a javított kiadásra
PHP 8.1 és régebbiNem támogatott upstream ágakSzolgáltatói javítás ellenőrzéseFrissítés támogatott ágra, vagy igazolt LTS-javítás

Az első javított kiadások a PHP hivatalos közleménye alapján. [1]

Hol találod a PHP-verziót?

WordPress Eszközök → Webhely-egészség → Információ → Szerver → PHP-verzió. [5]

cPanel MultiPHP Manager: nézd meg az adott domainhez kiválasztott ágat, majd kérd el a szolgáltatótól a teljes csomagverziót és a javítás igazolását. Az ea-php83 név önmagában csak az ágat azonosítja. [6]

Saját szerver A php -v a parancssori PHP-t mutatja. Ellenőrizd külön a webes futtatókörnyezetet és az összes FPM-poolt, konténert, illetve kiszolgálót is.

03 / MEGOLDÁS

A következő lépés: frissítés.

Válaszd ki, melyik szerep illik rád, és haladj végig a teendőkön.

  1. 01

    Ellenőrizd, melyik PHP fut az oldalad alatt.

    A teljes verziószámot keresd; a „PHP 8.3” vagy „PHP 8.4” felirat nem elég a javítás megállapításához.

  2. 02

    Kérd a tárhelyszolgáltató megerősítését.

    Kérdezz rá mindkét CVE-re, a telepített javításra és a PHP-folyamatok újraindítására. Ha nincs javított kiadás a panelen, a szolgáltatónak kell intézkednie.

  3. 03

    Frissíts, és ellenőrizd a működést.

    Legyen friss biztonsági mentésed. Teszteld a bejelentkezést, űrlapokat és vásárlást; PHP-ág váltásakor a bővítmények kompatibilitását is. [5]

  4. 04

    Rögzítsd a javítás eredményét.

    Jegyezd fel a verziót és a frissítés idejét. Gyanús fájl, ismeretlen adminisztrátor vagy rendellenes működés esetén kezdeményezz külön incidensvizsgálatot.

GYORS SEGÍTSÉG

Ezt kérdezheted a tárhelyszolgáltatótól

Kérem, erősítsék meg, hogy a weboldalamat kiszolgáló PHP-csomag tartalmazza a PHP2Shell (CVE-2026-109618 és CVE-2026-109619) javításait. Kérem a teljes csomagverziót, a kapcsolódó gyártói közleményt, valamint a javítás telepítésének és az érintett PHP-folyamatok újraindításának visszaigazolását.

Mi legyen, ha még nem tudok frissíteni?

Az átmeneti beállítások csak egyes támadási utakat korlátoznak. A PHP szerint nincs teljes értékű kerülőmegoldás. Ha nem biztosítható a javítás, mérlegeld az érintett szolgáltatás hozzáférésének ideiglenes korlátozását. [1]

A hivatalos közlemény többek között az session.upload_progress.enabled=0 beállítást és az összes worker újraindítását említi. PHP 8.5 esetén a fatal_error_backtraces=0 is csökkenthet egy ismert támadási útvonalat. Ezek nem fednek le minden változatot. [3]

A memory_limit=-1 egy ismert útvonal kockázatát csökkentheti, de nem teljes javítás, és korlátlan PHP-memóriahasználatot enged. Csak megfelelő külső erőforráskorláttal és a hivatalos útmutató szerint mérlegelhető; ne állítsd át általános receptként. [2]

A teljes hivatalos útmutató
04 / LINUX ÚTMUTATÓK

Javítás, lépésről lépésre.

Három gyakori szerverkörnyezethez: Ubuntu Server 24.04 LTS, Debian 13 és RHEL 9. Válaszd ki a rendszeredet, majd haladj a leltártól a webes záróellenőrzésig.

KEZDÉS ELŐTT

Mentés. Helyes csomagforrás. Karbantartási ablak.

Legyen visszaállítható adatbázis-, alkalmazás- és konfigurációmentésed, valamint működő adminisztrátori hozzáférésed. Több kiszolgálót egyenként kezelj. A csomagok telepítése és a folyamatok újraindítása rövid kiesést okozhat.

A parancsok a szerveren, Bash alatt futtatandó minták, sudo-jogosultsággal. Rootként a sudo elhagyható. Nem távoli ellenőrzőszolgáltatás: az oldal nem csatlakozik a szerveredhez.

Ubuntu Server 24.04 LTSGyártói tároló · PHP 8.3 · USN-8948-15 lépés
01

Azonosítsd a rendszert és az összes PHP-ágat.

A példák Bash-munkamenethez készültek. A php -v csak a CLI-t mutatja; ha nincs CLI telepítve, az önmagában nem hiba. A leltárban minden webes PHP-példányt, tárolót és visszatartott csomagot azonosíts.

Ubuntu Server 24.04 LTS · leltár
cat /etc/os-release
php -v
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n'   'php[0-9]*' 'libapache2-mod-php[0-9]*' 2>/dev/null
apt-mark showhold
systemctl list-units --type=service --all   'php*-fpm.service' 'apache2.service' 'nginx.service'
02

Frissítsd a csomagindexet, és nézd meg a tervezett módosítást.

A következő blokk csak a telepített PHP 8.3 csomagokat gyűjti össze, majd próbafuttatást végez. Az apt-cache policy kimenetében ellenőrizd az Installed/Candidate verziót és a csomag forrását. Hibás indexletöltés, hiányzó javítás vagy függőségi hiba esetén előbb azt rendezd. [14]

Ubuntu Server 24.04 LTS · tároló és próbafuttatás
php83_packages=()
if sudo apt-get update --error-on=any; then
  mapfile -t php83_packages < <(
    dpkg-query -W -f='${binary:Package} ${db:Status-Status}\n' \
      'php8.3*' 'libapache2-mod-php8.3*' 2>/dev/null |
      awk '$2 == "installed" {print $1}'
  )
  if ((${#php83_packages[@]})); then
    apt-cache policy "${php83_packages[@]}"
    sudo apt-get --simulate install --only-upgrade --no-remove "${php83_packages[@]}"
  else
    printf 'Nem találtam telepített PHP 8.3 csomagot. Ellenőrizd a PHP forrását.\n'
  fi
fi
03

Telepítsd a javítást.

Ugyanabban a Bash-munkamenetben, az elfogadható próbafuttatás után futtasd. A parancs jóváhagyást kér, és nem végez PHP-ágváltást. A csomagkezelő már a telepítés során is újraindíthat szolgáltatásokat.

Ubuntu Server 24.04 LTS · telepítés
if ((${#php83_packages[@]})); then
  sudo apt-get install --only-upgrade --no-remove "${php83_packages[@]}"
else
  printf 'Előbb végezd el a csomaglista és a tárolók ellenőrzését.\n'
fi
04

Indítsd újra a tényleges PHP-futtatókörnyezetet.

Csak a használt kiszolgálási módhoz tartozó blokkot válaszd. PHP-FPM esetén az FPM-et indítsd újra; Apache mod_php esetén az Apache-ot. Több PHP-ág és pool esetén mindegyiket kezeld. Az Nginx újraindítása önmagában nem cseréli le az FPM-folyamatokat.

Ubuntu Server 24.04 LTS · PHP-FPM újraindítás
sudo php-fpm8.3 -t &&
sudo systemctl restart php8.3-fpm &&
systemctl is-active php8.3-fpm
sudo systemctl show php8.3-fpm -p MainPID -p ActiveEnterTimestamp
sudo journalctl -u php8.3-fpm --since '-15 min' --no-pager
Ubuntu Server 24.04 LTS · Apache mod_php újraindítás
sudo apache2ctl configtest &&
sudo systemctl restart apache2 &&
systemctl is-active apache2
sudo journalctl -u apache2 --since '-15 min' --no-pager
05

Igazold a csomagverziót és a webes működést.

A kiadás gyártói csomagjainál az első javított verzió 8.3.6-0ubuntu0.24.04.13. A küszöbvizsgálat csak a megfelelő kiadáshoz és csomagforráshoz érvényes; nem teljes sérülékenységvizsgálat. Minden érintett bináris csomag legyen javított, majd végezd el az alábbi webes záróellenőrzést. [10]

Ubuntu Server 24.04 LTS · telepített verzió ellenőrzése
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' \
  'php8.3*' 'libapache2-mod-php8.3*' 2>/dev/null
apt-cache policy php8.3-common
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-common)" \
  ge '8.3.6-0ubuntu0.24.04.13' &&
  printf 'A csomagverzió eléri a megadott küszöböt; a csomageredetet és a webes futtatókörnyezetet még ellenőrizni kell.\n'
Debian 13 (trixie)Gyártói security tároló · PHP 8.4 · DSA-6574-15 lépés
01

Azonosítsd a rendszert és az összes PHP-ágat.

A példák Bash-munkamenethez készültek. A php -v csak a CLI-t mutatja; ha nincs CLI telepítve, az önmagában nem hiba. A leltárban minden webes PHP-példányt, tárolót és visszatartott csomagot azonosíts.

Debian 13 (trixie) · leltár
cat /etc/os-release
php -v
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n'   'php[0-9]*' 'libapache2-mod-php[0-9]*' 2>/dev/null
apt-mark showhold
systemctl list-units --type=service --all   'php*-fpm.service' 'apache2.service' 'nginx.service'
02

Frissítsd a csomagindexet, és nézd meg a tervezett módosítást.

A következő blokk csak a telepített PHP 8.4 csomagokat gyűjti össze, majd próbafuttatást végez. Az apt-cache policy kimenetében ellenőrizd az Installed/Candidate verziót és a csomag forrását. Hibás indexletöltés, hiányzó javítás vagy függőségi hiba esetén előbb azt rendezd. [14]

Debian 13 (trixie) · tároló és próbafuttatás
php84_packages=()
if sudo apt-get update --error-on=any; then
  mapfile -t php84_packages < <(
    dpkg-query -W -f='${binary:Package} ${db:Status-Status}\n' \
      'php8.4*' 'libapache2-mod-php8.4*' 2>/dev/null |
      awk '$2 == "installed" {print $1}'
  )
  if ((${#php84_packages[@]})); then
    apt-cache policy "${php84_packages[@]}"
    sudo apt-get --simulate install --only-upgrade --no-remove "${php84_packages[@]}"
  else
    printf 'Nem találtam telepített PHP 8.4 csomagot. Ellenőrizd a PHP forrását.\n'
  fi
fi
03

Telepítsd a javítást.

Ugyanabban a Bash-munkamenetben, az elfogadható próbafuttatás után futtasd. A parancs jóváhagyást kér, és nem végez PHP-ágváltást. A csomagkezelő már a telepítés során is újraindíthat szolgáltatásokat.

Debian 13 (trixie) · telepítés
if ((${#php84_packages[@]})); then
  sudo apt-get install --only-upgrade --no-remove "${php84_packages[@]}"
else
  printf 'Előbb végezd el a csomaglista és a tárolók ellenőrzését.\n'
fi
04

Indítsd újra a tényleges PHP-futtatókörnyezetet.

Csak a használt kiszolgálási módhoz tartozó blokkot válaszd. PHP-FPM esetén az FPM-et indítsd újra; Apache mod_php esetén az Apache-ot. Több PHP-ág és pool esetén mindegyiket kezeld. Az Nginx újraindítása önmagában nem cseréli le az FPM-folyamatokat.

Debian 13 (trixie) · PHP-FPM újraindítás
sudo php-fpm8.4 -t &&
sudo systemctl restart php8.4-fpm &&
systemctl is-active php8.4-fpm
sudo systemctl show php8.4-fpm -p MainPID -p ActiveEnterTimestamp
sudo journalctl -u php8.4-fpm --since '-15 min' --no-pager
Debian 13 (trixie) · Apache mod_php újraindítás
sudo apache2ctl configtest &&
sudo systemctl restart apache2 &&
systemctl is-active apache2
sudo journalctl -u apache2 --since '-15 min' --no-pager
05

Igazold a csomagverziót és a webes működést.

A kiadás gyártói csomagjainál az első javított verzió 8.4.27-1~deb13u1. A küszöbvizsgálat csak a megfelelő kiadáshoz és csomagforráshoz érvényes; nem teljes sérülékenységvizsgálat. Minden érintett bináris csomag legyen javított, majd végezd el az alábbi webes záróellenőrzést. [11][12]

Debian 13 (trixie) · telepített verzió ellenőrzése
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' \
  'php8.4*' 'libapache2-mod-php8.4*' 2>/dev/null
apt-cache policy php8.4-common
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.4-common)" \
  ge '8.4.27-1~deb13u1' &&
  printf 'A csomagverzió eléri a megadott küszöböt; a csomageredetet és a webes futtatókörnyezetet még ellenőrizni kell.\n'
Red Hat Enterprise Linux 9DNF / AppStream · streamenként eltérő csomagverziók5 lépés
01

Azonosítsd a kiadást, a PHP-streamet és a tárolókat.

RHEL 9-en a PHP több AppStream-változatból érkezhet. Az aktuális streamhez és a használt RHEL/EUS kiadáshoz tartozó javítást keresd.

RHEL 9 · leltár
cat /etc/os-release
php -v
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}.%{ARCH}\n' 'php*'
sudo dnf repolist --enabled
sudo dnf module list php --enabled
systemctl list-units --type=service --all   'php*-fpm.service' 'httpd.service' 'nginx.service'
02

Keresd meg mindkét CVE javítását.

A két lekérdezést külön értékeld. Az üres kimenet nem bizonyítja a védettséget: hiányzó vagy elavult tárolómetaadat is okozhatja. A gyártói errata csomaglistáját is hasonlítsd a telepített csomagokhoz. [13][15]

RHEL 9 · errata és próbafuttatás
sudo dnf --refresh updateinfo info --all --cve=CVE-2026-109618
sudo dnf --refresh updateinfo info --all --cve=CVE-2026-109619
sudo dnf upgrade --refresh --assumeno 'php' 'php-*'
03

Frissítsd a telepített PHP-csomagokat.

Ellenőrzött tranzakció után telepíts. Ne válts streamet pusztán a verziószám növeléséért, és ne kerüld meg az aláírás-ellenőrzést vagy a függőségi hibákat.

RHEL 9 · telepítés
sudo dnf upgrade --refresh 'php' 'php-*'
04

Ellenőrizd a konfigurációt, majd indítsd újra az érintett szolgáltatást.

Csak a használt mód blokkja szükséges. A szokásos PHP-FPM szolgáltatás neve php-fpm. Egyedi vagy párhuzamos telepítésnél a leltárban talált szolgáltatásnevet és binárist használd.

RHEL 9 · PHP-FPM újraindítás
sudo php-fpm -t &&
sudo systemctl restart php-fpm &&
systemctl is-active php-fpm
sudo systemctl show php-fpm -p MainPID -p ActiveEnterTimestamp
sudo journalctl -u php-fpm --since '-15 min' --no-pager
RHEL 9 · Apache mod_php újraindítás
sudo httpd -t &&
sudo systemctl restart httpd &&
systemctl is-active httpd
sudo journalctl -u httpd --since '-15 min' --no-pager
05

Ellenőrizd a teljes RPM-verziót és az alkalmazott erratákat.

Az RHSA-2026:87151 egyik javított csomagja a php-common-8.0.30-8.el9_8.1. Ez nem univerzális küszöb minden RHEL 9-streamre: a saját ágad erratájának teljes verzióját, kiadását és architektúráját használd. Az --installed lekérdezés a metaadatok alapján segít igazolni a javítást; a teljes csomaglista és a webes ellenőrzés is szükséges. [13][15]

RHEL 9 · telepített javítás ellenőrzése
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}.%{ARCH}\n' 'php*'
sudo dnf updateinfo list --installed --cve=CVE-2026-109618
sudo dnf updateinfo list --installed --cve=CVE-2026-109619
MINDHÁROM RENDSZEREN

Mikor tekinthető igazoltnak a javítás?

  1. Csomag: minden használt PHP-ág tartalmazza mindkét CVE gyártói javítását. A teljes csomagverziót és a csomag eredetét is rögzítetted.
  2. Folyamat: a frissítés után az összes érintett FPM-, Apache- vagy egyéb PHP-folyamat újraindult, a szolgáltatások aktívak, a naplóban nincs új indulási hiba.
  3. Webes futtatókörnyezet: az alkalmazás tényleges PHP-kiszolgálóját ellenőrizted. WordPressnél ehhez használható a Webhely-egészség; egyedi alkalmazásnál meglévő adminisztrációs diagnosztika vagy ideiglenes, hozzáférés-korlátozott tesztútvonal. Minden backend/pool külön ellenőrizendő.
  4. Működés: sikeres a belépés, űrlapkezelés, feltöltés és a fontos üzleti folyamatok próbája; a pontos csomagverziót és a frissítés idejét elmentetted.
Hogyan nézzem meg a PHP-t a webes útvonalon?

Ha nincs beépített diagnosztika, az alkalmazás megfelelő webgyökerében, előre korlátozott hozzáférésű útvonalon rövid időre elhelyezhető az alábbi fájl. A megfelelő domainen és backend felé kérd le, majd töröld. Ne hagyj nyilvános phpinfo() oldalt.

Minimális PHP-diagnosztika · csak hozzáférés-korlátozott útvonalon
<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP_VERSION=' . PHP_VERSION . "
";
echo 'PHP_SAPI=' . PHP_SAPI . "
";

A PHP_SAPI például fpm-fcgi vagy apache2handler lehet. A kapott verziót rendeld a leltárban azonosított csomaghoz; backport esetén a rövid PHP_VERSION önmagában nem bizonyítja és nem is cáfolja a javítottságot.

Gyártói közlemények ellenőrizve: · A példák szerkesztett üzemeltetési minták; éles szervereken itt nem futtattuk őket.

05 / GYIK

Jó kérdések.
Egyenes válaszok.

A legfontosabb tudnivalók röviden, technikai túlzások nélkül.

Nézd meg a forrásokat
Elég frissíteni a WordPresst és a bővítményeket?

Nem. A hiba a PHP futtatókörnyezetében van. A WordPress és a bővítmények frissítése mellett a kiszolgáló PHP-jának javítását is el kell végezni. [1][5]

A PHP 8.4.26 már biztonságos?

Az eredeti PHP 8.4.26 még nem tartalmazza ezeket a javításokat. A 8.4-es ág első javított kiadása a 8.4.27. Gyártói backport esetén a teljes csomagverzió és a gyártói közlemény dönt. [1][4]

A PHP-FPM vagy az Nginx használata megvéd?

Nem tekinthető teljes védelemnek. A kockázat futtatási módonként eltér; a PHP-FPM-et is érintettnek kell kezelni és frissíteni kell. Az Nginx mögött PHP-FPM szolgálhatja ki a PHP-kéréseket. [1][2]

Megvéd a Cloudflare vagy egy WordPress-tűzfal?

A Cloudflare bejelentett PHP2Shell elleni WAF-védelmet. Ez kiegészítő védelem: a PHP frissítését nem helyettesíti. Alkalmazásszintű bővítményre különösen nem szabad teljes megoldásként támaszkodni, mert egyes támadási utak már az alkalmazáskód előtt aktiválódhatnak. [7][2]

Mit jelent, hogy a tárhelyen „ea-php83” van beállítva?

Ez a PHP 8.3-as ágát jelöli, a pontos javítási szintet nem. A cPanelben nézd meg a domain beállítását, és a szolgáltatótól kérj teljes csomagverziót, illetve megerősítést mindkét CVE javításáról. [6]

A régi PHP 7.4 vagy 8.1 biztosan nem javítható?

Ezek már nem támogatott upstream ágak, de egy disztribúció vagy LTS-szolgáltató adhat visszaemelt javítást. A PHP csapata 7.4, 8.0 és 8.1 forráshoz is közzétett minimális backportokat. Ne feltételezd a védettséget: kérj konkrét igazolást, vagy válts támogatott ágra. [1][4]

A frissítés bizonyítja, hogy korábban nem törtek fel?

Nem. A javítás a sérülékenységet szünteti meg. Korábbi behatolás gyanúja esetén külön vizsgálat szükséges: naplók, módosított fájlok, jogosultságok és hozzáférések ellenőrzésével.

A látogatóknak vagy egy statikus oldalnak van teendője?

A PHP javítása a kiszolgáló üzemeltetőjének feladata. Kizárólag HTML/CSS/JavaScript fájlokat kiszolgáló, PHP-t nem futtató környezetet ez a PHP-hiba nem érint közvetlenül. A háttérben működő más szolgáltatásokat külön kell ellenőrizni.

06 / FORRÁSOK

Ellenőrizhető információk.

Állapot:
Statikus összefoglaló, nem frissül automatikusan.

  1. 01PHP — Hivatalos biztonsági közleményÉrintettség, javított verziók és átmeneti intézkedések
  2. 02CVE-2026-109618 — PHP biztonsági jelentésRCE via OOM corruption · GHSA-w8hw-w9fx-j79w
  3. 03CVE-2026-109619 — PHP biztonsági jelentésRCE via stale global state · GHSA-6wmf-4rv5-p3rp
  4. 04Ubuntu — Javított disztribúciós csomagokTeljes csomagverziók és frissítési tudnivalók
  5. 05WordPress — PHP-verzió ellenőrzése és frissítéseWebhely-egészség, biztonsági mentés és kompatibilitás
  6. 06cPanel — MultiPHP ManagerA domainhez beállított PHP-ág kezelése
  7. 07Cloudflare — PHP2Shell elleni WAF-védelemA szolgáltató védelmi intézkedései
  8. 08Wiz Research — PHP2Shell kutatási beszámolóKódfuttatás és érzékeny folyamatmemória kiszivárgása
  9. 09NCSC — Sürgős intézkedési felhívásA brit kiberbiztonsági hatóság tájékoztatója
  10. 10Ubuntu — USN-8948-1Javított PHP-csomagok Ubuntu kiadásonként
  11. 11Debian Security Tracker — CVE-2026-109618Trixie és bookworm javított csomagverziói
  12. 12Debian Security Tracker — CVE-2026-109619A második sérülékenység javítási állapota
  13. 13Red Hat — RHSA-2026:87151PHP2Shell-javítás RHEL 9-hez; csomaglista
  14. 14Debian — apt-get kézikönyvPróbafuttatás, célzott frissítés és csomagkezelés
  15. 15Red Hat — Security updatesTelepített és elérhető erraták ellenőrzése
  16. 16DNF — Hivatalos parancsreferenciaCVE-szűrés, frissítés és tranzakció-előnézet
A LEGFONTOSABB LÉPÉS

Ellenőrizd. Frissítsd. Igazold.

A javítás legyen minden érintett kiszolgálón telepítve.

Vissza a teendőkhöz