🚨 Критическая дыра в Remnawave subscription-page

Коротко: в отдельном компоненте remnawave/subscription-page нашли критическую уязвимость. Фикс вышел в версии 7.2.5. Детали эксплойта автор закрыл на 3 месяца (ответственное раскрытие), то есть «как именно ломать» пока знают единицы, но окно для атаки уже открыто, и через 3 месяца способ опубликуют. Закрывать нужно сейчас, до публикации.

📖 Незнакомые слова? Все термины простыми словами есть в Словаре терминов.

⚠️ Уязвим только отдельный браузерный компонент subscription-page. Сам бэкенд Remnawave (панель/API) этой дырой не затронут.

Кого это касается

Тебя это касается, если у тебя поднят отдельный remnawave/subscription-page (красивая страница подписки, на которую ведёт SUB_PUBLIC_DOMAIN). Проверка за 10 секунд:

docker ps | grep subscription-page        # есть контейнер?
ls /opt/remnawave/subscription             # есть каталог?
grep SUB_PUBLIC_DOMAIN /opt/remnawave/.env # куда ведут ссылки клиентов?

Если контейнера нет, а подписку отдаёт сам бэкенд (SUB_PUBLIC_DOMAIN ведёт на панель/бэкенд), ты не уязвим. Важно: sub-страница часто стоит на отдельном сервере за Caddy/CDN, проверяй там, куда реально резолвится твой sub-домен.

Что это за компонент

subscription-page это необязательный фронтенд: отдельный веб-сервис, который принимает короткий ID подписки в URL, ходит на бэкенд за конфигом и красиво его рендерит (HTML-страница для браузера + сырой конфиг для приложений по User-Agent). Версионируется отдельно от бэкенда. Многие ставят его ради брендированной страницы, и именно он дырявый.

Гипотеза: в чём дыра

Официальных деталей нет (эмбарго 3 мес, advisory на GitHub пустой). Но по типу компонента (публичный фронт, который сам делает серверные запросы и рендерит данные) критичное обычно это:

• SSRF: подмена серверного запроса фронта → доступ во внутренние сервисы / админ-API бэкенда / облачную метадату → утечка секретов (API-токен, JWT, пароль БД из .env).
• Path traversal / RCE: чтение произвольных файлов (тот же .env с секретами) или выполнение кода.
• IDOR / перебор: вытащить чужие подписки (конфиги, ключи, список твоих серверов).

Худший сценарий любой из них = слив конфигов/ключей всех твоих клиентов и/или захват панели. Косвенное подтверждение, что дыра в браузерном пути: см. что делает фикс ниже.

Что делает фикс 7.2.5

После обновления компонент блокирует браузерный доступ к странице. На запрос из браузера отдаётся 502, а в логе:

Webpage access is not allowed by Remnawave's SRR

Клиенты-приложения (по User-Agent) получают конфиг штатно (200). То есть фикс закрыл именно браузерный webpage-путь, отсюда и гипотеза, что дыра была там.

Способ 1: патч (минимум усилий)

В каталоге компонента:

cd /opt/remnawave/subscription
docker compose pull        # тянет свежий :latest (= с фиксом)
docker compose down
docker compose up -d

Проверь, что образ реально сменился (а не «уже актуальный»):

docker inspect remnawave-subscription-page --format '{{.Image}}'
docker image inspect remnawave/subscription-page:latest --format '{{.Created}}'

Image id и дата сборки должны быть свежими. Подписки клиентам продолжают идти, обрыва нет.

Способ 2: убрать компонент (надёжнее)

Раз бэкенд этой дырой не затронут, можно вообще не держать уязвимый фронт и отдавать подписку прямо с бэкенда за Cloudflare:

1. На сервере бэкенда сделай server-блок (nginx/Caddy): sub-домен → http://<backend>:3000.
2. Серт для sub-домена (LE или CF Origin Certificate на 15 лет).
3. SUB_PUBLIC_DOMAIN = этот домен, в Cloudflare включи оранжевое облако (origin скрыт, из РФ доступно).
4. Погаси subscription-page.

Плюсы: уязвимого компонента больше нет (патчить нечего), origin за CF, на один сервис меньше. Минус: теряешь брендированную браузерную страницу подписки (но клиентам-приложениям всё равно).

Что выбрать

• Нужна красивая браузерная страница → патч (способ 1) + следи за обновлениями компонента.
• Браузерная страница не критична (клиенты в приложениях) → способ 2, и забудь про этот класс дыр.

В любом случае, не тяни: через ~3 месяца эксплойт станет публичным, и непропатченные sub-страницы начнут массово выгребать.