Критическая уязвимость SharePoint с идентификатором CVE-2026-50522 уже пошла в активную эксплуатацию, и проблема неприятнее обычного «срочно поставьте патч». Злоумышленники крадут machine keys с on-premise серверов Microsoft SharePoint, а это значит, что доступ к системе можно сохранить и после обновления, если атакующий успел закрепиться заранее.
Об этом сообщает BleepingComputer со ссылкой на Microsoft, watchTowr и компанию Defused, которая занимается ранним предупреждением об атаках. По данным Microsoft, речь идет о flaw класса deserialization of untrusted data: удаленный атакующий может выполнить код по сети без аутентификации. В июльских обновлениях SharePoint дыру закрыли, но в advisory ее пометили как уязвимость с повышенной вероятностью эксплуатации. Формально статус «already exploited» тогда не поставили, практически это продержалось недолго.
Сам сценарий атаки выглядит особенно токсично для корпоративной инфраструктуры. Если злоумышленник получает machine keys, он может генерировать валидные токены аутентификации и выдавать себя за легитимных пользователей. Дальше начинается классика плохих дней для ИТ-службы: доступ к сайтам SharePoint, документам и связанным ресурсам открывается уже с привилегиями поддельной личности. Иными словами, патч закрывает входную дверь, но не выгоняет того, кто уже сделал дубликат всех ключей.
По данным watchTowr, 20 июля исследователи обнаружили публичный proof-of-concept для CVE-2026-50522, а уже через несколько часов их глобальная honeypot-сеть Attacker Eye зафиксировала попытки эксплуатации, которые закончились успешной компрометацией целей. Компания отдельно подчеркивает, что атакующие не ограничиваются разовым выполнением кода, а именно вытаскивают machine keys для долгосрочного доступа. Это важная деталь: в истории с SharePoint речь идет не просто о RCE, а о механизме закрепления, который переживает стандартную реакцию «обновили и забыли».
Есть и еще один маркер, что кампания началась не вчера. Defused говорит, что заметила в атаках «недокументированный SharePoint-вектор десериализации» уже 17 июля, хотя тогда аналитики не могли привязать активность к конкретной CVE. Позже компания заявила, что, вероятно, эти атаки и были связаны с CVE-2026-50522. Хронология получается показательная: сначала в полях видят аномальную активность, затем появляется публичный PoC, после чего эксплуатация масштабируется почти мгновенно. Для защитников это уже привычный ритм рынка: окно между публикацией исследовательского кода и массовыми атаками сжалось до часов.
Публичный демонстрационный эксплойт, о котором идет речь, выложил на GitHub исследователь Janggggg. По описанию BleepingComputer, PoC использует вредоносный .NET BinaryFormatter payload, который передается в cookie поддельного SecurityContextToken внутри WS-Federation sign-in response, отправляемого на эндпоинт /_trust/default.aspx. Если SharePoint обрабатывает этот токен через уязвимый путь десериализации, атакующий получает произвольное выполнение кода на сервере. Издание отдельно оговаривает, что не тестировало эксплойт, но с технической точки зрения он выглядит правдоподобно. Важная оговорка: пока неясно, использовали ли злоумышленники именно опубликованный PoC или схожий собственный вариант. Для команды эксплуатации разница, честно говоря, академическая.
Для русскоязычной ИТ-аудитории смысл здесь предельно приземленный. Если у компании SharePoint живет on-premise, одной установкой июльских обновлений закрыться нельзя. После патчинга нужно как минимум проверять признаки компрометации и ротировать учетные данные и ключевой материал на активах, которые могли попасть под атаку, именно такую рекомендацию дает watchTowr. Для ИТ-директоров это отдельная операционная нагрузка, для админов и безопасников — неприятный аудит доверия ко всем токенам, которые система считает валидными. Для бизнеса — напоминание, что старые добрые внутренние порталы с документами по-прежнему остаются очень удобной точкой входа: там и данные, и доступы, и пользователи, которые редко ждут подвоха от корпоративного SharePoint.
История с CVE-2026-50522 еще раз показывает, как изменился цикл эксплуатации корпоративных уязвимостей: advisory, публичный PoC, успешные атаки, закрепление — все это укладывается практически в один уикенд. Главный вопрос теперь не в том, поставили ли администраторы патч, а в том, успели ли атакующие забрать machine keys до того, как окно закрыли. Первоисточник с техническими деталями и упоминанием публичного PoC доступен у .