Ledger remediază o vulnerabilitate în aplicația Ethereum care putea duce la semnături de tranzacții nepotrivite
Rezumat al pieței generat de AI
Ledger a remediat o vulnerabilitate în aplicația sa Ethereum (remediată în v1.22.2) care ar fi putut permite unei aplicații web malițioase să exploateze o condiție de cursă pentru a schimba datele tranzacției după revizuire, transformând potențial acțiuni inofensive în aprobări dăunătoare. Deși nu au fost compromise chei private sau firmware și nu sunt raportate pierderi confirmate, incidentul evidențiază riscul operațional pentru utilizatorii Ethereum/ERC-20 care interacționează cu dApp-uri prin WebHID și ar putea reduce apetitul pentru risc pe termen scurt în activitatea asociată cu ETH.
Nivelul impactului
● Mediu
Active afectate
ETH/USDT-1.21%
Perspectivă AI · ETH/USDTPerspectivă AI
▼ Bearish
Tranzacționează acum
⚠️ Perspectivele generate de AI se bazează pe conținutul știrilor și sunt furnizate exclusiv în scop informativ. Nu constituie consiliere de investiții și nu reprezintă opiniile BingX. Investițiile implică risc. Tranzacționează responsabil.
Cei care folosesc un Ledger pentru Ether sau tokenuri ERC20 ar trebui să deschidă Ledger Live și să verifice versiunea aplicației Ethereum instalate pe dispozitiv. Orice versiune mai veche decât 1.22.2 nu include un patch de securitate. Corecția închide o breșă care lovea chiar în promisiunea centrală a unui hardware wallet: că ecranul arată exact ce urmează să fie semnat.
Subiectul a devenit public la 24 august 2026, după ce firma de securitate TestMachine și-a publicat analiza. Patch-ul exista deja la acel moment. Între aceste repere s-a conturat un diferend legat de cine a descoperit primul problema și când a fost livrată corecția. Pentru utilizatori, disputa contează mai puțin. Relevant este ce versiune rulează pe dispozitiv și ce aprobări au fost acordate în trecut.
Ce s-a întâmplat, de fapt, în aplicația Ethereum de pe Ledger
Nu a fost afectat firmware-ul dispozitivului și nici custodia cheii private. Problema era în aplicația Ethereum (software-ul instalat separat pe dispozitiv pentru Ether și ERC20), care pregătește tranzacția, o afișează pentru verificare și colectează confirmarea.
În versiunile vulnerabile, această secvență putea fi dereglată. O aplicație web malițioasă, cu acces la dispozitivul conectat, putea trimite o a doua comandă de semnare în timp ce prima tranzacție era încă pe ecran, în așteptarea revizuirii. Aplicația înlocuia datele din memorie fără să afișeze un nou ecran de verificare. Transferul aparent inofensiv rămânea vizibil, dar confirmarea utilizatorului se aplica datelor schimbate.
Cercetătorii afirmă că scenariul a fost reprodus demonstrabil pe un Ledger Flex. Pentru că dispozitivele împart în mare parte același cod al aplicației Ethereum, Nano X, Nano S Plus, Stax și Apex sunt considerate de asemenea potențial expuse. Ledger nu a precizat din ce versiune a apărut eroarea; comparația cercetătorilor pornește de la 1.22.1, versiunea etichetată anterior la 27 mai 2026.
"Clear signing" pe înțelesul tuturor: de ce ecranul este promisiunea reală de securitate
Prin "clear signing" se înțelege afișarea integrală, în clar, pe ecranul hardware wallet-ului, a datelor tranzacției înainte de confirmare: adresa destinatarului, suma, iar pentru apeluri de contract, acțiunea pe care contractul urmează să o execute. Acesta este motivul pentru care un astfel de dispozitiv are sens: computerul poate fi compromis, browserul poate afișa o interfață manipulată, iar site-ul poate fi fals. Cât timp dispozitivul are un ecran propriu, independent de PC, și afișează datele reale, manipularea ar trebui să devină evidentă înainte de apăsarea butonului.
În acest incident, cheia privată rămânea în siguranță și firmware-ul nu era atins, dar utilizatorul putea ajunge să își dea acordul pentru altceva decât ceea ce citise pe ecran. Un dispozitiv al cărui ecran nu mai poate fi considerat "obligatoriu", la acest capitol, nu e cu mult diferit de un software wallet pe o mașină infectată.
Miezul tehnic: "race condition" și comenzi APDU
O "race condition" este un defect în care rezultatul depinde de ordinea în care sunt procesate două comenzi aproape simultane. E periculoasă tocmai pentru că, în mod normal, codul pare corect și fluxul funcționează în majoritatea cazurilor; problema apare când cineva orchestrează deliberat ordinea.
APDU este formatul de comandă folosit de smart card-uri și hardware wallet-uri pentru a comunica cu computerul. O semnătură implică mai multe astfel de comenzi. Aplicația Ethereum păstra o stare internă care indica ce tranzacție era în revizuire. Această stare putea fi suprascrisă cât timp revizuirea era încă în curs: două comenzi în paralel, fără o stare neechivocă.
WebHID în browser: de ce un site poate vorbi cu dispozitivul
WebHID este o interfață de browser care permite unui site să comunice direct cu un dispozitiv USB conectat, după ce utilizatorul acordă explicit permisiunea. Fără WebHID, folosirea comodă a unui hardware wallet în aplicații descentralizate ar fi dificilă; cu WebHID, site-ul ajunge mai aproape de dispozitiv decât își imaginează mulți.
Atacul descris presupune că utilizatorul a acordat deja acces unui site manipulat sau compromis și inițiază o tranzacție acolo. Nu funcționează de la distanță împotriva unui dispozitiv aflat într-un sertar. Asta restrânge aria, fără a diminua miza: cei care folosesc regulat DEX-uri, bridge-uri sau interfețe de staking acordă frecvent astfel de permisiuni.
De ce "token approval" (mai ales nelimitat) este mult mai periculos decât un transfer
Într-un schimb de semnătură de acest tip, paguba rar vine din transferul în sine. Miza este ce poate fi "strecurat" în locul lui. Un "token approval" reprezintă permisiunea acordată unui smart contract să cheltuiască pe viitor o anumită cantitate de tokenuri, fără confirmarea fiecărei debiteri. Din comoditate, multe aplicații cer aprobări nelimitate. O aprobare acordată nu expiră și rămâne activă până la revocare.
Diferența practică:
- Un transfer te costă exact suma confirmată.
- O aprobare nelimitată poate costa, în cel mai rău caz, întregul sold al tokenului, la un moment ales de beneficiar.
Actualizarea aplicației Ethereum la 1.22.2: prin Ledger Live
Versiunea 1.22.2 blochează vectorul descris prin două mecanisme: aplicația refuză inițierea unei noi sesiuni de semnare cât timp o revizuire este în desfășurare și respinge o confirmare primită dacă starea internă nu mai corespunde cu ce a fost afișat.
În prezentarea de release a aplicației Ethereum la Ledger, nota indică doar "fixed security issues", fără detalii despre defect. Actualizarea este simplă: conectați dispozitivul, deschideți managerul de aplicații instalate în Ledger Live și actualizați aplicația Ethereum. Soldurile nu sunt afectate, deoarece cheile sunt derivate din fraza de recuperare și nu "locuiesc" în aplicație. Dezinstalarea și reinstalarea aplicației nu duce la pierderea fondurilor.
Cum verificați versiunea instalată
Ledger Live afișează versiunea fiecărei aplicații în managerul de dispozitiv. Dacă vedeți 1.22.2 sau mai sus, corecția este instalată. Dacă vedeți 1.22.1 sau mai jos, lipsește. Verificarea versiunii Ledger Live nu este suficientă.
De ce un update de firmware nu actualizează și aplicația Ethereum
Firmware-ul, Ledger Live și aplicațiile pentru monede sunt întreținute și actualizate separat. Un utilizator poate face update la firmware și să creadă că a rezolvat problema, dar să rămână cu o aplicație Ethereum veche. Separarea explică și de ce incidentele de securitate sunt adesea comparate greșit: în cazul Coldcard, problema era la generarea seed-ului și necesita un seed nou; vulnerabilitățile BitBox țineau de firmware. Aici eroarea este la nivelul aplicației, deci e suficient un update de aplicație. Fraza de recuperare nu trebuie regenerată.
Pasul doi după update: verificați și revocați aprobările vechi
Actualizarea protejează semnăturile viitoare, dar nu anulează permisiunile acordate în trecut. Dacă ați folosit dApp-uri în ultimele luni, merită să verificați aprobările active pe adresa dvs. Explorerele de blockchain și interfețele specializate listează ce contracte pot dispune de ce tokenuri. Aprobările pentru contracte pe care nu le mai folosiți pot fi revocate una câte una.
Revocarea este o tranzacție obișnuită și implică taxe de rețea, motiv pentru care curățenia e mai eficientă în perioade cu comisioane reduse. Un efect secundar adesea ignorat: fiecare revocare apare în istoricul tranzacțiilor și generează costuri. Cei care își documentează mișcările au un proces mai simplu la declarația fiscală; multe instrumente de taxe și portofoliu importă automat astfel de evenimente.
Disputa de divulgare dintre Ledger și TestMachine
Există două cronologii prezentate public, care nu coincid. Ambele sunt relatări ale părților și nu au fost confirmate independent.
CTO-ul Ledger, Charles Guillemet, a declarat că laboratorul intern Ledger Donjon ar fi descoperit eroarea și că patch-ul ar fi fost livrat cu aproximativ două săptămâni înainte de publicare. Potrivit lui, TestMachine ar fi venit la programul de bug bounty abia ulterior, iar afirmațiile firmei ar fi menite să inducă teamă pentru a atrage atenție.
TestMachine susține că sistemul său de testare, Azimuth, a identificat vulnerabilitatea într-o rulare automată pe un Ledger Flex și că rezultatele au fost împărtășite cu Ledger. În perspectiva firmei, la momentul publicării nu exista o corecție disponibilă.
Faptele verificabile par să stea între cele două versiuni: changelog-ul pentru 1.22.2 este datat 12 august 2026, iar tag-ul semnat din repo are data 13 august. Publicarea vizibilă ca release a apărut abia în jurul lui 24 august, simultan cu analiza firmei de securitate. Între timp, un utilizator care încerca să verifice existența unui fix nu îl putea găsi publicat.
S-au pierdut fonduri? Ce se știe despre impact
Pe baza informațiilor disponibile până acum de la ambele părți, nu există un caz confirmat în care vulnerabilitatea să fi fost exploatată. Nu sunt documentate pierderi, iar extragerea cheilor private nu era posibilă prin această cale.
Rămâne totuși o rezervă importantă: o semnătură obținută astfel ar arăta on-chain ca orice semnătură voluntară. Un utilizator afectat ar observa problema abia când tokenurile ar începe să iasă ulterior și ar putea pune incidentul pe seama unui phishing obișnuit. Absența cazurilor confirmate nu demonstrează că nu au existat.
Ce spune episodul despre hardware wallets și autocustodie
Concluzia utilă nu este respingerea hardware wallet-urilor. Atacul necesita acces deja acordat, o aplicație malițioasă, nu atingea cheia și a fost remediat. Lecția este că un hardware wallet mută încrederea de pe computer pe un dispozitiv mic cu ecran propriu, iar acel dispozitiv include firmware, aplicații și software de însoțire, toate întreținute separat. Securitatea nu e un statut obținut la cumpărare, ci un proces de întreținere: aplicații actualizate, aprobări curățate periodic și, pentru sume mari, un nivel suplimentar de confirmare.
Ce aveți de făcut, pe scurt
- Verificați versiunea și faceți update: în Ledger Live, în managerul de dispozitiv, aplicația Ethereum trebuie să fie 1.22.2 sau mai nouă. Un update de firmware, singur, nu rezolvă.
- Curățați aprobările deschise: verificați ce contracte au drepturi asupra tokenurilor și revocați ce nu mai folosiți.
- Documentați operațiunile: revocările și rearanjările generează taxe și apar în istoric; e mai simplu să le înregistrați pe parcurs decât să le reconstruiți ulterior.
(La data de 25 august 2026. Acest material nu reprezintă sfat de investiții. Prețurile și structurile de comisioane se pot modifica; verificați condițiile la furnizor înainte de achiziție.)