Az elmúlt héten a szakmában mindenki erről beszélt, így mi is teljesen rápörögtünk a témára. Főleg azután, hogy megírtuk a vibe code megoldásokról szóló korábbi elemzésünket, és láttuk, milyen vakmerően ugranak fejest sokan a kontroll nélküli fejlesztésbe.

A gyorsaság veszélyes illúziója

A modern eszközök elképesztő sebességet adnak a kezedbe. Pár mondattal kész weboldalakat, adatbázis-kapcsolatokat, teljes modulokat hozhatsz létre. Ez a látszólagos egyszerűség azonban veszélyes illúziót szül. Azt a hitet kelti a laikusokban, hogy bárki szoftverfejlesztővé válhat anélkül, hogy értené a háttérben futó folyamatokat.

Mi történt pontosan? A PHP2Shell röviden

A valóság azonnal visszavág, amikor beüt egy váratlan hiba. A közelmúltban napvilágot látott súlyos PHP sebezhetőség pontosan erre a veszélyre mutatott rá. A „PHP2Shell” néven elhíresült incidens két kritikus távoli kódfuttatási hibát takar (CVE-2026-109618 és CVE-2026-109619), amelyek részletei október 20-án, még a koordinált nyilvánosságra hozatal és a javítások kiadása előtt kiszivárogtak az internetre. Mindkét hiba 9,2-es CVSS pontszámot kapott, és hitelesítés nélküli távoli kódfuttatást tehet lehetővé. huntresseuropa

A kitettség óriási. A Patchstack szerint minden webes kéréseket kiszolgáló PHP-telepítés veszélyben van, így a WordPress, Drupal, Magento, Joomla vagy Laravel alapú oldalak is, ha sebezhető PHP verzión futnak. A Palo Alto Networks telemetriája több mint 22,6 millió, potenciálisan sebezhető példányt azonosított. A támadók sem tétlenkedtek: a kiszivárgott technikai részletek nyomán aktív kihasználási kísérleteket jeleztek, a Unit 42 kutatói pedig október 25-én egy európai kormányzati szerv elleni támadásról számoltak be, amelyet ezekhez a sebezhetőségekhez kötöttek. Major security alert: PHP vulnerable to critical RCE, attacks ongoing – Patchstack +3

Egy ilyen hiba nem a felületen jelenik meg. A látogató számára a weboldal tökéletesen működik, a gombok kattinthatók, az adatok betöltődnek. A háttérben mégis nyitva áll az ajtó az illetéktelenek előtt – a kutatók azt is demonstrálták, hogy a PHP folyamatok memóriája kiolvasható, amelyben jelszavak, tokenek és API-kulcsok is lehetnek. patchstack

A működő kód még nem biztonságos kód

Itt mutatkozik meg a képzetlen kódolók igazi kockázata. Amikor egy hozzáértés nélküli alkotó promptok segítségével rak össze egy alkalmazást, kizárólag a működésre koncentrál. Ha a funkció teszi a dolgát, a feladatot lezártnak tekinti. Nem vizsgálja meg a használt függvények biztonsági előzményeit. Nem ellenőrzi, hogy a beépített kód milyen verziójú környezetet feltételez. Nem ismeri a sanitization elvét, és fogalma sincs arról, hogyan juthat be kártékony utasítás a beviteli mezőkön keresztül.

Persze a biztonsági rés a tökéletesen felépített rendszereken is jelentkezett. A hibákat felfedező Wiz Research szerint a PHP 5.4-ig visszamenőleg minden verziót érint legalább az egyik probléma, és már egy egyszerű „Hello World” alkalmazás is támadható sebezhető PHP verzión. A különbség az, hogy ott a fejlesztők ezt azonnal kezelték, mert felmérték a kockázatot. A nem hozzáértő „vibe coder” pedig vígan használja a szoftverét, és fel sem merül benne, hogy bármit kellene kezdenie a szituációval… patchstack

A mesterséges intelligencia nem pótolja a hiányzó szaktudást

Az algoritmus mintákból építkezik. Ha a betanított adathalmazban elavult vagy hibás megközelítések szerepelnek, az AI gondolkodás nélkül átveszi azokat. Mivel a tanítóadatok minden korszak kódját tartalmazzák, az eszközök elavult függvényeket és mintákat is javasolnak, kutatások szerint pedig gyakran ismert sebezhetőségű, régi könyvtárakat ajánlanak. Olyan PHP megoldást javasolhat, amely öt évvel ezelőtt még elterjedt volt, ma viszont azonnali behatolási pontot kínál a támadóknak. appsecsantapaloaltonetworks

A számok is ezt igazolják. A Veracode 2026-os GenAI Code Security Reportja szerint a több mint 100 vizsgált modell átlagos biztonsági megfelelési aránya 56 százalék, ami gyakorlatilag változatlan az előző évhez képest. A modellek szinte 100 százalékban fordítható kódot írnak, biztonsági iránymutatás nélkül mégis közel 44 százalékban elbuknak a biztonsági teszteken. Ennél is beszédesebb egy Stanford-kutatás: az AI-asszisztenst használó fejlesztők nagyobb valószínűséggel vittek be sebezhetőséget a kódba, ugyanakkor magabiztosabbak voltak abban, hogy a kódjuk biztonságos. Veracode Finds AI-Generated Code Security Has Barely Improved Since Last Year +2

A hozzá nem értő felhasználó ezt nem látja át. Nem olvassa a biztonsági értesítőket, nem követi a hibajavító csomagokat, és nem tudja felmérni a választott könyvtárak kitettségét.

A szoftverfejlesztés nem gépelés

A valódi érték a felelős tervezésben és a védelmi rétegek kialakításában rejlik. Ha a csapatod nem rendelkezik mély mérnöki alapokkal, a terméked időzített bombává válik. A PHP incidens világosan bebizonyította, hogy a látszólag működő kód és a biztonságos kód között szakadék tátong.

Hogyan védheted meg az üzletedet ettől a csapdától?

Első lépés: felejtsd el a vak bizalmat

Minden egyes sort, amit az eszközök generálnak, szigorú ellenőrzésnek kell alávetned. Egy német kutatás is arra jutott, hogy a biztonságos kód előállításához AI-asszisztensek mellett is szükség van szakmai, különösen biztonsági hozzáértésre, és nem elég alapos felülvizsgálat nélkül megbízni a generált kódban. Ha nincs a csapatodban olyan szakember, aki képes értelmezni a beépített logikát és a rendszerszintű hívásokat, a kód nem kerülhet éles szerverre. arxiv

Második lépés: alkalmazz modern biztonsági irányelveket

Tiltsd le a veszélyes függvényeket a futtatókörnyezetben – az OWASP PHP konfigurációs ajánlása szerint minden olyan veszélyes PHP függvényt érdemes letiltani, amelyet nem használsz. Használj szigorú típuskezelést és zárt adatbázis-kezelő interfészeket: az OWASP elsődleges védekezésként a paraméterezett lekérdezéseket (prepared statements) javasolja, amelyeknél előbb rögzíted a teljes SQL kódot, és csak utána adod át a paramétereket. Építs a rendszerbe behatolásvédelmi eszközöket, amelyek azonnal jelzik a szokatlan paramétereket. githubowasp

Harmadik lépés: állíts fel folyamatos frissítési és tesztelési protokollt

A technológia világa gyorsan változik. Egy ma biztonságosnak tartott komponens holnapra sebezhetővé válhat. A PHP2Shell esetében a CISA azt kérte a szervezetektől, hogy azonnal frissítsenek a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra. Aki nem követi a gyártói közleményeket, az ilyenkor napokig vagy hetekig nyitva hagyja a kaput. Frissítsd rendszeresen a szerverkörnyezetet, mindig a PHP biztonsági támogatással rendelkező verzióját futtasd, és végezz rendszeres biztonsági auditokat. cisaowasp

Összegzés

Kijelenthetjük, hogy a sebesség értékes előny az üzleti életben, de a megbízhatóság nélkülözhetetlen alap. Használd az intelligens segédeszközöket az ötleteid felgyorsítására, de a rendszer stabilitását bízd képzett mérnökökre. A valódi biztonság ott kezdődik, ahol a felületes megoldások véget érnek. Ma már nem az a kérdés, hogy lesz-e következő kritikus sebezhetőség, hanem az, hogy lesz-e valaki a csapatodban, aki időben észreveszi és kezeli.

És ha mégis Vibe Code. akkor legalább ellenőrizd itt: https://vibecodeaudit.hu/ (Köszi, srácok! Hiánypótló! 🫶 )

Források

• CERT-EU – Critical Vulnerabilities in PHP (Security Advisory 2026-018)
• CISA – Critical Vulnerabilities in PHP Require Immediate Patching
• Huntress – Rapid Response: php2shell
• Patchstack – Major security alert: PHP vulnerable to critical RCE
• Unit 42 (Palo Alto Networks) – Threat Brief: CVE-2026-109618, CVE-2026-109619
• Recorded Future – PHP2Shell Exploitation
• SD Times – Veracode 2026 GenAI Code Security Report
• Götz & Schaad – „You still have to study” – On the Security of LLM generated code (arXiv)
• Palo Alto Networks – AI security debt
• AppSec Santa – AI-generated code security
• OWASP – PHP Configuration Cheat Sheet
• OWASP – SQL Injection Prevention Cheat Sheet

Bővebb információkért keresse kollégánkat:

Bagi Tamás üzletfejlesztési vezető
nextentservices@nextent.hu