Hacker News Digest

Пользователь попросил Muse экспортировать файлы, которые он может видеть, и получил архив размером 2,7 ГБ сжатого и 6,8 ГБ распакованного. В нём оказалась корневая файловая система Linux-среды сессии: системные файлы Ubuntu, внутренняя документация Muse, код интеграций, шаблоны приложений, файлы памяти и журналы агентов, включая SSH-ключи. Автор не публикует архив из-за чувствительности данных.

Большая часть интересных файлов находилась в /home/hatch, /opt/hatch и /opt/hatch-image. В директории agents/ хранились 113 записей суб-агентов в формате JSONL, а в домашней директории агента — файлы вроде SOUL.md, IDENTITY.md, MEMORY.md и др. Документация включала около 20 Markdown-файлов по использованию браузера, платежам, данным, голосовым функциям и расписанию, а также гайды для WhatsApp, Mac, Tailscale и Home Link.

В /opt/hatch/skills/ насчитывалось около 68 директорий навыков, каждая с файлом SKILL.md и связанным кодом — для Google Workspace, соцсетей Meta, Outlook, здоровья, бытовых устройств и генерации медиа. Особенно примечательной оказалась документация по экспериментальной интеграции Home Link (docs/devices/home_link.md), описывающая использование ESP32-C5 с Wi-Fi и BLE для подключения Muse к домашним устройствам через прокси с отдельным шагом одобрения.

Автор отправил отчёт в программу bug bounty Meta, но получил ответ «Not Applicable» без уточнения причин. Он также связался с несколькими сотрудниками, но не добился дальнейших действий. Несмотря на попытки исследовать границы контейнера (например, через 80 открытых сокетов), escape не был продемонстрирован из-за недостатка опыта и осторожности по отношению к продакшен-системе. Для уточнений пользователь предлагает связаться по почте pete@mouse.dev.

Обсуждение уточняет, что предоставление Muse полного доступа к файловой системе виртуальной машины — запланированная особенность, а не уязвимость; поднимает спор о том, что считается «software engineering» в эпоху LLM‐агентов; раскрывает технические детали (изолированная VM на пользователя, 332 МБ Rust‐бинарник, возможный отдельный Postgres вместо SQLite); отмечает готовность Meta выпускать рискованные AI‐продукты без баг‐баунти и даёт практические рекомендации по точному промпт‐инжинирингу и будущей миграции конфигураций в базы данных.

• Спор: Некоторые комментаторы считают, что создание markdown‐файлов — это «software engineering», тогда как другие утверждают, что реальная инженерная работа заключается в оценке этих файлов, а markdown лишь продукт, а не процесс.

• Большинство участников согласны, что каждый пользователь получает отдельную VM и что агент имеет полный доступ к своей файловой системе, что является запланированной функцией, а не уязвимостью.

• Совет: Для получения желаемого поведения от Muse рекомендуется формулировать запросы максимально точно, сравнивая процесс с «взмахом волшебной лампы» — так называют «magic genie engineering».

• Спор: Некоторые пользователи критикуют отсутствие баг‐баунти за раскрытие полной файловой системы, в то время как другие считают, что это не баг, а преднамеренный доступ внутри изолированной VM.

• Тред отмечает, что готовность Meta запускать этически неоднозначные AI‐продукты даёт ей уникальное преимущество по сравнению с другими крупными технологическими компаниями.

• Полный доступ агента к VM рассматривается как положительный сигнал для открытости: разработчики могут работать с агентами так же, как с обычными программами на компьютере.

• Спор: Один комментарий указывает, что Muse, судя по всему, использует отдельный экземпляр Postgres для каждого агента, что кажется избыточным по сравнению с заявлением о единой SQLite базе.

• Пользователь поделился, что основной «harness» Muse представляет собой монолитный 332 МБ бинарник, написанный на Rust, подтверждая значительный размер исполняемого кода.

• Совет: Ожидается, что текущий подход к конфигурации в виде ini‐файлов будет заменён более структурированной базой данных в будущих версиях.

• Несколько комментариев выражают обеспокоенность, что зависимость от AI‐генерируемых markdown‐файлов свидетельствует о деградации традиционных навыков программной инженерии.

• Совет: Рекомендовано не публиковать извлечённый архив с файловой системой, так как в нём могут находиться SSH‐ключи и внутренняя документация, представляющие конфиденциальную информацию.

• Спор: Некоторые считают файлы с SSH‐ключами и внутренними документами чувствительными, тогда как другие полагают, что в контексте изолированной VM они могут не быть строго конфиденциальными.

About 20 Markdown files described browser use, connectors, payments, credentials, data handling, generated files, voice, goals, and scheduling.This the state of software engineering in 2026.Edit: clarified engineering to software engineering, which is more correct — @tolugenius

HackerOne прошёл путь от идеи безопасного пространства для этических хакеров до упадка, когда компания потеряла свою изначальную миссию. В 2011 году её создатели создали платформу, чтобы устранить риски судебного преследования исследователей, предлагая им легальный канал для выявления уязвимостей в обмен на вознаграждение. Это стало основой для индустрии баг-бонтов, где первые годы были «золотым веком»: проводились эксклюзивные Live Hacking Events, привлекающие топ-исследователей, с бесплатными поездками, персонализированными плакатами и высокой ценностью для программ.

С тех пор компания изменила стратегию, сместив фокус с поддержки хакеров на развитие внутренних технологий, включая ИИ-агенты для автоматизации тестирования и приоритизации уязвимостей. Основатели признают, что текущие инструменты ещё не готовы заменить человеческий опыт, но стремятся создать систему, где ИИ и исследователи работают в партнёрстве. Однако критики видят, что дух платформы «выродился», а её текущая модель — лишь попытка сохранить рынок, пока не появится более дешёвые альтернативы для компаний, готовых строить собственные платформы. Для хакеров ключевой посыл: их экспертиза остаётся неотъемлемой, а будущее принадлежит тем, кто создаст новую эру баг-бонтов.

HackerOne стал ориентирован на продажи и маркетинг, утратив изначальную миссию в области безопасности и сообщества хакеров. Платформа сталкивается с проблемами: низкое качество отчетов, высокий шум, сложности с оплатой вознаграждений. Некоторые пользователи признают её ценность в обработке оплат и фильтрации, но отмечают, что эти функции можно заменить альтернативными решениями. Компаниям не обязательно использовать HackerOne — можно создать собственную систему на базе существующих инструментов для платежей и фильтрации. Использование ИИ для триажа может сэкономить время, но повышает риск ложных отчетов и снижает качество. Спорно: требуется ли прозрачность в использовании ИИ для триажа и оплат — одни считают это важным, другие — несущественным.

Cursor содержит критическую уязвимость, позволяющую выполнить произвольный код при открытии репозитория с вредоносным файлом git.exe в корне — без каких-либо предупреждений или действий пользователя. Уязвимость проста, но опасна: IDE автоматически запускает этот файл, игнорируя безопасность. Учитывая, что Cursor используют более 7 млн активных пользователей и 50 тыс. компаний, а его оценка достигает $60 млрд, отсутствие реакции на уязвимость, обнаруженную в декабре 2025 года, вызывает серьёзные вопросы.

Mindgard неоднократно сообщал о проблеме через официальные каналы, включая security.txt и HackerOne, но Cursor игнорировал сообщения в течение семи месяцев, несмотря на подтверждение уязвимости и повторные запросы. Только после публичного давления компания признала сбой в автоматизированной системе, но не предприняла действий по исправлению. В ответ исследователи решили раскрыть детали — чтобы защищать пользователей, когда разработчик отказывается это делать. Для защиты рекомендуется блокировать выполнение исполняемых файлов в рабочих каталогах через AppLocker или использовать изолированные среды.

• LLM‑сгенерированные отчёты перегружают команду, их сложно отсеять без риска пропустить реальные проблемы
• Cursor по умолчанию не проверяет рабочее пространство, что позволяет выполнить произвольный код из репозитория (например, git.exe)
• Уязвимость связана с особенностью Windows, когда текущая директория имеет приоритет в поиске исполняемых файлов
• Публичное раскрытие вызвало споры о ответственности разработчиков и необходимости более строгих механизмов доверия

HackerOne — это платформа для координации программ bug bounty, где компании платят исследователям за обнаружение уязвимостей в их системах. Для полноценной работы сайта требуется включенный JavaScript в браузере, так как многие интерактивные функции, включая отправку отчетов и взаимодействие с интерфейсом, зависят от него.

Без JavaScript пользователь не сможет получить доступ к основному функционалу, включая просмотр программ, отправку отчетов об уязвимостях и управление профилем. Это стандартная практика для современных веб-приложений, обеспечивающая безопасность и удобство использования.

• Пользователи обсуждают волну бесполезных AI-генерируемых отчетов об уязвимостях (например, для cURL), которые тратят время разработчиков.
• Высказываются опасения, что в будущем AI сможет генерировать более правдоподобные, но все же ложные доказательства концепций (PoC).
• Предлагаются решения для борьбы со спамом: платный депозит за отправку отчета, баны, фильтрация по эмодзи и другим признакам AI-текста.
• Обсуждается негативное влияние AI на качество кода, ревью и общую культуру разработки, а также возможные скрытые мотивы таких атак.
• Отмечается профессиональная реакция мейнтейнера (badger) на некорректный отчет и ссылки на соответствующие доклады Дэниела Стенберга о проблеме.

• aka.ms — коротилка Microsoft. Попытка зайти на https://aka.ms привела к логину только для сотрудников.
• akasearch.net — индекс ссылок aka.ms; нашёлся eng.ms.
• eng.ms — домен с приложением EngineeringHub. При входе через личный M365-аккаунт появился consent-запрос на доступ к профилю. После подтверждения — 500-я ошибка, но OAuth-токен уже выдан.
• rescue.eng.ms — поддомен, где после аналогичного согласия открылся Engineering Hub Rescue: список 22 внутренних сервисов Microsoft (Cloud + AI, Gaming, Finance и др.) с полным доступом через обычный аккаунт.

Итог: публичные OAuth-приложения Microsoft внутри корпоративных тенантов могут выдавать токены сторонним пользователям, если не ограничены политикой согласия. Проверьте свои тенанты на наличие подобных приложений и настройте Admin consent workflow, чтобы избежать утечек.

• Документация Microsoft по Entra ID/SSO вызывает у разработчиков «тыкание в темноте» и ошибки конфигурации.
• Уязвимости в мультитенантных приложениях возникают из-за непроверенных полей токена (iss, tid, audience) и отсутствия фильтрации по тенантам.
• Даже внутренние сервисы Microsoft открыты в интернет из-за политики Zero Trust, что увеличивает поверхность атаки.
• Исследователь получил RCE на сборочных серверах Windows, но Microsoft не выплатила ни цента, вызвав критику программы bug bounty.
• Сообщество советует: не полагаться на Entra для авторизации, всегда валидировать каждое поле токена и строить defense-in-depth.