Egy feltört külső szolgáltatón keresztül rosszindulatú kód került a Polymarket weboldalára, amely több felhasználó tárcájából összesen közel 3 millió dollárnyi kriptoeszközt csapolhatott le. A predikciós piaci platform teljes kártalanítást ígér, az eset azonban ismét megmutatta, hogy egy decentralizált rendszer leggyengébb pontja nem feltétlenül az okosszerződés, hanem a felhasználó és a blokklánc között működő webes felület lehet.
Feltörték a Polymarket egyik külső szolgáltatóját
A Polymarket 2026. június 25-én közölte, hogy egy meg nem nevezett külső szolgáltatóját támadás érte. A kompromittált partneren keresztül a támadók rosszindulatú programkódot tudtak beilleszteni a Polymarket webes kezelőfelületébe, vagyis a frontendbe.
A vállalat szerint a hibás vagy fertőzött függőséget eltávolították, az incidenst sikerült megfékezni, az érintett felhasználókat pedig közvetlenül megkeresik és teljes egészében kártalanítják. A Polymarket egyelőre nem nevezte meg a kompromittált szolgáltatót, és részletes technikai eseményelemzést sem tett közzé.
Külső blokklánc-elemzők szerint a támadás során megközelítőleg 2,94–3 millió dollárnyi eszközt loptak el. A Specter nevű on-chain elemző legalább 11 érintett tárcát azonosított, míg a Bubblemaps becslése szerint 15-nél kevesebb felhasználói fiók lehetett érintett. Ezek külső becslések: a Polymarket a pontos veszteséget és a károsultak végleges számát még nem erősítette meg nyilvánosan.
Az eset így egyszerre tekinthető kriptotárcákat célzó adathalász támadásnak, frontendincidensnek és szoftverellátásilánc-támadásnak.
Hogyan történhetett a 3 millió dolláros lopás?
A Polymarket közleményéből az derül ki, hogy nem közvetlenül a platform központi infrastruktúráját vagy alapvető okosszerződéseit törték fel. Ehelyett egy külső szolgáltató kompromittálásával rosszindulatú szkriptet juttattak el bizonyos felhasználók böngészőjébe.
A pontos technikai támadási láncot a részletes utólagos jelentés hiányában még nem lehet teljes bizonyossággal rekonstruálni. A nyilvános adatok alapján azonban valószínűleg a következő folyamat valamely változata történhetett:
- A felhasználó megnyitotta a valódi Polymarket weboldalt.
- A böngésző a Polymarket saját kódja mellett betöltött egy kompromittált külső komponenst.
- A rosszindulatú kód tárcakapcsolatot vagy tranzakciós jóváhagyást kezdeményezett.
- Az érintett felhasználó egy látszólag szabályos műveletet írt alá.
- Az engedély segítségével a támadó át tudta mozgatni a tárcában található pUSD-t.
Ez különösen veszélyes támadási forma, mert a felhasználó nem feltétlenül egy hamis webcímet nyit meg. Előfordulhat, hogy a hivatalos oldalon találkozik a rosszindulatú kóddal.
Az OWASP webbiztonsági szervezet szerint a külső JavaScript használatának egyik legsúlyosabb kockázata éppen az, hogy a harmadik fél szerverének kompromittálása után rosszindulatú kód kerülhet az eredeti weboldalba. A szoftverellátási lánc hibái ezért a 2025-ös OWASP Top 10 listáján is kiemelt biztonsági kockázatként szerepelnek.
Egyszerű példa a frontend veszélyére
Képzeljünk el egy banki széftermet, amelynek a zárai hibátlanul működnek. A bejáratnál azonban egy hamis ügyintéző ül, aki a valódi banki nyomtatványhoz megtévesztően hasonló dokumentumot írat alá az ügyféllel.
A széfet ebben a példában nem törték fel. Az ügyfél viszont olyan felhatalmazást adott, amely alapján a támadó jogszerűnek látszó módon hozzáférhetett a vagyonhoz.
Egy blokkláncos rendszerben az okosszerződés csak azt tudja ellenőrizni, hogy egy tranzakció érvényes aláírással és megfelelő engedélyekkel érkezett-e. Azt nem feltétlenül tudja megállapítani, hogy a felhasználót félrevezették-e az aláírás előtt.
Frontend és okosszerződés: mi a különbség?
A kriptopiaci incidenseknél gyakran minden támadást egyszerűen „hackként” említenek, pedig a támadás helye és módszere alapvetően meghatározza a kockázat nagyságát.
Az okosszerződés, angolul smart contract, a blokkláncon futó program. Ez kezeli többek között az elszámolást, a tokenek mozgatását és a piaci pozíciók rendezését.
A frontend ezzel szemben az a webes felület, amelyet a felhasználó lát. A gombok, egyenlegek, árfolyamok és tranzakciós ablakok mind a frontend részei.
A Polymarket hivatalos dokumentációja szerint a platform hibrid központi limitáras ajánlati könyvet, úgynevezett CLOB-rendszert használ. Az ajánlatok párosítása a blokkláncon kívül történik, az elszámolás viszont Polygon-alapú okosszerződéseken keresztül zajlik. A megbízásokat a felhasználók kriptográfiailag aláírják, az egymáshoz illeszkedő ügyletek pedig a blokkláncon rendeződnek.
A mostani támadás jelentősége éppen abban áll, hogy egy biztonságos okosszerződés sem feltétlenül elegendő, ha a felhasználó által látott felület rosszindulatú művelet aláírására veszi rá.
A decentralizált nem feltétlenül jelent teljesen bizalommentes rendszert
A Polymarket dokumentációja nem letétkezelő, vagyis non-custodial rendszerként írja le a platformot. Ez azt jelenti, hogy elvileg nem a vállalat őrzi központilag a felhasználók pénzét; az eszközök a blokkláncos tárcákban maradnak.
Ez csökkentheti annak kockázatát, hogy egyetlen központi tárca feltörésével minden ügyfél pénze elveszjen. Nem szünteti meg azonban az összes bizalmi függőséget.
A felhasználónak továbbra is bíznia kell többek között:
- a weboldal által betöltött kódban;
- a tárcaszoftverben;
- a domainnév és a DNS-rendszer biztonságában;
- a külső bejelentkezési és adatfeldolgozó szolgáltatókban;
- az okosszerződés címének helyességében;
- a tranzakciós ablak által megjelenített információkban.
A valódi kérdés tehát nem az, hogy egy rendszer decentralizált-e, hanem az, hogy mely rétegek decentralizáltak, és mely pontokon marad fenn külső szolgáltatóktól való függőség.
Mi az a pUSD, amelyet a támadók elloptak?
A pUSD, teljes nevén Polymarket USD, a Polymarket kereskedési fedezetként használt tokenje.
A platform hivatalos dokumentációja szerint a pUSD:
- a Polygon hálózaton működő ERC-20 token;
- USDC-vel fedezett;
- a Polymarket kereskedési rendszerének alapvető fedezeti eszköze;
- nem algoritmikus stabilcoin;
- nem töredéktartalékos rendszerre épül.
A dokumentáció szerint a fedezetet okosszerződéses mechanizmus kényszeríti ki. Amikor egy felhasználó támogatott USDC-t helyez el a rendszerben, azt a Polymarket infrastruktúrája pUSD-vé alakítja, és ezzel lehet a platform piacain kereskedni.
Nem a pUSD árfolyamrögzítése omlott össze
Fontos megkülönböztetni a stabilcoin fedezeti kockázatát a tárcából történő lopástól.
A rendelkezésre álló információk nem arra utalnak, hogy a pUSD USDC-fedezete, kibocsátási mechanizmusa vagy egy dollár körüli átválthatósága sérült volna. A támadók a felhasználók már létező pUSD-egyenlegeit szerezték meg.
Ez olyan, mintha valaki dollárt lopna egy bankszámláról. A lopás önmagában nem jelenti azt, hogy a dollár fizetőeszközként összeomlott; azt jelenti, hogy a számla feletti hozzáférés sérült.
A pUSD ettől még hordozhat különböző technikai, likviditási és okosszerződéses kockázatokat, de a június 25-i esemény önmagában nem bizonyítja a fedezeti modell hibáját.
Hová került az ellopott kriptovaluta?
Az on-chain elemzők szerint a támadók legalább 11 tárcából vittek el pUSD-t. Az eszközöket a Polygon hálózatról Ethereumra hidalták át, majd hozzávetőleg 1 893 ETH-ra váltották. A bevételt ezt követően egy Ethereum-címen vonták össze.
A blokkláncok közötti áthidalás, angolul bridging, azt jelenti, hogy egy eszköz gazdasági értékét az egyik hálózatról egy másikra mozgatják. A token nem szó szerint „utazik át” a blokkláncok között: a hídmechanizmustól függően az egyik oldalon zárolják vagy elégetik, a másikon pedig megfelelő reprezentációt bocsátanak ki.
Az ETH-ra váltás több célt is szolgálhat:
- az ETH-nak nagy a piaci likviditása;
- számos decentralizált kereskedési rendszerben használható;
- Ethereumon több további pénzmozgatási lehetőség érhető el;
- a különböző eszközök egyetlen tokenbe történő összevonása egyszerűsíti a további tranzakciókat.
A hálózatváltás és az ETH-ra konvertálás ugyanakkor nem teszi automatikusan követhetetlenné az összeget. A nyilvános blokkláncokon a tranzakciók továbbra is láthatók, bár a címek mögötti személyek azonosítása már jóval nehezebb feladat.
Kevés károsult, mégis jelentős veszteség
Első pillantásra megnyugtatónak tűnhet, hogy a támadás 15-nél kevesebb fiókot érinthetett. A csaknem 3 millió dolláros összveszteség azonban arra utal, hogy néhány tárcában rendkívül nagy egyenleget tartottak.
Ha a 2,94 millió dolláros becslést és a legalább 11 tárcát vesszük alapul, az egyszerű számtani átlag körülbelül 267 ezer dollár lenne tárcánként. Ez nem jelenti azt, hogy minden károsult ennyit veszített: elképzelhető, hogy egy-két nagyobb tárca adta a veszteség nagy részét.
Az eset mindenesetre rámutat a „forró tárcák” egyik alapvető veszélyére. A hot wallet folyamatosan internetkapcsolattal rendelkező, gyakori tranzakciókra használt tárca. Kényelmes, de nem feltétlenül alkalmas hosszú távú, nagy összegű vagyon tárolására.
A Polymarketen aktív kereskedők számára különösen fontos különválasztani:
- a napi kereskedéshez szükséges összeget;
- a hosszabb távon tartott kriptovagyont;
- a különösen nagy értékű pozíciókat;
- az ismeretlen vagy kísérleti alkalmazásokkal használt tárcákat.
Egy rosszindulatú jóváhagyás káros hatása lényegesen kisebb lehet, ha az adott tárcában csak a tényleges kereskedéshez szükséges egyenleg található.
Mit jelent a tokenengedély vagy approval?
Az ERC-20 tokeneknél gyakran nem minden egyes tranzakciót külön hagy jóvá a felhasználó. Ehelyett engedélyezheti egy okosszerződésnek vagy más címnek, hogy meghatározott mennyiségű tokent mozgasson a nevében.
Ezt nevezik token approvalnak, magyarul tokenengedélynek vagy költési jóváhagyásnak.
Például egy felhasználó engedélyezheti egy tőzsdei okosszerződésnek, hogy legfeljebb 1 000 pUSD-t használjon fel. Ha azonban korlátlan jóváhagyást ad, az engedélyezett szerződés elméletileg a teljes aktuális és későbbi egyenleghez hozzáférhet.
A korlátlan engedély kényelmes, mert nem kell minden kereskedés előtt új tranzakciót aláírni. Biztonsági szempontból viszont növeli a lehetséges veszteséget.
A Polymarket fejlesztői dokumentációja szerint a kereskedéshez meghatározott pUSD- és szerződésengedélyekre van szükség. A mostani incidens után különösen fontos kérdés, hogy a rosszindulatú frontend pontosan milyen engedélyeket kért, és azok meddig maradhattak aktívak.
A Polymarket teljes kártalanítást ígér
A Polymarket közölte, hogy az érintett ügyfeleket teljes egészében kártalanítja. Ez a vállalás a felhasználók szempontjából kedvező, mert a kriptovilágban egy adathalász vagy tárcaengedélyes támadás után sok esetben semmilyen visszatérítés nem történik.
A 2026. június 26-án nyilvánosan elérhető információk alapján ugyanakkor még nem ismert:
- a kifizetések pontos időpontja;
- a jogosultság megállapításának módszere;
- a visszatérítés pénzneme;
- az árfolyam meghatározásának időpontja;
- hogy kizárólag az ellopott pUSD-t vagy más közvetett károkat is megtérítenek-e;
- hogy készül-e független biztonsági vizsgálat;
- mikor jelenik meg a részletes technikai incidensjelentés.
A vállalat nyilvánosan azt vállalta, hogy felveszi a kapcsolatot a károsultakkal, de a beszámolók szerint egyelőre nem közölt részletes visszatérítési menetrendet.
A kártalanítás önmagában nem oldja meg a bizalmi problémát
A visszatérítés pénzügyileg semlegesítheti a közvetlen veszteséget. A biztonsági és reputációs kérdéseket azonban nem zárja le.
A felhasználóknak tudniuk kellene például:
- mennyi ideig volt aktív a rosszindulatú kód;
- mely böngészők, országok vagy felhasználói csoportok kapták meg;
- milyen tranzakciókat vagy engedélyeket generált;
- miért nem észlelték korábban;
- maradtak-e aktív, veszélyes tokenengedélyek;
- milyen új ellenőrzéseket vezetnek be.
A „mindenkit kártalanítunk” fontos válságkezelési lépés. Hosszú távon azonban a bizalmat a bizonyítható technikai változtatások állíthatják helyre.
Ez már a második nagyobb Polymarket-incidens rövid időn belül
A június 25-i támadás nem az első jelentős biztonsági probléma volt a platform körül 2026-ban.
Május 22-én egy Polymarkethez kapcsolódó, belső feltöltésekhez és jutalomkifizetésekhez használt tárcát ért támadás. Az akkori veszteséget különböző elemzések 520–700 ezer dollár közé becsülték. A Polymarket fejlesztői szerint egy privát kulcs kompromittálódhatott, miközben az alapvető okosszerződések, a piaci eredmények és a felhasználói pénzek nem kerültek veszélybe.
A két incidens technikailag különböző volt:
A májusi támadásban egy belső operatív tárca kulcsa sérülhetett.
A júniusi támadásban egy külső szolgáltatón keresztül a felhasználói frontendbe kerülhetett rosszindulatú kód.
A közös pont az, hogy egyik eset sem feltétlenül a platform fő okosszerződéseinek programhibájából következett be. Ehelyett a támadók a rendszer peremén található, kevésbé látványos, de kritikus komponenseket célozták.
Korábban is felmerült külső szolgáltatói kockázat
2025 decemberében a Polymarket már elismert egy olyan incidenst, amely néhány felhasználót érintett, és amelyet a vállalat egy külső hitelesítési szolgáltató sebezhetőségével magyarázott.
Egyetlen ilyen esemény lehet elszigetelt hiba. Több, külső vagy operatív függőséghez kapcsolódó incidens azonban arra utalhat, hogy a platformnak nemcsak az okosszerződések auditálására, hanem a teljes technológiai beszállítói láncra is nagyobb figyelmet kell fordítania.
Ez még nem bizonyítja, hogy a Polymarket rendszerszinten hanyagul működik. Ilyen következtetéshez részletes incidensjelentésekre, független auditokra és a javítóintézkedések ismeretére lenne szükség. A nyilvános információk hiánya azonban önmagában is növeli a bizonytalanságot.
Miért fontos a szoftverellátási lánc biztonsága?
A modern webalkalmazások ritkán készülnek kizárólag saját fejlesztésű kódból. Külső könyvtárakat, elemzőszolgáltatásokat, hitelesítési rendszereket, ügyfélszolgálati modulokat, tartalomszolgáltató hálózatokat és fizetési infrastruktúrát használnak.
Minden új integráció felgyorsíthatja a fejlesztést, ugyanakkor új bizalmi kapcsolatot is létrehoz.
A Nemzeti Szabványügyi és Technológiai Intézet, a NIST szerint az ellátásilánc-kockázat kezelésének ki kell terjednie a külső termékekre, szolgáltatókra és függőségekre azok teljes életciklusa alatt. Ez nem egyszeri auditot, hanem folyamatos azonosítást, értékelést és kockázatcsökkentést jelent.
Egy kriptoplatform számára a probléma különösen súlyos. Egy hagyományos weboldalon a rosszindulatú kód adatokat lophat vagy hamis tartalmat jeleníthet meg. Egy tárcával összekapcsolt oldalon közvetlenül visszafordíthatatlan pénzügyi tranzakciókat is kezdeményezhet.
Mit kellene nyilvánosságra hoznia a Polymarketnek?
Egy megfelelő incidensjelentésnek legalább az alábbi kérdésekre választ kellene adnia.
A támadás pontos időablaka
A felhasználóknak tudniuk kell, mettől meddig töltődhetett be a rosszindulatú kód. Enélkül nehéz megállapítani, mely tárcákat szükséges átvizsgálni.
A kompromittált szolgáltató szerepe
Nem feltétlenül szükséges azonnal minden üzleti részletet közzétenni, de világosan meg kellene határozni, hogy a szolgáltató hitelesítést, analitikát, tartalomszolgáltatást, ügyfélszolgálatot vagy más funkciót biztosított-e.
Az aláíratott műveletek típusa
Lényeges, hogy a támadás egyszeri tokenátutalást, korlátlan approvalt, okosszerződés-hívást vagy más tárcaműveletet használt-e.
A veszélyes engedélyek listája
A Polymarketnek nyilvánosságra kellene hoznia az érintett szerződés- és támadói címeket, valamint egyszerű eszközt kellene biztosítania a veszélyes engedélyek visszavonására.
A megelőző ellenőrzések hiányosságai
A jelentésnek ki kellene térnie arra, hogy a rosszindulatú változtatás miért nem akadt fenn a telepítési ellenőrzéseken, tartalombiztonsági szabályokon vagy futásidejű megfigyelésen.
A bevezetett javítások
A valódi biztonsági előrelépéshez nem elegendő az érintett fájl eltávolítása. A beszállítói hozzáférések, a kódbetöltési szabályok és a tranzakciós jóváhagyások teljes folyamatát felül kell vizsgálni.
Milyen védekezési lépések csökkenthetik a hasonló támadásokat?
A platform oldalán több technikai és szervezeti megoldás kombinációjára lehet szükség.
Külső szkriptek számának csökkentése
A kritikus kereskedési felületen csak a valóban nélkülözhetetlen külső komponenseknek kellene futniuk. Ahol lehetséges, a fontos kódot saját infrastruktúráról érdemes kiszolgálni.
Content Security Policy
A megfelelő Content Security Policy, röviden CSP, korlátozhatja, hogy a weboldal milyen forrásokból tölthet be és hajthat végre kódot. Nem jelent tökéletes védelmet, de csökkentheti a rosszindulatú szkriptek lehetőségeit.
Subresource Integrity
A Subresource Integrity segítségével a böngésző ellenőrizheti, hogy egy külső fájl tartalma megfelel-e az előre rögzített kriptográfiai lenyomatnak. Ha a fájl váratlanul megváltozik, a böngésző megtagadhatja a végrehajtását.
Függőségek rögzítése és ellenőrzése
A szoftverkönyvtárak verzióit, forrását és integritását rögzíteni kell. Az automatikusan frissülő külső függőségek gyorsan javíthatnak hibákat, de kompromittált frissítés esetén azonnal szétteríthetik a rosszindulatú kódot.
SBOM és beszállítói leltár
Az SBOM, vagyis Software Bill of Materials a szoftverben használt komponensek jegyzéke. Segítségével gyorsabban azonosítható, hogy egy feltört könyvtár vagy szolgáltatás mely rendszereket érinti. A NIST külön is javasolja a harmadik féltől származó komponensek dokumentálását és folyamatos sérülékenység-ellenőrzését.
Tranzakciós riasztások
A platform valós időben figyelhetné az olyan szokatlan mintákat, mint:
- több ügyféltárcából ugyanarra a címre induló átutalások;
- rövid idő alatt létrejövő nagy tokenengedélyek;
- a szokásos kereskedési szerződésektől eltérő címek;
- a felület használatával egy időben jelentkező tömeges egyenlegcsökkenés.
Az on-chain átláthatóság nemcsak a támadás utólagos követésére, hanem korai riasztások kialakítására is használható.
Mit tehetnek most a Polymarket felhasználói?
A támadás lezárásának bejelentése után sem célszerű automatikusan feltételezni, hogy egy korábban megadott rosszindulatú engedély is megszűnt. A frontend eltávolítása és a blokkláncon már létező approval visszavonása két külön művelet.
Ellenőrizni kell a tárca tranzakcióit
A felhasználónak érdemes áttekintenie a Polygon- és Ethereum-címet, különösen a június 25. körüli tranzakciókat. Gyanús lehet minden ismeretlen engedély, szerződéshívás vagy átutalás.
Vissza kell vonni a szükségtelen engedélyeket
A már nem használt vagy ismeretlen címekhez tartozó tokenengedélyeket célszerű megszüntetni. Ez nem szerzi vissza a már ellopott eszközöket, de megakadályozhat további átutalásokat, amennyiben a támadó csak approvalt kapott.
Kulcskompromittálódás esetén új tárca szükséges
Ha felmerül, hogy a privát kulcs vagy a helyreállító kifejezés került illetéktelen kézbe, az engedélyek visszavonása nem elegendő. Ilyenkor a még meglévő eszközöket tiszta eszközön létrehozott új tárcába kell átmozgatni.
Külön kereskedési tárcát érdemes használni
A hosszú távú megtakarításokat nem célszerű ugyanabban a tárcában tartani, amelyet rendszeresen webalkalmazásokhoz csatlakoztatnak.
Egy lehetséges felosztás:
- hardvertárca a hosszú távú vagyonhoz;
- elkülönített tárca a Polymarkethez;
- külön, alacsony egyenlegű tárca új protokollok kipróbálásához.
Óvakodni kell a hamis kártalanítási oldalaktól
Nagyobb kriptoincidensek után rendszeresen megjelennek hamis „refund”, „claim” vagy „wallet verification” oldalak. A támadók kihasználhatják, hogy a károsultak gyorsan szeretnék visszakapni a pénzüket.
A valódi visszatérítéshez nem szabad privát kulcsot vagy seed phrase-t megadni. Egy legitim szolgáltató sem kérheti a 12 vagy 24 szavas helyreállító kifejezést.
A hardvertárca sem véd a vak aláírás ellen
A hardvertárca megakadályozhatja, hogy a privát kulcs közvetlenül elhagyja az eszközt. Ha azonban a felhasználó a hardvertárcán jóváhagy egy rosszindulatú tranzakciót, az eszköz szabályosan aláírhatja azt.
A legfontosabb kérdés nemcsak az, hogy hol található a kulcs, hanem az is, hogy pontosan mit ír alá a felhasználó.
Befektetői szemmel mi a támadás legfontosabb tanulsága?
A predikciós piacokon a kereskedők általában az esemény valószínűségére, a piaci árra és a potenciális hozamra figyelnek. A júniusi incidens azonban rámutat, hogy a tényleges eredményt az operatív kockázat is befolyásolja.
Egy kereskedő hiába becsüli helyesen egy politikai vagy gazdasági esemény esélyét, ha közben:
- feltörik a hozzáférési rendszerét;
- rosszindulatú tranzakciót ír alá;
- leáll a felület;
- nem tudja időben lezárni a pozícióját;
- problémássá válik a stablecoin átváltása;
- harmadik fél hibája miatt elveszíti az egyenlegét.
A várható hozam számításakor ezért nemcsak a piaci kimenetelt kell mérlegelni, hanem a platform-, tárca-, likviditási és infrastruktúra-kockázatot is.
Példa a pozícióméretezésre
Tegyük fel, hogy egy kereskedőnek 10 000 dollárnyi teljes kriptoportfóliója van, de egy adott Polymarket-pozícióhoz csak 500 dollárra van szüksége.
Ha a teljes 10 000 dollárt a rendszerhez kapcsolt tárcában tartja, egy rosszindulatú korlátlan engedély a teljes vagyonát veszélyeztetheti. Ha a kereskedési tárcában csak 500–700 dollár van, az incidens maximális közvetlen hatása lényegesen kisebb lehet.
Ez nem szünteti meg a kockázatot. A lehetséges veszteség felső határát azonban csökkenti.
Mit jelenthet az eset a Polymarket jövőjére nézve?
Rövid távon a teljes kártalanítási ígéret tompíthatja a felhasználói elégedetlenséget. A veszteség a vállalat méretéhez képest kezelhető lehet, különösen akkor, ha valóban kevés ügyfél érintett.
Hosszabb távon három kérdés válhat meghatározóvá.
Megbízható-e a teljes technológiai környezet?
A platform alapvető okosszerződéseinek biztonsága csak egy része a rendszernek. A felhasználói felület, a hitelesítési szolgáltatás, a jutalomkifizetési tárca és a külső kódfüggőségek ugyanúgy kritikusak.
Mennyire átlátható a válságkezelés?
A gyors közlemény és a visszatérítési ígéret pozitív lépés. A bizalom szempontjából azonban a részletes, ellenőrizhető utólagos jelentés lesz igazán fontos.
Megváltozik-e a felhasználók viselkedése?
A professzionálisabb kereskedők nagyobb valószínűséggel használhatnak elkülönített tárcákat, kisebb platformegyenlegeket és szigorúbb tranzakciós ellenőrzést. Ez növelheti a biztonságot, de ronthatja a platform használatának egyszerűségét.
A Polymarketnek ezért olyan megoldásokat kell találnia, amelyek nem csupán biztonságosabbá, hanem a kevésbé tapasztalt felhasználók számára is érthetőbbé teszik az aláírásokat és tokenengedélyeket.
Gyakori kérdések
Feltörték a Polymarket okosszerződéseit?
A jelenleg rendelkezésre álló információk alapján nem ez történt. A Polymarket szerint egy külső szolgáltató kompromittálása után rosszindulatú kód került a frontendbe. Részletes technikai utóelemzés hiányában azonban a végleges következtetésekkel érdemes megvárni a hivatalos jelentést.
Pontosan mennyi pénzt loptak el?
Külső on-chain elemzők körülbelül 2,94–3 millió dollárra becsülték a veszteséget. A Polymarket a pontos végleges összeget még nem közölte.
Hány felhasználót érintett a támadás?
A Specter legalább 11 károsult tárcáról számolt be, míg a Bubblemaps szerint az érintett fiókok száma 15 alatt maradhatott. Ezek előzetes elemzői becslések.
Visszakapják a pénzüket a károsultak?
A Polymarket teljes visszatérítést ígért, és közölte, hogy kapcsolatba lép az érintettekkel. A visszatérítés pontos határideje és részletes eljárása egyelőre nem ismert.
Mi az a pUSD?
A pUSD a Polymarket Polygon-hálózaton működő ERC-20 fedezeti tokenje. A platform dokumentációja szerint USDC fedezi, és ezt használják a Polymarket kereskedési rendszerében.
Összeomlott a pUSD fedezete?
Erre nincs nyilvános bizonyíték. A beszámolók szerint felhasználói pUSD-egyenlegeket loptak el, nem pedig a token fedezeti vagy kibocsátási mechanizmusát törték fel.
Miért váltották ETH-ra az ellopott eszközöket?
Az ETH nagy likviditású, számos szolgáltatásban használható, és megkönnyítheti a több tárcából származó eszközök összevonását. A váltás ugyanakkor nem tünteti el a nyilvános blokkláncon látható tranzakciós nyomokat.
Visszaszerezhető a pénz az approval visszavonásával?
Nem. Az engedély visszavonása csak a további jogosulatlan tokenmozgatást akadályozhatja meg. A már végrehajtott tranzakciókat nem fordítja vissza.
Teljes védelmet biztosít a hardvertárca?
Nem. A hardvertárca erősen védi a privát kulcsot, de nem akadályozza meg a felhasználót abban, hogy tévedésből rosszindulatú tranzakciót írjon alá.
Mi az a szoftverellátásilánc-támadás?
Olyan támadás, amelyben a támadó nem feltétlenül a végső célpontot töri fel közvetlenül. Ehelyett annak egyik beszállítóját, könyvtárát, fejlesztői eszközét vagy külső szolgáltatóját kompromittálja, majd ezen keresztül juttat rosszindulatú kódot a rendszerbe.
Biztonságos most újra használni a Polymarketet?
A Polymarket szerint a fertőzött függőséget eltávolították és az incidenst megfékezték. A kockázat teljes körű megítéléséhez azonban szükség lenne a támadás pontos időablakára, a kompromittált szolgáltató azonosítására és egy részletes technikai jelentésre.
Mit tegyen az, aki június 25-én használta az oldalt?
Ellenőrizze a tárca tranzakcióit és tokenengedélyeit, vonja vissza az ismeretlen jogosultságokat, és ne csatlakoztassa a tárcát nem ellenőrzött visszatérítési oldalakhoz. Gyanús pénzmozgás esetén érdemes azonnal felvenni a kapcsolatot a Polymarket hivatalos ügyfélszolgálatával.
Jogi nyilatkozat
A cikk kizárólag tájékoztatási és oktatási célt szolgál. Nem minősül befektetési, pénzügyi, jogi, adózási vagy informatikai biztonsági tanácsadásnak. A kriptoeszközök, predikciós piacok, stablecoinok, blokklánchidak és decentralizált alkalmazások használata jelentős technikai, piaci, likviditási, szabályozási és teljes tőkevesztési kockázattal járhat. Minden felhasználó saját felelősségére hozza meg döntéseit, és köteles ellenőrizni az adott szolgáltatás használatára vonatkozó helyi jogszabályokat. Biztonsági incidens vagy pénzügyi veszteség esetén célszerű megfelelő jogosultsággal rendelkező szakértőhöz fordulni.
