CVE-2026-65400: самопроверка удалённого Mac — чек-лист 2026

Симптом: удалённый Mac или CI-узел использует Screen Sharing, а статус исправления CVE-2026-65400 неизвестен.
Быстрое решение: сначала сверить версию и сборку macOS с бюллетенями Apple, затем проверить, включены ли Screen Sharing и Remote Management и доступны ли они из недоверенных сетей. SSH не следует автоматически считать затронутой службой.

Кому пригодится: инженерам, отвечающим за удалённые Mac и CI-узлы, — для проверки обновлений и удалённого доступа.
Операторам сборочной инфраструктуры — чтобы оценить влияние обновления и зафиксировать приёмку.
Руководителям небольших команд — чтобы вести список хостов, подтверждения исправлений и порядок эскалации.

Последняя проверка: 26 октября 2026 года. Сведения сверены с материалами Apple по CVE-2026-65400, перечнем обновлений безопасности Apple и записью CISA. При появлении новых бюллетеней статус нужно перепроверить.

Самопроверка удалённого Mac при CVE-2026-65400

CVE-2026-65400 касается проблемы аутентификации в Screen Sharing. Это не основание заключать, что уязвимы все протоколы удалённого доступа или каждый Mac, доступный через сеть. Ваша проверка должна ответить на три разных вопроса: относится ли установленная версия macOS к описанным Apple веткам, включён ли Screen Sharing или Remote Management и можно ли обратиться к ним из сети, которой вы не доверяете.

Apple опубликовала сведения об исправлениях для нескольких веток macOS. Сверяйте версию и номер сборки конкретного хоста с материалами Apple для соответствующей ветки, а также с актуальным перечнем обновлений безопасности. Не переносите выводы о более раннем выпуске на более позднюю систему без проверки: Apple может публиковать отдельные обновления и дополнять сведения о затронутых версиях.

CISA добавила CVE-2026-65400 в каталог KEV 18 августа 2026 года. Это значимое основание поставить проверку в приоритет, но само включение в каталог не означает, что конкретный ваш узел был скомпрометирован. По описанию Apple определяйте затронутую службу и статус устранения; запись CISA подтверждает факт включения в KEV. Не заменяйте этими первичными источниками пересказы без ссылок на бюллетени.

Оценки в таблице — рабочая классификация приоритета для сортировки узлов, а не результат измерения вероятности атаки. Сочетание неподтверждённого исправления и доступности извне требует более быстрой реакции, чем изолированный узел с отключённой службой, однако оба состояния нужно документировать.

Проверка обновления и идентификация сборки

Начните с записи данных, а не с установки обновления вслепую. На самом Mac или через SSH выполните команды:

sw_vers -productVersion
sw_vers -buildVersion

Первая команда выводит версию продукта, вторая — номер сборки. Команда не доказывает, что уязвимость исправлена: её результат нужно сопоставить с веткой macOS и сведениями Apple. Пояснение о версии и сборке macOS доступно в справке Apple.

Дальше действуйте последовательно:

1. Составьте перечень узлов. Для каждой машины запишите имя или внутренний идентификатор, назначение, владельца, версию macOS, сборку, способ администрирования и критичные задания. Не храните единственную копию сведений в терминальном журнале, доступном только с проверяемого хоста.
2. Сопоставьте данные с бюллетенем. Откройте страницу Apple о CVE-2026-65400 и найдите сведения именно для установленной ветки. Сверьте результат с общим списком обновлений безопасности, потому что более поздние записи могут уточнить, какие выпуски содержат исправление.
3. Отметьте статус без догадок. Используйте формулировки «исправление подтверждено по бюллетеню», «требуется обновление» или «не удалось сопоставить». Не записывайте «защищён» только потому, что версия выглядит новой или на экране нет предупреждения.
4. Если исправление отсутствует — согласуйте окно обслуживания. Перед установкой проверьте зависимые сборочные задания, требования к доступности узла и порядок возврата в эксплуатацию. Пароль, список разрешённых пользователей и закрытие порта не заменяют установку исправления; это дополнительные меры ограничения доступа.
5. Установите подходящее обновление и повторите сверку. После обновления снова получите версию и сборку, а затем проверьте их по документам Apple. Сохраните исходное состояние, итоговые данные и использованный бюллетень.
6. Проверьте рабочие задачи. Запустите согласованный тест сборки или другой контрольный сценарий. Обновлённый хост, который не выполняет критичную работу, нельзя считать принятым только на основании новой сборки.

Для актуальной ветки не используйте таблицу версий из старого внутреннего документа как единственный источник. Материалы Apple по Sonoma и Sequoia показывают, почему проверять следует бюллетень конкретной ветки: исправления и сведения привязаны к выпускам системы. Если для вашей версии нет однозначного совпадения, зафиксируйте неопределённость и уточните её по новейшей документации Apple, а не переносите номер сборки с другой ветки.

Screen Sharing, Remote Management и сетевой периметр

Установка исправления не отвечает на вопрос, кто может подключиться к графическому сеансу. Отдельно проверьте настройки macOS, права пользователей и сетевые правила. На узле откройте настройки общего доступа и зафиксируйте состояние Screen Sharing, Remote Management и списка пользователей с разрешением на доступ. Справка Apple описывает настройку Screen Sharing; сверяйте названия пунктов с актуальным интерфейсом системы, поскольку они могут отличаться между выпусками.

Следующая проверка — не только локальный брандмауэр. Проследите путь трафика через сетевой экран хоста, правила маршрутизатора, VPN или туннеля, а также облачные правила, если они применяются. Apple указывает TCP-порт 5900 для Screen Sharing в справочнике портов Remote Desktop. Наличие этого порта в справочнике не означает, что ваш узел слушает его или что он открыт наружу; это параметр для целевой проверки конфигурации.

Важно: проверка настройки на самом Mac не подтверждает сетевую недоступность извне. Для вывода о периметре сопоставьте локальную конфигурацию с правилами на всех промежуточных сетевых устройствах и проверьте результат из предусмотренной вашей процедурой контрольной точки.

Если графический доступ не нужен сборочному узлу, отключайте его по принятому процессу изменения конфигурации и проверьте, что задания продолжили выполняться через нужный им путь. Если Screen Sharing необходим, ограничьте его доверенной административной сетью и конкретными учётными записями, а не оставляйте доступ широким «на время» без владельца и срока пересмотра. Внутреннюю схему удалённых способов подключения можно сопоставить с описанием вариантов доступа и размещения Mac.

SSH и Screen Sharing отличаются как по назначению, так и по настройке. Включённый SSH не доказывает, что включён Screen Sharing; отключённый Screen Sharing не доказывает, что SSH закрыт или правильно ограничен. Инструкция Apple по Remote Login и SSH описывает именно удалённый вход, поэтому ведите отдельные строки учёта для каждой службы. Если сборочный процесс работает через SSH, проверяйте его после ограничения графического доступа, не ослабляя сетевые правила для всех остальных служб.

Подтверждение результата и обработка подозрений

В карточке каждого узла оставьте компактный, но проверяемый след: версию и сборку до и после обновления; ссылку на бюллетень Apple; состояние Screen Sharing и Remote Management; список разрешённых пользователей; относящиеся к узлу правила сетевого доступа; дату и результат контрольной сборки. Такой журнал помогает дежурному инженеру понять, что именно проверено, а не только увидеть отметку «обновлено».

Если замечены неизвестный сеанс, непривычная учётная запись или изменение настроек без владельца, не ограничивайтесь установкой обновления. Сначала действуйте по процедуре реагирования организации: сохраните доступные журналы и сведения о конфигурации, зафиксируйте время обнаружения и передайте случай ответственным за инциденты. Если это допускает процедура, ограничьте Screen Sharing до доверенной сети или отключите его через контролируемое изменение. Не удаляйте следы и не объявляйте инцидент закрытым лишь потому, что повторная проверка не обнаружила активного подключения.

Отсутствие видимой аномалии — это отсутствие обнаруженного события, а не доказательство отсутствия прежнего доступа. Текущая версия подтверждает состояние системы на момент проверки, но сама по себе не устанавливает, кто подключался ранее. Если нужны дополнительные сведения о порядке доступа к сервису, используйте раздел ответов zshmac как дополнение, а не замену внутренней процедуре реагирования.

Частые вопросы о проверке CVE-2026-65400

Какие ветки macOS следует проверить?

Apple опубликовала сведения об исправлениях для нескольких веток macOS. Проверяйте не только название системы, но и номер сборки, затем сопоставляйте их с отдельным бюллетенем Apple и текущим списком обновлений безопасности. Более поздний выпуск не следует автоматически считать исправленным без подходящей записи для этой ветки.

Как подтвердить исправление на удалённом Mac?

Получите версию macOS и номер сборки, сверяйте их с бюллетенем Apple по CVE-2026-65400 и списком обновлений. Убедитесь, что для вашей ветки указан выпуск с исправлением или более позднее обновление, включающее его. Запишите дату и ссылки на использованные материалы, чтобы результат можно было перепроверить.

Нужна ли проверка Screen Sharing при включённом только SSH?

Да, проверьте состояние, но не потому, что SSH автоматически подпадает под эту CVE. Apple связывает проблему с аутентификацией Screen Sharing, тогда как SSH — отдельный путь удалённого входа. Подтвердите, что Screen Sharing и Remote Management действительно отключены, а SSH доступен только по предназначенным для него правилам.

Как проверить сетевую доступность Screen Sharing?

Сверьте локальные настройки Mac с правилами брандмауэра, маршрутизатора и облачной сети. Для целевой проверки учитывайте TCP-порт 5900, указанный Apple для Screen Sharing, и проверяйте доступ из контрольной точки за пределами доверенной сети. Одной настройки на хосте недостаточно, чтобы подтвердить закрытие всего сетевого пути.

Завершение проверки и выбор среды

Если вы сейчас используете собственный удалённый Mac или CI-узел, слабые места обычно не сводятся к самому обновлению: сведения о сборках могут быть разрознены, правила доступа — различаться между командами, а графическая служба — оставаться включённой после завершения работ. Сначала завершите инвентаризацию, подтвердите патч и повторно проверьте сетевой периметр; затем сохраните результаты и назначьте владельца для повторной проверки при следующем обновлении Apple.

Если же вам требуется временная среда macOS для разработки или проверки сборок, аренда Mac может избавить от покупки и самостоятельного обслуживания дополнительного оборудования, но не отменяет обязанности проверять обновления и доступ. Для редких запусков и кратких тестов это может быть удобнее собственного узла; для постоянной тяжёлой нагрузки, специальных физических подключений или требований к локальному контролю разумнее оценить собственный Mac. До выбора сравните условия размещения и способы подключения, а затем примените к выбранному хосту тот же порядок проверки — исправление, права пользователей и сетевую доступность.

Часто задаваемые вопросы