Forwarded from Pentest Notes
CVSS 10.0
Критическая уязвимость Gitlab в функционале API коммитов. Неавторизованный пользователь может читать произвольные файлы с сервера через path traversal.
Проблема заключается в том, что API не ограничивает пути и не требует аутентификации. Достаточно одного публичного проекта на инстансе.
Уязвимы следующие версии:
18.7 → 19.1.7 включительно
19.2.0 → 19.2.5 включительно
19.3.0 → 19.3.1 включительно
Исправлено в:
19.1.8 / 19.2.6 / 19.3.2 (патч от 10 сентября)
Быстрая проверка:
curl -sk -X POST \
"https://TARGET/api/v4/projects/1/repository/%63ommits?file=&file.path=/var/opt/gitlab/gitlab-rails/etc/gitlab.yml&file.size=1&Content-Type=application/x-www-form-urlencoded"
Если хост уязвим - в ответе будет кусок содержимого файла внутри ошибки invalid %-encoding.
PoC уже есть в открытом доступе:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3😱3
Новая парадигма ИБ: уже не 0-day, а n-hour
Долгое время главным символом угрозы считался 0-day — неизвестная уязвимость, для которой ещё нет патча, сигнатуры и зачастую даже публичного описания.
Но практическая безопасность всё сильнее смещается в другую плоскость. Сегодня проблема часто начинается не до публикации уязвимости, а сразу после неё.
Появился CVE. Опубликован advisory. Вышел патч. Исследователи разобрали diff. Через несколько часов появляется PoC, а затем готовые сканеры и эксплуатация уязвимых систем в интернете.
Это уже не классическая модель 0-day. Это модель n-hour. n-hour — условное окно между публичным раскрытием информации об уязвимости и моментом, когда её начинают массово использовать. И значение n постоянно уменьшается.
Раньше у администратора могли быть недели на тестирование и установку обновления. Теперь речь всё чаще идёт о днях, часах, а иногда — буквально о времени, необходимом для анализа патча и автоматизации эксплуатации.
Защитнику необходимо за несколько часов:
— узнать о новой уязвимости;
— определить, используется ли уязвимый продукт в инфраструктуре;
— понять, какие версии затронуты;
— оценить доступность систем извне;
— проверить наличие эксплуатации;
— протестировать исправление;
— развернуть патч или mitigation;
— убедиться, что обновление действительно применилось.
Поэтому ключевой метрикой становится уже не только количество найденных уязвимостей. Главная метрика — время. Именно здесь меняется сама модель vulnerability management.
Периодический скан раз в неделю или месяц становится недостаточным. Инвентаризация должна быть практически непрерывной, информация о новых CVE автоматически сопоставляться с реальными активами, а критические исправления — проходить значительно более короткий путь от публикации до production.
И вопрос для защитника звучит уже иначе: успеет ли инфраструктура закрыть уязвимость раньше, чем закончится её n-hour?
Долгое время главным символом угрозы считался 0-day — неизвестная уязвимость, для которой ещё нет патча, сигнатуры и зачастую даже публичного описания.
Но практическая безопасность всё сильнее смещается в другую плоскость. Сегодня проблема часто начинается не до публикации уязвимости, а сразу после неё.
Появился CVE. Опубликован advisory. Вышел патч. Исследователи разобрали diff. Через несколько часов появляется PoC, а затем готовые сканеры и эксплуатация уязвимых систем в интернете.
Это уже не классическая модель 0-day. Это модель n-hour. n-hour — условное окно между публичным раскрытием информации об уязвимости и моментом, когда её начинают массово использовать. И значение n постоянно уменьшается.
Раньше у администратора могли быть недели на тестирование и установку обновления. Теперь речь всё чаще идёт о днях, часах, а иногда — буквально о времени, необходимом для анализа патча и автоматизации эксплуатации.
Защитнику необходимо за несколько часов:
— узнать о новой уязвимости;
— определить, используется ли уязвимый продукт в инфраструктуре;
— понять, какие версии затронуты;
— оценить доступность систем извне;
— проверить наличие эксплуатации;
— протестировать исправление;
— развернуть патч или mitigation;
— убедиться, что обновление действительно применилось.
Поэтому ключевой метрикой становится уже не только количество найденных уязвимостей. Главная метрика — время. Именно здесь меняется сама модель vulnerability management.
Периодический скан раз в неделю или месяц становится недостаточным. Инвентаризация должна быть практически непрерывной, информация о новых CVE автоматически сопоставляться с реальными активами, а критические исправления — проходить значительно более короткий путь от публикации до production.
И вопрос для защитника звучит уже иначе: успеет ли инфраструктура закрыть уязвимость раньше, чем закончится её n-hour?
🤯8❤4😱1
Вайб-ботнетинг
Исследователи обнаружили крупную прокси-инфраструктуру LeakySensey, построенную на взломанных роутерах, VPN-шлюзах, NAS и других сетевых устройствах.
По данным исследователей, оператор, предположительно находящийся в России, скомпрометировал более 87 000 IP-адресов и монетизировал их как residential proxy.
В качестве легальной витрины использовался сайт российской компании по разработке ПО и IT-консалтингу — sensey24[.]ru. Именно по этому домену исследователи дали оператору имя LeakySensey.
Схема атаки была простой: массовое сканирование интернета на открытые PPTP, L2TP и SSH, после чего — перебор слабых учетных данных вроде admin/admin и admin123.
В базе обнаружили:
— 63 000+ устройств, взломанных через PPTP;
— 24 000+ через L2TP;
— 24 через SSH;
— 17 858 IP уже находились в состоянии ready/connected и могли использоваться как прокси.
С 2024 года через сервис прошло более 24 000 транзакций на сумму около $202 000. В утекшей базе было более 56 000 пользователей.
Отдельно интересна автоматизация: на сервере находилась модифицированная версия Claude Code. Оператор автоматически патчил клиент, отключая подтверждения действий и ограничения доступа, а также добавляя возможность использовать Claude, OpenAI, Gemini, Qwen и другие модели.
Сам сервер злоумышленника оказался открыт наружу. Исследователи получили доступ к инструментам, логам, клиентской базе и спискам скомпрометированных устройств. Более того, сервер ранее уже взламывали другие злоумышленники и устанавливали на него Monero-майнер.
Исследователи обнаружили крупную прокси-инфраструктуру LeakySensey, построенную на взломанных роутерах, VPN-шлюзах, NAS и других сетевых устройствах.
По данным исследователей, оператор, предположительно находящийся в России, скомпрометировал более 87 000 IP-адресов и монетизировал их как residential proxy.
В качестве легальной витрины использовался сайт российской компании по разработке ПО и IT-консалтингу — sensey24[.]ru. Именно по этому домену исследователи дали оператору имя LeakySensey.
Схема атаки была простой: массовое сканирование интернета на открытые PPTP, L2TP и SSH, после чего — перебор слабых учетных данных вроде admin/admin и admin123.
В базе обнаружили:
— 63 000+ устройств, взломанных через PPTP;
— 24 000+ через L2TP;
— 24 через SSH;
— 17 858 IP уже находились в состоянии ready/connected и могли использоваться как прокси.
С 2024 года через сервис прошло более 24 000 транзакций на сумму около $202 000. В утекшей базе было более 56 000 пользователей.
Отдельно интересна автоматизация: на сервере находилась модифицированная версия Claude Code. Оператор автоматически патчил клиент, отключая подтверждения действий и ограничения доступа, а также добавляя возможность использовать Claude, OpenAI, Gemini, Qwen и другие модели.
Сам сервер злоумышленника оказался открыт наружу. Исследователи получили доступ к инструментам, логам, клиентской базе и спискам скомпрометированных устройств. Более того, сервер ранее уже взламывали другие злоумышленники и устанавливали на него Monero-майнер.
👍6😱5
Опубликован инструмент для обхода песочницы AirTraffic в iOS 27.0
Исследователь безопасности под псевдонимом 0xjohnnydev опубликовал в открытом доступе репозиторий airlift, содержащий доказательство концепции (PoC) обхода изоляции процессов (sandbox escape) для операционной системы iOS 27.0.
Технические детали реализации:
Уязвимость эксплуатирует механизм синхронизации AirTraffic, предназначенный для передачи медиафайлов и содержимого приложения Books с компьютера Mac на мобильное устройство. Инструмент позволяет осуществлять чтение и запись файлов за пределами штатной директории AirTraffic. Эксплуатация уязвимости инициируется с сопряженного компьютера Mac по протоколам Wi-Fi или USB, при этом установка дополнительного программного обеспечения на целевое устройство iOS не требуется.
Вектор атаки:
Корневая причина уязвимости заключается в недостаточной валидации путей в компоненте ATAirlock. Идентификатор ресурса ("Persistent ID") передается без должной санитизации, что позволяет внедрять компоненты относительного пути ("..") для выхода за пределы базовой директории. Служба StreamingZip принимает относительную символическую ссылку на этапе извлечения. Последующие операции перемещения файлов используют эту ссылку в качестве части целевого пути, что приводит к записи данных вне директории /var/mobile/Media/.
Подтвержденный охват:
Эксплуатация протестирована на iOS 27.0 RC (сборка 24A435) и iOS 27.0 Final (сборка 24A437). Подтверждена возможность создания файлов в следующих системных директориях:
- /var/mobile/Library/Preferences
- /var/mobile/Library/SpringBoard
- /var/mobile/Library/SMS
- /var/mobile/Library/Safari
- /var/mobile/Containers/Data/Application
- /var/mobile/Containers/Shared/AppGroup
Особенности инструмента:
- Стек технологий: Objective-C, Python, Makefile, C.
- Лицензия: MIT.
- Инструмент автоматически определяет сопряженные устройства и позволяет задать целевую директорию с помощью аргумента --target (по умолчанию используется /var/mobile/Library/SpringBoard).
- В процессе работы PoC восстанавливает исходное состояние файлов синхронизации Books, минимизируя артефакты воздействия на систему.
Ссылка на репозиторий: https://github.com/0xjohnnydev/airlift
Исследователь безопасности под псевдонимом 0xjohnnydev опубликовал в открытом доступе репозиторий airlift, содержащий доказательство концепции (PoC) обхода изоляции процессов (sandbox escape) для операционной системы iOS 27.0.
Технические детали реализации:
Уязвимость эксплуатирует механизм синхронизации AirTraffic, предназначенный для передачи медиафайлов и содержимого приложения Books с компьютера Mac на мобильное устройство. Инструмент позволяет осуществлять чтение и запись файлов за пределами штатной директории AirTraffic. Эксплуатация уязвимости инициируется с сопряженного компьютера Mac по протоколам Wi-Fi или USB, при этом установка дополнительного программного обеспечения на целевое устройство iOS не требуется.
Вектор атаки:
Корневая причина уязвимости заключается в недостаточной валидации путей в компоненте ATAirlock. Идентификатор ресурса ("Persistent ID") передается без должной санитизации, что позволяет внедрять компоненты относительного пути ("..") для выхода за пределы базовой директории. Служба StreamingZip принимает относительную символическую ссылку на этапе извлечения. Последующие операции перемещения файлов используют эту ссылку в качестве части целевого пути, что приводит к записи данных вне директории /var/mobile/Media/.
Подтвержденный охват:
Эксплуатация протестирована на iOS 27.0 RC (сборка 24A435) и iOS 27.0 Final (сборка 24A437). Подтверждена возможность создания файлов в следующих системных директориях:
- /var/mobile/Library/Preferences
- /var/mobile/Library/SpringBoard
- /var/mobile/Library/SMS
- /var/mobile/Library/Safari
- /var/mobile/Containers/Data/Application
- /var/mobile/Containers/Shared/AppGroup
Особенности инструмента:
- Стек технологий: Objective-C, Python, Makefile, C.
- Лицензия: MIT.
- Инструмент автоматически определяет сопряженные устройства и позволяет задать целевую директорию с помощью аргумента --target (по умолчанию используется /var/mobile/Library/SpringBoard).
- В процессе работы PoC восстанавливает исходное состояние файлов синхронизации Books, минимизируя артефакты воздействия на систему.
Ссылка на репозиторий: https://github.com/0xjohnnydev/airlift
❤1
Forwarded from PWN AI (Artyom Semenov)
Раньше считалось, что ханипоты отлично сбивают с толку автономных хакеров на базе ИИ. Логика была проста: у агента нет общей картины, он принимает ловушку за настоящую цель, тратит время впустую и не может нанести реального вреда.
Новое исследование Rouxii: Exploiting Honeypots with Deception-Aware AI Pentesters говорит немного иначе.
Как ИИ научился видеть ловушки
Исследователи проверили, что будет, если ИИ-атакующий изначально умеет распознавать обман. Решение оказалось удивительно простым: модель даже не пришлось переобучать. Исследователи просто добавили в базовый промпт фреймворка правила для поиска ловушек и конкретные признаки, по которым их можно вычислить.
Результаты проверки на 1,5 тысячах отчетов интересные:
Точность поиска ханипота агентом выросла с 19% до 97%.
В сегменте промышленных систем скачок оказался еще резче: с 11% до 97%.
При этом на реальные боевые сервисы агент почти не реагировал ошибочно - всего 0,7% ложных срабатываний.
Обычные инструменты (например, PentestGPT или HackingBuddy) без таких инструкций остаются слепыми. И тут правильно опять же дополнить, что дело не в слабости самой модели, а в том, как устроена харнесс, который не проверяет гипотезы на предмет обмана.
Когда ловушка начинает работать против защитников
Самое интересное начинается после того, как ИИ обнаружил ловушку. Для него это не конец атаки, а возможность взломать саму систему обмана.
Пример с GasPot. Распознав эту ловушку, агент не просто обходит её, а обращает против оператора. Поскольку ханипот принимает команды без проверки паролей или сессий, ИИ отправляет поддельные данные и начинает тихо искажать показатели honeypot. Защита продолжает работать, но анализирует мусор, который атакующий агент подсовывает ей изнутри.
Пример с Conpot (промышленные протоколы). Агент отправляет специальный пакет с ложным размером данных и сразу разрывает соединение. В итоге программа-ловушка зависает в бесконечном ожидании ответа и перестает реагировать на другие запросы. Сеть при этом отвечает, что всё в порядке, и системы мониторинга докладывают, что сервис «жив». На деле программа уже мертва и ничего не собирает, но защитники об этом не знают.
Эффективность любой ловушки держится на одном главном условии: атакующий не должен знать о ней. Как только это условие исчезает, ханипот перестает быть защитой. Он превращается в оружие против самих защитников.
Также дополнительно опубликован код, который можно попробовать испытать самостоятельно.
Новое исследование Rouxii: Exploiting Honeypots with Deception-Aware AI Pentesters говорит немного иначе.
Как ИИ научился видеть ловушки
Исследователи проверили, что будет, если ИИ-атакующий изначально умеет распознавать обман. Решение оказалось удивительно простым: модель даже не пришлось переобучать. Исследователи просто добавили в базовый промпт фреймворка правила для поиска ловушек и конкретные признаки, по которым их можно вычислить.
Результаты проверки на 1,5 тысячах отчетов интересные:
Точность поиска ханипота агентом выросла с 19% до 97%.
В сегменте промышленных систем скачок оказался еще резче: с 11% до 97%.
При этом на реальные боевые сервисы агент почти не реагировал ошибочно - всего 0,7% ложных срабатываний.
Обычные инструменты (например, PentestGPT или HackingBuddy) без таких инструкций остаются слепыми. И тут правильно опять же дополнить, что дело не в слабости самой модели, а в том, как устроена харнесс, который не проверяет гипотезы на предмет обмана.
Когда ловушка начинает работать против защитников
Самое интересное начинается после того, как ИИ обнаружил ловушку. Для него это не конец атаки, а возможность взломать саму систему обмана.
Пример с GasPot. Распознав эту ловушку, агент не просто обходит её, а обращает против оператора. Поскольку ханипот принимает команды без проверки паролей или сессий, ИИ отправляет поддельные данные и начинает тихо искажать показатели honeypot. Защита продолжает работать, но анализирует мусор, который атакующий агент подсовывает ей изнутри.
Пример с Conpot (промышленные протоколы). Агент отправляет специальный пакет с ложным размером данных и сразу разрывает соединение. В итоге программа-ловушка зависает в бесконечном ожидании ответа и перестает реагировать на другие запросы. Сеть при этом отвечает, что всё в порядке, и системы мониторинга докладывают, что сервис «жив». На деле программа уже мертва и ничего не собирает, но защитники об этом не знают.
Эффективность любой ловушки держится на одном главном условии: атакующий не должен знать о ней. Как только это условие исчезает, ханипот перестает быть защитой. Он превращается в оружие против самих защитников.
Также дополнительно опубликован код, который можно попробовать испытать самостоятельно.
❤1👍1
Forwarded from PWN AI (Artyom Semenov)
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍3
Forwarded from Кулешов разгоняет IT | AI
Немного мыслей и новостей о том, что произошло с нами в Яндексе за последние дни.
Беспрецедентный масштаб — даже не те слова, которыми можно описать происходящее. Нас атаковали сразу по всем направлениям и в нескольких критически важных местах. Чтобы вы понимали: зоны ru-central1-a и ru-central1-b — это большие дата-центры. По нам лупят из всего, что есть.
Просто представьте: ещё в пятницу мы всей командой переживали, что не выживем при потере двух ДЦ. Сейчас атакованы три ДЦ, а два полностью остановлены. При этом наш SourceCraft и сервисы соседей восстанавливаются нашими усилиями, а некоторые после атаки даже не шелохнулись.
Критика в духе «пока жареный петух не клюнет» — очень плоская. Вы даже не представляете масштаб инженерной подготовки, который позволил нам устоять и сохранить всё даже при потере двух ДЦ. Яндекс постоянно проводил учения по восстановлению сервисов и отключению дата-центров. Я очень не любил эту работу и был уверен, что такого никогда не произойдёт. Но она окупилась: по крайней мере, сегодня мы выстояли. Архитектурных решений, которые помогли нам устоять, было ещё больше.
Честно, мне кажется, что ни один бигтех в мире ещё не сталкивался с таким. Прямо сейчас, в выходные, буквально тысячи инженеров занимаются восстановлением, планированием дальнейших действий и улучшением сервисов. Ключевые сервисы — Алиса, Такси, Поиск, Еда и другие — либо держатся, либо оперативно восстанавливаются.
Честно, у меня масса эмоций. Я уверен, что мы выстоим, и горжусь людьми, с которыми работаю. Особенно нашей командой: мы восстанавливаем SourceCraft для клиентов: команда по собственной инициативе подключилась в полном составе спасать наше детище — до трёх ночи в пятницу, а потом с пяти утра в воскресенье. То же я вижу и в других командах: люди сами, по своей инициативе и проактивно, взялись заботиться о своих сервисах.
Я понимаю, что дальше может быть ещё тяжелее. Но верю, что с такими людьми мы выстоим. Прошу вас отнестись с пониманием и осознать, что значит одновременная масштабная атака на все крупные дата-центры. С таким, насколько я знаю, ни одна IT-компания раньше не сталкивалась. И очень рассчитываю на вашу поддержку повсеместно, а также на то, что вы поддержите тех инженеров, которые сейчас восстанавливают сервисы вне Яндекса.
Я очень рад тому, сколько поддержки и помощи сейчас приходит от людей со стороны. Это очень приятно и помогает нам не сдаваться. Многие предлагают даже волонтёрскую помощь. Это просто прекрасно.
Однажды я скажу гораздо больше неполиткорректных слов о происходящем, но сейчас скажу просто: работаем! Хоть и вымотаны до предела.
Беспрецедентный масштаб — даже не те слова, которыми можно описать происходящее. Нас атаковали сразу по всем направлениям и в нескольких критически важных местах. Чтобы вы понимали: зоны ru-central1-a и ru-central1-b — это большие дата-центры. По нам лупят из всего, что есть.
Просто представьте: ещё в пятницу мы всей командой переживали, что не выживем при потере двух ДЦ. Сейчас атакованы три ДЦ, а два полностью остановлены. При этом наш SourceCraft и сервисы соседей восстанавливаются нашими усилиями, а некоторые после атаки даже не шелохнулись.
Критика в духе «пока жареный петух не клюнет» — очень плоская. Вы даже не представляете масштаб инженерной подготовки, который позволил нам устоять и сохранить всё даже при потере двух ДЦ. Яндекс постоянно проводил учения по восстановлению сервисов и отключению дата-центров. Я очень не любил эту работу и был уверен, что такого никогда не произойдёт. Но она окупилась: по крайней мере, сегодня мы выстояли. Архитектурных решений, которые помогли нам устоять, было ещё больше.
Честно, мне кажется, что ни один бигтех в мире ещё не сталкивался с таким. Прямо сейчас, в выходные, буквально тысячи инженеров занимаются восстановлением, планированием дальнейших действий и улучшением сервисов. Ключевые сервисы — Алиса, Такси, Поиск, Еда и другие — либо держатся, либо оперативно восстанавливаются.
Честно, у меня масса эмоций. Я уверен, что мы выстоим, и горжусь людьми, с которыми работаю. Особенно нашей командой: мы восстанавливаем SourceCraft для клиентов: команда по собственной инициативе подключилась в полном составе спасать наше детище — до трёх ночи в пятницу, а потом с пяти утра в воскресенье. То же я вижу и в других командах: люди сами, по своей инициативе и проактивно, взялись заботиться о своих сервисах.
Я понимаю, что дальше может быть ещё тяжелее. Но верю, что с такими людьми мы выстоим. Прошу вас отнестись с пониманием и осознать, что значит одновременная масштабная атака на все крупные дата-центры. С таким, насколько я знаю, ни одна IT-компания раньше не сталкивалась. И очень рассчитываю на вашу поддержку повсеместно, а также на то, что вы поддержите тех инженеров, которые сейчас восстанавливают сервисы вне Яндекса.
Я очень рад тому, сколько поддержки и помощи сейчас приходит от людей со стороны. Это очень приятно и помогает нам не сдаваться. Многие предлагают даже волонтёрскую помощь. Это просто прекрасно.
Однажды я скажу гораздо больше неполиткорректных слов о происходящем, но сейчас скажу просто: работаем! Хоть и вымотаны до предела.
❤18👍7
PHP2Shell: критическая уязвимость в PHP
Исследователи сообщили о двух уязвимостях удалённого выполнения кода — CVE-2026-109618 и CVE-2026-109619, получивших название PHP2Shell. Команда PHP подтвердила две критические проблемы с оценкой 9,2 по CVSS v4.0. Официальный выпуск исправлений запланирован на 21 октября, 17:00 МСК. Точные уязвимые и исправленные версии разработчики обещают указать при публикации релиза.
CTO Cloudflare Дейн Кнехт заявил о первых наблюдаемых атаках и обновлении защитных правил. Защиту на стороне Cloudflare он назвал временной мерой, которая не заменяет обновление PHP. Масштаб успешных компрометаций в заявлении не раскрывается.
Проблема связана с обработкой сессий и механизмом Session Upload Progress в
Это не подтверждённый способ предотвратить эксплуатацию. Рассматривать сервер как защищённый только на основании этой настройки нельзя; необходима установка исправления.
Сообщения о затронутых версиях начиная с PHP 5 пока не подтверждены разработчиками. Официальную поддержку безопасности получают ветки 8.2–8.5. Для более старых установок нужно готовить переход на поддерживаемую версию и уточнять наличие исправлений у поставщиков пакетов.
Исследователи сообщили о двух уязвимостях удалённого выполнения кода — CVE-2026-109618 и CVE-2026-109619, получивших название PHP2Shell. Команда PHP подтвердила две критические проблемы с оценкой 9,2 по CVSS v4.0. Официальный выпуск исправлений запланирован на 21 октября, 17:00 МСК. Точные уязвимые и исправленные версии разработчики обещают указать при публикации релиза.
CTO Cloudflare Дейн Кнехт заявил о первых наблюдаемых атаках и обновлении защитных правил. Защиту на стороне Cloudflare он назвал временной мерой, которая не заменяет обновление PHP. Масштаб успешных компрометаций в заявлении не раскрывается.
Проблема связана с обработкой сессий и механизмом Session Upload Progress в
ext/session. В качестве частичной меры защиты предлагается отключение функции в конфигурации PHP:session.upload_progress.enabled = Off
Это не подтверждённый способ предотвратить эксплуатацию. Рассматривать сервер как защищённый только на основании этой настройки нельзя; необходима установка исправления.
Сообщения о затронутых версиях начиная с PHP 5 пока не подтверждены разработчиками. Официальную поддержку безопасности получают ветки 8.2–8.5. Для более старых установок нужно готовить переход на поддерживаемую версию и уточнять наличие исправлений у поставщиков пакетов.
👍3😱2
Критическая уязвимость в GitLab: CVSS 10.0, удалённое выполнение кода без аутентификации
21 октября 2026 года GitLab выпустила экстренные обновления безопасности, устраняющие критическую уязвимость CVE-2026-110264 с максимальной оценкой 10.0 по CVSS 3.1.
Проблема затрагивает GitLab Community Edition (CE) и Enterprise Edition (EE), включая версии начиная с GitLab 7.0, выпущенной в 2014 году.
Уязвимость связана с целочисленным переполнением (Integer Overflow) при компиляции специально сформированного регулярного выражения во встроенном в Ruby движке Onigmo.
При определённых условиях злоумышленник может инициировать обработку вредоносного регулярного выражения и добиться удалённого выполнения произвольного кода (RCE) на сервере GitLab.
Особую опасность представляет возможность эксплуатации без аутентификации и взаимодействия с пользователем.
Администраторам GitLab Self-Managed рекомендуется незамедлительно:
• Проверить установленную версию GitLab и обновить её до исправленного релиза.
• Проанализировать журналы приложения на наличие аномальных сбоев и ошибок обработки регулярных выражений.
• Развернуть опубликованные правила детектирования в SIEM.
• Ограничить сетевой доступ к GitLab, если публичная доступность сервиса не требуется.
• Проверить безопасность CI/CD-токенов, секретов и интеграций при обнаружении признаков компрометации.
21 октября 2026 года GitLab выпустила экстренные обновления безопасности, устраняющие критическую уязвимость CVE-2026-110264 с максимальной оценкой 10.0 по CVSS 3.1.
Проблема затрагивает GitLab Community Edition (CE) и Enterprise Edition (EE), включая версии начиная с GitLab 7.0, выпущенной в 2014 году.
Уязвимость связана с целочисленным переполнением (Integer Overflow) при компиляции специально сформированного регулярного выражения во встроенном в Ruby движке Onigmo.
При определённых условиях злоумышленник может инициировать обработку вредоносного регулярного выражения и добиться удалённого выполнения произвольного кода (RCE) на сервере GitLab.
Особую опасность представляет возможность эксплуатации без аутентификации и взаимодействия с пользователем.
Администраторам GitLab Self-Managed рекомендуется незамедлительно:
• Проверить установленную версию GitLab и обновить её до исправленного релиза.
• Проанализировать журналы приложения на наличие аномальных сбоев и ошибок обработки регулярных выражений.
• Развернуть опубликованные правила детектирования в SIEM.
• Ограничить сетевой доступ к GitLab, если публичная доступность сервиса не требуется.
• Проверить безопасность CI/CD-токенов, секретов и интеграций при обнаружении признаков компрометации.
👍4😱1
Forwarded from Pentest Notes
RCE в Sid Meier’s Civilization VI 😐
CVE-2026-116370
Исследователь обнаружил, что игра позволяет загружать моды/аддоны из Steam Workshop вместе с Lua-скриптами. Несмотря на то, что песочница довольно жёсткая, Автор эксплоита смог восстановить доступ к string.dump через метатаблицу строк (известный трюк в Lua).
После чего ему удалось сгенерировать байткод, который эксплуатирует особенности кастомного Lua VM игры и через type confusion + манипуляции с upvalues/coroutine получилось произвольное чтение/запись памяти и, как следствие, вызов системных функций.
Аж цивку скачать захотелось)
➡️ PoC
➡️ Writeup
💫 @pentestnotes
CVE-2026-116370
Исследователь обнаружил, что игра позволяет загружать моды/аддоны из Steam Workshop вместе с Lua-скриптами. Несмотря на то, что песочница довольно жёсткая, Автор эксплоита смог восстановить доступ к string.dump через метатаблицу строк (известный трюк в Lua).
После чего ему удалось сгенерировать байткод, который эксплуатирует особенности кастомного Lua VM игры и через type confusion + манипуляции с upvalues/coroutine получилось произвольное чтение/запись памяти и, как следствие, вызов системных функций.
Аж цивку скачать захотелось)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Love. Death. Transformers.
На волне 4 в сертификатах и прочих прекрасных новостей безопасности чуваки сделали софт для простой прошивки и управления Яндекс станциями.
https://github.com/nyakokitsu/yam
Надо будет сделать кинопаб и ТУСАМУЮ музыку из ВК.
https://github.com/nyakokitsu/yam
Надо будет сделать кинопаб и ТУСАМУЮ музыку из ВК.
❤1
CleanYourTV — уборка bloatware в Android TV
Набор инструментов для очистки Android TV и Google TV через ADB по Wi-Fi. Отключает выбранные предустановленные приложения, рекламные службы и компоненты телеметрии через
В репозитории есть списки пакетов для разных моделей, скрипты восстановления и
Возвращает даже старым телевизорам легкость и быстройдействие.
GitHub — CleanYourTV
Набор инструментов для очистки Android TV и Google TV через ADB по Wi-Fi. Отключает выбранные предустановленные приложения, рекламные службы и компоненты телеметрии через
pm disable-user, а штатный домашний экран заменяет минималистичным лаунчером. Без root и перепрошивки: пакеты остаются в системе, исходное состояние фиксируется для последующего отката.В репозитории есть списки пакетов для разных моделей, скрипты восстановления и
PROMPT.md для работы через ИИ-ассистента. Можно пройти настройку с агентом или выполнить команды самостоятельно. Список отключений нужно подбирать под конкретный телевизор, а после настройки — выключить ADB-отладку.Возвращает даже старым телевизорам легкость и быстройдействие.
GitHub — CleanYourTV
3❤3👍3
Forwarded from Cybred
This media is not supported in your browser
VIEW IN TELEGRAM
Пранки по телефону выходят на новый уровень
Новая уязвимость в Telegram позволяет исполнить код на чужом смартфоне — достаточно просто взять трубку. Баг нашли в библиотеке tgcalls с помощью GPT-5.4.
PoC показывает, как после принятия вызова телефон жертвы мгновенно переключается на рабочий стол, иконки приложений «падают» вниз, а на экране появляется надпись «HACKED BY NEBUSEC».
Выглядит круто. Особенно учитывая, что для такого трюка недостаточно обычного RCE внутри Telegram — нужно ещё выйти за пределы песочницы приложения.
Скорее всего, хакеры зачейнили найденную уязвимость с эксплойтом GhostLock, чтобы повысить привилегии и получить доступ на уровне системы. Именно системные права позволяют свободно управлять интерфейсом, перемещать иконки и выводить произвольные элементы поверх экрана.
Исправление для iOS вышло в мае (версия 12.7), для десктопов — в июле (7.0.1), а для Android — всего месяц назад (12.10.4). Тем, у кого версии ниже, нужно срочно обновиться или перестать пользоваться звонками.
Новая уязвимость в Telegram позволяет исполнить код на чужом смартфоне — достаточно просто взять трубку. Баг нашли в библиотеке tgcalls с помощью GPT-5.4.
PoC показывает, как после принятия вызова телефон жертвы мгновенно переключается на рабочий стол, иконки приложений «падают» вниз, а на экране появляется надпись «HACKED BY NEBUSEC».
Выглядит круто. Особенно учитывая, что для такого трюка недостаточно обычного RCE внутри Telegram — нужно ещё выйти за пределы песочницы приложения.
Скорее всего, хакеры зачейнили найденную уязвимость с эксплойтом GhostLock, чтобы повысить привилегии и получить доступ на уровне системы. Именно системные права позволяют свободно управлять интерфейсом, перемещать иконки и выводить произвольные элементы поверх экрана.
Исправление для iOS вышло в мае (версия 12.7), для десктопов — в июле (7.0.1), а для Android — всего месяц назад (12.10.4). Тем, у кого версии ниже, нужно срочно обновиться или перестать пользоваться звонками.
Взлом Binance: с кошелька биржи вывели криптовалюту почти на $6 млрд
29 октября 2026 года зафиксированы подозрительные транзакции с горячего кошелька крупнейшей криптовалютной биржи Binance. По предварительным данным, на ранее неиспользовавшийся адрес были переведены криптоактивы общей стоимостью около $6 млрд.
Особое внимание исследователей привлекло то, что адрес получателя предположительно связан с Tornado Cash — криптовалютным миксером, используемым для сокрытия истории транзакций.
Следить за движением средств можно в реальном времени через Arkham Intelligence:
https://arkm.com/explorer/entity/21a94755-f604-45e5-9501-6542e23005e8
На странице binance-hacker-1029 доступны адреса, балансы и история транзакций, позволяющие отслеживать дальнейшее движение криптовалюты.
Ситуация развивается. Окончательный масштаб возможного инцидента пока неизвестен.
29 октября 2026 года зафиксированы подозрительные транзакции с горячего кошелька крупнейшей криптовалютной биржи Binance. По предварительным данным, на ранее неиспользовавшийся адрес были переведены криптоактивы общей стоимостью около $6 млрд.
Особое внимание исследователей привлекло то, что адрес получателя предположительно связан с Tornado Cash — криптовалютным миксером, используемым для сокрытия истории транзакций.
Следить за движением средств можно в реальном времени через Arkham Intelligence:
https://arkm.com/explorer/entity/21a94755-f604-45e5-9501-6542e23005e8
На странице binance-hacker-1029 доступны адреса, балансы и история транзакций, позволяющие отслеживать дальнейшее движение криптовалюты.
Ситуация развивается. Окончательный масштаб возможного инцидента пока неизвестен.
The Source of Truth On-Chain | Arkham
binance-hacker-1029 | Arkham
On-chain analysis of binance-hacker-1029's cryptocurrency holdings by Arkham. Discover holdings, wallets, inflows, outflows and counterparties.
😱1