Вскоре после нахождения шпионского модуля в Max я обнаружил критическую уязвимость во всех известных VLESS клиентах.
Эта уязвимость позволяет обходить per-app split tunneling и приватные пространства (Knox/Shelter/Island/etc) и гарантированно обнаруживать выходной ip прокси, который вы используете.
При этом один из клиентов уязвим настолько, что позволяет дампить ваши конфиги и, в худшем случае, расшифровать весь ваш трафик.
Я сообщил об этом разработчикам этих клиентов, но они это проигнорировали. На днях минцифры разослала методичку, из которой ясно что они либо знают, либо скоро узнаю об этой уязвимости.
Я решил, что ждать больше нельзя и нужно публиковать статью об этом чтобы у вас всех был хотя бы шанс. Но сейчас защиты от этого нет.
Предпосылки
Пока некие нехорошие люди ломали копья и кричали во все горло, что тот факт, что Max превращают в карманный ревизор это все выдумки и конспирология, Минцифры открыто потребовало от аккредитованных российских IT компаний внедрения в свои продукты шпионских модулей, которые будут помогать блокировать персональные впн серверы.
Так же они выпустили подробную методичку как именно должны работать такие модули, какие функции иметь и какую информацию о VPN собирать.
Так что теперь маленький РКН будет сидеть в каждом российском приложении.
Уязвимость
Все мобильные клиенты на основе xray/sing-box запускают локальный socks5 прокси без авторизации.
При этом per-app split tunneling реализуется используя VpnService, который перенаправляет трафик в tun2socks (или что-то похожее). Схема выглядит следующим образом:
VpnService -> tun2socks -> xray socks5 -> VPN server -> freedom
Но если на устройстве пользователя находится spyware (к примеру как часть какого-то государственного приложения), то ничего не мешает ему напрямую подключиться к этому xray socks5 proxy минуя VpnService и узнать внешний ip адрес и заблокировать его.
Ситуацию осложняет то, что android private space (Knox, Shelter, Island, etc) хотя и изолирует VpnService, но не изолирует loopback интерфейс. Это значит что даже если spyware находится внутри private space, то все равно возможно просканировать все localhost порты и найти socks5 proxy. Это очень плохо тем, что дает ложное чувство безопасности.
Судя по всему РКН либо знают, либо очень близки к самостоятельному нахождению этой уязвимости. Вот цитата из их методички:
Список характерных Proxy-портов для разных технологий: SOCKS: 1080, 9000, 5555, 16000-16100; http: 80, 443, 3128, 3127, 8000, 8080, 8081, 8888; прозрачные Proxy: 80, 443, 4080, 7000/7044, 8082, 12345; Tor: 9050, 9051, 9150.
Я так же публикую POC обхода per app split tunneling вот тут: https://github.com/runetfreedom/per-app-split-bypass-poc
Сама техника уже эксплуатировалась Яндексом ранее
Какие клиенты были проверены
10 марта 2026 года я разослал разработчикам всех популярных VLESS клиентов информацию об этой уязвимости. На сегодняшний день (7 апреля 2026) ни один клиент это не исправил.
Вот список клиентов которые я проверил и уведомил разработчиков:
Happ - уязвим и особо опасен, не рекомендуется использовать ни при каких обстоятельствах. Подробности ниже.
v2RayTun - уязвим
V2BOX - уязвим
v2rayNG - уязвим
Hiddify - уязвим
Exclave - уязвим
Npv Tunnel - уязвим
Neko Box - уязвим
Так же самые распространенные Clash и Sing-box клиенты в распространенных конфигурациях так же уязвимы.
Кто-то из разработчиков пообещал исправить (но, как видно, еще не), кто-то сразу сказал, что исправлять это не будет.
У меня у одного не получилось их убедить, возможно если мы все вместе обратимся к ним или кто-то пришлет PR, то это исправят.
Нам всем нужен хотя бы один безопасный клиент. В текущей ситуации уже не до большого.
Минус в том, что кроме включения авторизации на socks5 придется выключить UDP, так как UDP в socks5 работает фактически без авторизации.
Happ
Клиент Happ по праву удостоился отдельного раздела в этой статье. По никому не известной причине они активируют xray api без авторизации с включенным HandlerService, который позволяет буквально дампить пользовательские конфиги, включая ключи, входной ip адрес сервера и sni.
Если в связке с этим цензор проэксплуатирует еще одну достаточно распространенную уязвимость конфигурации xray, то он сможет буквально расшифровать трафик пользователя. По очевидным причинам я не буду раскрывать эту уязвимость тут. Если кто-то догадается что я имею в виду, то очень прошу не распространяться об этом.
Так же клиент Happ был подвергнут анализу и реверс инжинирингу, но не удалось найти ни одной разумной причины включать HandlerService. Выдвигались предположения, что это сделано для переключения конфигурации на лету, но нет - при смене конфига Happ явно перезапускает xray.
Когда я сообщал им об этой уязвимости и предоставил POC, то они сказали что им это нужно для сбора статистики подключения, что является наглой ложью. Для этого было бы достаточно только LogService (который тоже включается). Более того, не ясно причем тут статистика и управление конфигурацией.
Вы можете очень легко проверить это свайпом по серверу вправо -> поделиться -> json. Даже там будет видно как запускается api.
На уровне слухов злые языки говорят, что это бекдор и он был добавлен не случайно, а за некий крупный финансовый интерес. Я не знаю правда это или нет, но в любом случае исправить это уже невозможно. Их клиент удалены из русского AppStore, так что они не смогут выпустить обновление.
Единственный выход тут - заблокировать Happ на серверах своих подписок по UserAgent Happ/*. Помните - даже один пользователь вашего VPN сервера с уязвимым клиентом сдаст вас цензору с потрохами (включая входной ip и sni) и вашему серверу капут.
Я тестировал обычные конфиги и обычные подписки, не знаю как будут работать json подписки, но они не особо распространены.
В целом от общения с ними сложилось отвратительное впечатление. Все остальные разработчики нормально разговаривали и обсуждали (включая авторов огромных проектов), эти же ребята сразу включили какой-то дикий гонор, что у них тут коммерческий продукт и почти Big Tech, так что они понимают уж лучше всяких проходимцев. Забавно, что при этом разработчик другого коммерческого клиента (v2RayTun), у которых нет таких диких дыр, поблагодарил и сказал, что исправят.
Может быть ребята из Happ вели себя так, потому что были очень недовольны тем фактом, что я вообще это нашел.
Есть ли спасение?
А вот на вопрос что делать хорошего ответа нет. Прямо сейчас нет VLESS клиента, который не подвержен этой уязвимости или хотя бы позволяет вручную активировать socks5 авторизацию. А на iOS с этим особенно сложно, так как большинство клиентов удалено из стора, следовательно не получат обновления.
Per-app split tunneling и приватные окружения не спасут.
Даже если кто-то сейчас выпустит фикс, то останутся миллионы людей со старыми версиями приложения.
Поэтому я предлагаю готовиться к тому, что цензор обязательно узнает ваш выходной IP. Вот как мы можем поступить в этой ситуации:
Иметь отдельные входные и выходные IP. Если цензор узнает ваш выходной IP, то вы все еще сможете подключаться к входному и пользоваться интернетом. 1а. Если у вас нет возможности получить второй IP, то в качестве альтернативы вы можете завернуть весь ваш выходной трафик в CloudFlare WARP.
Следует применить раздельную маршрутизацию. На российских IP адресах нет заблокированных ресурсов (с ними борются другими методами). Так что на клиентах вам следует иметь стратегию
geoip:ru->direct,other->proxy.На сервере вам нужно заблокировать доступ обратно в
geoip:ru. Если вы этого не сделаете, то шпионы в яндексах/wb/ozon’ах и т.д. сдадут цензору то, что вы пользуетесь прокси и цензор сможет найти ip подключения проанализировав паттерн трафика. Я понимаю, что решение это сложное и неудобное, но и обстоятельства сейчас особые.
Кстати, для Windows нужная стратегия уже реализована в клиенте в v2rayN (пресет “Все, кроме РФ”)
Обычно я так не делаю, но эту статью вероятно скоро удалят, так что я попрошу всех вас помочь в распространении этой информации. Без огласки и помощи комьюнити справиться будет очень сложно.
UDP 1. Через час после публикации статьи разработчик Happ в своей телеграм группе отказался считать это уязвимостью и отказался исправлять даже под давлением своей собственной аудитории
