PHP2Shell (CVE-2026-109618 és CVE-2026-109619): mit tegyenek most a PHP-t futtató cégek

Laptoppal dolgozó technikus egy szerverrack mellett

A PHP projekt 2026. október 21-én kiadta a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióját, amelyek két olyan sebezhetőséget javítanak, amelyek „hitelesítés nélküli távoli kódfuttatást tehetnek lehetővé”. Egyszerűbben fogalmazva: bárki, aki HTTP-kérést tud küldeni a webhelyére, a saját kódját futtathatja a szerverén. Ehhez nem kell jelszó, és egyes konfigurációkban a támadás még azelőtt működik, hogy az alkalmazása egyetlen sort lefuttatott volna. A két hiba a PHP2Shell nevet kapta, és a PHP mindkettőt 9,2 pontra értékeli (CVSS 4.0, 10-es skálán).

Ez az útmutató azoknak szól, akiknek tenniük kell valamit: PHP-alapú webhelyek és webáruházak tulajdonosainak, informatikai vezetőknek, és mindenkinek, akinek egy beszállító futtat PHP-t. Az útmutatót 2026. október 22-én, a kiadás másnapján írtuk, a PHP projekt saját biztonsági közleményei, a nemzeti kiberbiztonsági hatóságok ajánlásai és a szállítók által közzétett adatok alapján. Ahol a források eltérnek egymástól, ezt jelezzük.

Röviden

Magát a PHP-t frissítse, majd indítsa újra. A WordPress, a Drupal, a Laravel vagy egy bővítmény frissítése ezt nem javítja. A hiba a PHP-ben van, az alkalmazása alatt.
Minden PHP-telepítés érintett, amely webes kéréseket szolgál ki, a PHP szerint: a PHP-FPM, a mod_php-vel futó Apache, a php-cgi, a FrankenPHP és a LiteSpeed. A legnagyobb kockázatot a PHP szerint a mod_php-vel futó Apache jelenti.
A PHP-webhelyek közel fele olyan ágon fut, amelyhez a PHP projekt már nem ad ki új verziót (ez a mi következtetésünk a W3Techs adataiból, lásd lent). Ezekhez nincs telepíthető hivatalos csomag.
A beállítások és a tűzfalak időt nyernek, nem biztonságot. A PHP ideiglenes intézkedéseket sorol fel, és azt írja, hogy ezek „nem teszik biztonságossá a telepítést”.
Ha ma nem tudja telepíteni a javítást, az amerikai, a brit és az uniós hatóságok ugyanazt tanácsolják: vegye le a rendszert az internetről, amíg ezt meg nem teheti.

Mi történt, időrendben

2026. augusztus 19. A Wiz kutatói saját közlésük szerint megtalálják a hibák közül az elsőt, és augusztus 24-én jelentik őket a PHP biztonsági csapatának. A PHP biztonsági közleményei több más cég kutatóit is feltüntetik a felfedezők között.
Október 20. A CVE-azonosítók két nappal a tervezett közzététel előtt kiszivárognak az interneten. A PHP egy nappal előrehozza a kiadást, október 21-ére, 14:00 UTC-re, és mindenkit felkészülésre szólít fel.
Október 21., 03:02 UTC. A Cloudflare tűzfalszabályokat kapcsol be minden olyan ügyfele számára, aki a WAF-ját használja, az ingyenes csomagot is beleértve. Később azt írja: „ügyfeleinket célzó támadási forgalmat észleltünk”, és azt is látta, hogy a támadók „módosítják a támadás payloadját, hogy megpróbálják megkerülni a védelmeinket”.
Október 21., 14:00 UTC körül. A PHP közzéteszi a javításokat és a biztonsági közleményét. Ugyanazon a napon az amerikai CISA, a brit NCSC, a CERT-EU, valamint az Európai Bizottság, az ENISA, a CERT-EU, az Europol és az uniós nemzeti CSIRT-ek közös nyilatkozata egyaránt arra szólítja fel a szervezeteket, hogy azonnal telepítsék a javítást.

Mennyire súlyos?

Három dolog különbözteti meg ezt a szokásos havi javításoktól.

A támadónak nem kell más, csak egy kérés. Nincs bejelentkezés, és senkinek nem kell linkre kattintania. A PHP biztonsági közleménye egy bemutatott exploitot ír le a mod_php-vel futó Apache ellen, „ahol egy hitelesítés nélküli kérés még azelőtt kiválthatja a támadást, hogy bármilyen alkalmazáskód lefutna”. A Wiz a WordPress, a Drupal és a Joomla aktuális verzióin mutatott be támadásokat, és megjegyzi, hogy „még egy érintett PHP-verzión futó egyszerű »Hello World« alkalmazás is sebezhető lehet”. Az így futtatott kód a webszerver felhasználói fiókjának jogosultságaival fut, amely a legtöbb webhelyen olvashatja az alkalmazás konfigurációját: az adatbázis-jelszót, az API-kulcsokat, a levelezési és fizetési hozzáférési adatokat. A második hibánál (CVE-2026-109619) a PHP memóriatartalom felfedését is megerősíti: a szerver memóriájából adatok szivárognak ki, teljes kódfuttatás nélkül is.

Óriási a telepítési bázis. A W3Techs szerint a PHP fut azon webhelyek 69,3%-án, amelyek szerveroldali nyelve ismert (2026. október 22-i adatok). A Palo Alto Networks Unit 42 csapata saját internetes szkennelése alapján több mint 22,6 millió kitett példányt számol, amelyek potenciálisan sebezhetők, és arról számol be, hogy legalább egy európai kormány elővigyázatosságból lekapcsolta a webhelyét.

Az exploitfejlesztés gyorsan halad. A CERT-EU szerint az első proof-of-concept kódok „elkezdtek terjedni”. A watchTowr biztonsági cég szerint a honeypotjai október 21. óta rögzítik a hibák kihasználását. A Cloudflare támadási forgalomról számol be. A Wiz pedig azt írja, hogy kutatói végig MI-modelleket használtak, így egyetlen kutató egy hét alatt elvégezte azt, ami „egy világszínvonalú csapatnak hónapokig tartott volna”. Ugyanezek az eszközök a támadók kezében is ott vannak, amikor egy exploitot az Ön PHP-verziójához igazítanak.

A kép teljességéhez hozzátartozik, hogy amikor a CISA október 21-én közzétette riasztását, még nem észlelt kihasználást, és egyik hiba sem szerepelt még a Known Exploited Vulnerabilities (ismert, kihasznált sebezhetőségek) katalógusában. A Red Hat „Important” (fontos), nem pedig kritikus besorolást ad a problémának, mert egy szokásos Red Hat Enterprise Linux szerveren PHP-FPM fut, ahol a kihasználás nehezebb. A nehezebb nem jelenti azt, hogy lehetetlen: a PHP megerősíti, hogy a második hiba egyik támadási útvonala PHP-FPM-en is működik. Mindez nem változtat azon, hogy mit kell tennie. Csak azon, hogy mennyi előzetes figyelmeztetést kap.

Melyik verziót használja? A számok

A W3Techs azt is közzéteszi, hogy a webhelyek mely PHP-verziókat futtatják, azokat a webhelyeket számolva, amelyek felfedik a verziójukat. A 2026. október 22-i két táblázatát összevetve:

PHP-ág	Arány a PHP-webhelyek között	Javítás a PHP projekttől
8.3, 8.4, 8.5	nagyjából 34%	Igen: 8.3.36, 8.4.27, 8.5.12
8.2	nagyjából 18%	Igen: 8.2.35. De maga a 8.2 2026. december 31-én eléri életciklusa végét
8.0, 8.1	nagyjából 14%	Nincs kiadás. 8.0 és 8.1: csak forráskódszintű backport
7.x	26,9%	Nincs kiadás. 7.4: csak forráskódszintű backport; 7.3 és régebbi: semmi
5.x és régebbi	7,8%	Semmi

Tehát a PHP-webhelyek nagyjából 48%-a olyan ágon fut, amelyhez a PHP projekt nem ad ki javított verziót, további 18% pedig most megkapja a javítást, de tíz hét múlva elveszíti a támogatást.

Két fenntartás. A W3Techs csak azokat a webhelyeket látja, amelyek megmutatják a verziójukat. Egy Linux-disztribúció pedig maga is javíthatott egy régi ágat: az Ubuntu megtette, ahogy lent látni fogja. Önmagában a verziószámból nem derül ki, hogy védett-e. A szállítója csomagjának verziójából igen.

1. lépés: Találja meg az összes PHP-telepítését

Amit nem vett listára, azt nem tudja javítani, a PHP pedig jól rejtőzik. A brit NCSC arra kéri a szervezeteket, hogy keressenek meg minden PHP-rendszert, elsőként az internet felől elérhetőket, és hozzáteszi: „ne korlátozzák a felderítést az elavult PHP-verziókra”. Az uniós közös nyilatkozat figyelmeztet, hogy egyes termékek „akkor is érintettek lehetnek ezekben a sebezhetőségekben, ha látszólag nem használnak közvetlenül PHP-t”.

Hol keresse:

Webhelyek és webáruházak: WordPress és WooCommerce, Drupal, Joomla, Magento és Adobe Commerce, Shopware, PrestaShop, TYPO3, valamint minden, ami Laravelre vagy Symfonyra épül.
Az elfelejtettek: kampány-mikrooldalak, egy régi nyelvi változat, az internetről elérhető staging- és tesztszerverek, a webmail vagy helpdesk, amelyet valaki évekkel ezelőtt telepített.
Konténerek: minden image, amely egy php alap-image-re épül, saját PHP-t visz magával. A gazdagép frissítése rajta semmit nem változtat.
Tárhelykezelő panelek: a cPanel, a Plesk és a hasonló panelek saját PHP-buildeket szállítanak a rendszer PHP-je mellett. A panelben engedélyezett minden verzió külön frissítendő elem.
Termékek, amelyekben PHP van: appliance-ek, monitorozó eszközök, CRM-ek, helpdeskek és szállítói adminisztrációs felületek. A holland NCSC nyilvános listát vezet az ilyen termékekről az állapotukkal együtt, szállítónként.
Beszállítók: a tárhelyszolgáltatója, az ügynöksége, bármely szolgáltatás, amelyről tudja, hogy PHP fut alatta. Kérdezze meg tőlük írásban, mely PHP-verziók futtatják a rendszereit, és mikor kapják meg a javítást.

Mindegyiknél jegyezze fel a PHP-verziót, a PHP futtatásának módját (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, konténer), azt, hogy elérhető-e az internetről, és hogy ki tudja telepíteni rá a javítást.

2. lépés: Telepítse a javításokat, a megfelelő sorrendben

Kezdje azzal, ami az internetről elérhető, azon belül pedig az Apache mod_php-s telepítésekkel.

Támogatott ágon (8.2-től 8.5-ig). Frissítsen a 8.5.12-es, 8.4.27-es, 8.3.36-os vagy 8.2.35-ös verzióra, vagy a disztribúciója javítást tartalmazó csomagjára. A PHP szerint a Linux-disztribúciók előre megkapták a javításokat. Amit eddig megerősítettek:

Ubuntu: javított csomagok minden kiadáshoz a 14.04-től a 26.10-ig. A 22.04-es és újabb kiadásokon a szokásos frissítésekkel érkeznek; a 20.04-es és régebbi kiadásokon Ubuntu Pro-előfizetés kell hozzájuk, amely legfeljebb öt gépig ingyenes (a Canonical közleménye).
Debian: php8.4 8.4.27 a Debian 13-hoz (DSA-6574-1) és php8.2 8.2.35 a Debian 12-höz (DLA-4848-1).
Red Hat Enterprise Linux: a Red Hat RHSB-2026-013 számú biztonsági közleménye kiadásonként sorolja fel a csomagokat.
A Remi tároló, amelyet a Red Hat családba tartozó rendszereken széles körben használnak újabb PHP-verziókhoz: a CERT-EU október 21-én megjegyezte, hogy a kiadás napján még nem voltak csomagjai, és azt tanácsolta, hogy térjenek át a disztribúció csomagjaira, vagy fordítsák le a PHP-t forráskódból. Mielőtt rá támaszkodna, ellenőrizze, hogy behozta-e már a lemaradást.

PHP 7.4, 8.0 vagy 8.1 esetén. A PHP projekt ezekhez nem ad ki új verziót. A biztonsági csapata minimális forráskódszintű backportokat készített a három ághoz, amelyek akkor segítenek, ha saját maga fordítja a PHP-t. Egyébként a javításnak a szállítójától kell érkeznie (az Ubuntu Pro például lefedi a PHP 7.4-et az Ubuntu 20.04-en), vagy egy újabb PHP-verzióra való átállásból. A CISA tanácsa azoknak, akik 8.1-es vagy régebbi verziót futtatnak, és nem tudnak frissíteni, kertelés nélküli: kapcsolják le a rendszert, amíg nincs javítva vagy újabb verzióra frissítve.

PHP 7.3 vagy régebbi esetén. A PHP projekttől semmi nem érkezik. Hacsak egy szállító még javítja az Ön buildjét, a választás: átállás újabb verzióra, vagy a rendszer lekapcsolása.

Frissítés után indítsa újra. Egy csomag telepítése nem cseréli le a már futó PHP-t. Az Ubuntu közleménye egyenesen fogalmaz: az alkalmazást „valószínűleg újra kell indítani”. Indítsa újra a PHP-FPM-et, az Apache-ot, a LiteSpeedet vagy a konténert minden szerveren. Utána ellenőrizze, melyik verziót futtatja ténylegesen a webszerver, és ne csak a parancssori php -v kimenetét nézze, mert az lehet egy másik build.

Konténerek: építse újra az image-eket egy javított alap-image-ből, és telepítse őket újra. Egy javított gazdagépen futó régi image továbbra is ki van téve a támadásnak.

Menedzselt tárhely: kérdezze meg a szolgáltatótól a dátumot és a verziót, majd ellenőrizze saját maga is.

3. lépés: Ha ma nem tudja telepíteni a javítást

A PHP biztonsági közleménye ideiglenes intézkedéseket sorol fel, és figyelmeztetéssel vezeti be őket: ezek „csökkentik a kitettséget bizonyos támadási útvonalakkal szemben, de nem teszik biztonságossá a telepítést”. Röviden, a szerverei üzemeltetőjének:

A CVE-2026-109618-hoz: állítsa be a memory_limit=-1 értéket úgy, hogy az alkalmazás ne írhassa felül (például php_admin_value segítségével a PHP-FPM poolban vagy az Apache konfigurációjában); állítson be alacsony post_max_size értéket (a PHP fájlfeltöltés nélkül 8M, fájlfeltöltéssel 32M értéket javasol); korlátozza a kérések méretét, a mezők számát és a multipart részek számát a webszerveren vagy a proxyn; és használjon konténer- vagy cgroup-memóriakorlátot, soha ne az RLIMIT_AS vagy az RLIMIT_DATA korlátot.
A CVE-2026-109619-hez: állítsa be a session.upload_progress.enabled=0 értéket a php.ini-ben vagy a szerver konfigurációjában (ne ini_set() hívással vagy .user.ini fájlban), és indítson újra minden workert. PHP 8.5-ön állítsa be a fatal_error_backtraces=0 értéket is.

Két figyelmeztetés. Az október 20-án széles körben terjedő munkamenet-beállítás csak a második hiba támadási útvonalait zárja le, ahogy a PHP biztonsági csapatának egyik tagja rámutatott; az első ellen semmit nem tesz. A memory_limit=-1 pedig megszünteti a PHP saját memóriakorlátját, így egyetlen nehéz kérés is kimerítheti a szervert. Párosítsa konténer- vagy cgroup-korláttal.

A webalkalmazás-tűzfal segít, egy kicsit. A Cloudflare szabályai minden WAF-ot tartalmazó csomagban alapértelmezetten be vannak kapcsolva, az ingyenest is beleértve, és a Palo Alto Networks, valamint más szállítók is közzétették saját védelmeiket. A Cloudflare ennek ellenére arra kéri az ügyfeleit, hogy „WAF-védelem mellett is” javítsák a PHP-t, és megfigyelte, ahogy a támadók módosítják a payloadjaikat, hogy átjussanak a szabályain. Egy WAF ráadásul csak a rajta áthaladó forgalmat védi. Ha a szervere a saját IP-címén is válaszol, a támadó megkerülheti a WAF-ot.

Ha ezek közül semmi nem oldható meg gyorsan, a CISA, a CERT-EU, az NCSC és az uniós közös nyilatkozat ugyanabba az irányba mutat: vegye le a rendszert a nyilvános internetről, amíg nincs javítva. Egy napig kint lévő karbantartási oldal kevesebbe kerül, mint egy újraépített szerver.

4. lépés: Ellenőrizze, nem törtek-e már be

A veszélyes időszak október 20-án kezdődött, a kiszivárgással, és másnap reggel már támadási forgalmat jelentettek. Ha egy rendszer ebben az időszakban elérhető és javítatlan volt, a javítás bezárja az ajtót, de nem mondja meg, hogy bejött-e valaki előtte. Az NCSC arra kér mindenkit, aki nem tudott azonnal javítani, hogy keresse a kompromittálódás és a hátsó ajtók jeleit.

Mit keressen, a közzétett ajánlások és a szokásos incidenskezelési gyakorlat alapján:

PHP-folyamatok, amelyek olyasmit csinálnak, amit a PHP soha nem csinál, például shellt indítanak vagy eszközöket töltenek le (CISA).
Szokatlan multipart kérések, amelyeket memóriakorlát-hibák vagy ismétlődő HTTP 500-as válaszok követnek, látható ok nélkül újrainduló PHP-workerek, valamint szokatlanul nagy vagy hibás formátumú PHPSESSID sütik a válaszokban (Wiz).
Új vagy módosított PHP-fájlok a feltöltési mappákban, a gyorsítótár-mappákban vagy a webes gyökérkönyvtárban, új rendszergazdai fiókok a CMS-ben, és ütemezett feladatok, amelyeket senki nem hozott létre.

A tiszta napló nem bizonyíték. A PHP második hibára vonatkozó közleménye pontosan erre figyelmeztet, a Wiz pedig megjegyzi, hogy az alkalmazásnaplókban kevés kontextus lehet.

Ha talál valamit, kezelje incidensként, ne javítási feladatként. Különítse el a szervert, őrizze meg a bizonyítékokat, vonjon be incidenskezelési szolgáltatót, és cseréljen le minden titkos adatot, amelyet a webszerver olvashatott: adatbázis-jelszavakat, API-kulcsokat, fizetési és levelezési hozzáférési adatokat, aláírókulcsokat. Mivel a második hiba memóriatartalmat fedhet fel, fontolja meg, hogy a legérzékenyebb titkos adatokat minden olyan szerveren lecseréli, amely napokig kitett és javítatlan volt, akkor is, ha nincsenek behatolásra utaló jelek.

5. lépés: Mit kell esetleg bejelentenie

Egy sebezhetőség önmagában nem bejelentendő incidens. Egy kihasznált sebezhetőség viszont az lehet.

NIS2: ha a szervezete a hatálya alá tartozik, és egy kompromittálódás jelentős incidensnek minősül, a nemzeti CSIRT-nek 24 órán belül korai figyelmeztetést kell küldenie. Lásd a NIS2-útmutatónkat.
GDPR: ha személyes adatokhoz fértek hozzá, az adatvédelmi incidensről való tudomásszerzéstől számított 72 órán belül értesíteni kell a felügyeleti hatóságot, kivéve, ha az incidens valószínűsíthetően nem jelent kockázatot az érintettekre. Lásd a GDPR-útmutatónkat.
A kiberrezilienciáról szóló rendelet (CRA): ha PHP-t tartalmazó szoftvert vagy eszközt értékesít, a CRA szerint Ön annak gyártója. 2026. szeptember 11. óta a gyártóknak az egységes CRA bejelentési platformon keresztül be kell jelenteniük a termékeikben lévő aktívan kihasznált sebezhetőségeket, ahogy erre az uniós közös nyilatkozat is emlékeztet. Lásd a CRA-útmutatónkat.
Az ügyfelei: ha ügyfeleknek üzemeltet vagy futtat PHP-t, kérdezni fognak. Egy rövid írásos tájékoztató (mit futtat, mikor kapta meg a javítást, mit ellenőrzött) a kérdéseik többségére választ ad, és ugyanezt a tájékoztatót akarja majd látni egy auditor vagy egy kiberbiztosító is.

A vészhelyzet után: mit változtasson

A legtöbb jól üzemeltetett szerveren a PHP2Shell napokon belül javítva lesz. Amit az Ön rendszeréről megmutatott, az utána is igaz marad.

Tudja, mennyi ideig tart Önnél egy javítás. A biztonsági közleménytől addig, amíg minden szerver újraindult: órák, napok vagy hetek? Ha az őszinte válasz az, hogy „meg kellene kérdeznünk az ügynökséget”, ezt hozza rendbe a következő előtt. Ha a kutatók szerint az MI hónapokról egy hétre rövidítette az exploitfejlesztési munkájukat, számoljon azzal, hogy a támadók is képesek ilyen tempóra.
Tartsa meg a most elkészített leltárt. Ez volt a reagálás legnehezebb része, és abban a pillanatban elavul, amikor senki nem felel érte.
Hagyja el az életciklusuk végén lévő PHP-verziókat. Egy 7.4-es vagy 8.1-es webhelynek ezúttal szállítóra vagy forráskódszintű backportra volt szüksége; legközelebb lehet, hogy egyik sem lesz. A PHP 8.2 életciklusa 2026. december 31-én véget ér, ezért egy 8.1-ről továbblépő webhely egyenesen 8.3-ra vagy újabbra álljon át. A PHP-verzió váltása gyakran az alkalmazás frissítését is jelenti: a Drupal, az Umbraco és a Kentico életciklusának végéről szóló cikkünk megmutatja, mivel jár ez egy CMS esetében.
Ahol lehet, válassza a PHP-FPM-et a mod_php helyett. Ezúttal ez volt a kisebb kockázatú konfiguráció.
Hagyja kikapcsolva a feltöltési folyamat követését, ha nem használja. A PHP biztonsági közleménye azt javasolja, hogy a session.upload_progress.enabled maradjon kikapcsolva a javítás után is, ha az alkalmazásnak nincs rá szüksége.
Írja bele a javítási határidőket a szerződéseibe. Kérdezze meg tárhelyszolgáltatóját és ügynökségét, milyen gyorsan telepítik a kritikus PHP-javításokat, és kérje írásban a választ.

Ellenőrzőlista erre a hétre

Vegyen listára minden PHP-telepítést, a konténereket, a vezérlőpaneleket, a szállítói termékeket és a staging-szervereket is.
Először az internetről elérhető rendszereket javítsa, az Apache mod_php-vel kezdve.
Indítson újra minden PHP-folyamatot, és ellenőrizze, melyik verziót jelzi a webszerver.
Építse újra és telepítse újra a konténer-image-eket.
Ahol ma nem tud javítani, alkalmazza a PHP ideiglenes beállításait, terelje a forgalmat WAF-on keresztül, vagy kapcsolja le a rendszert.
Kérje el írásban a beszállítóktól és a tárhelyszolgáltatóktól a PHP-verziójukat és a javítás dátumát.
Nézze át a naplókat és a fájlváltozásokat mindenen, ami október 20. óta kitett és javítatlan volt.
Döntse el, vonatkozik-e Önre bejelentési kötelezettség (NIS2, GDPR, CRA).
Tervezze meg az átállást a PHP 8.1-ről és a régebbi verziókról, valamint a 8.2-ről december 31. előtt.

Miben tudunk segíteni

A legtöbb cégnél nem a javítási szándék hiányzik, hanem a tiszta kép arról, mit futtatnak, vagy az emberek, akik ezen a héten elvégzik a munkát. Ezt a részt vállaljuk át:

Leltár és javítás, napok alatt. Megtaláljuk a PHP-telepítéseit a szervereken, a konténerekben, a tárhelykezelő paneleken és a beszállítóinál, telepítjük a javításokat, újraindítunk és ellenőrzünk, és írásos nyilvántartást hagyunk arról, mit és mikor végeztünk el. Ez a nyilvántartás egyben a válasza az ügyfeleinek és az auditoroknak.
Átállás a régi PHP-ről. Azokat az alkalmazásokat, amelyek PHP 7.x-en, 8.0-n vagy 8.1-en ragadtak, mert a kód semmi újabbon nem fut, támogatott verzióra portoljuk a régi rendszerek karbantartására vonatkozó szolgáltatásunk keretében.
Biztonsági megerősítés és javítási rutin, hogy a következő biztonsági közlemény ütemezett feladat legyen, ne vészhelyzet.

Ha betörésre utaló jeleket talál, először incidenskezelési szolgáltatót hívjon. Velük párhuzamosan mi vállalhatjuk az újraépítést és a verzióváltást.

Írjon az office@c9group.dev címre arról, hogy mit futtat, és megírjuk, mivel kezdenénk.

Források

Ellenőrizve: 2026. október 22. A helyzet még változik: különösen a kihasználás állapota és a szállítók csomagjai változhattak meg azóta.

PHP projekt

Hatóságok

Kutatók, szállítók és adatok