В популярных VPN‑ и VLESS‑клиентах на базе Xray и sing-box обнаружена опасная архитектурная ошибка, которая фактически сводит на нет анонимность прокси-серверов. Любое приложение, установленное на смартфоне, получает возможность узнать реальный IP‑адрес используемого прокси и передать его тем, кто заинтересован в блокировке или отслеживании трафика.
Об уязвимости сообщил исследователь под псевдонимом runetfreedom. По его данным, проблема затрагивает целый ряд клиентов, среди которых Hiddify, v2rayNG, NekoBox, Happ и другие приложения, работающие через ядра Xray и sing-box и поддерживающие протокол VLESS.
Суть ошибки в том, что при запуске такие клиенты поднимают на устройстве локальный SOCKS5‑прокси на адресе 127.0.0.1 без всякой авторизации. Это внутренний адрес самого устройства, который в норме используется только для системных нужд. Однако в данном случае к нему может обратиться любое другое приложение - от безобидных программ до вредоносного софта.
Достаточно отправить запрос к локальному SOCKS5‑прокси, и клиент вернёт реальный IP‑адрес сервера, через который пользователь выходит в интернет. Таким образом, любое приложение на смартфоне потенциально способно деанонимизировать используемый VPN или прокси-сервер, а затем передать эти данные третьим лицам, например блокирующим органам или злоумышленникам.
Отдельная проблема заключается в том, что задействованный loopback‑интерфейс (локальная сеть "внутри" устройства) не изолируется популярными системами песочниц и защищённых контейнеров. Решения вроде Knox, Shelter и аналогичные средства безопасности не блокируют доступ к адресу 127.0.0.1, поэтому даже запуск VPN‑клиента в условно "безопасной" среде не предотвращает утечку информации о сервере.
Особенно критичная ситуация сложилась вокруг клиента Happ. В нём, помимо открытого локального SOCKS5‑прокси, оставлен доступ к Xray API. Это означает, что при должной подготовке можно не только определить IP‑адрес сервера, но и выгрузить полную конфигурацию - включая ключи доступа и другие чувствительные параметры. Фактически, атакующий получает возможность не просто деанонимизировать, но и потенциально скомпрометировать используемую инфраструктуру.
По словам исследователя, большинство разработчиков затронутых приложений получили уведомления об уязвимости, но либо никак на них не отреагировали, либо отложили исправление на неопределённый срок. Представители Happ, как утверждается, прямо отказались что-либо менять в архитектуре клиента. Некоторые команды всё же согласились внести правки, однако публично не сообщается, какие именно проекты готовят обновления и в какие сроки.
Опасность обнаруженной бреши в том, что она не требует сложной эксплуатации. Для атаки не нужно получать системные привилегии, взламывать шифрование или проникать в трафик - достаточно, чтобы на устройстве было установлено приложение, способное установить соединение с 127.0.0.1 и сформировать корректный SOCKS5‑запрос. Это может быть как заведомо вредоносное ПО, так и обычное приложение с скрытым модулем слежки.
На практике такой механизм открывает несколько сценариев злоупотребления. Во‑первых, деанонимизированные IP‑адреса прокси-серверов могут быть оперативно добавлены в списки блокировок. Во‑вторых, информация о серверах может использоваться для построения карт инфраструктуры обхода ограничений и последующего давления на владельцев этих серверов. В‑третьих, в случае с Happ и похожими реализациями злоумышленники могут получить доступ к конфигурациям и попытаться перехватывать трафик.
Контекст обнаружения уязвимости особенно важен на фоне ужесточения отношения к VPN‑сервисам. Российский регулятор в лице Минцифры уже призывает крупнейшие цифровые платформы взаимодействовать с государством в части выявления и передачи информации о сервисах обхода блокировок. Более того, от российских онлайн‑сервисов ожидается готовность делиться сведениями о новых VPN‑решениях и прокси, что делает любую техническую возможность деанонимизации серверов крайне чувствительной.
Для обычных пользователей риск заключается не только в возможной блокировке конкретных серверов. Утечка IP‑адреса прокси может косвенно указывать на принадлежность к определённым сервисам или провайдерам, а при комбинировании с другими данными - использоваться для профилирования, ограничения доступа или целевых атак. Особенно это критично в странах с жёсткой цензурой и уголовной или административной ответственностью за обход ограничений.
С технической точки зрения уязвимость стала следствием удобного, но небезопасного архитектурного решения. Разработчики клиентов на базе Xray и sing-box часто поднимают локальный SOCKS5‑прокси как универсальный "мост" между приложениями и ядром. Это упрощает интеграцию и позволяет любым программам перенаправлять свой трафик через VPN. Но при отсутствии авторизации и ограничений доступа такой мост превращается в открытую дверь для любого софта, оказавшегося на устройстве.
Исправление ошибки теоретически несложно: можно внедрить обязательную авторизацию для локального прокси, ограничить доступ к нему только самим клиентом, добавить фильтрацию по UID/приложениям или вовсе отказаться от публично доступного SOCKS5‑интерфейса в пользу более безопасных внутренних механизмов. Однако на практике это требует переработки архитектуры и может нарушить совместимость, из‑за чего часть разработчиков откладывает изменения.
Пользователям, которые полагаются на VLESS‑ и Vmess‑клиенты для защиты трафика и анонимности, уже сейчас стоит учитывать несколько рекомендаций. Во‑первых, по возможности избегать использования приложений, о которых известно, что они оставляют открытым локальный прокси или Xray API, пока не выйдут обновления с исправлениями. Во‑вторых, минимизировать установку сомнительных программ на том же устройстве, где используется VPN, особенно ПО с чрезмерными разрешениями доступа.
Полезной практикой может стать раздельное использование устройств: одно - для повседневных задач и установки большого количества приложений, другое - для работы через VPN и прокси, где устанавливается только проверенный минимум софта. Это не устраняет уязвимость в самих клиентах, но снижает вероятность того, что на "чистом" устройстве окажется программа, способная обратиться к локальному прокси и слить IP‑адрес сервера.
Разработчикам VPN‑клиентов на базе Xray и sing-box уязвимость даёт важный сигнал: внутренние сервисы, даже работающие только на loopback‑интерфейсе, не могут считаться по умолчанию безопасными. Мобильные ОС не предоставляют строгой изоляции для локального адреса 127.0.0.1 между приложениями, поэтому к таким решениям следует относиться так же, как к любым другим открытым сетевым портам.
В долгосрочной перспективе инцидент может повлиять и на экосистему обхода блокировок в целом. Сервера, которые будут массово деанонимизированы и внесены в чёрные списки, придётся оперативно заменять, а сами провайдеры VPN‑услуг будут вынуждены пересматривать архитектуру клиентов и механизмов подключения. Это может ускорить переход к более сложным протоколам маскировки и динамическим схемам распределения IP‑адресов.
Важно понимать, что обнаруженная брешь не связана с криптографией протоколов VLESS или Vmess как таковых. Слабым звеном стала не передача данных по сети, а логика работы приложений на стороне пользователя. Даже самый надёжный протокол шифрования не спасёт от деанонимизации, если другой софт на устройстве может без ограничений запросить у клиента, к какому именно серверу он подключён.
Пока разработчики не внедрят исправления, пользователям остаётся только взвешивать риски и внимательно следить за обновлениями используемых клиентов. Установка последних версий, чтение технических описаний к релизам, выбор приложений с открытым кодом и активной реакцией на отчёты об уязвимостях - минимальный набор практик для тех, кто всерьёз рассчитывает на сохранение анонимности.
История с уязвимостью в Hiddify, v2rayNG, NekoBox, Happ и других VLESS‑клиентах подчёркивает, что в условиях нарастающего давления на VPN‑сервисы техническая гигиена становится не менее важной, чем выбор конкретного протокола или сервера. Ошибки на уровне архитектуры приложений сегодня могут иметь куда более серьёзные последствия, чем кажется на первый взгляд.
