# Az ellátási lánc a weben: ügynökség, tárhelyszolgáltató, bővítményszállító

> Weboldala a PHP-projekttől, a tárhelytől, az ügynökségtől és a bővítményszállítóktól függ. Így teheti láthatóvá és terhelhetővé ezt az ellátási láncot.

Forrás: https://phpsos.de/hu/blog/lieferkette-agentur-hoster/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy weboldal ellátási lánca a PHP-projekttől a disztribúción és a tárhelyszolgáltatón át a CMS-ig, a bővítményekig, az ügynökségig és a beépített szolgáltatásokig terjed. Az IT-biztonság szempontjából minden láncszem számít, mert egy javítás csak akkor ér el a weboldalához, ha mindenki továbbadta. Aki leírja a láncot, minden láncszemhez rögzít egy illetékes helyet és egy igazolást, és korlátozza a hozzáféréseket, az terhelhetővé teszi.

## Egy javítás és hosszú útja

2026. 10. 21-én 14:00 UTC-kor a PHP-projekt kiadta a PHP2Shell javításait. Ezzel egyetlen weboldalnál sem záródott le a rés. Először a disztribúcióknak, például a Debiannak, az Ubuntunak vagy az RHEL-családnak kellett átvenniük a javításokat a csomagjaikba; a beszámolók szerint a backportokat részben még ugyanazon a napon kiszállították. Azután a tárhelyszolgáltatóknak és a rendszergazdáknak telepíteniük kellett ezeket a csomagokat, és újra kellett indítaniuk az összes PHP-folyamatot. Csak ezután volt védett az adott weboldal.

Ebben a láncban minden láncszem késleltethet. És mindegyikhez egy másik szervezet tartozik saját prioritásokkal. Aki nem tudja, hogyan néz ki a lánca, az nem tudja megmondani, hol tart éppen a javítás.

Egyes láncoknak olyan további láncszemeik vannak, amelyeket alig ismer valaki. Sok Debian- és Ubuntu-szerver a PHP-t nem a disztribúcióból, hanem Ondřej Surý repositoryjából szerzi a sury.org-on, ami egy elterjedt harmadik fél forrás. A beszámolók szerint buildeket biztosított az 5.6-tól a 8.5-ig minden ághoz. Ez hasznos, de nem a Debian biztonsági archívuma: aki ezt a forrást használja, egy másik láncszemhez kötődik, saját ütemmel és saját felelősséggel. Hogy egy szerver így van-e beállítva, azt a csomagforrások listája mutatja, és éppen ennek az információnak a lánc dokumentációjában a helye.

## Az ellátási lánc láncszemeinek áttekintése

A következő táblázat egy PHP-weboldal tipikus láncszemeit mutatja, és azt, mit követelhet meg mindegyiktől.

| Láncszem | Tipikus kockázat | Mit érdemes rögzítenie |
|---|---|---|
| PHP-projekt | rés az értelmezőben, a támogatás vége | használatban lévő támogatott verzió, terv a támogatás végére |
| Disztribúció vagy harmadik fél forrás | a backport hiányzik vagy későn jön | ismert csomagforrás, feliratkozás a biztonsági közleményekre |
| Tárhelyszolgáltató vagy platformszolgáltatás | frissítés újraindítás nélkül, tájékoztatás hiánya | kötelezettség a frissítésre, újraindításra, igazolásra és értesítésre |
| CMS-gyártó | rés a magban | frissítési csatorna, felelős személy |
| Bővítmény- és témaszállító | felhagyott vagy nem biztonságos bővítmények | csak gondozott bővítmények hivatalos forrásból |
| Ügynökség vagy fejlesztő | messzemenő hozzáférések, tisztázatlan illetékesség | személyes hozzáférések, írásbeli feladatok |
| Külső szkriptek és szolgáltatások | idegen kód a böngészőben, adatszivárgás | lista, rögzített verziók, ellenőrzött cél |

A PHP2Shell hetéből két példa mutatja, milyen könnyen figyelmen kívül hagynak egy láncszemet. A Vercel arra mutat rá, hogy a helyi fejlesztői környezet, az alkalmazáskód vagy a bővítmények frissítése nem elég; a döntő az a PHP-futtatókörnyezet, amely ténylegesen kiszolgál. A Coolify azt tanácsolja, hogy minden alkalmazás PHP-futtatókörnyezetét külön frissítsék, a Cloudflare mögött is. A beszámolók szerint pedig a WordPress.org nem tervez saját frissítést a PHP2Shell ellen, mert a rés az értelmezőben van. Aki a CMS-re vár, hiába vár.

## Az ellátási lánc láthatóvá tétele: öt lépés

Így rendezheti a weboldalai függőségeit:

1. **A lánc leírása weboldalanként:** a PHP-futtatókörnyezettől a külső szkriptekig, a szállító vagy a személy nevével.
2. **Illetékesség rögzítése láncszemenként:** Ki telepíti a frissítéseket, ki ellenőriz, ki kit tájékoztat?
3. **Igazolások megállapodása:** Mi számít elvégzettnek? A PHP-futtatókörnyezetnél például a csomagállapot és az újraindítás, ahogyan azt a [Így kérdezze meg a tárhelyszolgáltatóját a javítási állapotról](https://phpsos.de/hu/ratgeber/hoster-patch-status-erfragen/) leírja.
4. **Hozzáférések korlátozása:** Minden ügynökség és szolgáltató csak azokat a jogokat kapja, amelyekre szüksége van, személyes fiókokkal.
5. **Kerülőutak tervezése:** Mi a teendő, ha egy láncszem kiesik, például egy bővítményszállító felhagy a termékével, vagy egy szolgáltató nem elérhető?

> **Tipp:**
> Kérdezze meg minden szolgáltatótól, hogyan tájékoztatja Önt a kritikus résekről. Aki csak kérdésre válaszol, az egy olyan helyzetben, mint a PHP2Shell, kockázatot jelent az Ön ütemtervére nézve. A választ rögzítse írásban.

## Bővítmények és kiegészítők: a legátláthatatlanabb hely

Sok weboldalnál az ellátási lánc legnagyobb része láthatatlan: az évek során hozzájött bővítmények és témák. Mindegyik másik szállítótól származik, saját tempóval a biztonsági frissítésekben. Egyes szállítók bejelentés nélkül felhagynak a termékükkel. Más kiegészítőket nem hivatalos forrásokból szereznek be, és sosem kapnak frissítést.

Itt egy egyszerű szabály segít: minden bővítménynek kell egy célja, egy gondozott szállítója és egy hivatalos beszerzési forrása. Ha ezek egyike hiányzik, a cserélendők listájára kerül. Hasonló érvényes a beépített szolgáltatásokra, például fizetési szolgáltatókra, foglalási rendszerekre, csevegőablakokra vagy elemzőeszközökre. Saját kódot hoznak az oldalára, vagy megkapják a látogatói adatait. Rögzítse, mely szolgáltatások vannak beépítve, ki rendelte meg őket, és szükség van-e még rájuk. Egy olyan szállító elfelejtett szkriptje, akivel már rég nincs szerződés, felelős nélküli láncszem.

Hogyan tarthatja tartósan naprakészen a bővítményeket és a csomagokat, azt a [Függőségek naprakészen tartása: Composer, npm és bővítmények](https://phpsos.de/hu/blog/abhaengigkeiten-aktuell-halten/) írja le.

## Ellátási lánc, szerződések és NIS2

A NIS2 hatálya alá tartozó vállalkozásoknál az ellátási lánc biztonsága kifejezetten a kockázatkezelés része, tehát a szolgáltatókkal és szállítókkal fennálló kapcsolatok is. A részleteket a [NIS2 és a webszerverek biztonsága](https://phpsos.de/hu/compliance/nis2/) tartalmazza. De törvényi kötelezettség nélkül is érvényes: a kiszervezett feladatok az Ön kockázatai maradnak. Ezért az öt lépés eredményei az ügynökséggel, a tárhelyszolgáltatóval és a szolgáltatókkal kötött szerződésekbe tartoznak; hogy milyen pontokat érdemes ott szabályozni, azt az [IT-szolgáltatói szerződések: a biztonsági kötelezettségek egyértelmű szabályozása](https://phpsos.de/hu/blog/dienstleistervertrag-sicherheit/) írja le. Ez az oldal általános tájékoztatás, nem jogi tanácsadás.

## Hogyan segít konkrétan a PHP SOS?

- Önnel együtt felrajzoljuk minden weboldal ellátási láncát, a PHP-futtatókörnyezettől a külső szkriptekig.
- Megvizsgáljuk a bővítmények, témák és csomagok gondozási állapotát és eredetét, és szükség esetén cserét javaslunk.
- Egyeztetünk a tárhelyszolgáltatóval és az ügynökséggel arról, ki melyik láncszemekért felel, és milyen igazolásokat szállítanak.
- Ahol egy láncszem gazdátlan, ott tartósan átvesszük egy [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében.

**Összegzés:** Egy weboldal biztonsága olyan erős, mint az ellátási láncának leglassabb láncszeme. Aki ismeri a láncot, és minden láncszemet összekapcsol egy illetékes hellyel és egy igazolással, az éles helyzetben tudja, hol akad el a javítás.


## Gyakori kérdések

**Mit jelent az ellátási lánc egy weboldalnál?**  
Mindazok, akiknek a munkájától a weboldala biztonsága függ: a PHP-projekt, a Linux-disztribúció, a tárhelyszolgáltató vagy platformszolgáltatás, a CMS-gyártó, a bővítmény- és témaszállítók, az ügynökség, valamint a beépített szolgáltatások, például fizetési szolgáltatók vagy külső szkriptek.

**Felelős vagyok, ha egy szolgáltató nem javít?**  
A saját weboldalért és a rajta lévő adatokért való felelősség általában az Ön oldalán marad, még ha a feladatokat ki is szervezték. Ezért az illetékességeket szerződésben egyértelműen rögzíteni és ellenőrizni kell. A jogi értékelés az ügyvéd és az adatvédelmi tisztviselő dolga.

**Elég, ha a tárhelyszolgáltató frissíti a PHP-t?**  
A tárhelyszolgáltatónál futó PHP-futtatókörnyezetre igen, feltéve, hogy az összes folyamatot is újraindítja, és ezt igazolja. Ha az alkalmazás egyes részei máshol futnak, például konténerekben, platformszolgáltatásokon vagy egy második szerveren, ott minden futtatókörnyezetet külön kell frissíteni.

**Hogyan ismerem fel a kockázatos bővítményeket?**  
Figyelmeztető jelek: régóta nincsenek frissítések, a szállítónak nincs felismerhető biztonsági kapcsolattartója, nem hivatalos forrásból származik, és olyan funkciókat tartalmaz, amelyeket már senki sem használ. Az ilyen bővítményeket le kell cserélni vagy el kell távolítani.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [Vercel: PHP2Shell Security Bulletin](https://vercel.com/kb/bulletin/php2shell-security-bulletin)
- [Coolify: PHP Security Advisory](https://coolify.io/docs/knowledge-base/php-security-advisory-2026)
- [BSI](https://www.bsi.bund.de/)