macOS Tahoe 26.6.1: уязвимость Screen Sharing и что с ней делать

Apple выпустила macOS Tahoe 26.6.1 в четверг, 6 августа 2026 года, через десять дней после 26.6. Не было ни бета-версии для разработчиков, ни публичной беты. Никаких новых функций, никакого обновления Safari, никаких изменений прошивки. В примечаниях к выпуску описано одно-единственное исправление безопасности, а в документе по безопасности перечислена ровно одна CVE.

Именно это сочетание и есть главная новость. Обычно Apple раздаёт промежуточный выпуск разработчикам хотя бы на несколько дней перед релизом, а обновление вида x.x.1 обычно несёт горстку исправлений ошибок вдобавок к тому, что в нём есть по части безопасности. Здесь этап раздачи бет пропущен полностью, а внутри один пункт: CVE-2026-65400 в компоненте Screen Sharing. В тот же день Apple перенесла то же самое исправление в macOS Sequoia 15.7.9 и macOS Sonoma 14.8.9 — так поступает вендор, который хочет закрыть дыру сразу везде, а не только в актуальном выпуске.

В уязвимости Screen Sharing из macOS Tahoe 26.6.1 стоит разобраться как следует, потому что в честной версии этой истории есть большой пробел ровно там, где должна была быть самая интересная деталь. Описание последствий у Apple — одно предложение. Там не сказано, должна ли была затронутая служба быть включена. Там не описан механизм. Некоторые издания заполнили этот пробел подробностями, которые никто не подтвердил. Этот материал разбирает, что действительно подтверждено, что по-настоящему неизвестно, кто реально был под угрозой, и практическую часть, которая важна независимо от того, как работала ошибка: аудит поверхности удалённого доступа на вашем собственном Mac.

Главное вкратце

• macOS Tahoe 26.6.1 — это сборка 25G76, выпущенная 6 августа 2026 года, с одним исправлением безопасности и больше ничем. Safari остаётся на версии 26.6, системная прошивка не менялась и остаётся на 18000.161.9, новых функций нет. По разбору пакетов обновления от Mr. Macintosh, дельта-обновление весит около 2,1 ГБ на Apple silicon и около 898,9 МБ на Intel.
• CVE-2026-65400 — это обход аутентификации в Screen Sharing. Формулировка Apple о последствиях звучит так: «An attacker on the network may be able to authenticate to Screen Sharing without valid credentials» (атакующий в сети может пройти аутентификацию в Screen Sharing без действительных учётных данных). Исправление, словами Apple: «An authentication issue was addressed with improved state management» (проблема аутентификации устранена за счёт улучшенного управления состоянием). Apple благодарит Alfredo Pesoli (@__rev), работавшего совместно с Bynario Atlas, — немецкое издание heise описывает это как систему поиска уязвимостей на основе ИИ.
• Область действия — локальная сеть, а не открытый интернет. heise отмечает: если Mac находится в локальной сети и соответствующие порты не проброшены на маршрутизаторе, удалённое подключение к экрану из интернета невозможно. Реалистичная модель угрозы — общая Wi-Fi-сеть: офис, общежитие, коворкинг, отель, кафе.
• Apple не сообщила, должен ли Screen Sharing быть включён для срабатывания атаки, и это самый весомый аргумент в пользу обновления. heise прямо заявляет, что на данный момент неясно, должны ли быть активны Screen Sharing или Apple Remote Desktop, или же атака возможна даже при в целом отключённом доступе к экрану. На новом Mac Screen Sharing выключен по умолчанию, поэтому многим хочется сделать вывод, что их это никогда не касалось. Ничего из опубликованного Apple такой вывод не подтверждает.
• То же исправление вышло в macOS Sequoia 15.7.9 (сборка 24G830) и macOS Sonoma 14.8.9 (сборка 23J631). То, что Apple в один день перенесла его в две более старые мажорные версии, — разумный сигнал того, что компания сочла проблему серьёзной. Об известных случаях активной эксплуатации Apple не сообщает. Оставаться на более старой macOS здесь нормально, если вы установили соответствующий патч.

Что такое macOS Tahoe 26.6.1 на самом деле

Tahoe 26.6 вышла 27 июля 2026 года как сборка 25G72 и стала крупнейшим пакетом исправлений безопасности за весь цикл Tahoe, закрыв заметно больше 140 проблем. Наш полный разбор macOS Tahoe 26.6 рассказывает, что туда вошло, включая работу над переиндексацией Spotlight, которую Apple описала как подготовку к macOS 27.

macOS Tahoe 26.6.1 — выпуск противоположного типа. Это сборка 25G76 от 6 августа 2026 года, и существует она ради закрытия одной дыры.

Вот что подтверждено о самом пакете:

• Сборка: 25G76
• Дата выпуска: 6 августа 2026 года, примерно через десять дней после 26.6
• Раздача бет: отсутствует. Ни беты для разработчиков, ни публичной беты
• Новые функции: нет
• Safari: остаётся на версии 26.6, не обновлялся
• Системная прошивка: без изменений, 18000.161.9
• Содержимое по безопасности: одна CVE, CVE-2026-65400, в Screen Sharing
• Документ Apple по безопасности: support.apple.com/en-us/148170

Размеры загрузки приводит Mr. Macintosh, который регулярно публикует детали пакетов для выпусков Apple. Дельта-обновление занимает около 2,1 ГБ на Apple silicon и около 898,9 МБ на Intel. Если вы скачиваете полный установщик вместо дельты, объём будет заметно больше. То, что дельта для Intel меньше гигабайта, а для Apple silicon превышает два, — нормально для Tahoe: на Apple silicon в состав входит полезная нагрузка подписанного системного тома, которая пересобирается иначе.

Почему важно отсутствие беты

Обычный ритм Apple для промежуточного выпуска включает хотя бы одну сборку для разработчиков, как правило кандидат в релизы, и часто публичную бету днём-двумя позже. Этот процесс нужен, чтобы выловить регрессии до того, как обновление получат миллионы машин.

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

Второй сигнал — бэкпорт. Apple поддерживает обновления безопасности для двух версий macOS, предшествующих текущей, но не всегда выпускает одно и то же исправление для всех трёх в один день. То, что здесь так и произошло — для Sequoia 15.7.9 и Sonoma 14.8.9, — говорит о том, что Apple сочла проблему такой, которая не должна оставаться незакрытой ни на одной поддерживаемой машине.

Хронология версий на сегодня

Если хотите понять, где вы находитесь, вот значимые недавние выпуски Tahoe:

• 26.5 — 11 мая 2026 года, описан в нашем руководстве по обновлению macOS Tahoe 26.5
• 26.5.1 — 1 июня 2026 года
• 26.5.2 — 29 июня 2026 года
• 26.6 — 27 июля 2026 года, сборка 25G72
• 26.6.1 — 6 августа 2026 года, сборка 25G76

Чтобы узнать, что установлено на вашем Mac, откройте Терминал и выполните:

sw_vers

Команда выведет название продукта, номер версии и сборку. Если версия — 26.6.1, а сборка — 25G76, патч у вас есть. Также можно открыть меню Apple, затем «Об этом Mac», и щёлкнуть по номеру версии, чтобы увидеть сборку.

Что позволяла CVE-2026-65400, простыми словами

Документы Apple по безопасности славятся своей лаконичностью. В этом случае всё описание укладывается в два предложения.

Последствия:

An attacker on the network may be able to authenticate to Screen Sharing without valid credentials.

Исправление:

An authentication issue was addressed with improved state management.

Оба предложения стоит прочитать внимательно.

«Authenticate to Screen Sharing»

Screen Sharing на Mac — это служба, которая передаёт живое управление графическим сеансом. Подключившийся видит то, что на экране, и может двигать указатель, набирать текст, открывать программы и читать всё, что мог бы прочитать вошедший в систему пользователь. Это не канал передачи файлов и не режим просмотра только для чтения. Это ваш рабочий стол целиком.

Обычно для доступа к этой службе нужны учётные данные. В зависимости от настройки это либо пароль учётной записи пользователя, которому разрешено подключаться, либо отдельный пароль VNC, если включён устаревший вариант VNC. Служба проверяет эти данные, прежде чем открыть сеанс.

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

Что это ему даёт — уровень привилегий той учётной записи, под которой авторизовано подключение. На Mac, где подключаемая учётная запись является администратором, это сеанс с правами администратора, что на практике близко к полному контролю над машиной. На Mac, где для общего доступа используется обычная учётная запись, это доступ этого пользователя, чего всё равно достаточно, чтобы читать документы, просматривать почту и видеть всё на экране.

«Improved state management»

Apple использует небольшой словарь описаний исправлений, и каждая формулировка примерно соответствует определённому классу ошибок. «Improved state management» обычно указывает на службу, которая неверно отслеживала собственный прогресс в многошаговом процессе. Где-то в коде хранилось представление о том, прошло ли данное подключение аутентификацию, и это представление могло оказаться неверным.

Дальше этого публичные сведения не идут. Apple не опубликовала механизм, и никакие сторонние бюллетени, кроме собственного бюллетеня Apple, его не описали.

О благодарности исследователю

Apple благодарит Alfredo Pesoli (@__rev), работавшего совместно с Bynario Atlas (bynar.io). heise описывает Bynario Atlas как систему поиска уязвимостей на основе ИИ, что делает этот случай одним из наиболее заметных примеров того, как автоматизированный конвейер обнаружения приводит к упомянутой в благодарностях CVE у Apple. Написание имени исследователя в разных изданиях слегка расходится; сам факт благодарности под сомнение не ставится.

Реалистичная модель угрозы: только локальная сеть

Формулировка «атакующий в сети» несёт в описании последствий Apple большую нагрузку, и это самый полезный контекст для того, чтобы решить, насколько сильно волноваться.

Материал heise проводит границу явно: если Mac находится в локальной сети и соответствующие порты не проброшены на маршрутизаторе, удалённое подключение к экрану из интернета невозможно. Screen Sharing слушает TCP-порт 5900, а Apple Remote Desktop дополнительно использует 3283. Потребительские маршрутизаторы не пробрасывают эти порты, пока кто-нибудь не настроит это вручную, а трансляция сетевых адресов означает, что атакующий из публичного интернета не может просто обратиться к приватному адресу вашего Mac.

То есть атакующий уже должен находиться в том же сегменте сети, что и ваш Mac.

Что «в той же сети» означает на практике

Это не так экзотично, как звучит. Сети, где вы делите широковещательный домен с людьми, которых не контролируете, включают:

• Офисный Wi-Fi, включая гостевые сети, которые толком не изолированы от основной
• Коворкинги, где сам смысл в том, что инфраструктурой пользуются незнакомые люди
• Университетские общежития и кампусные сети, которые часто плоские и огромные
• Wi-Fi в отелях, который нередко представляет собой одну подсеть на все номера
• Wi-Fi в кафе и аэропортах
• Сети на конференциях и мероприятиях
• Жилые дома с общим интернетом

Сети, где риск заметно ниже:

• Домашняя сеть с небольшим числом известных устройств — при условии, что пароль от Wi-Fi не раздан широкому кругу и в сети нет недоверенных устройств
• Машина, подключённая только через мобильную раздачу с телефона, который вы контролируете

Есть одна оговорка, которую стоит проговорить. «Атакующий в сети» не обязательно означает человека с ноутбуком, сидящего в здании. Скомпрометированное устройство, уже находящееся в сети, работает ничуть не хуже. Сюда относится заражённая машина с Windows, плохо обслуживаемое IoT-устройство или маршрутизатор с известной уязвимостью. Ограничение локальной сетью существенно сужает риск; оно не сводит его к нулю.

Почему это серьёзная ошибка, но не повод для паники

Температуру здесь задают три факта вместе. Первый: Apple не сообщает об известных случаях активной эксплуатации. Второй: атака требует нахождения в одной сети, поэтому массового сканирования всего интернета тут не будет. Третий: Apple не опубликовала механизм, а значит, потенциальному атакующему придётся находить его самостоятельно, а не читать чужой разбор.

С другой стороны, исправление было достаточно срочным, чтобы пропустить раздачу бет, и достаточно важным, чтобы дважды его перенести. Правильная реакция — установить обновление на этой неделе и заодно проверить настройки общего доступа. А не отключать Mac от интернета.

Кто действительно был под ощутимой угрозой

Не все Mac подвергались здесь одинаковому риску, и здесь стоит говорить конкретно, а не выпускать огульное предупреждение.

Повышенный риск

Постоянно включённые Mac mini и Mac Studio, используемые как серверы. Именно на этих машинах Screen Sharing чаще всего включён на постоянной основе, потому что клавиатуры и монитора к ним нередко просто не подключено. Они всегда работают, всегда в сети, и никто не смотрит на их экран. Mac mini в чулане, на котором крутится медиасервер, агент сборки или хаб домашней автоматизации, — ровно этот профиль.

Mac в общих офисах и коворкингах. Сочетание недоверенной сети и машины, на которой Screen Sharing может быть включён для удобства ИТ-службы, — худший вариант здесь.

Парки машин под управлением ИТ-отдела. В организациях, использующих Apple Remote Desktop или MDM с возможностью удалённого наблюдения, инфраструктура Screen Sharing включена политикой сразу на множестве машин. Если вы администрируете такой парк, это обновление — приоритетное к развёртыванию, а шаги аудита ниже применяются в масштабе, а не на каждой машине по отдельности.

Все, кто когда-то включил Screen Sharing и забыл об этом. Это встречается чаще, чем принято признавать. Вы включили его, чтобы помочь родственнику или чтобы достучаться до настольного Mac с ноутбука, и с тех пор он так и работает.

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

Пониженный риск

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

Mac, которые большую часть времени спят или выключены. Служба, которая не запущена, недоступна.

Машины за корректно сегментированной гостевой сетью. Изоляция клиентов в гостевом SSID не даёт устройствам в этой сети обращаться друг к другу, что убирает необходимую атаке смежность.

Причина, по которой всё это идёт с оговоркой, — в следующем разделе.

Чего Apple нам не сказала

Эту часть большинство публикаций пропускает, и именно она должна определять то, как вы думаете об этом обновлении.

Вопрос «включено или выключено» остался без ответа

В бюллетене Apple не сказано, должен ли Screen Sharing быть включён, чтобы CVE-2026-65400 можно было эксплуатировать. heise прямо констатирует этот пробел: на данный момент неясно, должны ли быть активны Screen Sharing или Apple Remote Desktop для доступа, или же атака возможна даже при в целом отключённом доступе к экрану.

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

Есть разумные аргументы в обе стороны. Службы, выключенные в «Системных настройках», действительно не держат открытыми свои слушающие сокеты в macOS, что поддерживает узкое прочтение. С другой стороны, macOS использует активацию через сокет в launchd для нескольких системных служб, поэтому демон запуска может быть неактивен, пока система всё же держит сокет, который запускает его по требованию, — а это поддерживает широкое прочтение. Решение Apple дважды сделать бэкпорт и пропустить раздачу бет по меньшей мере слабо согласуется с широким прочтением, хотя доказательством и не является.

Честный ответ: за пределами Apple этого никто не знает, и я не буду делать вид, что это не так.

Как рассуждать в такой неопределённости: относитесь к неизвестности как к аргументу за обновление, а не как к приглашению вычислять, были ли вы уязвимы. Цена установки 26.6.1 — перезагрузка. Цена ошибки в догадке о том, защищал ли вас выключенный переключатель, — незнакомец на вашем экране. Эта асимметрия закрывает вопрос без всякой недостающей детали.

Механизм не раскрыт, а часть опубликованных подробностей не подтверждена

О этой ошибке ходят и более детальные технические утверждения, включая конкретные описания того, какой именно демон был виноват, что приводило к сбойному состоянию и как быстро атакующий мог получить привилегированную оболочку. Эти утверждения встречаются в небольшом числе изданий второго эшелона, опираются на единственный источник и не подтверждаются ни Apple, ни heise, ни материалом 9to5Mac, где подобных подробностей нет вовсе. Относитесь к ним с осторожностью и не выстраивайте на них свои действия.

Это не гипотетическая проблема. Чрезмерно конкретные разборы уязвимостей влияют на поведение. Если вы прочитаете, что ошибка срабатывает только против машины с определённой настройкой, вы можете пропустить обновление. А если эта деталь окажется выдуманной, вы пропустили обновление совершенно зря.

Что это конкретно значит для вас

• Установите 26.6.1, или 15.7.9, или 14.8.9 — в зависимости от того, какая macOS у вас
• Не полагайтесь на «Screen Sharing был выключен, значит я в порядке» как на повод отложить обновление
• Всё равно проверьте настройки общего доступа, потому что такой аудит полезен сам по себе
• Игнорируйте утверждения о механизме эксплуатации, пока не появится заслуживающий доверия технический разбор

Как проверить поверхность удалённого доступа вашего Mac

Это практическое ядро статьи, и оно полезно независимо от того, угрожала ли вам эта конкретная CVE. Большинство людей никогда по-настоящему не смотрели, что их Mac выставляет в сеть.

Откройте Системные настройки, затем Основные, затем Общий доступ. Вы увидите список служб с отдельными переключателями. Три из них управляют удалённым доступом к вашей машине, и их постоянно путают.

Screen Sharing

Это и есть служба, которую затрагивает CVE-2026-65400. Когда она включена, другие машины могут подключаться и брать под управление ваш графический сеанс по VNC, через TCP-порт 5900.

Как проверить: в панели «Общий доступ» посмотрите на строку Screen Sharing. Если переключатель выключен, служба не включена. Если включён, щёлкните по маленькой кнопке информации рядом, чтобы увидеть список доступа.

Что означает список доступа: по умолчанию варианты — «Все пользователи» или конкретный список. «Все пользователи» здесь означает каждую учётную запись на этом Mac, включая любую созданную и забытую. Ограничение поимённым списком строго лучше. Нажмите кнопку информации, выберите вариант с доступом только для перечисленных пользователей и добавьте конкретные учётные записи, которым он нужен.

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

Выключите службу, если она вам не нужна. Это единственное изменение с наибольшей отдачей, которое большинство людей может сделать в этой панели.

Remote Login (SSH)

Это совершенно отдельная служба на TCP-порту 22. Она даёт доступ к командной строке, а не к графике. CVE-2026-65400 её не затрагивает, и выключение Screen Sharing на неё никак не влияет.

Эти две вещи путают, потому что обе — «удалённый доступ», и потому что выключение одной интуитивно ощущается как закрытая дверь. Это не так.

Проверьте из Терминала:

sudo systemsetup -getremotelogin

Команда сообщит, включён Remote Login или выключен. Чтобы выключить:

sudo systemsetup -setremotelogin off

То же самое можно сделать в панели «Общий доступ», выключив Remote Login. Как и в случае Screen Sharing, кнопка информации позволяет ограничить доступ конкретными пользователями вместо всех — и вам стоит это сделать.

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

Remote Management (Apple Remote Desktop)

Это третий переключатель, и именно он вызывает больше всего путаницы.

Remote Management — это агент Apple Remote Desktop. Он даёт наблюдение за экраном и управление им, а вдобавок распространение ПО, отчётность и удалённое выполнение команд. Именно им ИТ-отделы управляют парками машин. Помимо 5900 он использует порт 3283.

Критически важная деталь: Screen Sharing и Remote Management взаимоисключающи в интерфейсе macOS. Нельзя включить оба сразу. Включение Remote Management автоматически выключает Screen Sharing, и macOS вам об этом сообщит. Следствие — как раз то, что люди упускают: если вы зайдёте в «Общий доступ», увидите, что Screen Sharing выключен, и заключите, что никто не может видеть ваш экран, вы можете ошибаться. Вместо него может быть включён Remote Management, дающий ту же самую возможность через другую службу.

Так что проверяйте обе строки, каждый раз. Выключенный Screen Sharing плюс включённый Remote Management — не защищённая конфигурация. Это та же дверь с другой ручкой.

У Remote Management за кнопкой информации тоже есть детальный список разрешений: может ли удалённый пользователь наблюдать, управлять, копировать файлы, удалять объекты, перезагружать машину и так далее. Если Remote Management включён, потому что вашим Mac управляет работодатель, не выключайте его просто так. Сначала поговорите с теми, кто администрирует парк машин, потому что выключение может сломать управление и нарушить политику вашей организации.

Проверьте, зарегистрирован ли ваш Mac в MDM

Если вы не уверены, управляет ли вашим Mac какая-то организация, вот команда, которая это покажет:

sudo profiles status -type enrollment

Она сообщит, зарегистрирована ли машина через автоматизированную регистрацию устройств Apple и есть ли у неё сейчас активная регистрация в MDM. Личный Mac, купленный в магазине и настроенный вами самостоятельно, сообщит, что не зарегистрирован. Машина, выданная работодателем или учебным заведением, обычно покажет активную регистрацию.

Это важно по двум причинам. Во-первых, если Mac управляется, настройки удалённого доступа могут навязываться профилем и сбрасываться обратно после ваших изменений. Во-вторых, если он управляется, само обновление может контролироваться политикой обновления ПО вашей организации, а не вами, что меняет способ получения 26.6.1.

Можно также вывести список установленных конфигурационных профилей:

sudo profiles list

Команда покажет, что установлено. Если на машине, которую вы считаете личной, обнаружатся незнакомые профили, это стоит расследовать.

Проверьте брандмауэр

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

В интерфейсе: Системные настройки, затем «Сеть», затем «Брандмауэр». Включите его. За кнопкой «Параметры» можно настроить, каким службам и приложениям разрешено принимать входящие подключения, и включить режим невидимости, при котором Mac не отвечает на зондирование вроде пингов и сканирования портов от неавторизованных источников.

Из Терминала:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Команда сообщит, включён ли брандмауэр.

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

Посмотрите, что действительно слушает

Если хотите не доверять переключателям, а убедиться, вот как узнать, какой процесс привязан к порту общего доступа к экрану:

sudo lsof -i :5900

Пустой вывод означает, что на этом порту ничего не слушает. Вместо него можно подставить 22 для SSH и 3283 для порта Apple Remote Desktop.

Такой аудит — хорошая привычка независимо от какой-либо одной CVE. Наше руководство по безопасности и приватности Mac охватывает более широкий набор настроек, которые стоит периодически пересматривать, включая FileVault, Gatekeeper, разрешения приватности и то, что на самом деле выставляют наружу разные службы общего доступа.

Укрепление защиты, если удалённый доступ вам действительно нужен

У многих есть реальная причина обращаться к Mac удалённо. Домашний сервер, машина в офисе, компьютер родственника, которому вы помогаете. Просто выключить функцию для них не вариант. Вот как сохранить её, сократив уязвимость.

Подключайтесь к Mac по приватной сети, а не по публичной

Самое сильное отдельное изменение — перестать выставлять службу в любую сеть, которую вы не контролируете, и вместо этого поместить Mac и ваш клиент в одну приватную оверлейную сеть.

Подойдёт VPN в вашу домашнюю или офисную сеть. Подойдёт и оверлейная сеть вроде Tailscale, WireGuard или ZeroTier, которая создаёт зашифрованную сетку между вашими устройствами и даёт каждому стабильный приватный адрес, недостижимый из обычного интернета. При такой схеме Screen Sharing слушает только на интерфейсе, доступном исключительно вашим собственным устройствам. Атакующий в кафейном Wi-Fi больше не является смежным со службой в сколько-нибудь осмысленном смысле, потому что служба не выставлена на том локальном интерфейсе, который вы с ним делите.

Именно такой подход в основном свёл бы на нет локально-сетевую область действия CVE-2026-65400 для практических целей — и точно так же сработает со следующей уязвимостью. Если при настройке возникнут проблемы с подключением, наше руководство по устранению неполадок VPN в macOS разбирает типичные сбои с конфигурационными профилями, DNS и раздельным туннелированием.

Никогда не пробрасывайте порт 5900

Проброс порта 5900 с маршрутизатора на Mac выставляет службу общего доступа к экрану прямо в публичный интернет, где автоматические сканеры находят её в течение считаных часов. VNC на порту 5900 — один из самых интенсивно сканируемых портов в интернете. Не делайте так. Если уже сделали — отмените прямо сейчас.

То же касается 3283 для Apple Remote Desktop и 22 для SSH. Если SSH выставить наружу необходимо, перенесите его с порта по умолчанию, отключите аутентификацию по паролю и используйте ключи, но лучший ответ всё равно VPN.

Заведите отдельную учётную запись с явным списком разрешённых

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

Задайте ей по-настоящему надёжный пароль. Повторное использование паролей — причина, по которой многие инциденты с удалённым доступом превращаются в серьёзные.

Держите список разрешённых пользователей явным и пересматривайте его

«Все пользователи» — удобно и неправильно. Каждая учётная запись на Mac оказывается неявно авторизованной, включая старые записи, гостевые и служебные аккаунты, созданные для чего-то другого много лет назад. Задайте список явно и возвращайтесь к нему, когда люди уходят или когда вы выводите учётную запись из обращения.

Выключайте службы, когда не пользуетесь ими

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

Как установить macOS Tahoe 26.6.1

Обновление доставляется через «Обновление ПО», как любой другой промежуточный выпуск.

1. Сначала сделайте резервную копию. Time Machine или клон — подойдёт и то, и другое, но что-то должно быть. Обновление маленькое и риск невелик, но правило от этого не меняется.
2. Откройте Системные настройки, затем Основные, затем Обновление ПО.
3. Дождитесь окончания проверки. macOS Tahoe 26.6.1 должна появиться как доступное обновление.
4. Нажмите «Обновить сейчас» и введите пароль.
5. Дайте Mac перезагрузиться. На Apple silicon это обычно занимает от десяти до двадцати минут от начала до конца, в зависимости от машины и диска.
6. Когда система вернётся, подтвердите результат командой sw_vers в Терминале или через «Об этом Mac». Вам нужна версия 26.6.1 и сборка 25G76.

Из Терминала можно посмотреть список и установить обновления без интерфейса:

softwareupdate --list

Команда покажет, что доступно. Чтобы установить всё подходящее:

sudo softwareupdate -i -a

Добавьте --restart, если хотите, чтобы машина автоматически перезагрузилась по завершении.

Если обновление пока не появилось

Apple выкатывает промежуточные выпуски поэтапно. 6 августа пользователи сообщали, что 26.6.1 ещё не появилась на некоторых Mac с M4 и M5, тогда как на других машинах она уже была доступна, и эти случаи разрешились сами собой без вмешательства.

Если «Обновление ПО» ничего не показывает:

• Подождите несколько часов и проверьте снова. Поэтапная выкатка обычно доходит до всех примерно за сутки.
• Полностью закройте «Системные настройки» и откройте заново, затем проверьте ещё раз. Панель «Обновление ПО» кэширует своё состояние, и иногда её нужно подтолкнуть.
• Выполните softwareupdate --list в Терминале — эта команда обращается к серверам Apple напрямую и иногда показывает обновление, которого ещё нет в интерфейсе.
• Если вашим Mac управляет организация, обновление может быть отложено политикой. sudo profiles status -type enrollment подскажет, возможно ли это, и если да, то сроками распоряжается ваша ИТ-служба.
• В крайнем случае Apple публикует автономные установочные пакеты, а Mr. Macintosh регулярно каталогизирует прямые ссылки для каждого выпуска. Загрузка полного установщика обходит поэтапную выкатку ценой гораздо большего объёма скачивания.

Если установка не удаётся

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

Коротко: свободного места должно быть заметно больше объёма загрузки, потому что macOS нужно пространство, чтобы распаковать и подготовить обновление. Для дельты в 2,1 ГБ 20 ГБ свободного места — комфортный, а не избыточный запас.

Если у вас Sonoma или Sequoia

Apple выпустила то же исправление для обеих более старых поддерживаемых версий macOS 6 августа 2026 года:

Версия macOS	Исправленный выпуск	Сборка
macOS Tahoe 26	26.6.1	25G76
macOS Sequoia 15	15.7.9	24G830
macOS Sonoma 14	14.8.9	23J631

Путь тот же самый: Системные настройки, Основные, Обновление ПО, установка, перезагрузка.

О том, чтобы оставаться на более старой macOS, стоит сказать две вещи. Во-первых, конкретно в этом вопросе оставаться на Sequoia или Sonoma нормально, если вы установили соответствующий патч. Вы получаете не урезанное исправление. Apple закрыла одну и ту же CVE во всех трёх версиях.

Во-вторых, это верно лишь до тех пор, пока Apple продолжает выпускать обновления безопасности для вашей версии, а делает она это примерно для текущего выпуска плюс двух предыдущих. Sonoma 14 находится на дальнем краю этого окна. Если вы сидите на Sonoma по какой-то причине, эту причину стоит регулярно пересматривать, потому что в какой-то момент появится CVE, которую исправят только в более новых версиях.

Кроме того, старые версии иногда получают более узкий набор исправлений, чем актуальный выпуск, даже когда заглавная CVE у них общая. Здесь это не так, поскольку 26.6.1 содержит ровно одно исправление, но именно поэтому позиция «я на старой macOS, но ставлю все обновления» в долгосрочной перспективе слабее, чем кажется.

Отдельно про Intel

Intel-маки получают 26.6.1 наравне со всеми, с меньшей дельтой в 898,9 МБ. Отдельного упоминания это заслуживает из-за того, что оно символизирует.

macOS 27 будет только для Apple silicon. Intel-маки её запустить не смогут, а значит macOS Tahoe 26 — последний мажорный выпуск, который эти машины когда-либо получат. Практика Apple — выпускать обновления безопасности для версии примерно три года после того, как она перестала быть актуальной, так что владельцам Intel-маков стоит ожидать обновлений ровно такого вида, как это: рост номера сборки, одна или несколько CVE, никаких функций.

Это делает 26.6.1 полезным превью ближайших нескольких лет для железа на Intel. Обновления станут менее интересными и более важными. Оценивать новые возможности будет нечего, так что каждый раз останется единственный вопрос — ставить или нет, и ответ будет «да». Наш разбор конца эпохи Intel-маков охватывает полный список совместимости и реалистичные сроки поддержки.

Если ваш Intel-мак работает постоянно, раздел про аудит выше заслуживает особого внимания. Старые Mac mini — как раз те машины, которые с наибольшей вероятностью стоят в чулане с включённым и забытым Screen Sharing.

Наблюдение о сторонних VNC-клиентах

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

После выхода macOS Tahoe 26.6 в конце июля некоторые пользователи сообщали, что сторонние VNC-клиенты перестали подключаться к их Mac. В сообщениях фигурировали RealVNC и другие клиенты под Windows, iOS и Linux, причём RealVNC выдавал сообщение вроде ошибки протокола о слишком большой длине ключа. В тех же сообщениях указано, что Screen Sharing между Mac продолжал работать нормально, — и именно эта деталь делает картину интересной, а не просто очередной поломкой.

Прочитать первоисточник на форуме напрямую нам не удалось, так что всё это изложено по вторичным пересказам и должно восприниматься соответственно. О каком-либо заявлении Apple, признающем такое поведение, нам не известно.

Гипотеза, заявленная именно как гипотеза: 26.6 могла что-то изменить в пути аутентификации общего доступа к экрану так, что это сломало совместимость со сторонними VNC-клиентами, и CVE-2026-65400 может жить в том же коде. Изменение, ужесточившее обработку аутентификации, а спустя десять дней исправление ошибки состояния аутентификации в том же компоненте — наводящая на размышления последовательность. Apple не публиковала ничего, что связывало бы их, heise говорит, что механизм остаётся неясным, а наводящая на размышления последовательность доказательством не является.

Что это значит практически:

• Если ваш сторонний VNC-клиент сломался после 26.6, это известная картина, о которой сообщали и другие. Вы не одиноки и, скорее всего, ничего не настроили неправильно.
• Если он сломался, не рассчитывайте, что 26.6.1 это починит. Обновление закрывает проблему безопасности. Ничто не указывает на то, что оно восстанавливает совместимость со сторонними клиентами, и вполне возможно, что не восстанавливает.
• Если вы зависите от стороннего VNC-клиента для доступа к Mac, уточните у вендора вашего клиента совместимость с macOS 26.6 и 26.6.1, прежде чем обновлять машину, до которой вам физически трудно добраться.
• Ничто из этого не повод пропускать обновление. Если выбор стоит между работающим сторонним VNC-клиентом и закрытым обходом аутентификации, ставьте патч и ищите другой способ подключаться.

Устранение типичных проблем

macOS Tahoe 26.6.1 не появляется в «Обновлении ПО»

Проблема: «Обновление ПО» сообщает, что ваш Mac обновлён до последней версии на 26.6, а 26.6.1 нигде нет, хотя она вышла 6 августа. Несколько пользователей сообщали об этом на Mac с M4 и M5 в день выхода.

Решение: почти всегда это поэтапная выкатка, а не сбой. Apple выпускает промежуточные обновления для подмножеств машин на протяжении от часов до нескольких дней. Полностью закройте «Системные настройки» и откройте заново, поскольку панель «Обновление ПО» кэширует результаты. Затем выполните softwareupdate --list в Терминале — эта команда обращается к серверам Apple напрямую и иногда возвращает обновление, которого нет в интерфейсе. Если вашим Mac управляют, выполните sudo profiles status -type enrollment, чтобы понять, не откладывает ли обновления MDM по политике; в этом случае расписанием распоряжается ваша ИТ-служба. Описанные случаи от 6 августа разрешились сами в течение суток. Если обновление нужно немедленно и ждать нельзя, полный автономный установщик обходит выкатку ценой гораздо большего объёма загрузки.

Обновление скачивается, но так и не устанавливается

Проблема: загрузка завершается или выглядит завершённой, а затем Mac надолго застывает на «Подготовке» или на замершем индикаторе прогресса без видимого движения.

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

После обновления перестал работать Screen Sharing

Проблема: вы установили 26.6.1 и больше не можете подключиться к Mac или с него через общий доступ к экрану.

Решение: начните с проверки того, что действительно включено. Откройте Системные настройки, Основные, Общий доступ и посмотрите и на строку Screen Sharing, и на строку Remote Management, потому что они взаимоисключающи, а обновление или изменение политики могло оставить состояние не таким, каким вы его помните. Убедитесь, что подключающаяся учётная запись есть в списке разрешённых пользователей, а не полагайтесь на «Все пользователи», значение которого могли изменить. Если вы подключаетесь с другого Mac через Screen Sharing или Finder, сначала проверьте связь в локальной сети, чтобы понять, дело в службе или в маршруте до неё. Если вы подключаетесь из стороннего VNC-клиента, см. раздел выше: некоторые пользователи сообщали о сбоях сторонних клиентов начиная с 26.6, и это поведение не подтверждено, но о нём сообщают. Наконец, выполните sudo lsof -i :5900 на целевом Mac, чтобы убедиться, что там что-то действительно слушает.

Remote Management не выключается

Проблема: вы выключаете Remote Management в панели «Общий доступ», а он включается обратно, либо переключатель неактивен и его нельзя изменить.

Решение: это характерный признак управляемого Mac. Конфигурационный профиль, отправленный через MDM, может навязывать Remote Management и снова применит его после ваших изменений. Выполните sudo profiles status -type enrollment, чтобы подтвердить наличие активной регистрации в MDM, и sudo profiles list, чтобы увидеть установленные профили. Если Mac принадлежит работодателю или учебному заведению, не пытайтесь это обойти. Свяжитесь с теми, кто администрирует парк машин, поскольку снятие управления может нарушить политику и всё равно, скорее всего, откатится в течение нескольких минут. Если Mac действительно личный, а вы обнаружили регистрацию, которую не разрешали, это серьёзная находка, о которой стоит сообщить куда следует, и самое безопасное решение на личной машине — чистая установка после резервного копирования данных.

Вы не уверены, был ли ваш Mac скомпрометирован

Проблема: у вас постоянно работал Mac с включённым Screen Sharing в общей сети, и вы хотите знать, воспользовался ли кто-нибудь этой ошибкой против вас.

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

Что всё же можно проверить, понимая ограничения: откройте Консоль и просмотрите системные журналы за интересующий период, отфильтровав активность общего доступа к экрану, — но учтите, что срок хранения журналов в macOS ограничен и старых записей может уже просто не быть. Просмотрите Системные настройки, «Пользователи и группы», на предмет незнакомых учётных записей. Проверьте списки разрешённых пользователей в панели «Общий доступ» на записи, которых вы не добавляли. Загляните в объекты входа и фоновые объекты в поисках незнакомого. Выполните sudo profiles list, чтобы проверить конфигурационные профили, которых вы не устанавливали. Просмотрите список подключённых устройств на маршрутизаторе и, если он их хранит, его журналы.

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

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

Нужно ли ставить macOS Tahoe 26.6.1, если Screen Sharing был выключен?

Да. Apple ни разу не заявила, должен ли Screen Sharing быть включён, чтобы CVE-2026-65400 можно было эксплуатировать, а heise сообщает, что это остаётся неясным. Раз требование неизвестно, а обновление стоит вам одной перезагрузки, ставьте его. Не воспринимайте выключенный переключатель как подтверждение того, что вы были в безопасности.

Что такое CVE-2026-65400 простыми словами?

Это обход аутентификации в службе Screen Sharing в macOS. Формулировка Apple — что атакующий в сети может пройти аутентификацию в Screen Sharing без действительных учётных данных. На практике это означает, что кто-то в той же сети потенциально мог получить сеанс общего доступа к экрану, не зная пароля. Apple исправила это за счёт улучшенного управления состоянием.

Эту уязвимость действительно эксплуатировали?

Apple сообщает, что об известных случаях активной эксплуатации ей не известно. Это стандартная формулировка Apple, когда у неё нет данных об атаках в реальном мире, а об активно эксплуатируемых проблемах Apple сообщает явно, если знает о них. Отсутствие такой пометки здесь значимо, хотя и не гарантирует, что уязвимостью никто никогда не пользовался.

Могут ли атаковать мой Mac через интернет с помощью этого?

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

Добавляет ли 26.6.1 новые функции или меняет Safari?

Нет. Новых функций нет. Safari остаётся на версии 26.6 и этим обновлением не поднимается. Системная прошивка тоже остаётся неизменной, 18000.161.9. macOS Tahoe 26.6.1 — это сборка 25G76 с единственным исправлением безопасности, поэтому она и вышла без раздачи бет и с примечанием к выпуску в одну строку.

А что, если у меня macOS Sonoma или Sequoia?

Apple перенесла то же исправление. Ставьте macOS Sequoia 15.7.9, сборка 24G830, или macOS Sonoma 14.8.9, сборка 23J631. Вы получаете ту же защиту, а не её урезанную версию. Оставаться на более старой macOS в этом конкретном вопросе нормально, если вы вовремя установите соответствующий патч.

Заключение

macOS Tahoe 26.6.1 — маленькое обновление с одним исправлением, и то, как Apple его выпустила, говорит больше, чем примечания к выпуску. Отсутствие раздачи бет, отсутствие функций и бэкпорт в тот же день в Sequoia 15.7.9 и Sonoma 14.8.9 — всё это указывает на вендора, который хотел закрыть проблему везде и быстро. CVE-2026-65400 позволяла атакующему в локальной сети пройти аутентификацию в Screen Sharing без действительных учётных данных, и Apple исправила это улучшенным управлением состоянием. Это и есть подтверждённые границы публичных сведений.

Пробел в этих сведениях — вопрос «включено или выключено», и с ним стоит побыть, а не закрывать его допущением. Apple не сказала, должна ли служба была быть запущена. heise говорит, что это неясно. Screen Sharing выключен по умолчанию, из-за чего соблазнительно заключить, что вас это никогда не касалось, — и такой вывод ничем опубликованным не подкреплён. Более подробные утверждения о механизме циркулируют без подтверждения, и на их основе не стоит решать, обновляться ли.

Установите 26.6.1 на этой неделе — или 15.7.9, или 14.8.9. Затем потратьте десять минут в Системных настройках, Основные, Общий доступ, и посмотрите на все три переключателя удалённого доступа, а не на один. Убедитесь, что Screen Sharing и Remote Management оба выключены, если они вам не нужны, отдельно проверьте Remote Login, замените любую настройку «Все пользователи» явным списком и включите брандмауэр. Если удалённый доступ к Mac вам действительно нужен, ходите к нему через VPN или оверлейную сеть вместо того, чтобы выставлять его в ту сеть, где машина случайно оказалась, и никогда не пробрасывайте порт 5900. Такая конфигурация сделала бы эту CVE во многом умозрительной лично для вас — и то же самое она сделает со следующей.

Читайте также: Вышла macOS Tahoe 26.6: что нового, исправления безопасности, руководство по обновлению