접속하는 쪽이 당한다 — libssh2 CVE-2026-55200와 클라이언트 SSH의 사각지대

이미지 출처: The Hacker News

SSH 보안이라고 하면 대개 '서버를 어떻게 지키느냐'를 떠올림. 키 관리, 비밀번호 로그인 차단, fail2ban, 포트 바꾸기 같은 것들 말임. 그런데 libssh2의 이번 결함은 방향이 정반대임. 접속을 거는 쪽, 즉 클라이언트가 공격 표적이 되는 케이스라 평소 머릿속에 그려둔 위협 모델이 그대로 안 통함. libssh2는 git이나 각종 자동화 도구, 백업 스크립트, 모니터링 에이전트 안에 조용히 박혀 동작하는 클라이언트용 SSH 라이브러리인데, 이번에 공개 PoC까지 나오면서 "내가 접속한 서버가 나를 친다"는 시나리오가 탁상공론이 아니게 됨.

핵심 요약

• libssh2는 수많은 프로그램 속에 내장된 클라이언트용 SSH 라이브러리이고, CVE-2026-55200은 서버가 아니라 접속하는 클라이언트 쪽에서 터지는 결함임.
• 악의적이거나 이미 침해된 서버에 붙는 순간 클라이언트가 당하는 구조여서, PoC 공개로 위험이 실전 단계로 넘어옴.
• 방어 핵심은 라이브러리·의존성 업데이트, 신뢰할 수 없는 서버로의 자동 접속 차단, 그리고 내 환경 어디에 libssh2가 숨어 있는지 파악하는 것임.

libssh2가 뭐길래 — '서버'가 아니라 '클라이언트'가 문제

libssh2는 SSH 서버를 돌리는 OpenSSH와는 결이 다름. 프로그램이 다른 호스트에 SSH로 '붙으러 갈 때' 쓰는 C 라이브러리임. 그래서 사용자가 직접 콘솔에 입력하기보다, 개발 도구나 배포 파이프라인, 자동 동기화 작업이 백그라운드에서 호출하는 경우가 훨씬 많음. 문제는 SSH 핸드셰이크와 키 교환 과정에서 클라이언트가 서버가 보내준 데이터를 신뢰하고 파싱한다는 점임. 정상적인 서버라면 규격에 맞는 응답을 주지만, 공격자가 서버를 통제하고 있다면 일부러 비뚤어진 응답을 던져 클라이언트 측 파싱 로직을 무너뜨릴 수 있음. 이런 류의 메모리 안전성 결함은 C로 짠 프로토콜 라이브러리에서 반복적으로 등장해 온 단골 패턴임.

클라이언트 측 취약점이 왜 더 까다로운가

서버 취약점은 '내가 지키는 한 대'에 집중하면 됨. 반면 클라이언트 측은 표면이 넓고 흩어져 있음. 같은 라이브러리가 개발자 노트북, CI 러너, 사내 자동화 봇, 컨테이너 이미지 등 곳곳에 복제돼 박혀 있기 때문임. 게다가 접속 대상 서버를 항상 내가 고르는 것도 아님. 의존성을 끌어오는 과정, 미러 서버, 리다이렉트된 호스트 등 '나도 모르게 붙게 되는' 경로가 존재함. 공격자 입장에서는 악의적 서버 하나만 세워두고 피해자가 알아서 접속해 오기를 기다리면 되는 구조라, 표적형보다 광범위한 함정형 공격에 어울림. 그래서 "우리 서버는 외부에 안 열려 있어서 괜찮다"는 통념이 여기선 안전 보장이 못 됨.

PoC 공개가 의미하는 것

개념 증명 코드가 공개됐다는 건 단계가 한 칸 넘어갔다는 신호임. 이전까지는 "이론적으로 가능"이었다면, 이제는 분석할 줄 아는 사람이 동작 원리를 그대로 따라 해볼 수 있는 재료가 풀린 셈임. 공격 재현 자체를 여기서 자세히 풀 생각은 없음. 다만 방어자 관점에서 기억할 포인트는 두 가지임. 첫째, PoC가 돌아다니기 시작하면 스캐닝·악용까지의 시간차가 급격히 짧아짐. 둘째, 정확한 CVSS 점수나 영향 범위 같은 세부 수치는 공식 권고문을 직접 확인하는 게 맞고, 숫자보다 먼저 "내 환경에 이 라이브러리가 어디 들어 있나"를 파악하는 게 실질적인 첫 단추임.

방어자·학습자를 위한 점검 체크리스트

• 자산 식별이 먼저: 패키지 매니저로 libssh2가 직접/간접 의존성으로 끌려 들어온 곳을 훑음. git 클라이언트, 언어별 SSH 바인딩, 컨테이너 베이스 이미지 안까지 봐야 함.
• 업데이트가 본질적 해법: 배포판·벤더의 패치 버전으로 올리는 게 가장 확실함. 직접 빌드해 쓰는 경우라면 정적 링크된 바이너리까지 다시 빌드해야 누락이 없음.
• 신뢰 경계 점검: 자동화가 '아무 서버에나' 붙도록 방치돼 있지 않은지 봄. 호스트 키 검증을 끄거나 무시하도록 설정된 스크립트가 있다면 그게 바로 함정 서버에 무방비로 걸리는 길임.
• 접속 로그 관찰: 클라이언트가 평소 가지 않던 외부 호스트로 SSH를 맺으려 하거나, SSH 사용 프로세스가 비정상 종료·크래시되는 흔적이 늘면 의심해 볼 만함.
• 최소 권한: 자동화용 SSH 작업을 권한이 낮은 별도 계정·격리된 환경에서 돌리면, 설령 클라이언트가 당해도 피해 반경을 좁힐 수 있음.

마무리

이번 사례의 교훈을 한 줄로 줄이면 이거임. 방어는 '내가 운영하는 서버'에서 끝나지 않고, '내가 무심코 접속하는 모든 곳'까지 이어진다는 것. 개인적으로는 이런 클라이언트 측 결함이 뜰 때마다 의존성 목록을 다시 들춰보는 습관을 들이길 추천함. 평소엔 존재조차 잊고 있던 라이브러리가 의외의 약한 고리인 경우가 많기 때문임. 혹시 여러분 환경에서 libssh2가 어디에 박혀 있었는지 찾아본 경험이 있다면 댓글로 공유해 주면 좋겠음. 같이 점검 목록을 다듬어 가요.