XRP Healthcare опубликовала предварительные итоги расследования инцидента с кошельком XRPH: несанкционированные транзакции затронули около 4 011 кошельков, а общий ущерб оценивается примерно в $452 000 в цифровых активах.
По данным аналитической платформы xrpl.to, вечером 3 сентября 2026 года адрес, которого часом ранее не существовало, получил средства сразу с 4 011 кошельков: 267 664 XRP, 23,2 млн XRPH и 2,43 млн XRPHAI. Затем часть активов была направлена через NEAR Intents: 311 613 XRP конвертировались в 178,46 ETH, после чего превратились в 445 198 DAI на одном Ethereum-адресе. На момент публикации отчёта эти средства оставались без движения.
Компания подчеркнула, что предварительное расследование не выявило вины самого XRP Ledger. Уязвимость, вероятно, находится на уровне приложения: xrpl.to утверждает, что XRPH-платежи подписываются на телефоне, seed хранится в незашифрованном виде, а функция стейкинга отправляет seed на сервер XRP Healthcare. Из 1 225 кошельков, использовавших стейкинг почти все в период с декабря 2023 по июль 2024 года, были опустошены 1 198, включая собственный стейкинг-кошелёк компании. При этом семь из десяти пострадавших никогда не пользовались стейкингом, что указывает на возможную компрометацию всей пользовательской базы приложения.
Приложения XRPH Wallet были отключены командой в качестве меры предосторожности, а не удалены злоумышленником. XRP Healthcare призвала пользователей не использовать кошелёк до завершения расследования. Компания не гарантирует возврат средств, не объявила программу компенсаций и не подтвердила заморозку активов, хотя намерена добиваться внесения адреса в чёрные списки и рассматривать другие способы восстановления. Пользователям рекомендовано перевести оставшиеся средства на вновь созданные seed-фразы и не доверять посторонним сообщениям с предложениями вернуть активы за предоплату или передачу ключей.
Эксперты отмечают: отслеживание активов в публичном реестре не равно их возврату, поскольку контроль сохраняется за держателем приватного ключа. Окончательный технический разбор должен установить затронутые версии приложения, путь утечки ключей, период риска и принятые меры защиты.
