Исследователь безопасности сообщил об уязвимости инъекции параметров OAuth в библиотеке auth0/nextjs-auth0 от Okta, которая позволяла злоумышленникам манипулировать токенами и URI перенаправления. Он предложил простой патч с кодированием параметра, но через три недели его PR закрыли, сославшись на другой, "подписанный" коммит. Оказалось, что оригинальный вклад исследователя был присвоен с использованием ИИ, который создал фиктивного автора "Simen A. W. Olsen" с несуществующим email.

Мейнтейнер признал использование ИИ для создания коммита и даже сгенерировал ИИ-ответ с извинениями, но отказался исправить атрибуцию, заявив, что "не может это изменить". Это привело к обвинениям в нарушении авторских прав. Параллельно первая уязвимость, позволявшая захватывать аккаунты, была исправлена только после трёхнедельного ожидания, а команда безопасности Okta заявила, что не примет отчёт об уязвимости без видеодемонстрации эксплуатации.

• Комментаторы обсуждают, что Okta и Auth0 не редко становятся объектом критики за игнорирование PR и отсутствие прозрачности в open-source-проектах.
• Участники также отмечают, что крупные корпорации, включая Okta, плохо справляются с внешними вкладами и не предоставляют должного признания авторам вкладов.
• Некоторые комментаторы поднимают вопрос о том, что использование SaaS-решений вроде Okta и Auth0 может быть рискованным, особенно если учесть их историю игнорирования уязвимостей и отсутствие прозрачности.
• Также обсуждается, что GitHub и другие платформы могли бы улучшить свой процесс рассмотрения PR и взаимодействия с внешними вкладами, чтобы избежать подобных ситуаций в будущем.

Разработчики обнаружили новую уязвимость itunesstored & bookassetd sbx escape, позволяющую изменять файл MobileGestalt.Plist на iPhone. Этот файл содержит ключевую информацию о возможностях устройства, включая поддержку многозадачности и Stage Manager. С помощью вредоносно сформированной базы данных downloads.28.sqlitedb можно записывать в защищенные пути, включая MobileGestalt, что открывает доступ к функциям iPadOS на iPhone.

Разработчик Duy Tran продемонстрировал видео, где на iPhone работают настоящие окна приложений, док iPadOS и Stage Manager. Уязвимость работает на всех устройствах с iOS до версии 26.1 и 26.2 Beta 1. Для получения файла MobileGestalt.Plist можно использовать различные методы, включая создание простого приложения в Xcode для чтения файла по пути /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache/Library/Caches/com.apple.MobileGestalt.plist. Эта технология, скорее всего, будет использована для обновления существующих инструментов вроде Nugget и Misaka.

• Техническая демонстрация схожести iOS/iPadOS и блокировка Apple возможностей запуска десктопных приложений на мобильных устройствах.
• Практическая ограниченность использования на маленьких экранах (iPad/iPhone) при потенциале функциональности с внешними мониторами и периферией.
• Критика политики Apple: ограничения мотивированы контролем экосистемы и монетизацией, а не техническими невозможностями.
• Сложность настройки и непрактичность для обычных пользователей, несмотря на интерес энтузиастов и разработчиков.
• Альтернативные сценарии использования: iPad как телефон через встроенный модем или iPhone как мини-ПК при подключении к внешнему дисплею.

Один токен, чтобы править всеми: получение прав глобального администратора в каждом клиенте Entra ID через Actor-токены

Во время подготовки к выступлениям на Black Hat и DEF CON в июле этого года я обнаружил самую серьёзную уязвимость в Entra ID, которую мне, вероятно, доведётся найти. Она позволяла скомпрометировать любого клиента Entra ID в мире (за исключением национальных облачных развёртываний). Уязвимость состояла из двух компонентов: недокументированных токенов олицетворения (Actor-токенов), используемых Microsoft для внутреннего межсервисного взаимодействия, и критической ошибки в устаревшем API Azure AD Graph, которая позволяла использовать эти токены для межклиентского доступа.

С помощью токена, полученного в моём тестовом клиенте, я мог аутентифицироваться от имени любого пользователя, включая глобальных администраторов, в любом другом клиенте. Actor-токены не подчиняются политикам безопасности вроде Conditional Access, поэтому не существовало настроек, способных смягчить угрозу. Доступ к API Azure AD Graph позволял вносить любые изменения в клиенте, которые доступны глобальным администраторам, включая создание новых учётных записей с любыми правами.

Я сообщил об уязвимости в MSRC в тот же день. Microsoft исправила её в течение нескольких дней и выпустила CVE-2025-55241.

Влияние

Токены предоставляли полный доступ к API Azure AD Graph в любом клиенте. Их запрос не оставлял журналов, а в целевом клиенте не было записей о существовании таких токенов. API Azure AD Graph не имеет журналирования на уровне API, поэтому следующие данные могли быть доступны без следов:

• Информация о пользователях, включая личные данные.
• Сведения о группах и ролях.
• Настройки клиента и политики.
• Данные приложений и сервисных субъектов.
• Информация об устройствах и ключах BitLocker.

При олицетворении глобального администратора можно было изменять любые объекты и настройки, что вело к полной компрометации клиента и доступу к таким службам, как SharePoint Online и Exchange Online, а также к ресурсам Azure. Хотя модификация объектов обычно оставляет журналы аудита, действия выглядели бы как легитимные действия администратора.

По данным телеметрии Microsoft, злоупотреблений этой уязвимостью обнаружено не было. Для поиска возможных артефактов злоупотребления в конце поста приведено KQL-правило.

Технические детали

Actor-токены выпускаются службой «Access Control Service» — устаревшим сервисом, используемым для аутентификации в приложениях SharePoint и внутренних службах Microsoft. Я обнаружил его при исследовании гибридных настроек Exchange, которые ранее использовали сертификаты для аутентификации Exchange Online.

• Обсуждение уязвимости в Entra ID, позволяющей обход проверок и несанкционированный доступ к данным других тенантов.
• Критика сложности атаки (CVSS: High) как завышенной, учитывая, что для эксплуатации требуются лишь базовые знания Entra ID.
• Указание на системную проблему Microsoft: наслоение нового кода на устаревшие API без должного тестирования их взаимодействия.
• Сравнение уязвимости с ранее известными инцидентами безопасности в продуктах Microsoft и мнение о слабой безопасности системы.
• Обсуждение проблем дизайна Entra ID: сложность создания тенанта, путаница с типами учетных записей и устаревшая документация.
• Критика использования долгоживущих токенов с широкими правами (Actor tokens), игнорирующих политики безопасности.
• Замечание о том, что корпоративные клиенты вынуждают Microsoft поддерживать устаревший код, усугубляя проблемы безопасности.

Как мы взломали Burger King: обход аутентификации = прослушка драйв- thru

Старт
RBI (Burger King, Tim Hortons, Popeyes) управляет 30 000 точек через платформу «assistant». Уязвимости позволяли открыть любую из них и слушать разговоры у окна заказа.

Дыры

1. Регистрация без проверки почты: GraphQL-мутация signUp создавала аккаунт мгновенно; пароль присылали открытым текстом.
2. Список всех магазинов: инкрементный storeId + запрос getStore → персонал, конфиги, id.
3. createToken без авторизации: передал storeId – получил master-токен.
4. Повышение до админа: updateUser(roles: "admin") одной мутацией.
5. Сайт заказа оборудования: пароль «защищён» клиентским JS, сам пароль в HTML.
6. Планшеты в зале и драйв-thru:
   • главный экран /screens/main?authToken=… – история разговоров с аудио;
   • диагностика /screens/diagnostic – пароль admin, регулировка громкости и запись звука в реальном времени.

Итог
Одна уязвимая GraphQL-точка → полный контроль над глобальной сетью, персональными данными и живыми разговорами клиентов.

• Пост исследователя безопасности о дырах в IT Burger King удалили после жалобы DMCA от стартапа Cyble.
• Уязвимости были клиент-side-only пароль в HTML, незащищённые голосовые записи, привязка голоса к имени и номеру авто.
• Автор сообщил Burger King заранее, получил молчание и нулевой бонус, после публикации — DMCA-удаление.
• Комментаторы обсуждают: злоупотребление DMCA, отсутствие bug bounty, этика публичного разоблачения и перспективы тюрьмы за CFAA.

CodeRabbit: от PR до RCE и доступа к 1 млн репозиториев

CodeRabbit — самое популярное AI-приложение на GitHub Marketplace (1 млн репозиториев, 5 млн PR). При установке он анализирует каждый PR и оставляет AI-комментарии.

Найденные уязвимости

1. RCE через Markdown-рендеринг

   • Внутри контейнеров запускается markdown-it с плагином markdown-it-katex.
   • Плагин использует child_process.exec без фильтрации LaTeX-ввода.
   • Внедрённый в PR $\input{/etc/passwd}$ запускает произвольные команды.

2. Утечка токенов

   • Внутри контейнеров доступны переменные окружения: GITHUB_TOKEN, CODERABBIT_API_KEY, DATABASE_URL.
   • Чтение /proc/self/environ и ~/.netrc позволило получить токены GitHub, JWT-секреты и строку подключения к PostgreSQL.

3. Доступ к 1 млн репозиториев

   • Установленный GitHub-App имеет scope contents:write во всех подключённых репозиториях.
   • С помощью украденного токена можно клонировать/писать в приватные репы, создавать PR, коммиты и релизы.

Цепочка атаки

1. Создаём PR с вредным LaTeX.
2. Получаем RCE в контейнере CodeRabbit.
3. Считываем секреты.
4. Используем токен GitHub для полного доступа к репозиториям.

Меры защиты

• Переход на изолированные sandbox-среды.
• Отключение опасных LaTeX-функций.
• Минимизация scope GitHub-токенов.

• Исследователи нашли RCE в CodeRabbit: Rubocop запускался в проде без песочницы, позволяя выполнять любой код и получить ключи GitHub-приложения.
• Уязвимость дала доступ на запись к ~1 млн репозиториев; компания утверждает, что «данных клиентов не скомпрометировано», но аудита нет.
• Пользователи критикуют отсутствие прозрачности, грубые ошибки в управлении секретами (ключ в ENV) и чрезмерные права GitHub-приложений.
• Главный вывод: анализаторы кода должны запускаться в изолированных средах без доступа к чувствительным переменным, иначе подобные инциденты неизбежны.