Tailscale SSH 'Tailworm' 취약점 — 홈랩 대응 가이드

2026년 10월 25일, 보안 연구자가 Tailscale의 SSH 기능에서 발견한 취약점 묶음 Tailworm을 공개하면서 홈랩·셀프호스팅 커뮤니티가 술렁였습니다. 핵심은 "SSH로 로그인만 할 수 있으면 일반 계정이라도 그 서버의 root 권한까지 넘볼 수 있다"는 것. 이 글에서는 Tailworm이 정확히 무엇인지, 왜 위험한지, 그리고 지금 당장 내 홈서버에서 취할 수 있는 대응을 정리합니다.

핵심 요약

Tailworm은 2026-10-25 Cyberdione Labs의 Erica Windisch가 공개한 Tailscale 취약점 묶음으로, 5개 영역 11건의 문제를 담고 있습니다(테스트 버전: Tailscale 1.104.2, headscale 0.29.5).
가장 위험한 것은 Tailscale SSH의 Unix 소켓 포워딩을 통한 root 권한 상승입니다. 포워딩을 tailscaled(root로 동작)가 대신 처리하기 때문에, 로그인 권한만 있는 사용자가 Docker 소켓 같은 root 전용 소켓에 접근할 수 있습니다.
공개 시점 기준 전용 CVE·CVSS 점수·수정 버전이 아직 없었고, Tailscale은 공개 코드에서 수정 작업을 진행 중이라고 밝혔습니다.
check mode는 로그인 단계만 막을 뿐 세션 안에서 일어나는 권한 상승은 막지 못합니다.
당장 할 일: 불필요한 Tailscale SSH 끄기, ACL을 1:1로 좁히기, TS_SSH_DISABLE_FORWARDING 설정, 자동 업데이트 켜기.

Tailscale SSH가 뭐길래

Tailscale은 WireGuard 기반의 메시 VPN으로, 기기들을 하나의 사설 네트워크(tailnet)로 묶어 어디서든 서로 접속하게 해 줍니다. 홈랩에서는 포트 개방이나 DDNS 없이 외부에서 집 서버에 들어가는 용도로 특히 인기가 많습니다.

그중 Tailscale SSH는 tailscale up --ssh 한 줄로 켜는 기능으로, 별도의 SSH 키 관리 없이 tailnet 내부에서 SSH 접속을 열어 줍니다. 누가 어느 기기에 어떤 사용자로 접속할 수 있는지는 Tailscale의 ACL 정책으로 통제합니다. 편의성이 큰 만큼, 이 접속 경로가 뚫리면 영향도 큽니다.

Tailworm — 무엇이 문제인가

Tailworm의 중심에는 SSH Unix 소켓 포워딩 문제가 있습니다. 메커니즘을 단계로 풀면 이렇습니다.

Tailscale SSH로 들어온 사용자가 로컬 Unix 소켓 포워딩을 요청합니다.
이 포워딩을 실제로 수행하는 주체는 로그인한 그 사용자가 아니라 root로 돌아가는 tailscaled 데몬입니다.
그 결과 일반 사용자가 원래라면 닿을 수 없는 root 전용 소켓(예: Docker 소켓, tailscaled 로컬 API)에 접근할 수 있게 됩니다.

왜 "경쟁 상태(race condition)"가 핵심인가

Tailscale은 과거 비슷한 문제를 보안 공지 TS-2026-004에서 한 차례 수정했습니다. 소켓 경로가 실제로 어디를 가리키는지 검증하도록 보강한 것입니다. 하지만 Tailworm은 검증하는 시점과 실제로 사용하는 시점 사이에 경로를 바꿔치기(TOCTOU, time-of-check to time-of-use) 하는 경쟁 상태로 이 검증을 우회합니다. 즉, "확인할 땐 안전한 경로, 쓸 땐 위험한 경로"로 바꾸는 타이밍 공격입니다.

왜 홈랩에서 특히 무서울까요? 많은 홈서버가 Docker를 같은 머신에서 돌리고 있기 때문입니다. Docker 소켓에 접근할 수 있다는 것은 사실상 그 호스트의 root를 쥐는 것과 같습니다. 컨테이너를 root 권한으로 띄우고 호스트 파일시스템을 마운트하는 것이 가능해지니까요.

공개 방식과 현재 상태

연구자는 수정 패치를 기다리지 않고 공개했습니다(비협조적 공개). 공개 시점 기준으로 전용 CVE 번호도, CVSS 점수도, 공식 수정 릴리스도 없는 상태였으며, Tailscale은 공개 저장소 코드에서 수정을 진행 중이라고 밝혔습니다. 또한 Tailworm은 소켓 포워딩 외에도 세션 교체, 앱 커넥터, tailscale serve, headscale/릴레이 관련 등 5개 영역에 걸친 11건을 함께 다룹니다.

참고: 이 사안은 "SSH 접속 권한이 이미 있는 사용자"가 전제입니다. 아무나 인터넷에서 바로 공격할 수 있는 형태는 아니며, tailnet 안에서 SSH가 허용된 사용자가 권한을 넘어서는 시나리오입니다. 다만 공유 tailnet, 팀 계정, 탈취된 기기 등을 고려하면 결코 가볍게 볼 문제는 아닙니다.

check mode는 왜 해법이 아닌가

Tailscale SSH에는 세션 시작 전에 추가 인증(로그인 확인)을 요구하는 check mode가 있습니다. 평소엔 유용한 안전장치지만, Tailworm 문제에는 한계가 분명합니다. check mode는 "로그인을 허용할지"만 판단하고, 일단 세션이 열린 뒤 그 안에서 벌어지는 소켓 포워딩·권한 상승은 관여하지 않습니다. 즉, 정상적으로 로그인 권한이 있는 사용자가 세션 내부에서 권한을 끌어올리는 이번 공격은 check mode로 막히지 않습니다.

지금 당장 할 일 — 홈랩 체크리스트

조치	방법	효과
불필요한 SSH 끄기	꼭 필요한 기기에서만 `tailscale up --ssh` 사용, 나머지는 해제	공격 표면 축소
ACL 좁히기	광범위한 태그·autogroup 대신 "특정 사용자 → 특정 호스트" 1:1 규칙	접근 가능 사용자·대상 최소화
소켓/포트 포워딩 끄기	`tailscaled` 서비스에 `TS_SSH_DISABLE_FORWARDING=true` 설정	포워딩 경로 자체 차단
자동 업데이트 켜기	기기에서 auto-update 활성화	수정 릴리스가 나오면 자동 적용

구체적으로 포워딩이 필요 없다면, systemd 환경에서 tailscaled 서비스에 다음 환경변수를 추가하는 방식이 권장됩니다(공식 권고 설정).

# 예시: /etc/default/tailscaled 또는 서비스 Environment 항목
TS_SSH_DISABLE_FORWARDING=true

설정 후 tailscaled를 재시작해 반영합니다. 그리고 Docker를 돌리는 호스트에서는 Tailscale SSH 허용을 특히 보수적으로 가져가세요. 꼭 필요하지 않다면 그 머신에서는 Tailscale SSH를 끄고, 전통적인 OpenSSH + 키 인증으로 접속 경로를 분리하는 것도 방법입니다.

내 환경 점검 질문 3가지

지금 --ssh가 켜진 기기 중에 Docker 소켓이 열려 있는 머신이 있는가?
ACL에서 SSH 접속을 "모두 → 모두"에 가깝게 넓게 열어 두지 않았는가?
자동 업데이트가 꺼져 있어, 수정판이 나와도 수동으로 올려야 하는 기기가 있는가?

정리

Tailworm은 "SSH 로그인 권한 = 그 서버의 최고 권한"으로 이어질 수 있다는 점에서, Tailscale SSH를 즐겨 쓰는 홈랩·셀프호스팅 사용자가 반드시 챙겨야 할 사안입니다. 공개 시점 기준 전용 수정판이 없고 check mode로도 막히지 않으므로, 지금은 "접근 범위를 좁히고 포워딩을 끄는" 설정 기반 방어가 현실적인 대응입니다. 불필요한 SSH를 끄고, ACL을 1:1로 조이고, TS_SSH_DISABLE_FORWARDING을 적용하고, 자동 업데이트를 켜 두세요. 공식 수정 릴리스가 올라오면 가능한 한 빨리 업데이트하는 것이 마지막 한 조각입니다.

Tailscale SSH 'Tailworm' 취약점 정리와 대응법