Критические уязвимости ShareFile открывают неаутентифицированный RCE

А что, если ваша 'надёжная' платформа обмена файлами просто отдаст атакующим ключи от сети — без единого запроса пароля? Две критические дыры в ShareFile делают это пугающе реальным.

Диаграмма цепочки уязвимостей ShareFile от обхода редиректа до RCE с веб-шеллом

Key Takeaways

  • Две дыры (CVE-2026-2699 EAR, CVE-2026-2701 загрузка) цепляются для неаутентифицированного RCE в ShareFile.
  • Атакующие захватывают Storage Zones для эксфильтрации файлов или сброса веб-шеллов в webroot.
  • Патч до 5.12.4+; подчёркивает риски гибридных on-prem-архитектур обмена файлами.

Задумывались ли вы, почему корпоративное ‘приватное’ хранилище файлов ощущается скорее как дырявое ведро, чем как неприступный сейф?

Уязвимости ShareFile — конкретно две критические, выявленные WatchTowr — разрывают эту иллюзию в клочья. CVE-2026-2699 и CVE-2026-2701 соединяются в цепочку для неаутентифицированного удалённого выполнения кода (RCE), превращая инструмент совместной работы в песочницу для хакеров. И вот загвоздка: всё начинается с такой хитрой мелочи, как сбившийся редирект.

ShareFile предназначен для безопасной синхронизации файлов между облаками и on-prem-системами. Но атакующим не нужны учётки. Они бьют по админскому эндпоинту, активируя уязвимость Execution After Redirect (EAR). В браузере? Редирект на логин. Но подправьте ответ — уберите заголовок Location — и вуаля, вы на странице конфигурации Storage Zone.

А дальше? Кровавая баня. Переконфигурируйте зоны, чтобы они указывали на S3-бакеты под контролем атакующего. Эксфильтрируйте файлы при синхронизации. Или хуже: заставьте контроллеры жертвы перейти в злые зоны, перехватив админские права для выгрузки данных куда угодно.

«Мы могли изменить Storage Repository жертвы, чтобы оно указывало на AWS S3-бакет под нашим контролем. При синхронизации или загрузке файлов в инстанс они уходили в наше хранилище — по сути, эксфильтрация чувствительных данных», — отмечает WatchTowr.

Как простой редирект превращается в админский апокалипсис?

Всё упирается в ленивые проверки авторизации — или их полное отсутствие после редиректа. Архитектура ShareFile слишком доверяет потоку. Админские страницы? Предполагаются localhost-only. Но подкрутите HTTP в пути — и оборона слетает. Атакующие модифицируют ответы на лету, выуживают конфиги, меняют passphrase. И Storage Zone Controller внезапно переходит на тёмную сторону.

Ничего тонкого. Встроенные фичи позволяют перенаправлять загрузки в webroot. В произвольные места. Это CVE-2026-2701 на подхвате — неограниченная загрузка файлов. Сбросьте веб-шелл. Выполните код. Игра окончена.

WatchTowr связала их: EAR для доступа, загрузка для RCE. Без логина. Неаутентифицировано. На уязвимых инстансах.

Это не просто баг. Это гниль в архитектуре гибридного обмена файлами. ShareFile (принадлежит Citrix) продвигает on-prem-контроллеры для ‘контроля’ — но они превращаются в лакомые цели. Напоминает старые утечки Dropbox API 2012-го, когда кривые конфиги слили миллионы файлов. История рифмуется: обещают безопасность, подсовывают чёрный ход.

Но почему именно сейчас? Корпорации цепляются за on-prem-шары файлов на фоне облачного паранойи. ShareFile продаёт эту гибридную мечту. Однако эти дыры кричат: ваша ‘приватная’ зона публична, если прищуриться.

Почему это рвёт вашу сеть в клочья?

Представьте: атакующий захватил контроллер. Файлы текут в их S3. Или шеллы плодятся в webroot, переходя на боковой вектор. CVSS 9.8 и 9.1? Это территория апокалипсиса.

«Такие продукты обычно позволяют указывать место хранения файлов. Мы могли просто переконфигурировать ShareFile, чтобы загруженные файлы сохранялись в опасном месте, например в директории webroot приложения», — объясняет WatchTowr.

Глубже: Storage Zones в ShareFile децентрализуют контроль — круто для масштаба, катастрофа для сегрегации. Одна слабая звено тянет за собой эксфильтрацию, RCE, персистентность. Если синхронизируете чувствительные доки (юрка, HR, IP), это ваш вектор взлома.

Моё мнение? PR Citrix отпишется ‘быстро запатчили’ — сообщили в феврале, фикс в 5.12.4. Но это маскирует сдвиг: on-prem-обмен файлами отмирает. Облачные Box или Dropbox вылизывают такие углы с zero-trust. ShareFile держится за legacy — и это заметно. Прогноз: в 2025-м жди массовых миграций после этого.

Короткий абзац для удара: патчьте сейчас.

Патч — и большой звоночек

Версии до 5.12.4? Уязвимы. 6.x в безопасности. Но копаясь в коде, WatchTowr выявила халтуру: нет охраны авторизацией на чувствительных эндпоинтах, загрузка без проверок. Пофиксили? Да. Системно?

Нет. Это обнажает линию разлома в обмене файлами. Админы думают, ‘аппарат’ = безопасно. Ошибка. Сетевой экспоуз провоцирует EAR-трюки. Будущее? Бросьте силосы ради облака с API-шлюзами.

Сравните с бедой Citrix NetScaler — та же семья, то же кровотечение. CISA следит за похожим. Ваш ход: аудит зон, сегментация, мониторинг загрузок.

И уникальный угол? Эти дыры эхом отзываются на RCE в Apache Struts у Equifax (2017) — подкрутка конфига ведёт к тотальному компромиссу. ShareFile не веб-приложение; это хребет предприятия. Ставки выше.


🧬 Связанные материалы

Часто задаваемые вопросы

Что такое критические уязвимости ShareFile CVE-2026-2699 и CVE-2026-2701?

Это EAR-дыра для неаутентифицированного доступа к конфигу и произвольная загрузка файлов для RCE — цепляются без логина.

Мой инстанс ShareFile защищён от неаутентифицированного RCE?

Обновитесь до 5.12.4+ или 6.x; старые версии под высоким риском при экспоузе.

Как уязвимости ShareFile приводят к эксфильтрации данных?

Атакующие переконфигурируют зоны на свой S3, синхронизируя файлы жертвы наружу.

Marcus Rivera
Written by

Tech journalist covering AI business and enterprise adoption. 10 years in B2B media.

Worth sharing?

Get the best AI stories of the week in your inbox — no noise, no spam.

Originally reported by SecurityWeek