macOS 화면 공유 취약점 패치가 몰린 낮에 사내 네트워크가 느려졌다. 정작 내 맥은 5900 포트가 그대로 열려 있었다

오늘 낮에 사내 네트워크가 눈에 띄게 느렸다. 처음엔 회선이나 VPN 문제인가 싶어서 재접속을 몇 번 했다.

알고 보니 다들 macOS 보안 업데이트를 받고 있었다. 화면 공유 취약점 때문이었다. 회사 공동체 곳곳에서 같은 시간대에 같은 걸 받으니 그만큼 대역폭이 나간 것이다. 원인을 알고 나니 오히려 좀 안심이 됐다. 장애가 아니라 다들 제때 고치고 있다는 뜻이니까.

나도 받았다. 내 맥은 26.6.2가 됐고, 문제가 된 취약점은 이미 그 앞 버전에서 막혀 있었다. 여기까지는 잘 끝난 얘기다.

그런데 글을 쓰려고 자료를 뒤지다가 "화면 공유가 켜져 있는 시스템만 해당된다"는 문장을 읽었다. 내 맥은 켜져 있다. 원격에서 제어하려고 넉 달 전에 내가 켰다. 그건 알고 있었다.

몰랐던 건 그게 어디까지 열려 있는지였다. 5900이 모든 인터페이스에 열려 있었고, 방화벽은 꺼져 있었다.

무엇이 뚫렸는지부터

이번 건은 CVE-2026-65400이다. macOS 화면 공유의 인증 우회이고, CVSS 점수가 9.8이다. 10점 만점 척도에서 9.8은 거의 최상단이다.

애플의 설명은 짧다. 네트워크상의 공격자가 유효한 자격증명 없이 화면 공유에 인증할 수 있으며, 인증 과정의 상태 관리를 개선해 해결했다는 것이다. 이 한 줄만 보면 무슨 일인지 잘 안 그려진다.

헌트리스가 공개한 분석을 보면 좀 더 구체적이다. 화면 공유 데몬은 SRP라는 인증 프로토콜을 쓰는데, 그 구현에서 프레임 길이 검사기가 이전 상태의 성공 값을 그대로 반환하는 결함이 있었다. 인증이 끝나지도 않았는데 시스템이 "성공"이라고 읽는다. 그 결과 연결이 인증된 것으로 취급된다.

여기서 한 가지가 더 붙는다. 그렇게 통과한 연결은 암호화 없이 이어진다. 평문 세션이 된다. 원래 SRP를 쓰는 이유 중 하나가 세션 키를 만드는 건데, 인증 단계를 건너뛰니 키를 만들 재료도 없다.

그다음이 진짜 문제다. 이 연결로 SSFileCopySender라는 헬퍼 프로세스에 닿을 수 있다. 화면 공유 중에 파일을 주고받으라고 있는 물건인데, 이 프로세스가 물려받는 권한이 kTCCServiceSystemPolicyAllFiles다. 전체 디스크 접근 권한이고, TCC를 통째로 우회한다.

TCC는 맥에서 "이 앱이 사진 폴더에 접근하려 합니다" 같은 창을 띄우는 그 층이다. 사용자가 허락하고 거절하는 지점이 전부 거기 있다. 그 층 뒤로 들어가면 사용자는 아무것도 못 본다.

전체 디스크 접근이 실제로 무엇을 여는지 생각해보면 범위가 꽤 넓다. 메일 로컬 저장소, 메시지 데이터베이스, 사진 라이브러리, 브라우저 프로필, 그리고 개발자 맥이라면 SSH 키와 클라우드 자격증명 파일이 전부 홈 디렉터리 아래 있다. 예전에 시크릿 스캔 훅을 걸어놨는데 AWS 키가 그냥 통과했던 일을 정리한 적이 있는데, 그때 확인한 게 키라는 게 얼마나 여러 군데 흩어져 있는지였다. 그 흩어진 것들이 한 번에 읽히는 상태가 전체 디스크 접근이다.

SRP 자체는 나쁜 프로토콜이 아니다. 비밀번호를 네트워크로 보내지 않고도 양쪽이 같은 비밀번호를 아는지 확인하는 방식이고, 그 과정에서 세션 암호화에 쓸 키가 부산물로 만들어진다. 설계는 튼튼하다. 무너진 건 설계가 아니라 그걸 구현한 코드의 한 지점이었다. 프레임 길이를 검사하는 함수가 이전 호출의 결과값을 그대로 물고 있었다.

이런 종류의 결함이 특히 성가신 이유가 있다. 암호가 깨진 게 아니라 암호를 쓸지 말지 판단하는 코드가 잘못 답한 것이라, 밖에서 보면 정상 연결과 구분이 잘 안 된다. 애플이 수정 방식을 "상태 관리 개선"이라고 적은 것도 그래서다. 알고리즘을 바꾼 게 아니라 상태를 잘못 읽던 자리를 고쳤다는 뜻이다.

실제 공격에서는 여기까지 가서 root를 얻고 채굴기를 심었다. 마이크로소프트가 관측한 걸 보면 XMRig 6.26.0을 .config/sysmond라는 이름으로 숨기고, com.apple.airportd를 사칭하고, KeepAlive 옵션을 켠 런치데몬으로 재시작에도 살아남게 만들었다. 네덜란드 국가사이버보안센터는 인터넷에서 5900 포트에 닿을 수 있는 여러 시스템에서 실제 악용을 확인했다고 경고했다.

설정을 잠가도 안 되는 종류였다

이 취약점에서 제일 불편한 대목은 따로 있다.

헌트리스 분석에 이런 문장이 있다. 허용 사용자 계정을 지우거나 VNC 비밀번호 인증을 끄는 것 같은 개별 화면 공유 설정은 이 버그의 성공 여부에 영향을 주지 않는다는 것이다.

이게 왜 서늘하냐면, 우리가 보안 설정을 잠글 때 실제로 하는 일의 대부분이 그 아래에 있기 때문이다. 접근을 허용할 계정을 고르는 것도, 비밀번호를 어떻게 검증할지 정하는 것도, 전부 "인증을 통과한 다음"에 적용되는 규칙이다. 인증 자체가 우회되면 그 규칙들은 실행되지 않는다. 문 안쪽에 걸어둔 자물쇠는 문을 안 열고 들어온 사람에게 아무 의미가 없다.

내 맥에서 확인해봤다.

$ defaults read /Library/Preferences/com.apple.RemoteManagement
{
    AllowSRPForNetworkNodes = 0;
    DisableKerberos = 0;
}

AllowSRPForNetworkNodes = 0이다. 네트워크 노드에 SRP를 허용하지 않는다는 뜻이다. 이 값만 보면 SRP 경로가 닫혀 있는 것처럼 읽힌다. 그런데 이번 버그는 정확히 그 설정 바깥에서 났다.

설정값을 보고 안심하는 습관이 여기서 깨진다. 설정은 "이 기능을 어떻게 쓸지"를 정하는 것이고, 취약점은 "그 기능이 어떻게 잘못 동작하는지"의 문제다. 앞의 것으로 뒤의 것을 막을 수 없는 경우가 있고, 이번이 그런 경우였다.

이 구분이 실무에서 중요한 이유는 우리가 보안 점검을 할 때 보는 게 거의 다 앞쪽이기 때문이다. 체크리스트를 돌리면 나오는 항목들이 대체로 그렇다. 비밀번호 정책이 걸려 있는가, 허용 계정이 최소인가, 암호화가 켜져 있는가. 전부 설정값이고, 전부 기능이 정상 동작한다는 전제 위에 있다.

그 전제가 깨지는 종류의 결함에 대해서는 설정 점검이 아무 신호도 주지 않는다. 오히려 반대로 작동한다. 항목이 전부 초록색이면 점검을 마쳤다고 기록되고, 그 기록이 다음 점검까지의 안심 근거가 된다.

그래서 설정을 잠그는 것과 노출을 줄이는 것은 다른 일이다. 앞의 것은 기능을 어떻게 쓸지 정하고, 뒤의 것은 그 기능이 애초에 켜져 있어야 하는지를 묻는다. 이번 건에서 실제로 효과가 있었던 건 뒤쪽뿐이다. 화면 공유를 안 켠 맥은 설정을 어떻게 해뒀든 상관없이 무사했다.

7월 27일에 이미 한 번 고쳤다

이 건에는 앞 이야기가 있다.

CVE-2026-43760이 7월 27일 업데이트에 들어갔다. 레거시 VNC 인증 경로의 혼동된 대리자 문제였다. 이쪽은 인증이 필요했다. VNC 자격증명을 가진 사용자가 root 권한으로 파일을 읽고 만들 수 있게 되는 결함이었고, 대상 프로세스는 같은 SSFileCopySender와 SSFileCopyReceiver였다.

열흘 뒤에 65400이 나왔다. 목적지가 같다. 같은 헬퍼 프로세스, 같은 전체 디스크 접근이다. 다른 건 가는 길이다. 43760은 인증을 통과한 뒤에 쓰는 길이고, 65400은 인증이 아예 필요 없는 길이다.

헌트리스는 이 둘이 순차적으로 이어지는 체인이 아니라 같은 특권 파일 작업으로 가는 두 개의 별도 경로라고 정리했다.

문이 두 개인 이유를 생각해보면 구조가 보인다. 화면 공유는 오래된 기능이고, 그동안 인증 방식이 여러 번 바뀌었다. 옛날 VNC 방식이 있고, 애플이 나중에 만든 방식이 있다. 호환을 위해 옛것을 지우지 않고 남겨두면 인증 경로가 둘이 된다. 그런데 그 뒤에 있는 방은 하나다.

이런 모양은 아주 흔하다. 레거시 인증을 남겨둔 API, 예전 토큰 형식을 계속 받아주는 게이트웨이, 구버전 클라이언트를 위해 살려둔 엔드포인트가 전부 같다. 뒷방을 튼튼하게 지켰는지가 아니라 그 방으로 들어오는 문이 몇 개인지가 실제 공격 표면이고, 문 개수를 정확히 아는 사람은 대개 없다.

이 모양을 어제 망분리 글에서도 봤고, 그 앞 아티팩토리 글에서도 봤다. 파일 쓰기를 막으니 폴더 이름으로 썼고, 랜선을 막으니 테더링이 남았다. 여기서는 인증 후 경로를 막으니 인증 전 경로가 나왔다.

경로를 하나씩 지우는 방식이 왜 항상 뒤처지는지가 이 세 사건에서 같은 모양으로 반복된다. 지워야 할 경로의 목록을 완전하게 쓸 수 있다는 가정 위에서만 그 방식이 성립하는데, 그 목록을 다 쓴 사람이 아무도 없다. 애플도 열흘 간격으로 두 번 썼다.

그런데 왜 하필 오늘이었나

여기서 좀 이상한 게 있다. 패치는 8월 6일에 나왔다. 오늘은 19일이다. 열사흘 차이다.

날짜를 늘어놓으면 이렇게 된다.

날짜	무슨 일
7월 27일	CVE-2026-43760 패치 (Tahoe 26.6, Sequoia 15.7.8, Sonoma 14.8.8)
8월 6일	CVE-2026-65400 패치 (Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9)
8월 중순	네덜란드 NCSC가 실제 악용 경고. 채굴기 설치 관측
8월 17일	Tahoe 26.6.2. 보안 항목 28건
8월 19일	사내에서 패치가 몰림

8월 6일 업데이트는 취약점 하나만 고친 업데이트였다. 애플이 단일 항목으로 릴리스를 낸다는 건 그만큼 급하다는 신호인데, 그날 곧바로 몰리지는 않았다.

움직이게 만든 건 패치가 나왔다는 사실이 아니라 실제로 뚫리고 있다는 뉴스였다. 이론적 위험은 일정에 밀리고, 관측된 악용은 일정을 밀어낸다. 어느 조직이든 대체로 그렇다.

이 비대칭은 사실 합리적인 구석이 있다. 패치 하나하나에 전사 대응을 걸면 업무가 안 돌아간다. 애플만 해도 이번 달에 세 번 업데이트를 냈다. 그러니 우선순위를 매겨야 하고, "실제로 악용되고 있는가"는 그 우선순위에서 가장 강한 신호 중 하나다. 미국 CISA가 아예 악용이 확인된 취약점만 따로 목록으로 관리하는 것도 같은 이유다.

문제는 그 신호가 도착하는 시점이 공격자의 일정에 달려 있다는 것이다. 8월 6일부터 뉴스가 뜨기까지의 그 열흘 남짓이 무방비 구간이었고, 그 구간의 길이를 정한 건 우리가 아니라 채굴기를 깔던 쪽이었다. 조용히 했으면 그 구간은 더 길어졌을 것이다.

여기서도 탐지가 얼마나 늦는지 얘기와 같은 구조가 나온다. 대응 속도가 아니라 인지 시점이 전체를 결정한다. 그리고 인지는 대개 남이 시켜준다.

그리고 한 가지 짚어둘 게 있다. 8월 17일에 나온 26.6.2는 보안 항목이 스물여덟 건인데 그 구성이 웹킷 스무 건, 커널 세 건, 이미지IO 두 건, 오디오와 IOGPUFamily 각각 한 건 식이다. 화면 공유는 여기 없다. 화면 공유는 8월 6일 26.6.1에서 이미 끝난 얘기다.

그러니까 오늘 사내에서 오간 트래픽 중 상당 부분은 "화면 공유 때문에" 받는다고 생각하며 받은 26.6.2일 가능성이 있다. 물론 웹킷 스무 건도 받아야 할 이유로 충분하다. 다만 사람들이 어떤 이유로 움직였는지와 실제로 무엇을 받았는지가 어긋나 있었다면, 그건 다음번에 같은 상황이 왔을 때 판단을 흐린다.

해커는 한 명도 안 왔는데 가용성이 깨졌다

오늘 실제로 손해가 난 지점을 보자.

우리 회사에 침입자가 들어왔다는 얘기는 없다. 채굴기가 심어졌다는 보고도 없다. 그런데 낮 시간에 일하던 사람들이 다 같이 느려졌다. 파일이 늦게 열리고, 회의 도구가 끊기고, 빌드가 늘어졌다.

용량을 대충 세어보면 왜 그런지 나온다. 26.6.1이 애플 실리콘 기준 2.1GB쯤이고, Sequoia 15.7.9는 4.2GB쯤이다. 26.6.2는 26.6.1에서 올라갈 때 애플 실리콘 2.89GB, 인텔 1.27GB다. 한 사람이 두 번 다 받았으면 5GB에 가깝다.

여기에 사람 수를 곱하면 된다. 1,000명이 평균 3GB씩만 받아도 3TB다. 그게 점심 전후 네 시간에 몰리면 평균으로만 1.7Gbps고, 피크는 그 몇 배로 뛴다. 실제 수치를 재본 건 아니니 어림이지만, 자릿수는 이 근처다.

여기서 좀 허탈한 대목이 있다. 이 문제는 이미 해결책이 macOS 안에 들어 있다.

콘텐츠 캐싱이라는 기능이 있다. 사내에 맥 한 대를 캐시로 지정해두면 애플 소프트웨어 업데이트를 그 한 대가 받고, 나머지는 인터넷이 아니라 그 맥에서 받아간다. 설정에서 켜기만 하면 되고, 같은 네트워크의 맥들이 알아서 찾아 쓴다. 수천 대가 각자 밖으로 나가서 같은 3GB를 받는 상황을 막으려고 있는 물건이다.

구조를 보면 어제 글에서 다룬 패키지 프록시 캐시와 정확히 같은 모양이다. 밖에 나가는 통로를 하나로 모으고 나머지는 그 하나에서 가져간다. 아티팩토리도 그래서 거기 있었다.

그러니 오늘 느려진 건 기술적으로 불가피한 일이 아니었다. 캐시가 없었거나, 있는데 안 쓰였거나, 아무도 그 얘기를 안 꺼낸 것이다. 급한 패치를 돌릴 때 대역폭 계획까지 같이 세우는 조직은 생각보다 드물다. 보안 공지와 네트워크 운영이 다른 사람 손에 있고, 둘이 같은 회의에 안 들어가기 때문이다.

이 사건을 어떻게 분류할지가 좀 재밌다. 보안 사고인가? 침입은 없었다. 장애인가? 고장 난 장비는 없었다. 그런데 서비스가 정상적으로 안 돌아간 시간이 실재했다.

보안을 지키는 행동이 가용성을 깎았다. 그리고 이건 예외적인 일이 아니라 규칙적으로 일어나는 일이다. 긴급 패치, 인증서 일괄 교체, 백신 전체 검사, 강제 재부팅이 전부 같은 모양이다. 방어 조치는 항상 어딘가에서 자원을 쓰고, 그 자원은 대개 그 시간에 일하던 사람들의 것이다.

비용이 눈에 안 띄는 이유도 같다. 침해 사고는 보고서가 남고 숫자가 붙는데, 패치 때문에 오후 내내 느렸던 건 아무 데도 기록되지 않는다. 각자 조금씩 손해를 보고 아무도 청구서를 쓰지 않는다.

4년 전에 훨씬 큰 규모로 같은 성질의 사건이 있었다. 2022년 10월 판교 데이터센터 화재다. 그때도 해커는 없었다. 불이 났고 서버가 죽었고 전 국민이 며칠 불편했다. 그 화재가 태운 서버 중 하나가 나중에 40개월 은폐로 드러난 그 침해 사건의 물건이기도 한데, 화재 자체는 순수한 가용성 사고였다.

보안을 침입 차단으로만 좁히면 이 두 사건이 다 밖으로 밀려난다. 그런데 사용자 입장에서 "서비스를 못 썼다"는 결과는 완전히 같다.

내 맥을 실제로 열어봤다

여기까지는 남 얘기다. 내 것을 봤더니 다른 게 나왔다.

$ sw_vers
ProductVersion:     26.6.2
BuildVersion:       25G83

$ launchctl list | grep -i screensharing
-   0   com.apple.screensharing.agent
-   0   com.apple.screensharing.menuextra
-   0   com.apple.screensharing.MessagesAgent

$ netstat -an | grep 5900
tcp4       0      0  *.5900                 *.*                    LISTEN
tcp6       0      0  *.5900                 *.*                    LISTEN

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)

버전은 26.6.2다. 패치는 됐다. 65400은 26.6.1에서 막혔으니 이 맥은 그 취약점에 안 걸린다.

그런데 5900 포트가 모든 인터페이스에 열려 있다. *.5900의 별표가 그 뜻이다. 특정 주소에만 바인딩된 게 아니라 이 맥이 붙어 있는 모든 네트워크에서 닿는다. 화면 공유 관련 프로세스도 세 개 돌고 있다. 그리고 응용 프로그램 방화벽은 꺼져 있다.

언제부터 이랬는지 찾아봤다.

$ ls -lT /Library/Preferences/com.apple.RemoteManagement.plist
-rw-r--r--@ 1 root  wheel  96 Apr  1 21:54:02 2026

4월 1일 밤 9시 54분이다. 원격 관리 설정 파일이 마지막으로 쓰인 시각이고, 화면 공유를 켠 시점으로 보면 맞다. 오늘까지 넉 달 반이다.

회사가 민 설정인지도 확인해봤다.

$ profiles status -type enrollment
Enrolled via DEP: No
MDM enrollment: No

$ profiles -L
There are no configuration profiles installed

아니다. MDM에 등록돼 있지 않고 구성 프로파일도 없다. 그 시각에 바뀐 파일도 com.apple.RemoteManagement.plist 하나뿐이라 다른 게 건드린 흔적이 없다. 내가 켠 것이다.

기억도 난다. 원격에서 이 맥을 제어하려고 켰다. 지금도 그 용도로 쓴다.

이 글이 여기서 흔한 실수담이 될 뻔했다. "켜놓고 잊었다"로 쓰면 교훈이 깔끔하게 떨어진다. 끄면 되니까.

그런데 사실이 아니다. 나는 이 기능이 필요하고, 끌 생각이 없다. 그러면 답이 "끄세요"인 조언은 나한테 아무 소용이 없고, 화면 공유를 실제로 쓰는 다른 사람들에게도 마찬가지다.

그런데 여기서 더 뼈아픈 게 하나 나왔다.

$ ls -l /Library/Preferences/com.apple.VNCSettings.txt
ls: No such file or directory

VNC 비밀번호 파일이 없다. 레거시 VNC 인증을 설정하지 않았다는 뜻이다. 나는 화면 공유를 켜면서 비밀번호 방식은 안 쓴 것이고, 그건 보안적으로 더 나은 선택이었다. 실제로 7월 27일에 나온 43760은 VNC 자격증명이 있어야 성립하는 결함이라 내 맥은 애초에 해당이 없었다.

그 신중함이 8월 6일 건에는 하나도 도움이 안 됐다. 65400은 자격증명을 요구하지 않으니까. 앞서 인용한 그 문장이 여기서 실물이 된다. 개별 화면 공유 설정은 이 버그의 성공 여부에 영향을 주지 않는다. 내가 잠근 자물쇠가 정확히 그 "개별 설정"이었다.

한 가지 더 눈에 걸린 게 있다.

$ ls -lTd /Library/Application\ Support/Apple/Remote\ Desktop
drwxr-xr-x  3 root  wheel  96 Aug 19 14:34:52 2026

오늘 오후 2시 34분이다. 원격 데스크톱 관련 디렉터리가 오늘 낮에 건드려졌다. 네트워크가 느려졌다고 느낀 게 딱 그 시간대다. 남의 얘기인 줄 알았던 패치 물결 안에 내 맥도 있었다.

여기서 오늘 한 일이 무엇이었는지가 정확해진다. 패치는 취약점을 막았지 노출을 줄이지 않았다. 65400은 닫혔다. 그런데 화면 공유 서비스는 여전히 켜져 있고, 포트는 여전히 열려 있고, 방화벽은 여전히 꺼져 있다. 다음 취약점이 나오면 나는 다시 같은 자리에 서 있다.

그리고 내가 진짜로 몰랐던 건 켜져 있다는 사실이 아니었다. 어디까지 열려 있는지였다.

내가 켠 건 "원격에서 내가 이 맥에 접속한다"였다. 실제로 켜진 건 "이 맥이 붙은 모든 네트워크에서 5900으로 누구나 말을 걸 수 있다"였다. 이 둘은 같은 스위치에 묶여 있다. 설정에서 체크박스 하나를 켜면 전 인터페이스에 바인딩된다. 어느 네트워크에서 받을지, 누구한테서 받을지는 그 스위치가 묻지 않는다.

기능을 켜는 결정과 노출 범위를 정하는 결정은 원래 별개인데, 대부분의 운영체제 설정이 그 둘을 하나로 합쳐놨다. 그래서 쓰겠다고 결정한 사람은 노출 범위까지 자동으로 결정한 셈이 되고, 자기가 그런 결정을 했다는 자각이 없다. 나도 넉 달 반 동안 없었다.

인터넷에 직접 노출된 건 아니다. 회사 네트워크 안이다. 그런데 어제 글에서 20년치로 정리한 게 정확히 "내부망이니까 괜찮다"는 문장이 어떻게 관리를 멈추게 하는지였다. 그 글을 쓴 다음 날 내 맥에서 그 문장의 실물이 나왔다. 4만 대 규모로 관측된다는 인터넷 노출 호스트들도 대부분 이 경로로 만들어졌을 것이다. 누가 악의로 연 게 아니라, 쓰려고 켰고 범위는 안 물어봤을 뿐이다.

목록이 없으면 전량 대응이 기본값이 된다

오늘 벌어진 일을 조금 떨어져서 보면 이런 구조다.

화면 공유는 macOS에서 기본으로 켜지는 기능이 아니다. 누군가 의도적으로 켠 맥만 해당된다. 그러면 실제 대상은 전체의 일부다. 이론적으로는 그 일부만 골라서 먼저 처리하면 된다.

그런데 어느 맥에서 화면 공유가 켜져 있는지 아는 사람이 없다. 나조차 내 것을 몰랐다. 그러니 답은 하나로 수렴한다. 전부 패치한다.

전량 대응은 안전한 선택이다. 대상을 못 세도 되니까. 그리고 비용은 대역폭으로 나간다.

이건 어제 망분리 글에서 본 것과 같은 저울이다. 거기서는 개인정보를 다운로드할 수 있는 사람이 누군지 세는 것보다 전 직원 인터넷을 끊는 게 쌌다. 여기서는 화면 공유가 켜진 맥을 세는 것보다 전량을 받게 하는 게 싸다. 두 경우 다 목록을 안 쓴 자리에 광범위한 조치가 들어섰고, 그 조치는 목록보다 싸 보이지만 매번 값을 치른다.

차이가 있다면 이번 값은 하루치라 눈에 띄었다는 것이다. 망분리 쪽 값은 20년에 걸쳐 나눠 냈기 때문에 아무도 청구서를 못 봤다.

여기서 짚을 게 하나 더 있다. 전량 대응이 안전해 보이는 건 대상을 못 세도 되기 때문인데, 그 대신 끝났는지도 알 수 없게 된다.

오늘 사내 맥이 몇 대나 실제로 26.6.1 이상이 됐는지 누가 아는가. 자리를 비운 사람, 저전력 모드로 미룬 사람, 재부팅을 내일로 미룬 사람이 남는다. 대상 목록이 없으면 완료 목록도 없다. "다들 받았을 것"이라는 상태로 끝나고, 그 상태는 다음 취약점이 나올 때까지 검증되지 않는다.

목록을 세는 쪽은 이게 반대다. 화면 공유가 켜진 맥이 서른 대라고 나오면, 그 서른 대가 다 처리됐는지 확인할 수 있다. 세는 비용을 내면 완료를 확인할 권리가 따라온다. 안 세면 둘 다 없다.

세는 게 그렇게 어려운 일도 아니다. 자산 관리 도구가 있는 조직이면 화면 공유 서비스 상태는 조회 가능한 항목이다. 없어도 명령 한 줄이면 각자 확인한다.

netstat -an | grep 5900

문제는 이걸 아무도 안 물어봤다는 것이다. 오늘 오간 메시지는 전부 "업데이트하세요"였고, "화면 공유 켜져 있는 사람?"은 없었다. 후자를 먼저 물었으면 오늘 급하게 받아야 할 사람이 훨씬 적었을 것이고, 나머지는 저녁에 받아도 됐다.

패치 다음에 해야 하는 것

이번 건에서 조치는 두 갈래다. 그리고 대부분의 조직이 앞의 것만 한다.

취약점을 막는 쪽은 업데이트다. Tahoe는 26.6.1 이상, Sequoia는 15.7.9 이상, Sonoma는 14.8.9 이상이면 65400은 해결된다. 취약한 건 26.5.2 이하, 15.7.7 이하, 14.8.7 이하다.

노출을 줄이는 쪽은 별개다. 화면 공유를 안 쓰면 끈다. 설정의 일반 항목 아래 공유에서 화면 공유를 끄면 되고, 터미널로 확인하려면 앞의 netstat 한 줄이면 충분하다. 끈 다음 다시 조회했을 때 5900이 안 나오면 닫힌 것이다.

문제는 나처럼 써야 하는 경우다. 여기가 실제로 어려운 자리이고, 대부분의 권고가 여기서 말이 없어진다.

끄지 않고 할 수 있는 게 몇 가지 있다.

• 방화벽을 켠다. 응용 프로그램 방화벽 상태는 socketfilterfw --getglobalstate로 보인다. 내 경우처럼 꺼져 있으면 켜는 게 기본값에 가깝고, 켜면 어떤 연결을 받을지 물어보는 층이 하나 생긴다
• 어느 네트워크에서 받을지 좁힌다. 집에서 붙는 용도면 회사 네트워크에 있을 때까지 열려 있을 이유가 없다. VPN을 경유하게 하면 5900을 공용 구간에 노출하지 않고도 같은 일을 한다
• 안 쓰는 동안 끈다. 원격 접속은 대개 특정 시간대에만 필요하다. 상시로 켜둘 이유가 있는지는 따로 판단할 문제다
• 최소한 열려 있다는 걸 알고 있는다. 이게 제일 낮은 단계인데, 나는 오늘까지 이것도 못 하고 있었다

인터넷에 열린 화면 공유 호스트가 4만 대 규모로 관측된다는 보고가 있다. 그중 상당수는 누가 일부러 공개한 게 아니라 쓰려고 켠 것이고, 범위를 정하는 화면이 따로 없어서 그렇게 된 것들일 가능성이 높다. 내 맥이 사내망에서 그랬던 것과 같은 이유다.

탐지 쪽도 항목이 나와 있다. 헌트리스는 ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH 이벤트에서 인증 유형이 SRP인데 RSA-SRP 암호화가 없는 세션, 그리고 세션 사용자명이 root인 연결을 이상 신호로 보라고 정리했다. root 세션은 macOS에서 기본적으로 비활성이라 그 자체가 신호다. 프로세스 쪽으로는 SSFileCopySender가 UID/GID 0과 80으로 뜨는 게 초기 탐색의 흔적이다.

이걸 다 보려면 엔드포인트 보안 이벤트를 수집하고 있어야 한다. 안 하고 있으면 나중에 무슨 일이 있었는지 되짚을 방법이 없다. 내가 세워둔 감시 훅들이 넉 달간 한 번도 발화하지 않았던 것을 뒤늦게 안 적이 있는데, 그때 배운 건 안 울리는 감시와 없는 감시가 화면상 같아 보인다는 것이었다. 여기도 같다. 오늘 이후 이 맥에 누가 붙었는지 나는 확인할 방법이 없다.

오늘 남은 것

정확히 말하면 오늘 회사에서 일어난 일은 보안 사고가 아니었다. 아무도 안 뚫렸다.

일어난 일은 이렇다. 수천 대의 맥이 몇 GB짜리 파일을 동시에 받았고, 그동안 다른 일이 느려졌고, 그 대가로 CVSS 9.8짜리 인증 우회가 닫혔다. 이건 좋은 거래다. 채굴기가 깔리고 전체 디스크가 열리는 것보다 낮 몇 시간 느린 게 훨씬 낫다.

다만 그 거래를 더 싸게 할 수 있었다. 대상을 셌으면 됐고, 콘텐츠 캐싱을 켰으면 됐다. 둘 다 오늘 아침에 결정할 수 있는 일이었지 새로 만들어야 하는 기술이 아니었다.

그리고 나 개인에게 남은 건 다른 것이다. 나는 오늘 패치 대열에 있었고, 끝냈고, 안전해졌다고 생각했다. 그 상태에서 명령 두 줄을 쳤더니 포트가 열려 있고 방화벽이 꺼져 있었다. 패치는 이번 구멍을 막은 것이지 내 맥의 노출 면적을 줄인 게 아니었다.

패치를 끝냈다는 감각과 안전해졌다는 감각이 붙어 있는 게 문제다. 앞의 것은 오늘 확실히 일어났고, 뒤의 것은 오늘 아무 근거 없이 따라왔다.

이 둘이 붙어 있으면 다음번에도 같은 순서로 간다. 뉴스가 뜨고, 급하게 받고, 네트워크가 느려지고, 끝났다고 생각하고, 그 상태로 몇 달이 지난다.

내 경우 그 몇 달이 넉 달 반이었다. 그런데 내가 그동안 몰랐던 건 화면 공유가 켜져 있다는 사실이 아니다. 그건 내가 켰고 알고 있었다. 몰랐던 건 그게 어느 범위까지 열려 있는지, 그리고 방화벽이 꺼진 채였다는 것이다. 켰다는 기억이 있으면 확인했다고 착각하기 쉽다.

떼어놓는 방법은 하나뿐이다. 열어보는 것이다. 명령 한 줄이면 된다. 나는 오늘에서야 쳐봤고, 이 글은 그 결과가 예상과 달라서 쓰게 됐다. 화면 공유는 안 끈다. 방화벽은 켤 것이다.

---

참고 자료: 헌트리스 기술 분석 — CVE-2026-43760과 CVE-2026-65400 · The Hacker News 보도 · Malwarebytes 경고 · SecurityWeek 보도 · 애플 보안 업데이트 안내 (macOS Sequoia 15.7.9)