macOS Tahoe 26.6.1: Screen Sharing 취약점과 대응 방법

macOSTahoe ·
macOS Tahoe 26.6.1: Screen Sharing 취약점과 대응 방법

Apple이 Screen Sharing 인증 우회를 막기 위해 macOS Tahoe 26.6.1을 배포했습니다. CVE-2026-65400이 실제로 무엇을 허용했는지, 그리고 내 Mac을 어떻게 점검할지 정리했습니다.

Apple은 2026년 8월 6일 목요일, 26.6 출시 열흘 만에 macOS Tahoe 26.6.1을 공개했습니다. 개발자 베타는 없었습니다. 퍼블릭 베타도 없었습니다. 새 기능도, Safari 버전 상승도, 펌웨어 변경도 없습니다. 릴리스 노트에는 보안 수정 하나만 적혀 있고, 보안 문서에도 CVE가 정확히 하나만 나열되어 있습니다.

바로 그 조합이 이번 이야기의 핵심입니다. Apple은 보통 포인트 릴리스를 최소 며칠은 개발자에게 시드한 뒤 배포하고, x.x.1 릴리스에는 보안 작업과 함께 몇 가지 버그 수정이 같이 들어가기 마련입니다. 그런데 이번에는 시드 과정을 통째로 건너뛰었고, 담긴 것은 단 하나, Screen Sharing 구성 요소의 CVE-2026-65400뿐입니다. Apple은 같은 날 macOS Sequoia 15.7.9와 macOS Sonoma 14.8.9에도 동일한 수정을 백포트했습니다. 이는 현재 릴리스에만 국한하지 않고 모든 곳에 한꺼번에 수정을 적용하고 싶을 때 제조사가 취하는 방식입니다.

macOS Tahoe 26.6.1의 Screen Sharing 취약점은 제대로 이해해 둘 가치가 있습니다. 이 이야기를 정직하게 서술하면, 정작 흥미로운 세부 정보가 있어야 할 자리에 커다란 공백이 남기 때문입니다. Apple의 영향(impact) 문구는 한 문장뿐입니다. 해당 서비스가 켜져 있어야 했는지에 대해서는 말하지 않습니다. 동작 원리도 설명하지 않습니다. 여러 매체가 그 공백을 아무도 교차 확인하지 않은 구체적인 내용으로 채워 넣었습니다. 이 가이드에서는 실제로 확인된 사실, 정말로 알려지지 않은 부분, 현실적으로 누가 위험했는지, 그리고 버그의 작동 방식과 무관하게 중요한 실무적인 부분, 즉 내 Mac의 원격 접근 표면을 점검하는 방법을 다룹니다.

핵심 요약

  • macOS Tahoe 26.6.1은 빌드 25G76이며, 2026년 8월 6일에 배포되었고, 보안 수정 하나 외에는 아무것도 담고 있지 않습니다. Safari는 26.6에 그대로 머물고, 시스템 펌웨어도 18000.161.9로 변함이 없으며, 새 기능은 없습니다. Mr. Macintosh가 업데이트 패키지를 뜯어본 바에 따르면 델타 업데이트는 Apple Silicon에서 약 2.1GB, Intel에서 약 898.9MB입니다.
  • CVE-2026-65400은 Screen Sharing의 인증 우회입니다. Apple의 영향 문구는 다음과 같습니다. 「네트워크상의 공격자가 유효한 자격 증명 없이 Screen Sharing에 인증할 수 있습니다.」 그리고 수정 내용은 Apple의 표현으로 「인증 문제를 개선된 상태 관리로 해결했습니다」입니다. Apple은 Bynario Atlas와 협력한 Alfredo Pesoli(@__rev)를 크레딧에 올렸으며, 독일 매체 heise는 Bynario Atlas를 AI 기반 취약점 탐지 시스템으로 소개합니다.
  • 공격 범위는 로컬 네트워크이며, 열린 인터넷이 아닙니다. 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은 2026년 7월 27일에 빌드 25G72로 출시되었고, Tahoe 사이클 전체를 통틀어 가장 큰 보안 묶음으로 140개를 훌쩍 넘는 이슈를 해결했습니다. macOS Tahoe 26.6 전체 정리에서는 Apple이 macOS 27을 위한 준비 작업이라고 설명한 Spotlight 재색인 작업을 포함해 그 안에 무엇이 담겼는지 다룹니다.

macOS Tahoe 26.6.1은 정반대 성격의 릴리스입니다. 빌드는 25G76, 날짜는 2026년 8월 6일이며, 구멍 하나를 막기 위해 존재합니다.

패키지 자체에 대해 확인된 사실은 다음과 같습니다.

  • 빌드: 25G76
  • 출시일: 2026년 8월 6일, 26.6 이후 약 열흘 뒤
  • 베타 시딩: 없음. 개발자 베타도, 퍼블릭 베타도 없음
  • 새 기능: 없음
  • Safari: 버전 26.6 그대로, 상승 없음
  • 시스템 펌웨어: 18000.161.9로 변경 없음
  • 보안 내용: CVE 하나, Screen Sharing의 CVE-2026-65400
  • Apple 보안 문서: support.apple.com/en-us/148170

다운로드 용량은 Apple 릴리스의 패키지 정보를 꾸준히 공개하는 Mr. Macintosh에서 나온 수치입니다. 델타 업데이트는 Apple Silicon에서 약 2.1GB, Intel에서 약 898.9MB입니다. 델타가 아니라 전체 설치 프로그램을 받는다면 훨씬 더 큽니다. Intel 델타가 1GB 미만인데 Apple Silicon 델타는 2GB를 넘는 것은 Tahoe에서 정상적인 현상입니다. Apple Silicon 경로에는 서명된 시스템 볼륨 페이로드가 포함되어 있고, 이것이 다른 방식으로 재구성되기 때문입니다.

베타가 없었다는 점이 중요한 이유

Apple의 일반적인 포인트 릴리스 주기에는 최소한 한 번의 개발자 시드, 대개 릴리스 후보, 그리고 하루 이틀 뒤의 퍼블릭 베타가 포함됩니다. 이 과정은 수백만 대의 기기가 업데이트를 받기 전에 회귀 버그를 잡아내기 위해 존재합니다.

이를 건너뛰는 일이 전례 없는 것은 아니지만, 무언가를 시사할 만큼은 이례적입니다. Apple이 시딩도 없고 기능 추가도 없이 곧바로 정식 배포로 갈 때, 합리적인 해석은 수정이 작고 잘 이해된 것이었으며 Apple이 시딩 일정보다 빠르게 내보내고 싶어 했다는 것입니다. 이는 버그가 악용되고 있었다는 뜻과는 다릅니다. Apple은 알려진 활발한 악용 사례가 없다고 명시적으로 밝혔습니다. 다만 Apple이 일주일을 기다리고 싶지 않았다는 뜻은 맞습니다.

두 번째 신호는 백포트입니다. Apple은 현재 버전 바로 아래 두 개의 macOS 버전에 대해 보안 업데이트를 유지하지만, 항상 같은 날 세 버전 모두에 동일한 수정을 내보내지는 않습니다. 이번에 Sequoia 15.7.9와 Sonoma 14.8.9에 그렇게 했다는 것은, 지원되는 어떤 기기에서도 이 문제가 패치되지 않은 채 남아 있어서는 안 된다고 Apple이 판단했음을 시사합니다.

현재 시점의 버전 타임라인

내 위치를 확인하고 싶다면, 최근 중요한 Tahoe 릴리스는 다음과 같습니다.

  • 26.5 2026년 5월 11일, macOS Tahoe 26.5 업데이트 가이드에서 다룸
  • 26.5.1 2026년 6월 1일
  • 26.5.2 2026년 6월 29일
  • 26.6 2026년 7월 27일, 빌드 25G72
  • 26.6.1 2026년 8월 6일, 빌드 25G76

내 Mac이 무엇을 실행 중인지 확인하려면 터미널을 열고 다음을 실행하세요.

sw_vers

제품 이름, 버전 번호, 빌드가 출력됩니다. 버전이 26.6.1이고 빌드가 25G76이면 패치가 적용된 것입니다. Apple 메뉴에서 이 Mac에 관하여를 연 다음 버전 번호를 클릭해 빌드를 확인할 수도 있습니다.

CVE-2026-65400이 허용한 것, 쉬운 말로

Apple의 보안 문서는 간결하기로 유명합니다. 이번 건은 설명 전체가 두 문장에 불과합니다.

영향:

네트워크상의 공격자가 유효한 자격 증명 없이 Screen Sharing에 인증할 수 있습니다.

수정:

인증 문제를 개선된 상태 관리로 해결했습니다.

두 문장 모두 꼼꼼히 읽어 볼 가치가 있습니다.

「Screen Sharing에 인증한다」는 것

Mac의 Screen Sharing은 그래픽 세션의 실시간 제어권을 넘겨주는 서비스입니다. 여기에 연결한 사람은 디스플레이에 표시된 내용을 그대로 보고, 포인터를 움직이고, 타이핑하고, 앱을 열고, 로그인한 사용자가 읽을 수 있는 모든 것을 읽을 수 있습니다. 파일 전송 채널도 아니고 읽기 전용 뷰도 아닙니다. 그 사람의 책상 그 자체입니다.

정상적으로는 이 서비스에 접근하려면 자격 증명이 필요합니다. 구성 방식에 따라 접속이 허용된 사용자 계정의 암호이거나, 레거시 VNC 옵션이 켜져 있다면 별도의 VNC 암호입니다. 서비스는 세션을 허용하기 전에 이 자격 증명을 검사합니다.

「유효한 자격 증명 없이 인증한다」는 것은, 올바른 비밀 정보 없이도 이 검사를 통과시킬 수 있었다는 뜻입니다. 공격자는 여러분의 암호를 알아내지 않습니다. 알아낼 필요도 없습니다. 서비스가 인증이 성공했다고 믿는 상태에 도달할 뿐입니다.

그 결과 공격자가 얻는 것은 해당 연결이 인가받은 권한 수준입니다. 연결된 계정이 관리자인 Mac이라면 관리자 권한을 가진 세션이 되고, 실질적으로는 기기 전체를 장악하는 것에 가깝습니다. 공유 계정이 일반 사용자인 Mac이라면 그 사용자의 접근 권한이지만, 그것만으로도 문서를 읽고, 메일을 둘러보고, 화면에 있는 모든 것을 보기에 충분합니다.

「개선된 상태 관리」

Apple은 수정 설명에 제한된 어휘를 사용하며, 각 표현은 대략 특정한 버그 유형에 대응합니다. 「개선된 상태 관리」는 일반적으로 여러 단계로 이루어진 절차에서 자신의 진행 상태를 잘못 추적한 서비스를 가리킵니다. 코드 어딘가에 이 연결이 인증되었는지에 대한 판단이 저장되어 있었고, 그 판단이 잘못된 값이 될 수 있었다는 것입니다.

공개된 기록은 여기까지입니다. Apple은 동작 원리를 공개하지 않았고, Apple 자체 외에 이를 설명한 벤더 권고문도 없습니다.

연구자 크레딧에 대해

Apple은 Bynario Atlas(bynar.io)와 협력한 **Alfredo Pesoli(@__rev)**를 크레딧에 올렸습니다. heise는 Bynario Atlas를 AI 기반 취약점 탐지 시스템으로 소개하는데, 이는 자동화된 발견 파이프라인이 크레딧을 받은 Apple CVE를 만들어 낸 비교적 눈에 띄는 사례입니다. 연구자 이름의 표기는 매체마다 조금씩 다르지만, 크레딧 자체에는 이견이 없습니다.

현실적인 위협 모델: 로컬 네트워크에 한정

Apple의 영향 문구에서 「네트워크상의 공격자」라는 표현은 아주 큰 역할을 하고 있으며, 얼마나 걱정해야 할지를 판단하는 데 가장 유용한 맥락입니다.

heise의 보도는 그 경계를 명확히 합니다. Mac이 로컬 네트워크에 있고 라우터에서 해당 포트가 포워딩되어 있지 않다면, 인터넷을 통한 원격 화면 공유는 불가능하다는 것입니다. Screen Sharing은 TCP 5900 포트에서 대기하고, Apple Remote Desktop은 그와 함께 3283을 사용합니다. 일반 가정용 라우터는 누군가 직접 설정하지 않는 한 이 포트를 포워딩하지 않으며, 네트워크 주소 변환(NAT) 때문에 공용 인터넷상의 공격자가 여러분 Mac의 사설 주소로 곧바로 접속할 수도 없습니다.

따라서 공격자는 이미 여러분 Mac과 같은 네트워크 세그먼트에 있어야 합니다.

「같은 네트워크에 있다」는 것의 실제 의미

들리는 것만큼 특수한 상황은 아닙니다. 여러분이 통제할 수 없는 사람들과 브로드캐스트 도메인을 공유하게 되는 네트워크에는 다음이 포함됩니다.

  • 사무실 Wi-Fi, 메인 네트워크와 제대로 분리되지 않은 게스트 네트워크 포함
  • 코워킹 스페이스, 낯선 사람들이 인프라를 공유하는 것이 존재 이유인 곳
  • 대학교 기숙사와 캠퍼스 네트워크, 흔히 평면 구조이고 규모가 매우 큼
  • 호텔 Wi-Fi, 모든 객실이 단일 서브넷인 경우가 많음
  • 카페와 공항 Wi-Fi
  • 콘퍼런스와 행사 네트워크
  • 인터넷을 공유하는 아파트 건물

위험이 훨씬 낮은 네트워크는 다음과 같습니다.

  • 알고 있는 소수의 기기만 있는 가정 네트워크, 단 Wi-Fi 암호가 널리 공유되지 않았고 신뢰할 수 없는 기기가 접속해 있지 않다는 전제하에
  • 본인이 소유한 휴대폰의 셀룰러 테더링으로만 연결된 기기

한 가지 짚어 둘 점이 있습니다. 「네트워크상의 공격자」란 노트북을 들고 건물 안에 앉아 있는 사람만을 의미하지 않습니다. 이미 그 네트워크에 있는 감염된 기기도 똑같이 역할을 합니다. 감염된 Windows 기기, 관리가 부실한 IoT 기기, 알려진 결함이 있는 라우터 등이 여기에 해당합니다. 로컬 네트워크로 범위가 좁혀지면 위험은 상당히 줄지만, 0이 되지는 않습니다.

심각한 버그이되 공황에 빠질 일은 아닌 이유

세 가지 사실이 함께 이 사안의 온도를 정합니다. 첫째, Apple은 알려진 활발한 악용 사례가 없다고 밝혔습니다. 둘째, 공격에는 네트워크 인접성이 필요하므로 인터넷 전역 스캐닝 같은 대량 공격 시나리오는 없습니다. 셋째, Apple이 동작 원리를 공개하지 않았기 때문에, 공격을 시도하려는 사람은 글을 읽고 따라 하는 대신 스스로 찾아내야 합니다.

반대편에는, 베타 시딩을 건너뛸 만큼 수정이 급했고 두 번이나 백포트할 만큼 중요했다는 사실이 있습니다. 올바른 대응은 이번 주 안에 업데이트를 설치하고, 그 김에 공유 설정을 점검하는 것입니다. Mac을 인터넷에서 분리하는 것이 아니고요.

실제로 의미 있는 위험에 놓였던 사람은 누구인가

모든 Mac이 동일한 노출 수준이었던 것은 아니며, 뭉뚱그린 경고보다는 구체적으로 짚는 편이 낫습니다.

위험이 높은 경우

서버로 쓰는 상시 가동 Mac mini와 Mac Studio. 키보드와 모니터가 연결되어 있지 않은 경우가 많아 Screen Sharing이 상시 켜져 있을 가능성이 가장 높은 기기들입니다. 전원이 계속 들어와 있고, 네트워크에 계속 붙어 있으며, 아무도 화면을 보지 않습니다. 벽장 안에서 미디어 서버, 빌드 에이전트, 홈 오토메이션 허브를 돌리는 Mac mini가 정확히 이 유형입니다.

공유 사무실과 코워킹 스페이스의 Mac. 신뢰할 수 없는 네트워크와, IT 편의를 위해 Screen Sharing이 켜져 있을 수 있는 기기의 조합이 여기서 최악의 경우입니다.

IT가 관리하는 기기 집단. Apple Remote Desktop이나 원격 관찰을 활성화하는 MDM을 운영하는 조직은 정책에 따라 다수의 기기에서 Screen Sharing 인프라를 한꺼번에 켜 둡니다. 다수의 기기를 관리한다면 이번 업데이트는 우선순위가 높은 배포 대상이며, 아래 점검 단계는 기기 하나가 아니라 전체 규모에 적용됩니다.

한때 Screen Sharing을 켜 놓고 잊어버린 모든 사람. 사람들이 인정하는 것보다 훨씬 흔한 일입니다. 가족을 도와주려고, 혹은 노트북에서 데스크톱에 접속하려고 켰다가 그 뒤로 계속 켜져 있는 경우죠.

라우터에서 5900 포트를 포워딩한 Mac. 누군가 의도적으로 Screen Sharing을 인터넷에 노출했다면 로컬 네트워크 한정이라는 제약은 그를 보호해 주지 못합니다. 이 구성은 이번 CVE가 존재하기 전에도 나쁜 생각이었고, 이제는 더 나쁜 생각입니다.

위험이 낮은 경우

기본 설정 상태로 가정 네트워크에서만 쓰는 노트북. 새 Mac에서 Screen Sharing은 기본적으로 꺼져 있습니다. 한 번도 켠 적이 없고 가정 네트워크가 작고 알려진 기기들로만 구성되어 있다면 노출 수준은 낮았습니다.

대부분의 시간을 잠자기 상태나 전원 꺼짐 상태로 보내는 Mac. 실행되지 않는 서비스에는 접근할 수 없습니다.

제대로 분리된 게스트 네트워크 뒤에 있는 기기. 게스트 SSID의 클라이언트 격리 기능은 해당 네트워크의 기기들이 서로에게 접근하지 못하게 막으며, 이는 공격에 필요한 인접성을 제거합니다.

이 모든 내용에 단서가 붙는 이유는 다음 섹션에 있습니다.

Mac의 공유 설정 패널

Apple이 말하지 않은 것

대부분의 보도가 건너뛰는 부분이자, 이번 업데이트를 어떻게 바라볼지를 결정해야 할 부분입니다.

켜져 있어야 하는지 아닌지는 답이 없다

Apple의 권고문은 CVE-2026-65400을 악용하려면 Screen Sharing이 켜져 있어야 하는지에 대해 말하지 않습니다. heise는 이 공백을 직접 언급합니다. 접근을 위해 Screen Sharing이나 Apple Remote Desktop이 활성화되어 있어야 하는지, 아니면 화면 공유가 전반적으로 비활성화되어 있어도 공격이 가능한지 현재로서는 불분명하다는 것입니다.

Screen Sharing이 기본적으로 꺼져 있기 때문에, 이 점은 개인의 위험 평가에 엄청나게 큰 차이를 만듭니다. 서비스가 실행 중이어야 한다면 영향을 받는 대상은 적고 스스로 선택한 사람들에 한정됩니다. 반면 공유 스택의 어떤 구성 요소가 토글이 꺼진 상태에서도 대기하거나 응답한다면, 영향을 받는 대상은 지원 버전에서 실행 중인 모든 Mac입니다.

양쪽 모두 나름의 근거가 있습니다. macOS에서 시스템 설정상 꺼져 있는 서비스는 실제로 수신 소켓을 열어 두지 않으며, 이는 좁은 해석을 뒷받침합니다. 반면 macOS는 여러 시스템 서비스에 launchd 소켓 활성화를 사용하므로, 런치 데몬이 잠들어 있는 동안에도 시스템이 필요할 때 그것을 기동시킬 소켓을 유지할 수 있고, 이는 넓은 해석을 뒷받침합니다. Apple이 두 번 백포트하고 베타 시딩을 건너뛰기로 한 결정은 넓은 해석과 최소한 약하게나마 부합하지만, 증거는 아닙니다.

정직한 답은 Apple 바깥의 누구도 모른다는 것이며, 저는 아는 척하지 않겠습니다.

그 불확실성 아래에서 판단하는 법: 알 수 없다는 사실을 업데이트해야 할 근거로 받아들이십시오. 내가 노출되었는지 따져 볼 기회로 삼지 마시고요. 26.6.1을 설치하는 비용은 재시동 한 번입니다. 토글이 꺼져 있었으니 안전했다는 추측이 틀렸을 때의 비용은 낯선 사람이 내 화면을 보는 것입니다. 이 비대칭성만으로도, 빠진 세부 정보 없이 결론이 납니다.

동작 원리는 비공개이며, 공개된 일부 세부 내용은 교차 확인되지 않았다

어떤 데몬이 문제였는지, 무엇이 결함 있는 상태를 유발했는지, 공격자가 얼마나 빨리 권한 있는 셸에 도달할 수 있는지 등 이 버그에 대한 더 구체적인 기술적 주장들이 돌아다니고 있습니다. 그런 주장들은 소수의 하위권 매체에만 등장하고, 단일 출처이며, Apple에서도 heise에서도, 그런 세부 내용이 전혀 없는 9to5Mac 보도에서도 확인되지 않았습니다. 신중하게 받아들이고, 그 위에 대응 방침을 세우지 마십시오.

이는 가상의 우려가 아닙니다. 지나치게 구체적인 취약점 해설은 사람의 행동을 바꿉니다. 특정 설정이 켜진 기기에만 버그가 통한다는 글을 읽으면 업데이트를 건너뛸 수도 있습니다. 그런데 그 세부 내용이 지어낸 것이라면, 아무 이유 없이 업데이트를 건너뛴 셈이 됩니다.

이것이 구체적으로 의미하는 바

  • 사용 중인 macOS에 따라 26.6.1, 15.7.9, 또는 14.8.9를 설치하십시오
  • 「Screen Sharing이 꺼져 있었으니 괜찮았다」를 미루는 이유로 삼지 마십시오
  • 그래도 공유 설정을 점검하십시오. 점검 자체로도 충분히 할 가치가 있습니다
  • 신뢰할 만한 기술 해설이 나오기 전까지 익스플로잇 동작 원리에 대한 주장은 무시하십시오

내 Mac의 원격 접근 표면을 점검하는 방법

이 글의 실질적인 핵심이며, 이번 CVE로 위험에 처했든 아니든 유용한 내용입니다. 대부분의 사람은 자기 Mac이 네트워크에 무엇을 노출하고 있는지 실제로 들여다본 적이 없습니다.

시스템 설정을 열고 일반, 공유로 이동하세요. 개별 토글이 달린 서비스 목록이 보입니다. 그중 세 가지가 기기에 대한 원격 접근을 관장하는데, 사람들이 늘 이 셋을 혼동합니다.

Screen Sharing(화면 공유)

CVE-2026-65400이 영향을 미치는 서비스입니다. 켜져 있으면 다른 기기가 TCP 5900 포트를 통해 VNC로 접속해 여러분의 그래픽 세션을 제어할 수 있습니다.

확인 방법: 공유 패널에서 화면 공유 행을 보십시오. 토글이 꺼져 있으면 서비스가 비활성 상태입니다. 켜져 있다면 옆의 작은 정보 버튼을 클릭해 접근 목록을 확인하세요.

접근 목록의 의미: 기본적으로 선택지는 「모든 사용자」 또는 특정 목록입니다. 여기서 「모든 사용자」란 Mac에 있는 모든 사용자 계정을 뜻하며, 여러분이 만들어 두고 잊어버린 계정까지 포함됩니다. 지정된 목록으로 제한하는 편이 무조건 낫습니다. 정보 버튼을 클릭해 지정한 사용자에게만 접근을 허용하는 옵션을 선택하고, 필요한 계정만 추가하십시오.

해당 패널 안의 컴퓨터 설정에는 두 가지 옵션이 더 있습니다. 하나는 누구나 화면 제어 권한을 요청할 수 있게 해서 로그인한 사용자에게 확인을 띄우는 옵션입니다. 다른 하나는 VNC 암호를 활성화해, Apple 외 클라이언트가 계정 자격 증명 대신 공유 암호로 접속할 수 있게 합니다. VNC 암호 옵션은 두 인증 경로 중 더 취약한 쪽이며, 프로토콜 특성상 8자로 제한됩니다. 서드파티 클라이언트 때문에 특별히 필요한 경우가 아니라면 꺼 두십시오.

필요 없다면 꺼 두십시오. 이 패널에서 대부분의 사람이 할 수 있는 가장 가치 있는 변경 한 가지입니다.

Remote Login(원격 로그인, SSH)

TCP 22 포트를 쓰는 완전히 별개의 서비스입니다. 그래픽 접근이 아니라 명령줄 접근을 제공합니다. CVE-2026-65400의 영향을 받지 않으며, Screen Sharing을 꺼도 여기에는 아무 영향이 없습니다.

둘 다 「원격 접근」이고, 하나를 끄면 문이 닫힐 것 같은 느낌이 들기 때문에 사람들이 혼동합니다. 그렇지 않습니다.

터미널에서 확인하기:

sudo systemsetup -getremotelogin

원격 로그인이 켜져 있는지 꺼져 있는지 알려 줍니다. 끄려면 다음을 실행합니다.

sudo systemsetup -setremotelogin off

공유 패널에서 원격 로그인 토글을 꺼도 동일합니다. Screen Sharing과 마찬가지로 정보 버튼에서 모든 사용자 대신 특정 사용자로 접근을 제한할 수 있으며, 그렇게 하는 편이 좋습니다.

SSH를 자주 사용한다면 의미 있는 강화 조치는 암호 인증을 완전히 비활성화하고 키를 사용하는 것입니다. 그러면 SSH를 겨냥한 추측 공격 유형 전체가 사라집니다.

Remote Management(원격 관리, Apple Remote Desktop)

세 번째 스위치이며, 가장 많은 혼란을 낳는 항목입니다.

Remote Management는 Apple Remote Desktop 에이전트입니다. 화면 관찰과 제어에 더해 소프트웨어 배포, 리포팅, 원격 명령 실행을 제공합니다. IT 부서가 다수의 기기를 관리할 때 쓰는 기능입니다. 5900 외에 3283 포트도 사용합니다.

결정적인 세부 사항은 이것입니다. macOS 인터페이스에서 Screen Sharing과 Remote Management는 상호 배타적입니다. 둘을 동시에 켤 수 없습니다. Remote Management를 켜면 Screen Sharing이 자동으로 꺼지고, macOS가 그 사실을 알려 줍니다. 사람들이 놓치는 결과는 이것입니다. 공유 설정에 들어가 Screen Sharing이 꺼진 것을 보고 아무도 내 화면을 볼 수 없다고 결론 내렸다면, 그 판단은 틀렸을 수 있습니다. 대신 Remote Management가 켜져 있어, 다른 서비스를 통해 동일한 기능을 제공하고 있을 수 있습니다.

그러니 매번 두 행을 모두 확인하십시오. Screen Sharing 꺼짐 + Remote Management 켜짐은 보안이 강화된 구성이 아닙니다. 손잡이만 다른 같은 문입니다.

Remote Management에도 정보 버튼 뒤에 세분화된 권한 목록이 있어, 원격 사용자가 관찰, 제어, 파일 복사, 항목 삭제, 기기 재시동 등을 할 수 있는지 여부를 정합니다. 회사가 Mac을 관리하기 때문에 Remote Management가 켜져 있는 것이라면 그냥 꺼 버리지 마십시오. 먼저 기기를 관리하는 담당자와 이야기하세요. 끄면 관리 체계가 망가질 수 있고, 조직의 정책을 위반할 수도 있습니다.

내 Mac이 MDM에 등록되어 있는지 확인하기

조직이 내 Mac을 관리하고 있는지 확실하지 않다면, 이 명령이 알려 줍니다.

sudo profiles status -type enrollment

Apple의 자동 기기 등록을 통해 등록되었는지, 그리고 현재 활성 MDM 등록이 있는지를 보고합니다. 소매점에서 직접 구입해 스스로 설정한 개인 소유 Mac은 등록되지 않았다고 보고합니다. 회사나 학교에서 지급한 기기라면 대개 활성 등록이 있다고 나옵니다.

이것이 중요한 이유는 두 가지입니다. 첫째, 기기가 관리 대상이라면 원격 접근 설정이 프로파일로 강제되어 있어, 여러분이 변경해도 다시 원래대로 돌아올 수 있습니다. 둘째, 관리 대상이라면 업데이트 자체도 여러분이 아니라 조직의 소프트웨어 업데이트 정책에 의해 통제될 수 있고, 이는 26.6.1을 받는 방식을 달라지게 합니다.

설치된 구성 프로파일 목록도 확인할 수 있습니다.

sudo profiles list

무엇이 설치되어 있는지 보여 줍니다. 개인 기기라고 믿고 있는데 알 수 없는 프로파일이 보인다면 살펴볼 가치가 있습니다.

방화벽 확인하기

macOS에는 애플리케이션 방화벽이 기본 탑재되어 있지만, 모든 구성에서 기본적으로 켜져 있는 것은 아닙니다. 이번 CVE와 무관하게 켜 둘 가치가 있습니다.

인터페이스에서: 시스템 설정, 네트워크, 방화벽으로 이동해 켜십시오. 옵션 버튼 뒤에서 어떤 서비스와 애플리케이션이 들어오는 연결을 수락할 수 있는지 제어할 수 있고, 스텔스 모드를 켜면 인가되지 않은 출처의 ping이나 포트 스캔 같은 탐지에 Mac이 응답하지 않게 됩니다.

터미널에서:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

방화벽이 켜져 있는지 알려 줍니다.

한 가지 중요한 한계가 있습니다. macOS 애플리케이션 방화벽은 여러분이 공유에서 명시적으로 활성화한 서비스는 차단하지 않습니다. Screen Sharing이 켜져 있으면 macOS는 그리로 들어오는 연결을 의도된 것으로 간주하고 통과시킵니다. 방화벽은 유용한 계층이지만, 쓰지 않는 서비스를 끄는 것을 대체하지는 못합니다. 공유에서 활성화한 서비스를 차단해야 한다면, 그것은 애플리케이션 방화벽이 아니라 라우터나 패킷 필터 규칙에서 처리할 일입니다.

실제로 무엇이 대기 중인지 보기

토글을 믿는 대신 직접 확인하고 싶다면, 다음 명령이 화면 공유 포트에 바인딩된 프로세스를 보여 줍니다.

sudo lsof -i :5900

출력이 없다면 해당 포트에서 대기 중인 것이 없다는 뜻입니다. SSH는 22로, Apple Remote Desktop 포트는 3283으로 바꿔서 확인할 수 있습니다.

이런 점검은 특정 CVE와 무관하게 들여 둘 만한 좋은 습관입니다. Mac 보안 및 개인정보 보호 가이드에서는 FileVault, Gatekeeper, 개인정보 보호 권한, 그리고 각 공유 서비스가 실제로 무엇을 노출하는지를 포함해 주기적으로 점검할 만한 설정 전반을 다룹니다.

원격 접근이 정말 필요하다면 이렇게 강화하십시오

Mac에 원격으로 접속해야 할 진짜 이유가 있는 사람도 많습니다. 홈 서버, 사무실에 둔 기기, 지원해 주는 가족의 컴퓨터 같은 것들이죠. 그런 사람들에게 기능을 끄는 것은 선택지가 아닙니다. 기능을 유지하면서 노출을 줄이는 방법은 다음과 같습니다.

공용 네트워크가 아니라 사설 네트워크로 Mac에 접속하기

가장 강력한 변화 하나는, 통제할 수 없는 네트워크에 서비스를 노출하는 것을 중단하고 Mac과 클라이언트를 같은 사설 오버레이 위에 두는 것입니다.

집이나 사무실 네트워크로 들어가는 VPN도 좋습니다. Tailscale, WireGuard, ZeroTier 같은 오버레이 네트워크도 마찬가지인데, 이들은 기기 사이에 암호화된 메시를 만들고 각 기기에 일반 인터넷에서는 접근할 수 없는 고정 사설 주소를 부여합니다. 이 구성이 갖춰지면 Screen Sharing은 오직 여러분 자신의 기기만 도달할 수 있는 인터페이스에서만 대기하게 됩니다. 카페 Wi-Fi의 공격자는 어떤 의미로도 더 이상 그 서비스에 인접하지 않게 됩니다. 그 서비스가 공격자와 공유하는 로컬 인터페이스에는 노출되어 있지 않기 때문입니다.

이 방식은 CVE-2026-65400의 로컬 네트워크 범위를 실질적으로 무력화했을 접근이며, 다음번 취약점에 대해서도 마찬가지로 작동합니다. 이 구성을 만드는 과정에서 연결 문제가 생긴다면, macOS VPN 문제 해결 가이드에서 구성 프로파일, DNS, 스플릿 터널링과 관련된 일반적인 실패 유형을 다룹니다.

5900 포트는 절대 포워딩하지 마십시오

라우터에서 5900 포트를 Mac으로 포워딩하면 화면 공유 서비스가 공용 인터넷에 그대로 놓이고, 자동화된 스캐너가 몇 시간 안에 찾아냅니다. 5900 포트의 VNC는 인터넷에서 가장 집중적으로 스캔되는 포트 중 하나입니다. 하지 마십시오. 이미 해 두었다면 지금 되돌리십시오.

Apple Remote Desktop의 3283 포트와 SSH의 22 포트에도 동일하게 적용됩니다. SSH를 꼭 노출해야 한다면 기본 포트에서 옮기고, 암호 인증을 비활성화하고, 키를 사용하십시오. 그래도 더 나은 답은 여전히 VPN입니다.

명시적 허용 목록과 전용 계정 사용하기

일상적으로 쓰는 관리자 계정을 원격 접근 계정으로 쓰지 마십시오. 별도의 계정을 만들어 꼭 필요한 권한만 부여하고, Screen Sharing 허용 사용자 목록에는 그 계정만 추가하십시오. 원격 경로가 침해되더라도 피해 범위는 관리자 세션이 아니라 그 계정에 그칩니다.

그 계정에는 정말로 강력한 암호를 설정하십시오. 암호 재사용은 많은 원격 접근 사고가 심각한 사고로 번지는 원인입니다.

허용 사용자 목록을 명시적으로 유지하고 정기적으로 검토하기

「모든 사용자」는 편하지만 잘못된 선택입니다. Mac의 모든 계정이 암묵적으로 인가되며, 여기에는 오래된 계정, 게스트 성격의 계정, 몇 년 전 다른 용도로 만든 서비스 계정까지 포함됩니다. 목록을 명시적으로 설정하고, 사람이 떠나거나 계정을 폐기할 때마다 다시 살펴보십시오.

사용하지 않을 때는 서비스를 끄기

Screen Sharing이 가끔만 필요하다면, 그때만 켜고 끝나면 끄십시오. 한 달에 20분 동안 실행되는 서비스와 3년 동안 쉬지 않고 실행되는 서비스는 노출 수준이 완전히 다릅니다.

원격 접근 보안 개념 일러스트레이션

macOS Tahoe 26.6.1 설치 방법

이 업데이트는 다른 포인트 릴리스와 마찬가지로 소프트웨어 업데이트를 통해 제공됩니다.

  1. 먼저 백업하십시오. Time Machine이든 클론이든 상관없지만, 무언가는 만들어 두십시오. 작은 업데이트라 위험은 낮지만 원칙은 달라지지 않습니다.
  2. 시스템 설정을 열고 일반, 소프트웨어 업데이트로 이동합니다.
  3. 확인이 끝날 때까지 기다립니다. macOS Tahoe 26.6.1이 사용 가능한 업데이트로 표시되어야 합니다.
  4. 지금 업데이트를 클릭하고 암호를 입력합니다.
  5. Mac이 재시동되도록 둡니다. Apple Silicon에서는 기기와 디스크에 따라 보통 처음부터 끝까지 10~20분 정도 걸립니다.
  6. 다시 켜지면 터미널에서 sw_vers를 실행하거나 이 Mac에 관하여에서 확인하십시오. 버전 26.6.1, 빌드 25G76이어야 합니다.

터미널에서는 인터페이스 없이 목록 확인과 설치를 할 수 있습니다.

softwareupdate --list

사용 가능한 항목을 보여 줍니다. 해당되는 모든 항목을 설치하려면 다음을 실행합니다.

sudo softwareupdate -i -a

완료 후 기기가 자동으로 재부팅되게 하려면 --restart를 추가하세요.

업데이트가 아직 보이지 않는다면

Apple은 포인트 릴리스의 배포를 단계적으로 진행합니다. 8월 6일에 일부 M4, M5 Mac에서는 다른 기기에서 이미 제공되던 26.6.1이 아직 나타나지 않았다는 보고가 있었고, 그 사례들은 별다른 조치 없이 스스로 해결되었습니다.

소프트웨어 업데이트에 아무것도 표시되지 않는다면 다음을 시도하세요.

  • 몇 시간 기다렸다가 다시 확인하십시오. 단계적 롤아웃은 흔히 하루 정도면 모두에게 도달합니다.
  • 시스템 설정을 완전히 종료했다가 다시 열고 재확인하십시오. 소프트웨어 업데이트 창은 상태를 캐시하기 때문에 가끔 자극이 필요합니다.
  • 터미널에서 softwareupdate --list를 실행하십시오. Apple 서버에 직접 질의하기 때문에 인터페이스에 아직 뜨지 않은 업데이트가 나타나기도 합니다.
  • Mac이 조직에 의해 관리되고 있다면 정책에 따라 업데이트가 연기되었을 수 있습니다. sudo profiles status -type enrollment로 그 가능성을 확인할 수 있고, 그렇다면 일정은 IT 팀이 통제합니다.
  • 최후의 수단으로 Apple은 독립 실행형 설치 패키지를 게시하며, Mr. Macintosh가 각 릴리스의 직접 링크를 꾸준히 정리합니다. 전체 설치 프로그램을 내려받으면 단계적 롤아웃을 우회할 수 있지만, 다운로드 용량이 훨씬 커집니다.

설치가 실패한다면

포인트 릴리스는 대개 문제 없이 설치되지만, 흔한 실패 유형은 여전히 적용됩니다. 여유 공간 부족, 중단된 다운로드, 준비 단계에서 멈춰 버린 업데이트 같은 것들이죠. 설치가 멈추거나 실패하는 macOS 업데이트 가이드에서 공간을 제대로 확보하는 법, 부분 다운로드를 정리하는 법, 멈춘 설치에서 복구하는 법을 단계별로 다룹니다.

요약하자면, 다운로드 용량보다 상당히 더 많은 여유 공간이 필요합니다. macOS가 업데이트를 풀고 준비하려면 공간이 있어야 하기 때문입니다. 2.1GB 델타라면 20GB 여유는 과하지 않은, 적절한 여유입니다.

Sonoma나 Sequoia를 사용 중이라면

Apple은 2026년 8월 6일 지원 중인 두 이전 macOS 버전에도 동일한 수정을 배포했습니다.

macOS 버전패치된 릴리스빌드
macOS Tahoe 2626.6.125G76
macOS Sequoia 1515.7.924G830
macOS Sonoma 1414.8.923J631

경로는 동일합니다. 시스템 설정, 일반, 소프트웨어 업데이트에서 설치하고 재시동하면 됩니다.

구버전 macOS에 머무는 것에 대해 두 가지를 짚어 둘 만합니다. 첫째, 이 사안에 한해서는 해당 패치를 적용하기만 한다면 Sequoia나 Sonoma에 머물러도 괜찮습니다. 열등한 수정을 받는 것이 아닙니다. Apple은 세 버전 모두에서 동일한 CVE를 해결했습니다.

둘째, 그것은 Apple이 여러분의 버전에 계속 보안 업데이트를 제공하는 동안에만 성립하며, 그 대상은 대략 현재 릴리스와 그 앞의 두 버전입니다. Sonoma 14는 그 범위의 맨 끝자락에 있습니다. 이유가 있어 Sonoma에 머물고 있다면 그 이유를 주기적으로 재검토할 가치가 있습니다. 언젠가는 최신 버전에서만 수정되는 CVE가 나올 것이기 때문입니다.

또한 구버전은 헤드라인 CVE가 공유되더라도 현재 릴리스보다 좁은 범위의 수정만 받는 경우가 종종 있습니다. 26.6.1은 수정이 정확히 하나뿐이라 이번에는 해당되지 않지만, 「나는 구버전 macOS를 쓰지만 모든 업데이트를 다 받는다」는 입장이 장기적으로는 들리는 것만큼 든든하지 않은 이유가 여기에 있습니다.

Intel 관점에서

Intel Mac도 다른 기기들과 함께 26.6.1을 받으며, 델타 용량은 더 작은 898.9MB입니다. 이를 따로 언급하는 이유는 그것이 상징하는 바 때문입니다.

macOS 27은 Apple Silicon 전용입니다. Intel Mac은 이를 실행할 수 없으며, 따라서 macOS Tahoe 26이 그 기기들이 받게 될 마지막 메이저 릴리스입니다. Apple은 어떤 버전이 현재 릴리스에서 물러난 뒤에도 대략 3년간 보안 업데이트를 제공하는 패턴을 보여 왔으므로, Intel Mac 사용자는 앞으로도 정확히 이번과 같은 모습의 업데이트를 계속 받게 될 것입니다. 빌드 번호 상승, CVE 한 개 또는 몇 개, 기능 없음.

그래서 26.6.1은 Intel 하드웨어에게 앞으로 몇 년이 어떨지 미리 보여 주는 사례입니다. 업데이트는 덜 흥미로워지고 더 중요해질 것입니다. 평가할 새로운 기능이 없으므로 매번의 질문은 설치할지 말지 하나뿐이고, 답은 늘 예입니다. Intel Mac 시대의 종말 정리에서 전체 호환성 목록과 현실적인 지원 일정 전망을 다룹니다.

Intel Mac을 상시 가동 기기로 운용하고 있다면 위의 점검 섹션을 특히 눈여겨보십시오. 오래된 Mac mini야말로 벽장 안에서 Screen Sharing이 켜진 채 잊혀 있을 가능성이 가장 높은 기기입니다.

서드파티 VNC 관련 관찰

이 섹션은 추측이며, 그렇게 표시해 둡니다. 확립된 사실이어서가 아니라 특정 독자층에게 유용할 수 있어서 포함했습니다.

macOS Tahoe 26.6이 7월 말에 배포된 뒤, 일부 사용자는 서드파티 VNC 클라이언트가 더 이상 자신의 Mac에 연결되지 않는다고 보고했습니다. 보고에는 Windows, iOS, Linux에서 실행되는 RealVNC를 비롯한 클라이언트가 등장했고, RealVNC는 키 길이가 너무 크다는 취지의 프로토콜 오류 메시지를 표시했습니다. 같은 보고에서 Mac 간 Screen Sharing은 정상적으로 작동했는데, 이 부분이 단순한 일반적 고장이 아니라 흥미로운 패턴으로 보이게 만드는 대목입니다.

원본 포럼 스레드를 직접 확인하지는 못했으므로, 이 내용은 간접적인 계정을 토대로 정리한 것이며 그에 맞게 받아들여야 합니다. 이 현상을 인정한 Apple의 공식 입장은 확인된 바 없습니다.

가설을 가설로서 말하자면, 26.6이 화면 공유 인증 경로의 무언가를 바꾸면서 서드파티 VNC 클라이언트와의 호환성이 깨졌을 수 있고, CVE-2026-65400도 같은 코드 안에 있었을 수 있습니다. 인증 처리를 엄격하게 만든 변경이 있었고, 열흘 뒤 같은 구성 요소의 인증 상태 버그가 수정된 순서는 시사적입니다. 다만 Apple은 둘을 연결 짓는 어떤 자료도 공개하지 않았고, heise는 동작 원리가 여전히 불분명하다고 말하며, 시사적인 순서는 증거가 아닙니다.

이것이 실무적으로 의미하는 바는 다음과 같습니다.

  • 26.6 이후 서드파티 VNC 클라이언트가 작동하지 않는다면, 다른 사람들도 보고한 알려진 패턴입니다. 여러분만 겪는 일이 아니고, 설정을 잘못했을 가능성도 낮습니다.
  • 작동하지 않게 되었더라도 26.6.1이 고쳐 줄 것이라고 가정하지 마십시오. 이 업데이트는 보안 문제를 해결합니다. 서드파티 클라이언트 호환성을 복구한다는 근거는 없고, 실제로 복구되지 않을 수도 있습니다.
  • 서드파티 VNC 클라이언트로 Mac에 접속해야 한다면, 물리적으로 접근하기 어려운 기기를 업데이트하기 전에 클라이언트 공급업체에 macOS 26.6 및 26.6.1 호환성을 문의하십시오.
  • 이 중 어느 것도 업데이트를 건너뛸 이유는 되지 않습니다. 작동하는 서드파티 VNC 클라이언트와 패치된 인증 우회 중 선택해야 한다면, 패치를 택하고 다른 접속 방법을 찾으십시오.

자주 발생하는 문제 해결

macOS Tahoe 26.6.1이 소프트웨어 업데이트에 표시되지 않음

문제: 8월 6일에 출시되었는데도 소프트웨어 업데이트는 Mac이 26.6에서 최신 상태라고 표시하고 26.6.1은 어디에도 보이지 않습니다. 출시 당일 여러 사용자가 M4 및 M5 Mac에서 이 현상을 보고했습니다.

해결: 거의 항상 결함이 아니라 단계적 롤아웃 때문입니다. Apple은 포인트 업데이트를 몇 시간에서 며칠에 걸쳐 기기 집단별로 순차 배포합니다. 소프트웨어 업데이트 창이 결과를 캐시하므로 시스템 설정을 완전히 종료했다가 다시 여십시오. 그다음 터미널에서 softwareupdate --list를 실행하면 Apple 서버에 직접 질의하기 때문에 인터페이스에 아직 뜨지 않은 업데이트가 반환되기도 합니다. Mac이 관리 대상이라면 sudo profiles status -type enrollment를 실행해 MDM이 정책으로 업데이트를 연기하고 있는지 확인하십시오. 그렇다면 일정은 IT 팀이 통제합니다. 8월 6일에 보고된 사례들은 하루 안에 스스로 해결되었습니다. 당장 필요하고 기다릴 수 없다면, 전체 독립 실행형 설치 프로그램이 훨씬 큰 다운로드를 대가로 롤아웃을 우회해 줍니다.

업데이트가 다운로드되지만 설치가 끝나지 않음

문제: 다운로드가 완료되거나 완료된 것처럼 보인 뒤, Mac이 준비 중 상태나 멈춘 진행 표시줄에서 눈에 띄는 진전 없이 오래 머물러 있습니다.

해결: 먼저 합리적이라고 느껴지는 것보다 더 오래 기다려 보십시오. 디스크가 거의 가득 찬 바쁜 기기에서는 준비 단계가 실제로 15분 이상 걸릴 수 있습니다. 정말로 멈춘 것이라면 여유 공간을 확인하십시오. macOS는 설치 프로그램을 풀고 준비하기 위해 다운로드 용량보다 훨씬 많은 여유가 필요합니다. Mac을 재시동하고 다시 시도하면 부분적이거나 손상된 다운로드가 정리됩니다. 두 번째에도 실패한다면 캐시된 업데이트를 제거하고 새로 내려받게 하십시오. 멈추거나 실패한 macOS 업데이트 가이드에서 업데이트 캐시를 안전하게 정리하는 법과 Mac이 설치 실패 루프로 재부팅될 때의 대처를 포함해 전체 절차를 다룹니다.

업데이트 후 Screen Sharing이 작동하지 않음

문제: 26.6.1을 설치했는데 화면 공유로 Mac에 접속하거나 Mac에서 접속할 수 없습니다.

해결: 실제로 무엇이 활성화되어 있는지 확인하는 것부터 시작하십시오. 시스템 설정, 일반, 공유를 열고 화면 공유 행과 원격 관리 행을 모두 확인하세요. 둘은 상호 배타적이며, 업데이트나 정책 변경으로 기억하던 것과 다른 상태가 되어 있을 수 있습니다. 접속하는 계정이 「모든 사용자」에 의존하지 않고 허용 사용자 목록에 들어 있는지 확인하십시오. 그 설정이 바뀌었을 수 있습니다. 다른 Mac에서 화면 공유나 Finder로 접속하고 있다면, 문제가 서비스에 있는지 아니면 거기에 이르는 경로에 있는지 가르기 위해 먼저 로컬 네트워크에서 테스트해 보십시오. 서드파티 VNC 클라이언트로 접속하고 있다면 위 섹션을 참고하십시오. 26.6부터 서드파티 클라이언트 실패를 보고한 사용자들이 있었고, 그 현상은 확인되지 않았지만 보고된 바 있습니다. 마지막으로 대상 Mac에서 sudo lsof -i :5900을 실행해 실제로 대기 중인 것이 있는지 확인하십시오.

Remote Management가 꺼지지 않음

문제: 공유 패널에서 원격 관리를 껐는데 다시 켜지거나, 토글이 회색으로 비활성화되어 변경할 수 없습니다.

해결: 관리 대상 Mac의 전형적인 증상입니다. MDM이 푸시한 구성 프로파일은 원격 관리를 강제할 수 있고, 여러분이 로컬에서 변경해도 다시 적용합니다. sudo profiles status -type enrollment로 활성 MDM 등록이 있는지 확인하고, sudo profiles list로 어떤 프로파일이 설치되어 있는지 확인하십시오. Mac이 회사나 학교 소유라면 우회하려 들지 마십시오. 기기를 관리하는 담당자에게 연락하세요. 관리를 제거하는 것은 정책 위반일 수 있고, 어차피 몇 분 안에 되돌려질 가능성이 큽니다. 정말로 개인 소유 Mac인데 승인한 적 없는 등록이 발견되었다면, 그것은 상부에 보고할 만한 심각한 사안이며 개인 기기에서 가장 안전한 해결책은 데이터를 백업한 뒤 클린 설치를 하는 것입니다.

내 Mac이 침해되었는지 확실하지 않음

문제: 공유 네트워크에서 Screen Sharing을 켠 채 상시 가동 Mac을 운용했고, 누군가 실제로 이 버그를 이용했는지 알고 싶습니다.

해결: 솔직히 말씀드리면, 일반 사용자 수준에서 이를 확실하게 답할 방법은 없습니다. Apple은 CVE-2026-65400의 침해 지표를 공개하지 않았고, 동작 원리도 비공개이며, Screen Sharing에 인증한 공격자는 정상 세션과 대체로 비슷해 보이는 로그 활동을 남겼을 것입니다. 여기서 증거가 없다는 것은 정말로 없었다는 증거가 되지 못합니다.

한계를 이해한 상태에서 그래도 확인할 수 있는 것들은 다음과 같습니다. 콘솔을 열어 우려되는 기간의 시스템 로그를 화면 공유 활동으로 필터링해 살펴보십시오. 다만 macOS의 로그 보존 기간은 제한적이라 오래된 항목은 이미 사라졌을 수 있습니다. 시스템 설정의 사용자 및 그룹에서 알아볼 수 없는 계정이 있는지 검토하십시오. 공유 패널의 허용 사용자 목록에 여러분이 추가하지 않은 항목이 있는지 확인하십시오. 로그인 항목과 백그라운드 항목에서 낯선 것이 있는지 살펴보십시오. sudo profiles list를 실행해 설치한 적 없는 구성 프로파일이 있는지 확인하십시오. 라우터의 연결된 기기 목록과, 로그를 보관한다면 그 로그도 검토하십시오.

특정 기기가 누군가에게 접근당했다고 믿을 구체적인 근거가 있고 그 기기에 민감한 정보가 있다면, 진정으로 신뢰할 수 있는 유일한 조치는 macOS를 클린 설치한 뒤 전체 시스템 백업이 아니라 데이터만 복원하고, 그 기기에서 로그인되어 있던 계정들의 암호를 변경하는 것입니다. 무거운 대응이며 대부분의 사람에게는 필요하지 않습니다. Apple은 이 문제의 알려진 악용 사례가 없다고 밝혔습니다.

FAQ

Screen Sharing이 꺼져 있었어도 macOS Tahoe 26.6.1을 설치해야 하나요?

네. Apple은 CVE-2026-65400을 악용하려면 Screen Sharing이 켜져 있어야 하는지 밝힌 적이 없고, heise도 이 부분이 여전히 불분명하다고 보도합니다. 조건이 알려지지 않았고 업데이트 비용은 재시동 한 번이므로 설치하십시오. 토글이 꺼져 있었다는 사실을 안전했다는 확인으로 받아들이지 마십시오.

CVE-2026-65400은 쉽게 말해 무엇인가요?

macOS Screen Sharing 서비스의 인증 우회입니다. 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를 설치하십시오. 그런 다음 시스템 설정, 일반, 공유에서 10분을 들여 하나가 아니라 세 개의 원격 접근 스위치를 모두 살펴보십시오. 필요하지 않다면 Screen Sharing과 Remote Management가 모두 꺼져 있는지 확인하고, Remote Login도 따로 확인하고, 「모든 사용자」 설정은 명시적인 목록으로 바꾸고, 방화벽을 켜십시오. Mac에 원격으로 접속할 필요가 정말 있다면, 기기가 우연히 놓인 네트워크에 서비스를 노출하는 대신 VPN이나 오버레이 네트워크로 접속하고, 5900 포트는 절대 포워딩하지 마십시오. 그런 구성이었다면 이번 CVE는 여러분에게 사실상 학술적인 이야기였을 것이고, 다음번에도 마찬가지일 것입니다.

관련 읽을거리: macOS Tahoe 26.6 출시: 새로운 기능, 보안 수정, 업데이트 가이드