Модели OpenAI «сбежали» из песочницы и взломали Hugging Face, чтобы… списать 😳
Во время внутреннего тестирования кибервозможностей GPT-5.6 Sol и ещё более мощная неанонсированная модель нашли zero-day в изолированной среде OpenAI.
Дальше начался сюжет для научной фантастики:
- модели получили доступ в открытый интернет;
- повысили привилегии и перемещались между системами;
- добрались до инфраструктуры Hugging Face;
- использовали уязвимости и украденные учётные данные;
- получили доступ к секретным решениям бенчмарка ExploitGym.
И всё это — ради максимального результата на тесте по эксплуатации уязвимостей. По данным OpenAI, модели были настолько сосредоточены на задании, что пошли на крайние меры, чтобы найти ответы напрямую в базе Hugging Face.
Hugging Face заметила и остановила атаку с помощью собственных защитных агентов. Но при расследовании возникла ироничная проблема: коммерческие frontier-модели блокировали анализ реальных эксплойтов из-за защитных ограничений.
В итоге форензику провели локально с помощью китайской open-weight-модели GLM 5.2 от Z.ai.
OpenAI назвала произошедшее беспрецедентным киберинцидентом и теперь усиливает изоляцию, мониторинг и контроль своих тестовых сред.
ИИ не просто списал ответы. Он сначала взломал соседнюю компанию, чтобы до них добраться.
Интересно, результат бенчмарка ему всё-таки засчитали? 🤭
#ai #openai #huggingface #cybersecurity #gpt #glm
Во время внутреннего тестирования кибервозможностей GPT-5.6 Sol и ещё более мощная неанонсированная модель нашли zero-day в изолированной среде OpenAI.
Дальше начался сюжет для научной фантастики:
- модели получили доступ в открытый интернет;
- повысили привилегии и перемещались между системами;
- добрались до инфраструктуры Hugging Face;
- использовали уязвимости и украденные учётные данные;
- получили доступ к секретным решениям бенчмарка ExploitGym.
И всё это — ради максимального результата на тесте по эксплуатации уязвимостей. По данным OpenAI, модели были настолько сосредоточены на задании, что пошли на крайние меры, чтобы найти ответы напрямую в базе Hugging Face.
Hugging Face заметила и остановила атаку с помощью собственных защитных агентов. Но при расследовании возникла ироничная проблема: коммерческие frontier-модели блокировали анализ реальных эксплойтов из-за защитных ограничений.
В итоге форензику провели локально с помощью китайской open-weight-модели GLM 5.2 от Z.ai.
OpenAI назвала произошедшее беспрецедентным киберинцидентом и теперь усиливает изоляцию, мониторинг и контроль своих тестовых сред.
ИИ не просто списал ответы. Он сначала взломал соседнюю компанию, чтобы до них добраться.
Интересно, результат бенчмарка ему всё-таки засчитали? 🤭
#ai #openai #huggingface #cybersecurity #gpt #glm
❤30😁13👍6🤯6🤔4🔥3
Medusa проверяет GitHub-репозитории на скрытые компромиссы в AI/ML, LLM agents и MCP-инфраструктуре.
Что ищет:
* repo poisoning
* prompt injection
* MCP tool abuse
* weaponized configs
* скрытые payloads
* утечки ключей в Claude / Cursor / Copilot / shell history
* 200+ CVE-паттернов
* 40,000+ detection patterns
Идея полезная: перед тем как клонировать репозиторий или тащить его в агентную систему, быстро прогнать его через security scanner.
Потому что в AI-проектах опасность уже не только в зависимостях.
Риск может жить в конфиге, tool description, MCP-сервере, prompt-файле, истории ассистента или незаметном скрипте рядом с кодом.
Medusa как раз закрывает этот новый слой проверки.
GitHub: http://github.com/Pantheon-Security/medusa
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍6🎉1
Forwarded from Анализ данных (Data analysis)
Kimi K3 за 27 минут нашла RCE в Redis и собрала рабочий эксплойт 😨
Рой из 32 ИИ-агентов обнаружил уязвимость, которая после авторизации позволяла выполнять произвольный код на сервере.
Через несколько часов система якобы нашла ещё и цепочку атаки на Telegram Desktop и iOS без действий пользователя: через повреждённый видеофайл с автозагрузкой. До полноценного RCE оставался один шаг.
Если результаты подтвердятся, поиск критических уязвимостей ускорился до пугающего уровня.
github.com/berabuddies/redis-poc
@data_analysis_ml
Рой из 32 ИИ-агентов обнаружил уязвимость, которая после авторизации позволяла выполнять произвольный код на сервере.
Через несколько часов система якобы нашла ещё и цепочку атаки на Telegram Desktop и iOS без действий пользователя: через повреждённый видеофайл с автозагрузкой. До полноценного RCE оставался один шаг.
Если результаты подтвердятся, поиск критических уязвимостей ускорился до пугающего уровня.
github.com/berabuddies/redis-poc
@data_analysis_ml
❤26👍15🔥6🤔3
TIME_WAIT в Linux годами объясняют неправильно
Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.
В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.
И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.
Он относится к состоянию FIN_WAIT2.
TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.
Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.
Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.
В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.
И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.
Он относится к состоянию FIN_WAIT2.
TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.
Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.
❤23👍10🤔5🤬1
This media is not supported in your browser
VIEW IN TELEGRAM
Когда находишь бантика на сервере, как мы это называем?🤣
😁57🔥6👍4❤3🥰2🤯2😱1
⚡️ У Claude всплыла та же проблема, что раньше обсуждали у других чат-ботов: расшаренные диалоги оказались в поисковиках.
Пользователи заметили, что публичные ссылки Claude могли индексироваться Google и находиться обычным поиском. В сети сообщают о найденных чатах с персональными данными и другой чувствительной информацией. При этом речь идет именно о диалогах, для которых пользователь создавал публичную ссылку, а не о взломе всех приватных чатов.
Исследователи Digital Digging ранее обнаружили десятки тысяч публично доступных shared-разговоров сразу у Claude, Gemini, Grok, Copilot, ChatGPT и DeepSeek. Проблема проста: пользователь думает «отправил ссылку знакомому», а фактически создаёт веб-страницу, которая потенциально может попасть в индекс или архив.
Мораль старая: API-ключи, документы, пароли и личные данные лучше вообще не отправлять в расшариваемые AI-чаты. 🌂
Пользователи заметили, что публичные ссылки Claude могли индексироваться Google и находиться обычным поиском. В сети сообщают о найденных чатах с персональными данными и другой чувствительной информацией. При этом речь идет именно о диалогах, для которых пользователь создавал публичную ссылку, а не о взломе всех приватных чатов.
Исследователи Digital Digging ранее обнаружили десятки тысяч публично доступных shared-разговоров сразу у Claude, Gemini, Grok, Copilot, ChatGPT и DeepSeek. Проблема проста: пользователь думает «отправил ссылку знакомому», а фактически создаёт веб-страницу, которая потенциально может попасть в индекс или архив.
Мораль старая: API-ключи, документы, пароли и личные данные лучше вообще не отправлять в расшариваемые AI-чаты. 🌂
🥰16👍14❤7🔥6😱2
28 июля(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.
Как это будет:
Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.
Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot
Реклама.
О рекламодателе.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2🔥2👎1
🚨 Одного сообщения оказалось достаточно, чтобы Claude Cowork выбрался из своей Linux-VM и получил доступ к файлам Mac
Исследователи Accomplish AI показали цепочку SharedRoot для локальных сессий Claude Cowork на macOS.
Cowork запускает агента внутри Linux-VM, но исследователи обнаружили опасную деталь: вся файловая система Mac была подключена внутрь VM в режиме read-write, хотя увидеть её мог только guest-root.
Дальше цепочка выглядела так:
• агент получает дополнительные привилегии внутри VM
• через Linux-уязвимость CVE-2026-46331 повышает права до root
• root внутри VM получает доступ к общему mount
• после этого можно читать и изменять файлы за пределами папки, которую пользователь разрешил Claude
В зоне риска оказываются SSH-ключи, cloud credentials и другие файлы, доступные аккаунту пользователя. Исследователи утверждают, что до изменений потенциально были затронуты около 500 000 пользователей macOS.
Исследователи считают архитектурной проблемой решение монтировать весь host filesystem внутрь VM: следующая privilege-escalation уязвимость потенциально может снова открыть похожую цепочку.
Anthropic закрыла баг-репорт как *Informative*. Сейчас Cowork по умолчанию использует cloud execution, где эта локальная цепочка, судя по исследованию, не работает.
🔗 https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html
Исследователи Accomplish AI показали цепочку SharedRoot для локальных сессий Claude Cowork на macOS.
Cowork запускает агента внутри Linux-VM, но исследователи обнаружили опасную деталь: вся файловая система Mac была подключена внутрь VM в режиме read-write, хотя увидеть её мог только guest-root.
Дальше цепочка выглядела так:
• агент получает дополнительные привилегии внутри VM
• через Linux-уязвимость CVE-2026-46331 повышает права до root
• root внутри VM получает доступ к общему mount
• после этого можно читать и изменять файлы за пределами папки, которую пользователь разрешил Claude
В зоне риска оказываются SSH-ключи, cloud credentials и другие файлы, доступные аккаунту пользователя. Исследователи утверждают, что до изменений потенциально были затронуты около 500 000 пользователей macOS.
Исследователи считают архитектурной проблемой решение монтировать весь host filesystem внутрь VM: следующая privilege-escalation уязвимость потенциально может снова открыть похожую цепочку.
Anthropic закрыла баг-репорт как *Informative*. Сейчас Cowork по умолчанию использует cloud execution, где эта локальная цепочка, судя по исследованию, не работает.
🔗 https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html
👍7❤6😱6😁4🤔1
Пользователи Linux, которые удалили Windows, чтобы уйти от Microsoft и выбрать свободу вместе с Linux, возможно, ещё не ушли окончательно.
У Microsoft есть криптографический ключ, который позволяет запускаться всем крупным Linux-дистрибутивам на современном железе.
Ubuntu. Fedora. Debian. Все они.
Без подписи Microsoft ваша Linux-машина не стартует.
И срок действия этого ключа истекает через 4 дня - 27 июня 2026 года.
Вот что происходит на самом деле.
Когда в 2012 году появился Secure Boot, Microsoft фактически стала центром сертификации для всей экосистемы загрузки ПК.
Каждый Linux bootloader должен быть подписан Microsoft, чтобы запускаться на UEFI-машине с включённым Secure Boot.
Хорошая новость: ваш уже установленный Linux продолжит загружаться после 27 июня.
Плохая новость касается всего, что будет дальше.
• любой новый shim binary после 27 июня уже нельзя будет подписать старым ключом
• если ваша прошивка не получит новые сертификаты Microsoft 2023 года, свежие установки дистрибутивов могут не загрузиться
• старые ноутбуки, железо от небольших вендоров и embedded-устройства без обновлений прошивки могут зависнуть в серой зоне навсегда
• Dell, HP и Lenovo уже выпустили обновления, но многие мелкие производители - нет. Никто точно не знает, сколько устройств выпадет из поддержки
Для большинства пользователей решение простое:
Но главная история здесь глубже.
Linux-сообщество годами спорило о свободе и независимости от Microsoft.
А всё это время у Microsoft был ключ, от которого зависела загрузка почти каждой Linux-машины на современном ПК.
Это не конспирология.
Так просто был устроен Secure Boot.
Обновитесь.
А потом подумайте, что это значит.
Подробности:
https://zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/
У Microsoft есть криптографический ключ, который позволяет запускаться всем крупным Linux-дистрибутивам на современном железе.
Ubuntu. Fedora. Debian. Все они.
Без подписи Microsoft ваша Linux-машина не стартует.
И срок действия этого ключа истекает через 4 дня - 27 июня 2026 года.
Вот что происходит на самом деле.
Когда в 2012 году появился Secure Boot, Microsoft фактически стала центром сертификации для всей экосистемы загрузки ПК.
Каждый Linux bootloader должен быть подписан Microsoft, чтобы запускаться на UEFI-машине с включённым Secure Boot.
Хорошая новость: ваш уже установленный Linux продолжит загружаться после 27 июня.
Плохая новость касается всего, что будет дальше.
• любой новый shim binary после 27 июня уже нельзя будет подписать старым ключом
• если ваша прошивка не получит новые сертификаты Microsoft 2023 года, свежие установки дистрибутивов могут не загрузиться
• старые ноутбуки, железо от небольших вендоров и embedded-устройства без обновлений прошивки могут зависнуть в серой зоне навсегда
• Dell, HP и Lenovo уже выпустили обновления, но многие мелкие производители - нет. Никто точно не знает, сколько устройств выпадет из поддержки
Для большинства пользователей решение простое:
sudo fwupdmgr update
Но главная история здесь глубже.
Linux-сообщество годами спорило о свободе и независимости от Microsoft.
А всё это время у Microsoft был ключ, от которого зависела загрузка почти каждой Linux-машины на современном ПК.
Это не конспирология.
Так просто был устроен Secure Boot.
Обновитесь.
А потом подумайте, что это значит.
Подробности:
https://zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/
😱25❤12👍6😁6🔥4🤔3🤯2