A WordPress bejelentette, hogy minden egyes bővítmény-kiadásnál automatizált biztonsági ellenőrzést indít, még mielőtt a WordPress.org frissítési API-n keresztül terjesztenék. Így még időben elemezhetik a lehetséges biztonsági problémákat, és kiszűrhetik a kockázatos frissítéseket.

„Az új bővítményeket átnézzük, mielőtt bekerülnek a könyvtárba, de a frissítések ezután folyamatosan érkeznek” – mondta David Perez, a WordPress Official Plugin Repository Team egyik vezetője nyilatkozatában. „Egy bővítmény ma lehet biztonságos, de egy későbbi kiadásban sebezhetőséget vagy rosszindulatú kódot vezethetnek be.”

A WordPress szerint az, hogy a kiadás commitja és a bővítmény felhasználókhoz eljutó kiadása között nem volt „következetes ellenőrzési lépés”, megnyithatta az utat a rosszindulatú támadások előtt.

A tartalomkezelő rendszer (CMS) platform közölte, hogy az automatizált ellenőrzés egy hátsó kaput szúrt ki, amelyet egy olyan bővítmény egyik kiadásába commitoltak, amelynek nagyjából 20 000 aktív telepítése volt 2026. július 28-án. Mivel a kiadás még a cooldown időszakban volt, a kompromittált verziót végül nem terjesztették a WordPress.org frissítési API-n keresztül.

A bővítményt 26 perccel azután zárták le letöltésre, hogy a Plugins Team értesítést kapott a frissítésről a WordPress-biztonsági cég, a Wordfence részéről. A WordPress nem hozta nyilvánosságra a bővítmény nevét.

2026. június 5. óta minden WordPress-bővítmény és -téma cooldown időszakon megy keresztül, mielőtt automatikus frissítésként terjesztenék. Ez a Protect The Shire nevű új biztonsági kezdeményezés része. A cél, hogy némi késleltetést vigyenek a folyamatba, és a rosszindulatú frissítések ne juthassanak el azonnal a felhasználókhoz. A cooldown időszak jelenleg hat óra, az eredeti 24 óráról csökkentették le.

A mostani lépés egy újabb kritikus biztonsági rést zárna be: ha egy bővítmény- vagy téma-kiadás magas kockázati pontszámot kap, a rendszernek automatikusan le kell állítania a terjesztést, a Plugins Team beavatkozása nélkül. A teljes folyamat a következő lépésekből áll:

• A cooldown időszak alatt minden kiadás változásait a WordPress.org-on mesterséges intelligencia (AI) modellek elemzik, a Jetpack Scan vizsgálatával együtt.
• Az eredményeket összevetik, majd egy biztonsági pontszámmá kombinálják: minél magasabb a pontszám, annál nagyobb a lehetséges kockázat.
• A magas kockázati pontszámú kiadásokat automatikusan blokkolják, amint az ellenőrzés befejeződik, a küszöbérték alatti kiadások pedig a szokásos folyamat szerint haladnak tovább.
• A bővítmény commit joggal rendelkező fejlesztői e-mailben kapják meg az eredményeket. E-mailt csak akkor küldenek, ha egy bővítményt blokkoltak.

Fontos kiemelni, hogy a magas kockázati pontszám önmagában nem jelent feltétlenül rosszindulatú szándékot. A rendszer azokat a biztonsági hibákat is figyelembe veszi, amelyek véletlenül kerültek a kódba, ugyanúgy, mint a szándékos kártevő kódot.

Egy későbbi hozzászólásában Perez részletesebben is elmagyarázta, hogy a biztonsági ellenőrzés „ugyanazokat a sebezhetőség-típusokat keresi, mint bármelyik biztonsági audit”, és arra biztatta a fejlesztőket, hogy tartsák be a WordPress Coding Standards előírásait, valamint használják a PHP_CodeSniffer (PHPCS) szabályait a kód ellenőrzésére és a kódminőség biztosítására. A WooCommerce-bővítményeket kiadó fejlesztőknek a Quality Insights Toolkit (QIT) tesztplatform használatát javasolják.

Vannak más minták is, amelyek szintén növelhetik a kockázati pontszámot:

• REST, AJAX vagy admin-post végpontok jogosultság-ellenőrzés nélkül (egy nonce önmagában nem jelent jogosultságkezelést)
• $wpdb->prepare() nélkül összeállított lekérdezések
• Kérésből származó adatokból épített fájlútvonalak, feltöltések, törlések vagy include-ok
• unserialize() meghívása kérésből érkező adatokon vagy távoli válaszon
• Olyan options, user meta vagy beállítások írása, amelyek olyan végpontokon keresztül érhetők el, amelyeket előfizetők vagy nem hitelesített felhasználók is elérnek
• Futásidőben letöltött vagy értékelt kód, illetve elrejtett vagy „becsomagolt” kód

Ha egy kiadást blokkolnak, a fejlesztő csak úgy tudja feloldatni a korlátozást, ha átnézi a találatokat, kijavítja a problémákat, és új kiadást ad ki. Ha az új kiadás pontszáma a magas kockázati küszöb alatt marad, a szokásos cooldown folyamat szerint halad tovább.

„Ha egy találat tévesnek tűnik, a szerzők felvehetik a kapcsolatot a Plugins Team csapatával” – mondta Perez. „Fontos megérteni, hogy a csapat nagyon sok ellenőrzést kezel, ezért szinte mindig gyorsabb egy javított kiadást publikálni, mint megvárni egy kézi felülvizsgálatot a fellebbezésre.”