Ledger закрив у застосунку Ethereum вразливість, що дозволяла підміняти дані транзакції під час підпису

Власникам Ledger, які керують Ether або токенами ERC20, варто відкрити Ledger Live і перевірити версію застосунку Ethereum на пристрої. У версіях нижче 1.22.2 відсутнє важливе виправлення безпеки. Воно закриває збій, який б'є в основу сенсу апаратного гаманця: екран має показувати саме те, що пристрій підписує. Публічно про проблему стало відомо 24 серпня 2026 року після виходу аналізу від компанії з кібербезпеки TestMachine. На той момент виправлення вже існувало. Між цими датами розгорівся спір про те, хто першим виявив вразливість і коли Ledger фактично поставив патч. Для власника це другорядне. Важливі дві речі: яка версія Ethereum app стоїть на пристрої та які дозволи (approvals) ви могли видати раніше. Що саме зламалося в Ethereum app За наявними даними, ні прошивка пристрою, ні зберігання приватного ключа не постраждали. Проблема була у застосунку Ethereum — окремому модулі, який встановлюють на Ledger для роботи з Ether та ERC20. Саме він готує транзакцію, показує її на екрані та збирає підтвердження користувача. У вразливих версіях цей процес можна було "розсинхронізувати". Шкідливий вебзастосунок, який має доступ до під'єднаного пристрою, міг надіслати другу команду на підпис, поки перша транзакція ще відображалася на екрані та чекала на перевірку. Далі застосунок міняв дані в пам'яті без повторного показу екрана з деталями. На дисплеї залишалася "безпечна" операція, яку ви щойно переглянули, але підтвердження застосовувалося до підмінених даних. Дослідники зазначають, що відтворили цей сценарій на Ledger Flex. Оскільки різні моделі значною мірою використовують спільний код Ethereum app, потенційно вразливими вважають також Nano X, Nano S Plus, Stax та Apex. Ledger не повідомила, з якої саме версії помилка з'явилася; порівняння дослідників починається з 1.22.1 — попередньо позначеної версії від 27 травня 2026 року. Чому "clear signing" — ключова обіцянка апаратного гаманця Clear signing означає, що перед підтвердженням пристрій показує на власному екрані повні дані транзакції у зрозумілому вигляді: адресу отримувача, суму, а для викликів смартконтрактів — дію, яку має виконати контракт. У цьому й сенс апаратного гаманця: комп'ютер може бути заражений, браузер — підміняти інтерфейс, сайт — бути фішинговим. Але якщо екран на пристрої незалежно показує реальні дані, маніпуляцію можна помітити до натискання підтвердження. У цьому випадку приватний ключ не виходив з пристрою, прошивку не чіпали, але користувач міг підтвердити іншу дію, ніж ту, яку прочитав. Якщо екран не можна вважати "остаточною істиною", то за цією ознакою пристрій наближається до софтверного гаманця на скомпрометованому ПК. Технічна суть: race condition та APDU Проблема належить до класу race condition — помилок, коли результат залежить від того, яка з майже одночасних команд буде оброблена першою. Такі баги підступні: код може виглядати правильним, і в більшості випадків усе працює штатно. Вони проявляються, коли хтось спеціально вибудовує порядок виконання. APDU — формат команд, яким смарткарти та апаратні гаманці обмінюються даними з під'єднаним комп'ютером. Підпис транзакції складається з кількох таких кроків. Ethereum app тримав внутрішній стан, що фіксував, яка транзакція зараз на перевірці. Цей стан можна було перезаписати, поки перевірка ще тривала. Чому браузер узагалі спілкується з пристроєм: WebHID WebHID — браузерний інтерфейс, який дозволяє сайту напряму взаємодіяти з USB-пристроєм після того, як користувач явно надав дозвіл. Без цього апаратним гаманцем було б незручно користуватися всередині dApp; з ним сайт отримує доступ ближче до пристрою, ніж багато хто усвідомлює. Описана атака потребує, щоб ви вже надали доступ (permission) скомпрометованому або підміненому сайту і ініціювали там транзакцію. Дистанційно, на пристрій "у шухляді", це не працює. Колу потенційно вразливих це звужує, але не нівелює ризик для активних користувачів DEX, мостів або staking-інтерфейсів, які регулярно видають такі дозволи. Підміна переказу на token approval: чому небезпечні безлімітні дозволи У подібних сценаріях найбільший ризик часто не в самому переказі, а в тому, що його можуть замінити. Token approval — це дозвіл смартконтракту надалі списувати певну кількість ваших токенів без окремого підтвердження кожного списання. Для зручності багато застосунків запитують безлімітні approvals. Один раз виданий дозвіл не має строку дії та зберігається, доки ви його явно не відкличете. Різниця проста: переказ коштує рівно ту суму, яку ви підтвердили. Безлімітний approval у найгіршому випадку може коштувати весь баланс відповідного токена у момент, який обере отримувач дозволу. Саме тому підміна невеликого переказу на "далекобійний" approval є вигідною для атакуючого. Оновлення до Ethereum app 1.22.2 через Ledger Live Версія 1.22.2 закриває описаний шлях двома запобіжниками: застосунок не приймає нову сесію підпису, поки триває перегляд, і відхиляє підтвердження, якщо внутрішній стан не відповідає тому, що було показано на екрані. Оновлення робиться у Ledger Live: під'єднайте пристрій, відкрийте менеджер встановлених застосунків і оновіть Ethereum app. Баланси не зміняться, адже ключі походять із recovery phrase і не "зберігаються" всередині застосунку. Видалення та повторне встановлення застосунку також не "коштує" монет. Як перевірити версію У Ledger Live в менеджері пристрою біля кожного застосунку показано номер версії. Якщо це 1.22.2 або вище — патч встановлено. Якщо 1.22.1 або нижче — виправлення немає. Перевірити лише версію Ledger Live недостатньо. Чому оновлення прошивки не оновлює Ethereum app Прошивка, Ledger Live та окремі coin apps підтримуються й оновлюються незалежно. Тому користувач може оновити firmware і помилково вважати, що все актуально, хоча Ethereum app на пристрої лишився застарілим. Ця ж відокремленість пояснює, чому порівняння інцидентів у різних гаманцях часто "не сходяться": десь проблема в seed, десь у firmware, а тут — на рівні замінного застосунку, тож достатньо оновлення app. Recovery phrase перевипускати не потрібно. Другий крок після оновлення: перевірити та відкликати старі approvals Патч захищає майбутні підписи, але не скасовує дозволи, видані раніше. Якщо ви протягом останніх місяців активно користувалися dApp, має сенс переглянути відкриті approvals для вашої адреси. Блок-експлорери та спеціалізовані інтерфейси показують, які контракти мають право розпоряджатися якими токенами. Непотрібні дозволи можна відкликати по одному. Відкликання — це звичайна транзакція з мережевою комісією. Практично робити таке "прибирання" у періоди нижчих комісій. Варто врахувати й побічний ефект: кожне відкликання потрапляє в історію транзакцій і генерує витрати. Тим, хто акуратно веде облік рухів, легше підготувати податкову звітність; типові податкові та портфельні сервіси зазвичай імпортують такі події автоматично. Спір щодо розкриття: версія Ledger проти TestMachine Є дві версії подій, які не збігаються. Обидві наведено як твердження сторін і незалежно не підтверджено. CTO Ledger Шарль Гійєме (Charles Guillemet) заявив, що помилку виявила власна лабораторія Ledger Donjon, а виправлення відвантажили приблизно за два тижні до публікації. За його словами, TestMachine звернулася до bug bounty уже після цього, а публічні заяви компанії він охарактеризував як нагнітання страху заради уваги. TestMachine відповідає, що слабкість знайшла їхня автоматизована система тестування Azimuth на Ledger Flex і результати передали Ledger. На момент публікації, на думку TestMachine, виправлення не було доступним. Перевірювані факти частково лежать посередині. У журналі змін для 1.22.2 стоїть дата 12 серпня 2026 року, підписаний тег у репозиторії — 13 серпня. Як опублікований реліз це стало видимим приблизно 24 серпня, одночасно з виходом аналізу. Користувач, який намагався перевірити наявність патча раніше, міг його там не знайти. Технічну реконструкцію хронології з цими датами зібрав CryptoSlate. Чи є підтверджені втрати коштів За даними, які наразі надали обидві сторони, підтверджених випадків експлуатації немає. Документованих втрат не наведено, а витяг приватних ключів цим шляхом і так був неможливий. Водночас важлива обмовка: підпис, отриманий у такий спосіб, на блокчейні виглядатиме як звичайний добровільний підпис. Постраждалий може помітити проблему лише коли токени згодом почнуть виходити з гаманця, і списати це на типове фішингове шахрайство. Тому відсутність підтверджених кейсів не доводить напевно, що їх не було — це оцінка, а не зафіксований факт. Що цей інцидент говорить про апаратні гаманці та self-custody Зводити висновок до відмови від апаратних гаманців було б помилкою. Для атаки потрібні вже наданий доступ до пристрою та шкідливий застосунок, приватний ключ не був скомпрометований, уразливість виправлено. Практичний висновок інший: апаратний гаманець переносить довіру з комп'ютера на невеликий пристрій із власним екраном, але цей пристрій складається з прошивки, застосунків і супровідного софту, які оновлюються окремо. Безпека тут — не стан "після покупки", а постійне обслуговування: тримати застосунки актуальними, регулярно чистити approvals і для великих сум додавати другий рівень підтвердження. Що робити зараз: короткий чеклист 1) Перевірте версію Ethereum app і оновіть. У Ledger Live відкрийте менеджер пристрою та переконайтеся, що встановлено 1.22.2 або вище. Оновлення прошивки само по собі цього не гарантує. 2) Перегляньте та відкличте зайві token approvals. Перевірте, які контракти мають дозволи на ваші токени, і скасуйте ті, якими ви більше не користуєтеся. 3) Фіксуйте дії. Відкликання та перерозподіли створюють комісії й записи в історії; зручніше документувати це одразу, а не відновлювати заднім числом. (Станом на 25 серпня 2026 року. Матеріал не є інвестиційною порадою. Ціни та комісії змінюються; перед покупкою перевіряйте умови у провайдера.)