Минулого тижня один з дослідників безпеки оприлюднив шокуючий випадок: у оновленні гаманця від 24 грудня було вмонтовано бекдор-код, що призвело до витоку приватних даних користувачів (включно з мнемонічними фразами), що спричинило збитки понад 200 мільйонів доларів США.

Цей інцидент на перший погляд здається новим, але при детальнішому аналізі він фактично відображає стару проблему покоління гаманців — відсутність контролю користувача над безпековими межами.

**Яка справжня небезпека плагін-гаманців**

Багато хто при обговоренні таких випадків звикла перекладати провину на користувача: «Може, імпортував мнемоніку? Може, випадково натиснув не ту кнопку?» Але з точки зору продуктового дизайну проблема не в цьому. Головний ризик криється у самому механізмі автоматичного оновлення.

Плагін-гаманці мають одну нездоланну реальність:

Кожне автоматичне оновлення фактично є повним дозволом на доступ до всіх ваших активів.

Якщо код у файлі оновлення буде змінено — можливо, через внутрішню проблему, або частіше — через атаку на ланцюг постачання (злому CI/CD процесів, середовища збірки, каналів розповсюдження) — зловмисна логіка може виконатися, коли користувач навіть не помітить. І користувачі цього навіть не здогадуються.

Ще більш боляче: цей ризик не обмежується лише сценаріями гарячих гаманців. Навіть якщо ви використовуєте плагін для підключення до апаратного гаманця — це також піддає ризику. Адже плагін контролює:

- те, що ви бачите у транзакціях
- адреси, які ви підтверджуєте
- всю інформацію перед і після підписання

Апаратний гаманець гарантує, що «приватний ключ ніколи не покине чіп», але не може гарантувати, що ви підписуєте саме ту транзакцію, яку думаєте. Якщо плагін має злі наміри, він може змусити вас підписати один об’єкт, а на ланцюгу виконати інший.

**Чому це стає системною проблемою**

Корінь проблеми — у централізованих правах на оновлення. Після встановлення плагіна користувач повністю передає безпеку своєї системи команді розробників. Вони можуть бути надійними, але якщо будь-який елемент інфраструктури — сервери, процеси розповсюдження, комп’ютери співробітників — буде зламаний, це може призвести до масштабних втрат активів.

А користувачі залишаються пасивними — вони не бачать, що саме оновлюється, і не можуть відмовитися від конкретної версії оновлення.

Саме тому вся спільнота Web3 почала переосмислювати архітектуру гаманців. Деякі проєкти досліджують механізми оновлення на основі розділення ключів, з можливістю верифікації користувачем, або ж архітектури з пріоритетом локальних рішень — щоб користувачі мали реальний контроль над безпекою своїх активів, а не просто довіряли.