Újabb súlyos szoftverellátási lánc elleni támadás rázta meg az AI- és kriptoszektort: támadók rosszindulatú kódot juttattak a Mistral AI hivatalos Python-csomagjának egyik PyPI-verziójába. A támadás azért különösen veszélyes, mert nem a végfelhasználókat próbálta közvetlenül átverni, hanem azokat a fejlesztői eszközöket mérgezte meg, amelyekre kriptós projektek, kereskedési botok, on-chain elemzőrendszerek és decentralizált alkalmazások is támaszkodhatnak.
Mi történt a Mistral AI csomagjával?
A Microsoft Threat Intelligence 2026. május 12-én jelezte, hogy vizsgálja a mistralai nevű PyPI-csomag 2.4.6-os verziójának kompromittálását. A jelentések szerint a támadók rosszindulatú kódot injektáltak a csomag egyik inicializáló fájljába, amely Linux rendszereken már importáláskor lefutott. Ez azt jelenti, hogy a fertőzéshez nem feltétlenül kellett külön elindítani egy gyanús programot: elég lehetett, ha egy fejlesztői projekt betöltötte a csomagot.
A GitHubon közzétett hivatalos biztonsági figyelmeztetés szerint a mistralai==2.4.6 verzió rosszindulatú droppert tartalmazott, amely Linuxon importáláskor aktiválódott. A Mistral AI advisories oldala azt is jelzi, hogy a probléma a Mistral SDK-csomagokat érintő TanStack-eredetű ellátási lánc támadáshoz kapcsolódik.
A „dropper” olyan rosszindulatú kódrészlet, amelynek elsődleges célja nem feltétlenül maga a lopás vagy rombolás, hanem egy második fázisú kártevő letöltése és futtatása. Egyszerű példával: mintha valaki nem magát a betörőt csempészné be egy házba, hanem egy kulcsot, amely később beengedi a valódi támadót.
A Mistral AI hivatalos GitHub security advisoryja szerint a 2.4.6-os PyPI-verzióhoz nem tartozott legitim v2.4.6 tag, commit vagy rendes release workflow, miközben a korábbi legitim verzió a 2.4.5 volt. Ez különösen fontos részlet: nem egyszerű programozási hibáról volt szó, hanem olyan csomagkiadásról, amely megkerülte a megszokott kiadási folyamatot.
Hogyan működött a rosszindulatú kód?
A Microsoft és más biztonsági források szerint a kompromittált csomag Linux rendszereken importáláskor letöltött egy másodlagos payloadot egy távoli IP-címről, majd azt a /tmp/transformers.pyz útvonalon mentette és háttérfolyamatként futtatta. A fájlnév megtévesztő, mert a „transformers” név könnyen emlékeztethet a Hugging Face népszerű AI-könyvtárára, amelyet rengeteg fejlesztő ismer és használ.
Ez a névválasztás pszichológiai és technikai szempontból is ügyes. Egy fejlesztői gépen a „transformers” szó nem feltétlenül kelt gyanút, főleg AI-projektekben. Ha valaki Mistral AI SDK-t, nagy nyelvi modelleket vagy AI-agenteket használ, egy ilyen fájlnév első ránézésre akár természetesnek is tűnhet.
A jelentések alapján a támadás fő célja hitelesítő adatok, tokenek, API-kulcsok és fejlesztői titkok megszerzése lehetett. Ezek közé tartozhatnak GitHub-tokenek, felhőszolgáltatói kulcsok, CI/CD-rendszerek titkai, npm- vagy PyPI-publikálási jogosultságok, valamint egyes esetekben kriptotárcákhoz vagy blockchain-infrastruktúrához kapcsolódó érzékeny adatok is.
A „token” itt nem kriptotoken jelentésben szerepel, hanem hozzáférési kulcsként. Például egy GitHub access token olyan, mint egy digitális belépőkártya: ha támadóhoz kerül, jogosulatlanul hozzáférhet privát kódtárakhoz, módosíthat release-folyamatokat, vagy akár újabb fertőzött csomagokat publikálhat.
Mi az a supply chain attack?
A supply chain attack, magyarul ellátási lánc elleni támadás, nem közvetlenül a végső célpontot támadja, hanem azt az eszközt, könyvtárat, szolgáltatót vagy fejlesztői infrastruktúrát, amelyben a célpont megbízik.
A hagyományos támadás így néz ki: a támadó megpróbál betörni egy cég szerverére.
Az ellátási lánc elleni támadás viszont így: a támadó megfertőz egy népszerű csomagot, amelyet aztán sok cég önként letölt és futtat.
Ez a különbség óriási. Egyetlen kompromittált nyílt forráskódú csomag több ezer vagy akár több millió fejlesztői környezetbe is bekerülhet. A modern szoftverfejlesztésben egy átlagos alkalmazás gyakran több tucat, több száz vagy akár több ezer külső függőséget használ. Ezek többségét a fejlesztők nem olvassák végig kézzel minden frissítés előtt.
A PyPI a Python ökoszisztéma egyik legfontosabb csomagtárolója, míg az npm a JavaScript/Node.js világ központi csomagregisztere. Ha ezekben a rendszerekben egy hivatalosnak tűnő csomag rosszindulatú verziója jelenik meg, az gyorsan óriási kockázattá válhat.
A Shai-Hulud-kampány nagyobb, mint egyetlen Mistral AI-incidens
A Mistral AI-eset nem elszigetelt támadásként jelent meg. Több biztonsági kutató és iparági forrás szerint az incidens a „Mini Shai-Hulud” néven emlegetett szélesebb kampány része, amely npm- és PyPI-csomagokat is érintett. A jelentések több mint 170 érintett csomagról és több száz rosszindulatú verzióról szólnak, köztük TanStack, UiPath, OpenSearch, Mistral AI és Guardrails AI projektekhez kapcsolódó csomagokkal.
A Snyk elemzése szerint a TanStack esetében 2026. május 11-én 84 rosszindulatú npm package artifact jelent meg 42 @tanstack névtérhez tartozó csomagban, és ezek nem egyszerűen ellopott felhasználói jelszóval kerültek ki, hanem legitim release pipeline-on keresztül publikálódtak. Ez azért különösen riasztó, mert a csomagok kívülről hitelesnek tűnhettek.
Ez a részlet a kriptoszektornak is kulcsfontosságú tanulság: a „hivatalos forrásból jött” ma már nem azonos azzal, hogy „biztonságos”. Ha egy támadó a kiadási folyamatot, a CI/CD pipeline-t vagy a publikálási jogosultságokat kompromittálja, akkor a fertőzött kód a megszokott, megbízhatónak hitt csatornán keresztül érkezik.
A CI/CD a continuous integration és continuous deployment rövidítése. Ez az a rendszer, amely automatikusan teszteli, építi és kiadja a szoftvereket. Ha ezt a láncot megtámadják, a támadó nem a kész alkalmazást piszkálja meg utólag, hanem már a gyártósorra csempészi be a mérgezett alkatrészt.
Miért veszélyes ez különösen a kriptós fejlesztőknek?
A kriptoiparban a fejlesztői kulcsok és infrastruktúrák gyakran közvetlen pénzügyi kockázatot hordoznak. Egy hagyományos webes cégnél egy ellopott API-kulcs adatvédelmi vagy szolgáltatáskiesési problémát okozhat. Egy kriptós projektnél viszont ugyanilyen incidens akár tokenkibocsátást, smart contract deployt, treasury-hozzáférést vagy wallet-infrastruktúrát is érinthet.
A Mistral AI és más AI-eszközök a blockchain-szektorban többféle módon jelenhetnek meg:
Fejlesztők használhatják őket smart contractok előzetes elemzésére. Egy DeFi-csapat AI-t alkalmazhat hibás kódrészletek keresésére. Kereskedési botok fejlesztői nyelvi modelleket használhatnak hírek, közösségi média posztok vagy on-chain adatok értelmezésére. Elemzőcégek AI-agenteket építhetnek wallet-mozgások, tokenáramlások vagy gyanús tranzakciós mintázatok azonosítására.
Ha egy ilyen fejlesztői környezet fertőződik, a támadó hozzáférhet például:
GitHub-repositorykhoz, ahol okosszerződés-kódok vannak;
felhőkulcsokhoz, amelyek node-infrastruktúrát vagy indexelő rendszereket vezérelnek;
CI/CD titkokhoz, amelyek automatikus deployokat indíthatnak;
kriptotárcákhoz kapcsolódó konfigurációkhoz;
belső API-khoz, amelyek trading botokat vagy market maker rendszereket irányítanak.
Egy konkrét példa: ha egy DeFi-projekt backendje automatikusan deployol egy új smart contract verziót, és a támadó hozzáfér a pipeline-hoz, elméletileg rosszindulatú kódot is bejuttathat a kiadási folyamatba. Még ha a szerződés on-chain auditált is, a környező infrastruktúra kompromittálása így is veszélyes lehet.
Nem csak walletlopásról van szó
A kriptós közösség gyakran minden kiberincidenst walletlopási szemüvegen keresztül értelmez. Ez érthető, de ebben az esetben a kép tágabb. Egy ellátási lánc támadásnál a támadó számára nemcsak a seed phrase vagy privát kulcs értékes, hanem minden olyan hozzáférés, amellyel később további támadásokat indíthat.
Egy GitHub-token például lehetővé teheti egy népszerű open-source könyvtár módosítását. Egy npm-token új csomagverzió publikálását engedheti. Egy felhőszolgáltatói kulcs hozzáférést adhat adatbázisokhoz, szerverekhez vagy logokhoz. Egy CI/CD secret segítségével a támadó új buildet indíthat, vagy módosíthatja a kiadási folyamatot.
A kriptóban különösen veszélyes az a pont, ahol a szoftverfejlesztés és a pénzügyi infrastruktúra összeér. Egy centralized exchange, wallet-szolgáltató, DeFi-protokoll vagy blockchain analytics cég esetében a fejlesztői környezet nem pusztán technikai háttér, hanem a pénzügyi bizalom egyik alapja.
Miért pont az AI- és fejlesztői csomagok kerülnek célkeresztbe?
Az AI-fejlesztői ökoszisztéma az elmúlt években rendkívül gyorsan nőtt. A fejlesztők gyakran próbálnak ki új modelleket, SDK-kat, agent frameworköket, data pipeline-okat és API-klienseket. Ez a gyorsaság innovációt hoz, de biztonsági oldalon növeli a kockázatot.
Egy AI-projektben természetes, hogy valaki gyakran futtat:
pip install parancsokat;
új könyvtárakat;
modellkliens SDK-kat;
kísérleti frameworköket;
automatikus frissítéseket.
A támadók pontosan ezt használják ki. A fejlesztő bízik a népszerű névben, a csomagregiszterben és a megszokott telepítési folyamatban. Egy kompromittált csomag pedig csendben lefuthat a háttérben.
A Mistral AI neve azért is érzékeny ebben a történetben, mert a vállalat az európai AI-szektor egyik fontos szereplője, és modelljeit, SDK-it sok fejlesztő használja modern AI-alkalmazásokhoz. Ez nem azt jelenti, hogy a Mistral modelljei önmagukban veszélyesek lennének, hanem azt, hogy a népszerű fejlesztői eszközök kiemelt célponttá váltak.
Mit tegyen az, aki használta a mistralai 2.4.6-ot?
A legfontosabb: aki Linux rendszeren telepítette vagy importálta a mistralai==2.4.6 verziót, annak az adott gépet potenciálisan kompromittáltnak kell tekintenie. A hivatalos advisory szerint a 2.4.6-os verzió rosszindulatú droppert tartalmazott, a PyPI-projekt pedig karanténba került.
A javasolt lépések:
Ellenőrizni kell, hogy bármely projektben szerepelt-e a mistralai==2.4.6 verzió. Ezt meg lehet nézni például requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, Dockerfile vagy CI-konfigurációk alapján.
Vizsgálni kell a /tmp/transformers.pyz fájl jelenlétét és minden gyanús ideiglenes fájlt. A Microsoft által jelzett támadási lánc éppen ezt az útvonalat használta a második fázisú payload mentésére.
Rotálni kell minden lehetségesen érintett titkot: GitHub-tokeneket, cloud API-kulcsokat, npm/PyPI tokeneket, CI/CD secreteket, adatbázisjelszavakat, wallet-infrastruktúrához kapcsolódó kulcsokat és belső API-hozzáféréseket.
Érdemes az érintett gépet nem pusztán „kitakarítani”, hanem újratelepíteni vagy tiszta image-ből újraépíteni. Egy fejlesztői gépen túl sok rejtett titok és konfiguráció lehet ahhoz, hogy kézi ellenőrzéssel teljes bizonyosságot lehessen szerezni.
A szervezeteknek auditálniuk kell a commitokat, release-eket és build pipeline-okat az érintett időszakban. A támadó célja nem feltétlenül azonnali pénzlopás volt; lehet, hogy későbbi hozzáférést, backdoort vagy további terjedési pontot keresett.
Mit tanulhat ebből a kriptopiac?
A kriptopiac gyakran az árfolyamokra figyel: Bitcoin, Ethereum, Solana, token unlockok, ETF-beáramlások, kamatpálya, makroadatok. De az infrastruktúra-biztonság legalább ennyire fontos. Egy blockchain-projekt értékét nemcsak a tokenomika, a TVL vagy a közösség határozza meg, hanem az is, hogy mennyire biztonságos a fejlesztési és kiadási folyamata.
Egy DeFi-protokollnál a befektetők általában megkérdezik: auditálták-e a smart contractot?
Ma már azt is meg kell kérdezni: auditálják-e a függőségeket? Van-e dependency pinning? Használnak-e software bill of materials, azaz SBOM rendszert? Rotálják-e a secreteket? Van-e többfaktoros hitelesítés? El vannak-e választva a fejlesztői, teszt- és éles környezetek?
A dependency pinning azt jelenti, hogy a projekt nem egyszerűen azt mondja: „telepítsd a legújabb verziót”, hanem pontos verziót rögzít. Ez csökkenti annak esélyét, hogy egy frissen feltöltött rosszindulatú csomag automatikusan bekerüljön a rendszerbe.
Az SBOM, vagy software bill of materials, lényegében egy szoftverösszetevő-lista. Olyan, mint egy élelmiszercímke: megmutatja, milyen alapanyagokból áll az alkalmazás. Ha később kiderül, hogy az egyik összetevő fertőzött, gyorsabban meg lehet találni, mely rendszereket érinti.
Miért fontos ez a befektetőknek is?
Első pillantásra ez fejlesztői hírnek tűnhet, de befektetői szempontból is jelentős. Egy kriptós projekt technikai kompromittálása árfolyamzuhanást, likviditási válságot, reputációs veszteséget vagy akár protokollszintű pánikot is okozhat.
A befektetők gyakran nézik a piaci kapitalizációt, a forgalmat, a tokenelosztást és a roadmapet. De a kiberbiztonsági érettség legalább ilyen fontos kockázati tényező. Egy projekt lehet innovatív, gyors és népszerű, de ha a fejlesztői lánca gyenge, akkor egyetlen kompromittált függőség is súlyos károkat okozhat.
Érdemes figyelni arra, hogy egy projekt:
közzétesz-e biztonsági auditokat;
van-e bug bounty programja;
nyíltan kommunikál-e incidensekről;
használ-e több aláírásos treasury-kezelést;
különválasztja-e az adminisztrátori jogosultságokat;
rendelkezik-e vészleállítási vagy kockázatkezelési mechanizmussal.
Ezek nem garantálják a teljes biztonságot, de csökkentik az egyetlen hibapontból eredő katasztrófa esélyét.
A „megbízható csomag” illúziója
A mostani eset egyik legfontosabb tanulsága, hogy a szoftverbiztonságban a bizalom nem lehet vak. Egy hivatalos csomag, egy ismert projekt vagy egy nagy márkanév önmagában nem elegendő garancia.
A fejlesztők sokszor abból indulnak ki, hogy ami PyPI-on vagy npm-en van, az ellenőrzött. A valóság árnyaltabb. Ezek a platformok rengeteg biztonsági intézkedést alkalmaznak, de a nyílt csomagökoszisztémák mérete és sebessége miatt a támadóknak mindig lehetőségük van új módszereket keresni.
Különösen veszélyesek az automatikus frissítések. Ha egy buildrendszer mindig a legújabb verziót húzza le, akkor egy rövid ideig elérhető rosszindulatú release is bekerülhet. Ezért a kriptós és pénzügyi projekteknek óvatosabb frissítési politikára van szükségük, mint egy hobbiprojektnek.
Mit jelent ez az AI és a kripto kapcsolatára nézve?
Az AI és a kripto egyre gyakrabban találkozik. Vannak AI-alapú trading botok, decentralizált AI-hálózatok, on-chain adatelemző rendszerek, automatikus smart contract audit eszközök és ügynökalapú pénzügyi alkalmazások. Minél több AI-eszköz épül be a kriptós infrastruktúrába, annál nagyobb lesz az AI-fejlesztői ellátási lánc jelentősége.
A Mistral AI-incidens tehát nem azt üzeni, hogy az AI-t kerülni kell. Inkább azt, hogy az AI-eszközök használatát ugyanolyan szigorú biztonsági kontrollokkal kell kezelni, mint bármely más kritikus függőséget.
Egy trading bot esetében például nem elég az algoritmus teljesítményét nézni. Vizsgálni kell azt is, milyen könyvtárakat használ, hol tárolja az API-kulcsokat, hogyan kezeli a tőzsdei hozzáféréseket, és van-e korlátozás arra, hogy egy kompromittált kulcs mekkora kárt okozhat.
Hogyan lehet csökkenteni a hasonló támadások kockázatát?
A teljes kockázatot nem lehet nullára csökkenteni, de sokat lehet tenni.
A fejlesztőknek érdemes rögzíteniük a függőségek pontos verzióit, és kerülniük az automatikus, ellenőrizetlen frissítéseket. Hasznosak a dependency scanning eszközök, például a sebezhetőségi adatbázisokat figyelő rendszerek. Fontos a lockfile-ok használata, mert ezek megmutatják, pontosan milyen csomagverziók kerültek telepítésre.
A szervezeteknek erősíteniük kell a secret managementet. A titkok ne legyenek .env fájlokban szétszórva, ne kerüljenek repositoryba, és ne legyenek túl széles jogosultságúak. Egy API-kulcsnak csak annyi hozzáférése legyen, amennyi feltétlenül szükséges.
A CI/CD pipeline-ok esetében célszerű izolált buildkörnyezeteket használni, korlátozni a hálózati hozzáférést, és naplózni a gyanús viselkedést. Egy buildfolyamatnak nem feltétlenül kell tetszőleges külső szerverekről fájlokat letöltenie.
Kriptós projektek esetében különösen fontos, hogy az éles treasury-kulcsok, multisig jogosultságok és smart contract adminisztrátori kulcsok ne legyenek közvetlenül elérhetők általános fejlesztői gépekről vagy CI-rendszerekből.
Piaci következmények: árfolyam helyett bizalmi kockázat
Egy ilyen incidens nem feltétlenül okoz azonnali, széles körű kriptopiaci árfolyamesést. Nem egy tőzsdei hackről vagy protokollból ellopott likviditásról beszélünk. A valódi hatás inkább középtávú: nő a bizalmi kockázat a fejlesztői infrastruktúrával szemben.
A befektetők és intézményi szereplők egyre inkább figyelni fognak arra, hogy egy projekt mennyire képes kezelni az ellátási lánc kockázatait. A nagyobb alapok, tőzsdék és letétkezelők számára a kiberbiztonsági érettség versenyelőny lehet. Egy kriptós projektnek ma már nem elég jó narratívát építenie; bizonyítania kell, hogy a működési biztonsága is erős.
Ez különösen igaz azoknál a projekteknél, amelyek AI-t és kriptót kombinálnak. Az „AI crypto” narratíva piaci szempontból vonzó, de technológiailag összetett. Minél több réteg kapcsolódik egymáshoz, annál több ponton keletkezhet sérülékenység.
Összegzés
A Mistral AI PyPI-csomagját érintő támadás újabb figyelmeztetés arra, hogy a modern kriptoszektor biztonsága nem csak a blockchainen múlik. A smart contract lehet auditált, a tokenomika lehet átgondolt, a közösség lehet erős, de ha a fejlesztői ellátási lánc sérül, az egész rendszer veszélybe kerülhet.
A mistralai==2.4.6 esete azért különösen tanulságos, mert egy ismert AI-fejlesztői eszközön keresztül mutatta meg, milyen könnyen válhat egy megbízhatónak hitt csomag támadási vektorrá. A Shai-Hulud-kampány pedig azt jelzi, hogy ezek a támadások már nem elszigetelt trükkök, hanem skálázható, automatizált és gyorsan terjedő műveletek.
A kriptopiaci szereplőknek, fejlesztőknek és befektetőknek ebből azt kell levonniuk: a biztonság nem egyszeri audit, hanem folyamatos fegyelem. Aki pénzügyi infrastruktúrát épít nyílt forráskódú komponensekre, annak nemcsak a kódját, hanem a teljes szoftverellátási láncát védenie kell.
Gyakori kérdések
Érinti ez a támadás közvetlenül a Mistral AI modelleket?
A jelenlegi információk alapján a probléma a mistralai PyPI-csomag 2.4.6-os verziójához kapcsolódott, nem magukhoz a Mistral AI modellekhez. A hivatalos advisory szerint a rosszindulatú verzió PyPI-on jelent meg, és nem volt legitim release tag vagy normál kiadási folyamat része.
Mit jelent az, hogy importáláskor futott le a kártevő?
Pythonban az import parancs betölt egy csomagot vagy modult. Ha egy rosszindulatú kód bekerül az inicializáló fájlba, akkor már a csomag betöltésekor aktiválódhat. Ez azért veszélyes, mert a fejlesztő nem feltétlenül indít el kézzel semmilyen gyanús fájlt.
Csak Linux rendszerek voltak veszélyben?
A jelentések szerint a rosszindulatú dropper Linux rendszereken aktiválódott importáláskor. Ez nem jelenti azt, hogy más rendszereken semmilyen vizsgálatra nincs szükség, de a konkrét ismert futási lánc Linux-környezetre fókuszált.
Miért fontos ez a kriptósoknak?
Mert a kriptós fejlesztők gyakran kezelnek érzékeny API-kulcsokat, wallet-infrastruktúrát, smart contract deployment kulcsokat, GitHub-tokeneket és felhőhozzáféréseket. Ha ezek támadóhoz kerülnek, annak pénzügyi következménye is lehet.
Ellophatták a privát kulcsokat?
Ez attól függ, hogy az érintett gépen voltak-e privát kulcsok, seed phrase-ek, walletfájlok vagy ezekhez kapcsolódó hozzáférések. A biztonságos feltételezés az, hogy minden, az érintett gépen tárolt titok veszélybe kerülhetett, ezért kulcsrotáció és alapos incidensvizsgálat szükséges.
Elég törölni a fertőzött csomagot?
Nem feltétlenül. Ha a kártevő már lefutott, akkor a csomag törlése önmagában nem bizonyítja, hogy a rendszer tiszta. Érdemes a gépet kompromittáltnak tekinteni, a titkokat rotálni, a logokat átnézni, és kritikus környezetben tiszta image-ből újraépíteni a rendszert.
Mi az a PyPI?
A PyPI, vagy Python Package Index, a Python programozási nyelv legfontosabb csomagtárolója. A fejlesztők innen telepítenek könyvtárakat például a pip install paranccsal.
Mi az npm?
Az npm a JavaScript és Node.js ökoszisztéma egyik központi csomagkezelő rendszere. A Shai-Hulud-kampány több npm-csomagot is érintett, nem csak PyPI-projekteket.
Mit jelent a Shai-Hulud név?
A Shai-Hulud egy korábbi és most újra felbukkanó szoftverellátási lánc támadási kampány neveként szerepel a biztonsági jelentésekben. A mostani „Mini Shai-Hulud” hullám több népszerű npm- és PyPI-csomagot is érintett.
Mit tehet egy átlagos kriptobefektető?
Nem kell minden technikai részletet ismernie, de érdemes figyelnie arra, hogy az általa használt projektek mennyire átláthatóan kezelik a biztonságot. Fontos jel a rendszeres audit, a bug bounty, a nyílt incidenskommunikáció, a multisig treasury és a felelős kulcskezelés.
Jogi nyilatkozat
Ez a cikk kizárólag tájékoztató és oktatási célokat szolgál, nem minősül befektetési, pénzügyi, jogi, adózási vagy kiberbiztonsági tanácsadásnak. A kriptovaluták és a kapcsolódó technológiák magas kockázatúak, a kiberbiztonsági incidensek pedig gyorsan változó információkon alapulhatnak. Fejlesztői vagy vállalati érintettség esetén érdemes képzett kiberbiztonsági szakértővel, incidenskezelő csapattal és jogi tanácsadóval konzultálni. Befektetési döntés előtt mindenki végezzen saját kutatást.
Kulcsszavak: Mistral AI, PyPI malware, mistralai 2.4.6, Shai-Hulud, Mini Shai-Hulud, supply chain attack, ellátási lánc támadás, kriptovaluta biztonság, blockchain fejlesztők, AI biztonság, Python csomag, npm támadás, GitHub token, API kulcs, CI/CD biztonság, smart contract biztonság, DeFi kockázat, kripto kiberbiztonság
