{"schema_version":"1.0","service":"Publicasta","type":"article","id":745,"slug":"carbonato_exposed_docker_daemons_response","title":"CARBONATO показывает: открытый Docker API — это компрометация хоста, а не проблема контейнера","excerpt":"Кампания CARBONATO атакует доступные из интернета Docker API без аутентификации. Ответ должен включать закрытие доступа, проверку хоста, ротацию секретов и аудит всех доступных Docker-сред.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru","image":{"url":"https://publicasta.com/storage/projects/9/pages/745/2026/10/e0e84b0a-a1d3-4792-aed0-fb9fd83a79da.webp","alt":"Редакционная иллюстрация открытого Docker-хоста: путь доступа из интернета к серверу и панели управления контейнерами."},"publisher":{"id":9,"slug":"cybersecurity","name":"Кибербезопасность без паники","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-10-01T13:58:39+00:00","updated_at":"2026-10-01T13:58:39+00:00","content_markdown":"Хост Docker с API без аутентификации, доступным из интернета, предоставляет не просто удобный канал удалённого управления. Он открывает удалённый путь к машине, на которой работают контейнеры. Кампания CARBONATO, о которой сообщили 30 сентября, не оставляет возможности игнорировать это различие: злоумышленники используют открытые Docker Remote API, чтобы создавать привилегированные контейнеры, закрепляться в системе, красть учётные данные и искать другие хосты Docker.\n\n ![Редакционная иллюстрация открытого Docker-хоста: путь доступа из интернета к серверу и панели управления контейнерами.](https://publicasta.com/storage/projects/9/pages/745/2026/10/e0e84b0a-a1d3-4792-aed0-fb9fd83a79da.webp)\n\n Это происшествие важно не потому, что в нём обязательно используется новая уязвимость Docker. В основе лежит более обычная проблема: административный интерфейс оказался в недоверенной сети без границы аутентификации. Вредоносная программа добавляет современную полезную нагрузку, включая переиспользованный фреймворк открытого ИИ-агента, но условие, сделавшее атаку возможной, старое и простое: любой, кто может обратиться к демону, способен попросить его выполнить операции с полномочиями хоста.\n\n Для команд, которые запускают Docker на облачных серверах, машинах сборки, разработческих хостах, самостоятельно размещаемых сервисах или периферийных системах, правильная реакция — оценка экспозиции и возможной компрометации. Нужно закрыть путь без аутентификации, установить, использовался ли хост, заменить всё, что могло быть прочитано, а затем проверить соседние системы. Переустановка контейнера или смена тега образа недостаточны, если сам хост или его учётные данные уже могли оказаться под чужим контролем.\n\n ## Что именно говорится в материалах о CARBONATO\n\n В [рекомендациях Агентства кибербезопасности Сингапура](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012/), опубликованных 30 сентября, сказано, что исследователи обнаружили ботнет-кампанию против хостов Docker, чьи удалённые API без аутентификации были доступны из интернета, обычно через TCP-порт 2375. В документе описывается использование штатных возможностей Docker для создания привилегированного контейнера с доступом к файловой системе, процессам и сети хоста.\n\n Последовательность действий здесь принципиальна. Если демон принимает административные запросы от недоверенного источника, злоумышленнику не обязательно эксплуатировать ошибку безопасности памяти в Docker Engine. Создание контейнера, подключение пути, запуск процесса или подключение к сети — обычные действия администратора. Но когда отправитель не аутентифицирован, а демон работает с высокими полномочиями, тот же запрос может привести к управлению хостом.\n\n Сингапурское агентство сообщает, что кампания способна обеспечивать постоянный удалённый доступ, красть учётные данные и другую конфиденциальную информацию, а также сканировать подключённые сети в поисках дополнительных открытых хостов Docker. При этом в рекомендациях не утверждается, что каждый открытый хост был скомпрометирован, и не приводится универсальный индикатор, который сам по себе мог бы доказать или исключить инцидент. Эти ограничения существенны. Документ — основание проверить экспозицию и журналы, а не повод объявлять заражённой каждую установку Docker.\n\n Отдельная [исследовательская записка Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-carbonato-botnet-docker-ai-agent-20260928/) дополняет картину сведениями о полезной нагрузке. В ней CARBONATO описывается как самораспространяющийся ботнет, устанавливающий неизменённый фреймворк ИИ-агента с открытым исходным кодом Hermes Agent и меняющий конфигурацию его персоны так, чтобы фреймворк служил целям операторов. В записке сказано, что заражённые хосты сканируют соседние диапазоны сети в поисках дополнительных демонов Docker.\n\n Необычен именно выбор полезной нагрузки. Для защитников по-прежнему важнее путь доступа. Наличие фреймворка ИИ может привлечь внимание, но ИИ-агент не нужен, чтобы превратить открытый демон Docker в серьёзный инцидент. Та же административная экспозиция может использоваться для кражи учётных данных, майнинга криптовалют, разрушительных действий, проксирования трафика, бокового перемещения или установки обычного бэкдора.\n\n ## Почему к порту 2375 нужен точный подход\n\n В документации Docker различаются обычный локальный сокет и удалённые сетевые подключения. По умолчанию Docker в Linux и macOS использует не сетевой Unix-сокет. Для удалённого администрирования можно применять SSH либо TCP-сокет, защищённый TLS и аутентификацией клиентов.\n\n Документация Docker также описывает традиционное разделение портов: TCP 2375 обычно используется для небезопасного соединения без TLS, а TCP 2376 обычно связан с TLS. Сам номер порта не доказывает компрометацию, а другой порт не делает API без аутентификации безопасным. Порт 2375 — лишь полезный сигнал разведки, поскольку часто показывает, что демон Docker настроен на обычный удалённый доступ.\n\n Ключевой вопрос звучит не так: «Открыт ли порт 2375?» Важно выяснить следующее:\n\n - Какой процесс прослушивает порт?\n- Доступен ли слушатель из публичного интернета, широкой корпоративной сети или только из ограниченного сегмента управления?\n- Требуется ли аутентификация и правильно ли проверяются полномочия клиента?\n- Какой демон Docker, учётная запись, хост и рабочая нагрузка находятся за этим интерфейсом?\n- Есть ли в журналах запросы, которые владелец не выполнял?\n\n Сервис, доступный из интернета, может быть опасным даже тогда, когда он не виден всему миру. Демон в плоской внутренней сети может быть доступен скомпрометированной рабочей станции, устройства подрядчика, учётной записи разработчика или другой рабочей нагрузке, которой никогда не следовало предоставлять административный контроль над хостом. Фраза «он открыт только внутри VPC» описывает сеть, но не модель авторизации.\n\n ## Корневая проблема: доступ к Docker означает доступ к хосту\n\n Контейнеры создают полезную границу изоляции, но доступ к демону Docker является административной привилегией. Docker предупреждает: изменение привязки демона на TCP-сокет или предоставление доступа к Unix-сокету через группу `docker` может позволить пользователю получить доступ к хосту на уровне root. Это предупреждение легко упустить, когда команда устраняет неполадки системы сборки или пытается упростить удалённую разработку.\n\n Контейнер с повышенными привилегиями может видеть или изменять ресурсы хоста. Даже без воспроизведения конкретной цепочки атаки защитный вывод однозначен: учётные данные демона Docker и доступ к его сокету нужно рассматривать как root-учётные данные. Они относятся к той же категории риска, что ключи облачного администратора, интерфейсы управления гипервизором и доступ к плоскости управления Kubernetes.\n\n Поэтому простое удаление подозрительного контейнера — слабая мера локализации. Если злоумышленник получил доступ к демону, он мог прочитать переменные окружения, подключить каталоги хоста, изучить другие контейнеры, скопировать файлы конфигурации, изменить механизмы запуска, создать дополнительные учётные записи или собрать учётные данные с хоста. Видимый контейнер может быть лишь одним артефактом более широкой компрометации.\n\n Тот же принцип действует для CI-раннеров. Раннер сборки с доступом к привилегированному сокету Docker может раскрыть исходный код, материалы подписи, учётные данные пакетов, облачные токены и права на развёртывание. Ноутбук разработчика с подключённым сокетом Docker может открыть локальные файлы и окружение хоста. Удалённый API, добавленный ради удобства, способен связать контейнерный процесс с идентификацией и инфраструктурой вокруг него.\n\n ## Что администраторам следует сделать в первую очередь\n\n Первая реакция должна уменьшить досягаемость для атакующего, не уничтожив доказательства.\n\n ### 1. Найти каждый демон Docker с сетевой экспозицией\n\n Начните с достоверного инвентаря, а не с воспоминаний команды. Проверьте облачные группы безопасности, межсетевые экраны хостов, балансировщики, маршруты VPN, записи обнаружения сервисов, конфигурацию контейнерных хостов, unit-файлы systemd, файлы конфигурации демона, шаблоны оркестрации и репозитории инфраструктуры как кода.\n\n Ищите слушатели демона Docker на TCP-портах 2375 и 2376, но также проверяйте нестандартные порты и привязки, например слушатель на всех интерфейсах. Охватите рабочие и нерабочие среды. Разработческие хосты часто сильнее открыты, хуже контролируются и при этом подключены к сетям, где находятся ценные учётные данные.\n\n [Рекомендации CISA по сокращению интернет-экспозиции](https://www.cisa.gov/resources-tools/resources/exposure-reduction) советуют формировать видимость активов, доступных из интернета, и устранять ненужную экспозицию. Такой же подход нужен для внутреннего доступа: установите, что достижимо, откуда и по какой деловой причине. Актив, отсутствующий в инвентаре, невозможно надёжно исправлять, отслеживать или расследовать.\n\n Если демон без аутентификации открыт наружу, немедленно ограничьте доступ на сетевом уровне, сохранив журналы и записи изменений. Экстренная цель — остановить новые подключения без аутентификации. Не считайте изменение правила межсетевого экрана доказательством чистоты хоста: оно лишь меняет круг тех, кто может до него добраться.\n\n ### 2. Убрать обычный удалённый доступ\n\n [Официальные рекомендации Docker по защите сокета демона](https://docs.docker.com/engine/security/protect-access/) предлагают использовать SSH или TLS для защиты удалённого доступа. SSH может быть практичным вариантом для операторов: он пересылает запросы к удалённому Unix-сокету и опирается на существующую модель аутентификации и авторизации хоста.\n\n Если TCP-доступ действительно необходим, используйте взаимную аутентификацию TLS с контролируемым центром сертификации, защищайте закрытые ключи, ограничивайте исходные сети и журналируйте административные действия. Сервис, зашифрованный TLS, но не требующий аутентификации, всё равно остаётся проблемой авторизации. Шифрование защищает трафик от наблюдения и подмены, но не решает, должен ли клиент иметь право создавать привилегированные контейнеры.\n\n Предпочтительнее частный путь управления, а не публичный слушатель. Применяйте принцип минимальных привилегий к идентификаторам, которым разрешено администрировать демон, разделяйте действия людей и автоматизации и не раздавайте один широко применимый клиентский сертификат заданиям сборки или нескольким командам. Сертификат, дающий неограниченный доступ к Docker, нужно считать учётными данными root хоста.\n\n Не пытайтесь исправить экспозицию одной лишь сменой номера порта. Группы безопасности, межсетевые экраны хоста, маршрутизация, аутентификация и авторизация должны согласованно описывать предполагаемую границу управления.\n\n ### 3. Сохранить и проверить доказательства\n\n Для потенциально открытого хоста сохраните соответствующие системные, сетевые, облачные, Docker-, оркестрационные журналы и журналы идентификации до ротации или перестройки системы. Определите период, когда демон был доступен, и сопоставьте его с сообщениями о кампании и собственной телеметрией.\n\n Полезные вопросы для проверки:\n\n - Были ли неожиданные запросы к конечным точкам Docker API?\n- Создавались, запускались, останавливались или удалялись контейнеры вне обычных окон развёртывания?\n- Появлялись ли новые образы, реестры, сети, тома или секреты?\n- Подключались ли к контейнерам пути хоста без ожидаемой причины?\n- Запускался ли контейнер с повышенными привилегиями, сетевым режимом хоста или доступом к чувствительным каталогам?\n- Создавались ли на хосте новые процессы, пользователи, запланированные задания, сервисы, SSH-ключи или записи автозапуска?\n- Устанавливал ли хост необычные исходящие соединения, особенно с инфраструктурой управления и контроля или незнакомыми реестрами?\n- Показывали ли другие хосты в той же сети попытки подключений, связанных с Docker, вскоре после этого?\n\n Цель — не найти одно магическое имя файла. Злоумышленники могут удалять контейнеры, переименовывать процессы, использовать штатные инструменты или устанавливать другую полезную нагрузку. Сопоставляйте активность API с запуском процессов, сетевыми потоками, обращениями к реестрам, событиями облачного аудита и журналами провайдера идентификации.\n\n Если на хосте работают чувствительные нагрузки или журналы не позволяют установить произошедшее, изолируйте его и следуйте процессу реагирования организации. Когда целостность хоста вызывает сомнения, перестройте его из доверенного образа. Перестройка убедительнее, если вместе с ней проверены учётные данные, конфигурация и артефакты развёртывания, а не выполнено их бездумное копирование с потенциально скомпрометированной системы.\n\n ### 4. Заменить раскрытые секреты с учётом их полномочий\n\n Исходите из того, что могли быть раскрыты секреты, доступные демону Docker, хосту, подключённым томам, переменным окружения, слоям образов или работающим процессам. Приоритизируйте учётные данные по тому, что они позволяют сделать, а не по месту хранения.\n\n В список могут входить ключи доступа к облаку, токены CI, токены системы контроля версий, учётные данные реестра, пароли баз данных, SSH-ключи, ключи подписи, секреты вебхуков, токены сервисных аккаунтов и данные, встроенные в файлы развёртывания. Отозвать или заменить их нужно из доверенного административного канала. После выпуска новых данных проверьте, не использовались ли они необычным образом.\n\n Ротация без отзыва неполна, если старый секрет остаётся действительным. Ротация без просмотра журналов не учитывает возможность, что атакующий уже воспользовался секретом для доступа к другой службе. Ротация без карты зависимостей может нарушить рабочую среду, поэтому её нужно координировать, но операционные неудобства не оправдывают сохранение активных ценных учётных данных после достоверной экспозиции.\n\n Проверьте также секреты, которые непосредственно не хранились на хосте, но были достижимы через его идентификатор. Скомпрометированная роль облачного экземпляра, идентификатор рабочей нагрузки или сервисный аккаунт CI могут расширить инцидент далеко за пределы одного сервера Docker.\n\n ## Как выглядит безопасная архитектура\n\n Защищаемая конфигурация Docker обычно имеет узкий административный путь и явную причину для каждого исключения.\n\n Для локального администрирования сохраняйте стандартный Unix-сокет под контролем разрешений хоста и ограничивайте членство в группе `docker`. Это членство не является безобидным удобством: оно может давать широкое управление демоном, а значит, и хостом.\n\n Для удалённого администрирования используйте SSH или взаимную аутентификацию TLS, ограничивайте исходные адреса и при необходимости помещайте сервис за управляемую сеть или VPN. Храните журналы вне хоста, чтобы атакующий не мог стереть единственную копию. Отслеживайте выпуск сертификатов, использование ключей и изменения конфигурации демона.\n\n Для CI не передавайте недоверенному заданию сборки привилегированный сокет хоста. Рассмотрите rootless-режимы, изолированные раннеры, краткоживущие рабочие узлы, отдельные идентификаторы для сборки и развёртывания, а также API с узкой областью действия. Если сборке действительно нужны привилегированные операции, относитесь к раннеру как к высокорисковой административной системе и изолируйте его соответственно.\n\n В облачных средах включите слушатели Docker в управление поверхностью атаки и обнаружение дрейфа конфигурации. Безопасный шаблон может быть отменён последующим скриптом запуска, конфигурацией демона, встроенной в образ, командой для устранения неполадок или временным исключением в межсетевом экране, которое стало постоянным.\n\n Для разработчиков задокументируйте утверждённый удалённый процесс. Команды часто создают небезопасные слушатели, потому что защищённый путь непонятен или неудобен. Поддерживаемый SSH-контекст, управляемая среда разработки или грамотно спроектированный сервис сборки уменьшают давление, подталкивающее к прямому раскрытию демона.\n\n ## Как отличить экспозицию от подтверждённой компрометации\n\n Публичный или широко доступный внутренний слушатель Docker — серьёзная находка, но сам по себе он не доказывает, что атакующий им воспользовался. В записях об инциденте нужно разделять три состояния:\n\n 1. **Экспозиция подтверждена:** демон принимал или мог принимать подключения из недоверенной сети.\n2. **Подозрительная активность обнаружена:** журналы или телеметрия хоста показывают запросы, процессы, сетевую активность или изменения конфигурации, которые нельзя объяснить разрешённой работой.\n3. **Компрометация подтверждена:** у расследования достаточно доказательств, что неавторизованная сторона получила контроль или доступ к данным.\n\n Такое разделение улучшает решения. Подтверждённая экспозиция должна привести к немедленному закрытию доступа и проверке на основе риска. Обнаруженная подозрительная активность требует локализации и реагирования на инцидент. Подтверждённая компрометация требует полного определения масштаба, отзыва учётных данных, восстановления, оценки необходимости уведомлений и извлечения уроков.\n\n Это также помогает избежать двух распространённых ошибок. Первая — самоуспокоенность: «Мы не видели вредоносный контейнер, значит, экспозиция была безвредной». Вторая — преувеличение: «Порт 2375 был открыт, значит, вся среда точно взломана». Хороший отчёт по безопасности может быть срочным, не делая вид, будто доказательств больше, чем есть.\n\n ## ИИ здесь вторичен, но этот аспект тоже полезен\n\n Использование CARBONATO фреймворка ИИ-агента показывает, как атакующие могут упаковывать автоматизацию, но не означает, что каждый компонент ИИ сам по себе вредоносен. Описанный Cloud Security Alliance фреймворк имеет открытый исходный код и может использоваться легитимно. Его превращение в часть ботнета иллюстрирует знакомую закономерность: легитимное программное обеспечение становится элементом атаки, когда противник контролирует окружение исполнения и конфигурацию.\n\n Поэтому в расследование следует включить установленное программное обеспечение, файлы конфигурации, запланированную активность, исходящие направления и учётные данные, к которым обращались процессы. Поиск только названия продукта может пропустить изменённое развёртывание или совершенно другую полезную нагрузку. И наоборот, блокировка имени легитимного фреймворка без устранения экспозиции Docker оставит исходный путь доступа открытым.\n\n Более широкий вывод связан с границами автоматизации. Фреймворк ИИ на скомпрометированном хосте может сделать выполнение задач гибче, но он не создаёт исходное полномочие. Полномочие пришло от демона Docker. Именно сильная аутентификация, сегментация сети, целостность хоста, гигиена учётных данных и полезные журналы остаются важными средствами защиты.\n\n ## Практический список для следующей проверки\n\n Команды могут превратить этот инцидент в повторяемую проверку средств контроля:\n\n - Составьте инвентарь всех демонов Docker и сетей, которые могут до них добраться.\n- Подтвердите, что ни один API Docker без аутентификации не доступен из интернета или недоверенной внутренней сети.\n- Ищите TCP 2375 и нестандартные слушатели демона, а не только ожидаемые имена сервисов.\n- Замените произвольное TCP-администрирование на SSH или корректно настроенную взаимную аутентификацию TLS.\n- Ограничьте доступ к сокету Docker и проверьте членство в группе `docker`.\n- Отделите CI-раннеры от чувствительных производственных сетей и учётных данных.\n- Централизуйте журналы Docker, хоста, межсетевого экрана, облака, идентификации и реестров.\n- Проверяйте неожиданные создания контейнеров, привилегированные настройки, подключения путей хоста, новые образы и исходящие соединения.\n- Заменяйте учётные данные, которые могли быть доступны с затронутых хостов или рабочих нагрузок.\n- Перестраивайте хосты, если их целостность невозможно установить с доверенного носителя.\n- Добавьте экспозицию демонов и дрейф конфигурации в регулярные проверки безопасности.\n- Документируйте утверждённый удалённый процесс управления, чтобы инженеры не создавали аварийные слушатели.\n\n CARBONATO вовремя напоминает: плоскость управления контейнерной платформы сама является критически важным активом. Решающее защитное действие — не рассуждать о новизне полезной нагрузки, а проверить, кто может обратиться к демону, что демон способен делать, что он делал недавно и какие идентификаторы окажутся раскрыты, если хост будет скомпрометирован. Когда эти вопросы становятся обычной практикой, риск легче контролировать без паники и без желаемого за действительное.","available_translations":[{"language":"ar","title":"تكشف CARBONATO لماذا يعني كشف واجهة Docker API اختراق المضيف، لا مجرد مشكلة في الحاوية","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ar"},{"language":"de","title":"CARBONATO zeigt, warum eine offengelegte Docker-API ein Host-Kompromittierungsszenario und kein Containerproblem ist","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=de"},{"language":"en","title":"CARBONATO Shows Why an Exposed Docker API Is a Host Compromise, Not a Container Problem","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=en"},{"language":"es","title":"CARBONATO demuestra por qué una API de Docker expuesta implica comprometer el host, no solo un contenedor","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=es"},{"language":"fr","title":"CARBONATO montre qu’une API Docker exposée compromet l’hôte, pas seulement les conteneurs","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=fr"},{"language":"pl","title":"CARBONATO pokazuje, że ujawnione API Dockera oznacza przejęcie hosta, a nie tylko problem z kontenerem","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=pl"},{"language":"ru","title":"CARBONATO показывает: открытый Docker API — это компрометация хоста, а не проблема контейнера","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ru"},{"language":"zh","title":"CARBONATO 揭示：暴露在公网的 Docker API 是主机失陷问题，而不只是容器问题","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ru","html":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru","canonical":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru","markdown":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ru","json":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}