A Drupal biztonsága a nyílt forráskódú CMS-világ egyik kevés olyan területe, ahol a közzétett folyamat jobb, mint a platform hírneve. A Drupal biztonsági csapata rögzített közzétételi menetrend szerint dolgozik, minden közleményt dokumentált számskálán pontoz, és összehangolja a javításokat a magban és több tízezer közösségi projektben.

A gyakorlati mérleg rosszabb, mint amit ez a folyamat megérdemelne. A Drupal webhelyeket valóban feltörik, és az ok szinte soha nem az, hogy senki nem tudott róla. A közlemény megjelent, időben, egy szerdán. A javítás a következő héten jutott el az éles rendszerbe. Ez a rés a cikk témája, és a megerősítés, a tűzfalak és a fájljogosultságok mind azért léteznek, hogy túlélhetővé tegyék vagy lerövidítsék.

A kockázatot az szabja meg, milyen gyorsan javít, nem az, hogy éppen milyen modulokat futtat. A magra vonatkozó közlemények havi szerdai ablakban jelennek meg, a közösségi projektek közleményei pedig minden szerdán, mindegyik közzétett skálán 0 és 25 között pontozva. A mag kritikusan súlyos hibáit órákon belül kihasználták a nyilvánosságra hozatal után: a 2014-es SQL injection közlemény után a hivatalos útmutatás az volt, hogy minden hét órán belül nem javított webhelyet tekintsenek eleve feltörtnek. Az a webhely, amely egy munkanapon belül nem tud kiadni egy magjavítást, viseli szinte a teljes létező kockázatot.

Hogyan működik valójában a Drupal biztonsági közleményfolyamat

A legtöbben, akik Drupal webhelyet üzemeltetnek, soha nem olvasták a folyamatleírásokat, és ez kár: pontosan megmondják, mennyi előzetes figyelmeztetést kap az ember, milyen formában és mely napokon.

A kiadási ablakok

A biztonsági csapat naptár szerint publikál. A közösségi projektek közleményei minden szerdán mennek ki. A magnak a hónap első szerdáján van hibajavító és funkciós kiadási ablaka, a harmadikon pedig biztonsági kiadási ablaka, ahogy azt a biztonsági kiadások időzítéséről szóló dokumentáció leírja. Az ablak nem ígéret arra, hogy megjelenik valami; azért van, hogy az üzemeltetők tudják, mely napokat kell figyelniük.

Néha van előzetes figyelmeztetés. Egy kritikusan súlyos magkiadás előtt a csapat közérdekű bejelentést tehet közzé, rendszerint hétfőn. A PSA-2026-05-18 pontosan ezt tette a 2026. május 20-i kiadás előtt: 17:00 és 21:00 UTC közötti ablakot nevezett meg, és arra kérte a tulajdonosokat, hogy előbb frissítsenek a saját águkon elérhető legfrissebb javítókiadásra, hogy a frissítési gondok korán kiderüljenek. Két nap a legtöbb előny, amit kaphat.

Mag-közlemények és közösségi projektek közleményei

Ez két rendszer, eltérő garanciákkal. A magra vonatkozó közlemények a támogatott minor ágakat fedik le, egyszerre kettőt, a legfrissebbet és az azt megelőzőt. A gyakorlatban a mag kiadási menetrendje 11.4.x és 11.3.x verziót jelent, miközben a 10.6.x is fedett marad, amíg a Drupal 10 el nem ér az életciklusa végére 2026. december 9-én. 2026 szeptemberének elején az aktuális kiadások a 11.4.5, a 11.3.16 és a 10.6.15. A Drupal 12.0.0 és a 11.5.0 a 2026. december 7-i héten várható, és ekkor ér véget a 11.3.x és a 10.6.x támogatása.

A közösségi projektek lefedettsége önkéntes és feltételes. Közlemény csak azoknak a projekteknek a támogatott fő ágaiban lévő stabil kiadásaira jelenik meg, amelyek karbantartói kérték és meg is kapták a lefedettséget, a biztonsági közlemények folyamatáról és jogosultságairól szóló szabályzat szerint. Az alfa, béta vagy kiadásra jelölt verzión lévő modul a rendszeren kívül esik, ahogy az is, amelynek karbantartója soha nem jelentkezett be. Egyik tény sem látszik az adminisztrációs felületről, amíg a webhely normálisan működik.

A mennyiség a valódi munkateher. 2026. augusztus 26-án, szerdán a csapat egyetlen nap alatt tíz közösségi projektről adott ki közleményt, mindegyik mérsékelten kritikus volt. Egy hatvan modult futtató webhely évente többször is szerepelni fog, és ez a folyam idővel többe kerül, mint a mag vészhelyzetei.

A kockázati pontszám, és miért nem CVSS

Minden közlemény 25-ből kapott számot visel. A skála a NIST Common Misuse Scoring System, azaz a NISTIR 7864 alapján készült, és a biztonsági kockázati szintek oldalán van dokumentálva. Hat mérőszám táplálja: a hozzáférés összetettsége, a szükséges hitelesítés, a bizalmasságra gyakorolt hatás, az integritásra gyakorolt hatás, van-e ismert exploit, és mennyire elterjedt a célpont. A sávok a nem kritikustól 0 és 4 között, a kevéssé kritikuson 5 és 9 között, a mérsékelten kritikuson 10 és 14 között, a kritikuson 15 és 19 között át a kritikusan súlyosig 20 és 25 között tartanak.

Mivel a célpontok elterjedtsége is része a pontszámnak, az a hiba, amely csak ritka konfigurációt érint, alacsonyabbra kerül, mint CVSS szerint kerülne. Az SA-CORE-2026-005 közlemény 2026. június 17-én egy PHP objektuminjekciós problémáról szólt, amelyet CVE-2026-55803 néven tartanak nyilván, 18 pontot kapott, és pontosan emiatt minősült kritikusnak, nem pedig kritikusan súlyosnak.

Amikor egy közösségi modul támogatás nélkül marad

A biztonsági csapat nem kényszeríthet önkéntes karbantartót arra, hogy bármit megjavítson. Ha egy karbantartó nem válaszol többé, a dokumentált eljárás szerint ismételt megkeresések után a projektet nem támogatottként jelölik meg. A projekt oldala ekkor figyelmezteti a tulajdonosokat, hogy válasszanak aktívan karbantartott alternatívát, vagy fizessenek valakit a hiba javításáért, hogy a modult újra közzé lehessen tenni.

Ez a tanács helyes és drága, mert mire egy modult nem támogatottként jelölnek meg, rendszerint tartószerkezet, a cseréje pedig adatmigrációt, sablonmódosítást és teljes regressziós tesztet jelent. Az olcsó pillanat a cselekvésre az elhagyás előtti kiadás, amikor a karbantartó már elhallgatott, de még semmi nem romlott el, és akkor szinte senki nem néz oda.

A Drupal 7 életciklusa lejárt, és a kiterjesztett támogatás nem egyenlő a biztonsággal

A Drupal 7 életciklusa 2025. január 5-én ért véget, amit a PSA-2025-01-06 is megerősít. Ezt követően a biztonsági csapat megszüntette a támogatást és a közleményeket a Drupal 7 magjára, valamint a hozzá tartozó közösségi modulokra és sablonokra. A bejelentés kifejezetten leszögezte, hogy a Drupal 7 biztonsági hibái mostantól egyeztetés nélkül nyilvánosságra hozhatók, és nulladik napi hibák is előfordulhatnak.

Létezik kereskedelmi kiterjesztett támogatási piac. A Drupal Association szolgáltatókat minősített, köztük a HeroDevs és a Tag1 Consulting cégeket, egy Extended Security Support Provider Program keretében, és ezek valóban készítenek javításokat. Ez jobb a semminél, de nem ugyanaz, mint a támogatottság. A szolgáltató a magot és az általa lefedésre kiválasztott, meghatározott modulkészletet javítja, saját ütemezés szerint, a fizető ügyfelek számára. Az ökoszisztéma többi része, amelytől a webhelye függ, kívül esik a hatókörön.

Egy nem támogatott CMS-t ráadásul nehéz megvédeni egy beszállítói kérdőívben vagy egy biztosító előtt egy incidens után. A Drupal migráció költségeiről, útjairól és határidőiről szóló útmutatónk bemutatja, mibe kerül a kilépés.

A történeti minta: Drupalgeddon és ami utána jött

Három incidens formálta azt, ahogy a közösség a javítás gyorsaságáról gondolkodik. Mindegyik injekciós vagy távoli kódfuttatási hiba volt a magban, és mindegyiknél órákon vagy napokon belül tömeges, automatizált kihasználás indult.

A 2014. októberi hétórás ablak

Az eredeti Drupalgeddon az SA-CORE-2014-005 volt, amely 2014. október 15-én jelent meg. A CVE-2014-3704 SQL injection hiba volt a Drupal 7 adatbázis-absztrakciós rétegében, névtelen felhasználók által kihasználható, és a teljes 25-ből 25 pontot kapta. Minden 7.32 alatti Drupal 7 webhely érintett volt.

Az utókövetés tette mérföldkővé. A PSA-2014-003 közölte a tulajdonosokkal, hogy automatizált támadások a bejelentés után órákon belül elkezdték feltörni a nem javított webhelyeket, és hogy minden olyan webhelyet, amely aznap 23:00 UTC-ig, azaz a közzététel után hét órával nem kapott javítást, feltörtnek kell tekinteni. Nem hogy talán feltörték. Feltörték. Figyelmeztetett arra is, hogy a támadók elvihették az összes adatot és hátsó ajtókat telepíthettek, és éppen ez az, ami egy javítási feladatból incidenskezelési feladatot csinál.

Drupalgeddon 2 és 3

Az SA-CORE-2018-002, amely 2018. március 28-án jelent meg, a CVE-2018-7600 volt: távoli kódfuttatási hiba több alrendszeren át a Drupal 7 és a Drupal 8 verziókban, 25-ből 24 ponttal. A Drupal 7.0 verziótól a 7.57 verzióig és a 8.x ágakat a 8.5.0 verzióig érintette, és nyilvános exploitok körülbelül két héten belül követték.

Négy héttel később, 2018. április 25-én érkezett az SA-CORE-2018-004. A CVE-2018-7602 egy másik távoli kódfuttatási hiba volt rokon kódban, 25-ből 20 ponttal, és a közlemény kimondta, hogy már aktívan kihasználják. A tanulság a köztes idő: azok a webhelyek, amelyek márciusban javítottak, majd abbahagyták a figyelést, áprilisban ismét ki voltak téve a támadásnak.

2026 májusa, és ami nem változott

A minta nem történelem. Az SA-CORE-2026-004 2026. május 20-án jelent meg: a CVE-2026-9082 SQL injection hiba a PostgreSQL-en futó webhelyeket érintette, kritikusan súlyosnak minősült 25-ből 23 ponttal, és a 8.9 verziótól a 11.3.9 verzióig minden ágra kiterjedt. Május 22-én 04:30 UTC-kor a közleményt kiegészítették a vadonban észlelt kihasználási kísérletekkel: a közzététel és a megfigyelt támadások között kevesebb mint 48 óra telt el.

Mindebből semmi nem a biztonsági csapatot bírálja. Két nap előzetes figyelmeztetést adott, a bejelentett ablakban szállított, és frissítette a közleményt, amikor a kép megváltozott. A hiba az üzemeltetői oldalon van: nincs begyakorolt út a közleménytől a javított éles rendszerig.

Hol bukik el valójában a Drupal biztonsága a gyakorlatban

A mag kapja a főcímeket, és ez a legkisebb gond. Az általunk auditált webhelyeken a számító megállapítás ritkán egy nem javított magkiadás, mert a magfrissítések megjelennek az adminisztrációs felületen, és valaki észreveszi őket. A kitettség máshol van.

A modulleltár, ami senkinek sincs meg

Egy tipikus közepes méretű Drupal webhely negyven és nyolcvan közötti számú közösségi modult futtat, mindegyiket külön karbantartóval és külön ütemmel. Az a kérdés, amelyre szinte senki nem tud azonnal válaszolni, hogy melyiknek van még aktív karbantartója, melyikre terjed ki a közleményszabályzat, és melyikbe nem érkezett commit két éve. Ennek a listának az elkészítése egy délutánt vesz igénybe.

Az egyedi modul, amiért senki nem felel

A leggyakoribb komoly megállapítás egy olyan egyedi modul, amelyet egy azóta távozott külsős fejlesztő írt. Rendszerint valami integrációszerűt csinál: CRM-adatátadást, egyedi űrlapkezelőt, fizetési visszahívást. Régebbi API-ra íródott, nincsenek tesztjei, és a csapatból senki nem tudja megmondani, mit validál. Az egyedi kód fogalmilag a közleményrendszeren kívül van: semmilyen szerdai e-mail nem fogja megírni, hogy SQL injection van benne, az állapotjelentés pedig mindent naprakésznek mutat. Ugyanarra az átvizsgálási fegyelemre van szüksége, mint bármely más szoftverfejlesztési munkának.

A Drupal alatti technológiai réteg

A Drupal PHP, a PHP verziói pedig saját ütemterv szerint érnek életciklusuk végére. Egy webhely CMS-szinten lehet teljesen javított, és mégis olyan PHP-verzión futhat, amely egy éve nem kap biztonsági javításokat, mert a tárhely soha nem került szóba a karbantartási beszélgetésben. A fájljogosultságokról és tulajdonlásról szóló útmutatás azon az elven nyugszik, hogy a webkiszolgáló nem írhatja azokat a fájlokat, amelyeket futtat, sok webhely mégis írható kódkönyvtárral fut, mert ez egyszerűbbé tett egy telepítési szkriptet.

Hogyan kellene valójában javítani egy Drupal webhelyet

A válasz unalmas, és éppen ezért marad megvalósítatlan. Semmilyen eszköz nem szünteti meg a begyakorolt út szükségességét a közleménytől az éles rendszerig, és egyszer megépíteni olcsóbb, mint az első vészhelyzet.

A Composer munkafolyamat

A Drupal 8-tól kezdve minden Composer-projekt. Frissítse a mag csomagjait a függőségeikkel együtt, majd futtassa az adatbázis-frissítéseket és építse újra a gyorsítótárat:

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

A Drush helyettesíthető az update.php használatával. Nézze meg az állapotjelentést előtte és utána. Nem a parancsok a lényeg, hanem az, hogy előbb máshol fussanak, mint az éles rendszeren.

Olyan staging, ami tényleg másolat

A staging környezet csak akkor segít, ha tükrözi az éles rendszert: ugyanaz a modulkészlet, ugyanaz a PHP-verzió, friss és tisztított adatbázis. Az elavult staging olyan zöld eredményt ad, amely semmit nem jelent, és ez rosszabb, mint ha egyáltalán nem lenne staging, mert magabiztosságot gyárt.

A sorrend: húzza le az éles rendszert stagingre, alkalmazza a frissítést, futtassa az adatbázis-frissítéseket, járja végig azokat az oldalakat és űrlapokat, amelyek a webhelyet üzletileg hasznossá teszik, majd élesítsen. Működő folyamattal ez 45 és 90 perc közötti idő. Nélküle másfél nap.

Az automatizálás és a korlátai

Az automatizált függőségfrissítések a közösségi modulok folyamában segítenek a legtöbbet, azaz a nagy mennyiségű, kis súlyosságú végén. Egy robot, amely modulfrissítésenként egy egyesítési kérést nyit, és mindegyiken lefuttatja a teszteket, a havi kézi átfésülésből átvizsgálási sort csinál. A mag ugyanerre halad: az Automatic Updates munka a Package Manager modulra épül, amely a magban érkezik, de még kísérleti.

A reális időkeret

Egy karbantartott Drupal webhely nagyjából havi fél napba kerül rutin modulfrissítésekben, plusz egytől három óráig terjedő időbe minden vonatkozó biztonsági magkiadásnál. Számoljon tartalékot az évi egy-két kritikusan súlyos kiadásra, amelyet még aznap este el kell végezni. Ez az a szám, amelyet a legtöbb belsős csapat soha nem tervezett be, és ezért csúszik a munka.

Megerősítés a javításon túl

A megerősítés nem helyettesíti a javítást. Azt csökkenti, hány közzétett sebezhetőség használható ki az adott telepítésen, és időt nyer, amikor egy javítás nem mehet ki azonnal. A Drupalra jellemző lépések olcsók és tartósak.

Megbízható gazdagépek és a fájlrendszer

Állítsa be a megbízható gazdagép-mintákat. A Drupal a Symfony trusted host mechanizmusát használja, amelyet a settings.php fájl trusted_host_patterns beállításán keresztül lehet megadni, reguláris kifejezésekkel arra a tartományra, amelyen a webhely válaszol. A bármely más Host fejlécet hordozó kéréseket 400 hibakóddal utasítja el. Enélkül a támadó hamisított fejléccel megmérgezheti a jelszó-visszaállító hivatkozásokat és a gyorsítótárazott abszolút URL-eket.

Használja a privát fájlrendszert mindenre, aminek nem szabad nyilvánosan olvashatónak lennie, és gondoskodjon arról, hogy a PHP ne futhasson a nyilvános fájlkönyvtárban. A Drupal szállít egy .htaccess fájlt, amely Apache alatt tiltja a futtatást, de az nginx alatt nincs egyenértékű, egyszerűen bemásolható fájl, és a szabályt kézzel kell beírni a kiszolgáló konfigurációjába. Azok a webhelyek, amelyek évekkel ezelőtt Apache-ról nginxre költöztek, gyakran csendben elveszítették ezt a védelmet.

Ezután alkalmazza a tulajdonlási modellt: könyvtárak 750 jogosultsággal, kódfájlok 640 jogosultsággal, a fájlkönyvtár csak a webkiszolgáló számára írható, a settings.php pedig csak a tulajdonosa számára olvasható.

Jogosultságok, adminisztrációs útvonalak és az átvizsgálás

Korlátozza az adminisztrációs útvonalakat. Semmi nem indokolja, hogy egy olyan webhely bejelentkezési és adminisztrációs útvonalai, amelynek szerkesztői három irodából dolgoznak, az egész internetről elérhetők legyenek, egy IP-engedélyezési lista vagy egy hitelesítő proxy pedig egy egész támadási osztályt szüntet meg a hitelesítő adatok ellen.

Ezután vizsgálja át a jogosultsági rácsot. Minden telepített modullal nő, és a megállapítás szinte mindig ugyanolyan alakú: egy szerkesztői szerepkör, amely szövegszűrőket adminisztrálhat, vagy egy szerepkör, amely tetszőleges PHP kódot futtathat. Mindkettő távoli kódfuttatássá alakít egy ellopott szerkesztői jelszót, így egy adathalász levélből kiszolgáló-kompromittálódás lesz.

Futtassa a Security Review modult, mielőtt bármi máson vitatkozna. Automatizálja azokat az ellenőrzéseket, amelyek kézzel fárasztóak: fájlrendszer-jogosultságok, nem biztonságos szövegformátumok, PHP vagy JavaScript a tartalomban, hibajelentések kiszivárgása, feltöltési kiterjesztések, sikertelen bejelentkezések, veszélyes jogosultságok és a megbízható gazdagépek konfigurációja. A 3.1.3 verzió, amely 2026 januárjában jelent meg, a Drupal 10.3 és újabb verzióit támogatja a Drupal 11 mellett.

Mit ad egy tűzfal, és mit nem

A webalkalmazás-tűzfal virtuális javítás, és a Drupal Association pontosan így pozicionálja a Drupal Steward szolgáltatást, azt a fizetős szolgáltatást, amelyet a biztonsági csapattal együtt üzemeltet. Hálózati szintű enyhítést alkalmaz bizonyos kritikusan súlyos maghibákra, és védi a webhelyet a közlemény és a telepítés közötti résben. A közzétett ár havi 20 amerikai dollár alatt van egymillió HTTP-kérést kiszolgáló webhelyre, és 100 amerikai dollár alatt tízmillió felett.

A korlátokat maga a projekt mondja ki: nem minden probléma enyhíthető így, és a mechanizmus csak azokra a sebezhetőségekre terjed ki, amelyeket a webkiszolgálóhoz intézett kéréssel használnak ki. A tűzfal semmit nem tesz egy kompromittált adminisztrátori jelszó, egy rosszindulatú modulfrissítés vagy a saját kódjában lévő hiba ellen. Kezelje biztosításként a javítási ablakra, ne pedig okként arra, hogy szélesítse, és ezt az álláspontot képviseljük a WordPress biztonsági megerősítési listánkban is.

Mennyibe kerül egy kompromittálódás, és hogyan néz ki a helyreállítás

Egy Drupal kompromittálódásból való helyreállás nem javítás kérdése. Amint a támadó kódfuttatást ért el, a munkafeltevés az, hogy fájlokat írtak, hitelesítő adatokat vittek el, és állandósító mechanizmust telepítettek, és a biztonsági csapat pontosan ezt mondta a Drupal 7 tulajdonosainak 2014-ben. Egy feltört webhely helyben való takarítása találgatás, remediációnak öltöztetve.

A védhető megközelítés az, hogy a kódbázist verziókövetésből építi újra egy új kiszolgálón, csak a tartalmat és a feltöltött fájlokat állítja vissza ellenőrzés után, minden hitelesítő adatot lecserél, amelyet a webhely tárolt, és megőrzi a kompromittált lemezképet ahelyett, hogy törölné. Ez az utolsó lépés az, amit nyomás alatt kihagynak, pedig ez az egyetlen bizonyíték arra, mi történt.

Az üzleti költség ritkán az újraépítés. Hanem a leállás, az igazságügyi elemzés, az ügyfélkommunikáció és a hatósági eljárás. Egy incidenshelyzetben végzett újraépítés jellemzően 5 000 és 20 000 font közötti mérnöki munka, ami rendszerint a legkisebb tétel a végösszegben.

Az Egyesült Királyság adatvédelmi kötelezettségei

Ha személyes adatokhoz hozzáfértek vagy hozzáférhettek, a brit GDPR órája akkor indul, amikor tudomást szerez róla, nem akkor, amikor befejezi a vizsgálatot. Az ICO adatvédelmi incidensekről szóló útmutatása megköveteli, hogy a bejelentendő incidenst indokolatlan késedelem nélkül, de legkésőbb a tudomásszerzéstől számított 72 órán belül jelentsék, és ha ennél tovább tart, indokolást kell adni. Ha az incidens valószínűsíthetően magas kockázattal jár az érintettek jogaira és szabadságaira, indokolatlan késedelem nélkül az érintetteket is tájékoztatni kell.

Az ICO egyértelmű abban, hogy a hiányos kép nem indok a határidő elmulasztására: jelentse, amit tud, és pótolja később. A kötelező bejelentés elmulasztása akár 8,7 millió font vagy a globális árbevétel 2 százaléka mértékű bírságot vonhat maga után.

Ez az óra az oka annak, hogy az igazságügyi kérdés számít. Az a webhely, amelynek nincsenek naplói és nincs feljegyzése arról, melyik verzió futott, nem tudja megmondani, mely adatokhoz fértek hozzá, ezért a legrosszabb esetet fogja jelenteni. Ez az érv a webhely-biztonsági audit mellett az incidens előtt, nem pedig utána.

Mit tartalmazzon egy Drupal biztonsági szerződés

Az a szerződés, amely csak a frissítések telepítését ígéri, nem éri meg a pénzét, mert a frissítések telepítése a könnyebbik fele. Amiért fizet, az a reagálási út azon a napon, amikor kritikusan súlyos közlemény érkezik, és az azt igazoló eredmény egy próba.

A megfizetni érdemes hatókör lefedi a közleményfolyamok figyelését pontosan az adott modulkészletre, a havi javítási ciklust staginggel, teszteléssel és visszaállítási tervvel, egy megállapodott munkaidőn kívüli reagálási ablakot a kritikusan súlyos magkiadásokra, az elhagyott modulok negyedéves felülvizsgálatát árazott cserékkel, a PHP- és platformverziók követését, valamint az éves konfigurációs felülvizsgálatot.

Az Egyesült Királyságban a csak figyelést nyújtó megállapodások nagyjából havi 250 és 450 font között mozognak. Egy staginget, tesztelést és élesítést is tartalmazó szerződés közepes méretű webhelyre inkább havi 600 és 1 500 font között van, a modulok számával és az egyedi kód mennyiségével arányosan, mert mindkettő eldönti, mennyi regressziós tesztre van szükség ciklusonként. A 600 és 900 font közötti ügynökségi napidíjakkal szemben ennek a sávnak a teteje körülbelül két mérnöknapot vásárol. A Drupal fejlesztői díjakról és szűrésről szóló jegyzetünkben megvannak a számok.

Az ablak bezárása

A Drupal több előzetes figyelmeztetést és több szerkezetet ad, mint szinte bármely összehasonlítható platform. A közlemények menetrend szerint jönnek, a kritikusan súlyos kiadások pedig két nap előzetes jelzéssel érkeznek. Mindez semmit nem ér annak a webhelynek, amelynek két hétbe telik kiadni egy egysoros javítást.

A Mecanik a Drupal javítását és megerősítését a webhely-biztonsági audit és a folyamatos szoftverfejlesztési munka részeként végzi. Az első megbízás rendszerint leltár, nem javítás, mert a legtöbb webhely nem tudja megmondani, mely moduljai támogatottak még. Ha magát a platformot mérlegeli, a 2026-os Drupal webfejlesztési útmutatónk erről szól.

Gyakran ismételt kérdések

Milyen gyakran ad ki a Drupal biztonsági frissítéseket? A közösségi projektek közleményei minden szerdán jelennek meg, a Drupal magnak pedig minden hónap harmadik szerdáján van biztonsági kiadási ablaka, bár az ablak nem garantál kiadást. A kritikusan súlyos magkiadásokat rendszerint körülbelül két nappal korábban közérdekű bejelentés előzi meg, amely megnevezi a dátumot és az idősávot.

Mit jelent a 25-ből 20 pontos Drupal kockázati pontszám? A Drupal minden közleményt 0 és 25 között pontoz a NIST Common Misuse Scoring System alapján, egyesítve a hozzáférés összetettségét, a szükséges hitelesítést, a bizalmasságra és integritásra gyakorolt hatást, az ismert exploit meglétét és az érintett webhelyek számát. Minden 20 és 25 közötti érték kritikusan súlyos, ami azt jelenti, hogy aznap javítani kell.

Biztonságos-e még a Drupal 7 futtatása 2026-ban? Nem. A Drupal 7 életciklusa 2025. január 5-én véget ért, és a Drupal biztonsági csapata nem ad ki több közleményt a magjára, a közösségi moduljaira vagy a sablonjaira, így a hibák egyeztetett javítás nélkül hozhatók nyilvánosságra. A kereskedelmi kiterjesztett támogatás a szolgáltató feltételei szerint meghatározott kódkészletet fed le, ami migráció közben segít, de nem ugyanaz, mint a támogatottság.

Milyen gyorsan használják ki a támadók a Drupal sebezhetőségeket? A legrosszabb esetben órákon belül. A 2014. októberi SQL injection közlemény után a Drupal biztonsági csapata azt mondta a tulajdonosoknak, hogy tekintsenek minden hét órán belül nem javított webhelyet eleve feltörtnek. 2026 májusában egy kritikusan súlyos SQL injection elleni kihasználási kísérleteket a közzététel után kevesebb mint két nappal észleltek a vadonban.

Szükségtelenné teszi-e a webalkalmazás-tűzfal a Drupal javítását? Nem. Az olyan tűzfal, mint a Drupal Steward, virtuális javítást ad bizonyos kritikusan súlyos maghibákra, amelyeket webes kéréssel használnak ki, és ezzel időt nyer a telepítési ablakban. Nem segít ellopott adminisztrátori jelszó, kompromittált modul vagy a saját kódban lévő hiba esetén, tehát a rés kockázatát csökkenti, nem pedig megszünteti.