Mesterséges intelligencia, magyarul.
Az eredeti közleményekből.

Három szoftverkomponens miatt sürgető kérdés lett: „Védettek vagyunk?”

2026. október 30. 21:21Forrás: JFrog
Három szoftverkomponens miatt sürgető kérdés lett: „Védettek vagyunk?”
Kép: JFrog

A Curl, a PHP és a LiteLLM körüli biztonsági események ismét ráirányították a figyelmet arra, hogy a vállalatoknak gyorsan kell megválaszolniuk, érintettek-e. A JFrog szerint ehhez a szoftverfejlesztési környezet teljes átláthatóságára van szükség.

A lényeg röviden
  • A JFrog szerint a libcurl magas súlyosságú hibái fejlesztési és telepítési környezeteket érinthetnek.
  • A LiteLLM 1.107.0 verzióját eltávolították a PyPI-ról, de október 21-én több órán át letölthető volt.
  • Két kritikus PHP-hibát PHP2Shell néven ismertettek, a CISA azonnali javítást sürgetett.
  • A biztonsági vezetőknek a komponensek használatát, az üzleti hatást és a jelentési kötelezettségeket is fel kell mérniük.
  • A JFrog Security Maturity Assessment 11 területen vizsgálja a szoftverellátási lánc biztonsági érettségét.

A Curl sérülékenysége rendszerszintű kockázatot jelenthet

A JFrog szerint a Curl és az alapjául szolgáló libcurl a vállalati szoftverkörnyezetek széles körében jelen van. Backend mikroszolgáltatások, konténerfuttatók, automatizált CI/CD-folyamatok és shell-szkriptek is használhatják, ezért egy libcurl-probléma az internetes adatátvitel alapjait érintheti.

A 2026 októberében nyilvánosságra hozott, magas súlyosságú hibák között szerepel egy HTTP/2 használat utáni memóriakezelési sérülékenység, a CVE-2026-92392. A JFrog leírása szerint egy feltöltést kezelő rosszindulatú upstream szerver bizonyos körülmények között megrongálhatja a kliens memóriáját, távoli kódfuttatást válthat ki, vagy összeomlaszthatja az átvitelt kezdeményező gépen futó alkalmazást.

A libcurl HTTPS-címeknél alapértelmezés szerint HTTP/2-t egyeztet, ha azt a szerver támogatja. Mivel az alkalmazások ritkán vizsgálják részletesen a háttérben működő libcurl viselkedését, a javított verzióra nem frissített fejlesztési környezetek és telepítési folyamatok továbbra is külső, ellenséges végpontoknak lehetnek kitéve.

A LiteLLM csomag rövid ideig elérhető volt a PyPI-n

A JFrog Security Research a LiteLLM problémáját a beszámoló szerint két órán belül észlelte. Az érintett, 1.107.0 verziójú LiteLLM-csomagot azóta eltávolították a PyPI-ról, a karbantartók pedig jelentést is közzétettek.

A csomagot 2026. október 21-én 11:39 és 13:23 UTC között tölthették le szoftverfejlesztők, ügynökalapú rendszerek vagy buildrendszerek. Az érintett Docker-lemezképek 14:20 UTC-ig maradtak elérhetők. A JFrog hangsúlyozza, hogy egy kompromittált csomag vagy sérülékeny komponens bekerülése az informatikai környezetbe a fejlesztőkön és a biztonsági csapaton túl az IT-üzemeltetést és később az auditorokat is érintheti.

A PHP2Shell miatt azonnali javítást sürgettek

A PHP esetében két kritikus súlyosságú, a PHP magját érintő sérülékenységet hoztak nyilvánosságra: a CVE-2026-109618 és a CVE-2026-109619 azonosítójú hibákat. A nyilvános biztonsági tájékoztatók szerint ezek hitelesítés nélküli távoli kódfuttatást és Heartbleedhez hasonló memóriakiszivárgást tehetnek lehetővé magában a PHP-ban, az arra épülő alkalmazástól függetlenül.

A hibákat a híroldalak PHP2Shell néven ismertették, a CISA pedig riasztást adott ki, amelyben az érintett szervezetek azonnali javítására szólított fel. A JFrog példaként a CNBC-t és a BBC-t is megemlíti.

A CISO-knak a teljes működési láncot kell látniuk

A JFrog szerint a „Védettek vagyunk?” kérdés megválaszolásakor a biztonsági vezetőknek azt kell tisztázniuk, valódi fenyegetésről van-e szó, hol használják az érintett komponenst, és mekkora lehet az üzleti hatás. A vizsgálat része az is, hogy fennáll-e jelentési vagy közzétételi kötelezettség például az amerikai SEC, a PCI DSS vagy a termékgyártókra vonatkozó EU Cyber Resilience Act alapján.

A vállalat szerint a gyors és megbízható válaszhoz a szervezet eszközeinek, munkatársainak, folyamatainak, munkafolyamatainak és függőségeinek láthatósága szükséges. Ez kiterjedhet a fejlesztők munkaállomásaira, az ügynökalapú folyamatokra és az AI-kódoló ügynökök által közvetlenül végzett műveletekre is.

A JFrog saját Security Maturity Assessment felmérése 11 területen vizsgálja a szoftverellátási lánc biztonsági programjának érettségét. A cég szerint a felmérés segíthet az erősségek, gyengeségek, lehetőségek és kockázatok feltárásában. A JFrog külön kiemeli, hogy az eszközök önmagukban nem elegendők, a megfelelő munkatársak és folyamatok nélkül nem biztosítják a vállalat védelmét.

Kövesd az AI Hírek oldalát a FacebookonA legfontosabb MI-hírek magyarul, rögtön a megjelenés után a hírfolyamodban.Követem

Kapcsolódó hírek

Kilenc vállalat kapta meg első alkalommal a JFrog szoftverellátási díjait
Biztonság és etika2026. október 28. 15:30

Kilenc vállalat kapta meg első alkalommal a JFrog szoftverellátási díjait

A JFrog kilenc vállalatot ismert el első Software Supply Chain Excellence Awards díjaival. A nyertesek az amerikai kontinensről, Európából és az ázsiai csendes-óceáni…

Az AI elárasztja a CVE-rendszert hamis és túlértékelt hibákkal
Biztonság és etika2026. október 27. 15:00

Az AI elárasztja a CVE-rendszert hamis és túlértékelt hibákkal

A generatív AI felgyorsította a sérülékenységek felfedezését, közben azonban tömegével készülnek alacsony minőségű vagy teljesen kitalált jelentések. A JFrog szerint ez…

A hagyományos biztonsági szkennerek nem látják az AI-eszközök szándékait
Biztonság és etika2026. október 21. 08:18

A hagyományos biztonsági szkennerek nem látják az AI-eszközök szándékait

A hagyományos alkalmazásbiztonsági eszközök könnyen átsiklhatnak az AI-ügynököknek szánt készségek, bővítmények és csomagok veszélyes utasításai felett. A JFrog olyan…