Некоторые пользователи Keplr, входившие через Google или Apple, сообщили о несанкционированных операциях. Кошелёк Web3Auth приостановил связанные сервисы на время расследования инцидента. Вопрос касается не только доступа к аккаунтам, но и возможной утечки приватных ключей, а также судьбы активов. Импорт ключа в другой кошелёк меняет способ доступа к аккаунту, но сам по себе не означает, что ключ остаётся конфиденциальным.
Web3Auth приостановила сервисы; срок возобновления не назван
7 ноября Keplr сообщила, что в некоторых аккаунтах, созданных с помощью входа через Google или Apple, прошли несанкционированные операции. После этого компания отключила оба способа входа. В тот же день Web3Auth заявила, что обнаружила проблему безопасности в своей инфраструктуре, затронувшую некоторые встроенные кошельки Keplr.
В уведомлении Web3Auth указано, что техническое обслуживание началось 6 ноября в 18:30 UTC в связи с инцидентом. По состоянию на 8 ноября, 13:08 UTC, компания обещала опубликовать обновление после восстановления сервиса. Указанное окно обслуживания завершилось 7 ноября, однако в уведомлении не подтверждалось, что работа сервиса возобновилась.
В заявлении от 7 ноября MetaMask Builder сообщила, что предварительное расследование не выявило влияния на пользователей MetaMask. Это заявление относится к MetaMask и не раскрывает ни число затронутых аккаунтов Keplr, ни статус их активов.
Импорт ключа не устраняет риск его компрометации
В рекомендациях по безопасности, обновлённых в сентябре 2025 года, Keplr указывает, что для аккаунтов со входом через Google используется сгенерированный Web3Auth приватный ключ в шестнадцатеричном формате, а не фраза восстановления. Ключ зашифрован и хранится на устройстве пользователя. В документации Keplr также описана возможность просмотреть ключ, хотя для некоторых старых аккаунтов она может быть недоступна. Отдельная инструкция для мобильного приложения охватывает вход через Google и импорт аккаунтов с помощью фразы восстановления или приватного ключа; пользователям рекомендуется хранить ключи в безопасности.
Эти инструкции показывают, что приватный ключ может служить способом доступа, отдельным от входа через Google. Однако наличие функции просмотра или экспорта не означает, что каждый пострадавший пользователь мог получить ключ во время приостановки сервисов. Документация также не подтверждает, что альтернативный способ входа работал в ходе инцидента.
В более позднем обновлении от 7 ноября Keplr сообщила, что приватные ключи некоторых пользователей, входивших через социальные сети, были скомпрометированы. Компания заявила, что совместно с Web3Auth работает над защитой активов. По данным Keplr, аккаунты, созданные с помощью фразы восстановления или аппаратного кошелька, не затронуты; риск касается аккаунтов, связанных с Google или Apple. Потенциально пострадавшим пользователям компания рекомендовала не переводить на эти аккаунты новые средства, а оставшиеся активы, которые можно переместить, перевести на аккаунт, защищённый фразой восстановления или аппаратным кошельком.
Импорт того же приватного ключа в другой кошелёк меняет программу, через которую пользователь обращается к аккаунту, но не секрет, позволяющий подтверждать операции. Если ключ был раскрыт, смена интерфейса не гарантирует, что другие лица утратили возможность им воспользоваться. Поэтому общие инструкции по импорту ключа не заменяют рекомендации Keplr, выпущенные в связи с инцидентом, и не дают решения, работоспособность которого подтверждена для каждого затронутого аккаунта.
Изменение баланса нужно оценивать с учётом мер защиты
Web3Auth сообщила, что вместе с партнёрами начала операцию по восстановлению уязвимых кошельков Keplr, которые ещё не пострадали. Для этого использовался маршрут, которым ранее воспользовался злоумышленник. Keplr предупредила, что из-за мер по снижению ущерба баланс некоторых аккаунтов мог уменьшиться или обнулиться. Ответ осложняет и то, что часть активов находится в стейкинге или заблокирована.
Незнакомый перевод или снижение баланса сами по себе не позволяют определить, было ли изменение следствием атаки, защитных действий или другой меры реагирования. Воздействие на каждый аккаунт, ход возврата активов и возможность пользователей получить приватные ключи необходимо оценивать отдельно. Даже если сервисы входа заработают снова, это подтвердит доступность сервиса, но само по себе не докажет, что ключи защищены или активы возвращены.