rsync 3.5.2 보안 업데이트: 읽기 전용 미러도 송신자 CPU 고갈을 점검해야 한다

송신자의 과도한 체크섬 계산과 보안 업데이트를 표현한 생성형 개념 이미지다. 실제 제품 화면이나 공격 재현 결과는 아니다.

백업 서버가 파일을 받기만 하는지, 보내기도 하는지부터 확인할 때다. rsync 프로젝트는 November 4, 2026 3.5.2를 공개하면서 CVE-2026-119741을 수정했다. 악의적인 수신자가 보내는 체크섬 정보 때문에 송신자의 CPU 작업이 과도하게 늘어나는 문제다. 공개 미러가 읽기 전용이어도 파일을 내려주는 순간에는 송신자이므로 점검 대상이 된다.

공식 공지에서 확인된 범위

공식 보안 권고는 심각도를 HIGH, 영향을 받는 upstream 버전을 3.5.1까지로 명시한다. 3.5.2는 앞선 CVE-2026-70453 대응 이후 남아 있던 송신 측의 강한 체크섬 계산량에 제한을 둔다. 공개 데몬에 대한 연결을 반복하면 호스트 CPU가 고갈될 수 있다는 것이 프로젝트의 설명이다. rsync 공식 보안 권고

문제는 수신자가 전달한 약한 체크섬이 연속된 롤링 윈도와 충돌하면서, 송신자가 많은 위치에서 강한 체크섬을 다시 계산하게 되는 데 있다. 이번 권고를 곧바로 원격 코드 실행이나 파일 유출 문제로 확대해서 읽으면 안 된다. 여기서 다루는 영향은 계산 자원과 서비스 가용성이다.

공식 릴리스 안내에는 보안 수정 외의 버그 수정과 프로세스 우선순위 기능도 포함되어 있다. 업데이트 대상은 “오래된 3.4 계열”에만 한정되지 않는다. 이미 3.5.1로 올린 환경도 다시 확인해야 한다. 3.5.2 릴리스 안내

1. 클라이언트·서버 이름보다 전송 방향을 본다

운영 목록에 “백업 서버”라고 적혀 있다고 해서 항상 수신자인 것은 아니다. 같은 머신도 작업에 따라 역할이 바뀐다.

로컬 파일을 원격지로 push: 로컬 rsync가 송신자다.

원격지에서 파일을 pull: 원격 rsync가 송신자다.

공개 미러에서 사용자가 다운로드: 미러의 rsync 데몬이 송신자다.

백업 복원 작업: 평소 백업을 받던 머신이 데이터를 보내는 쪽으로 바뀔 수 있다.

push와 pull의 경로 표기는 공식 사용법에서 확인할 수 있다. 각 예약 작업을 실제 데이터 흐름으로 읽어야 패치할 실행 지점을 놓치지 않는다. rsync 전송 방식

읽기 전용 설정도 별도로 해석해야 한다. 데몬의 read only = yes는 업로드를 막는 설정이다. 다운로드를 제공하는 송신 과정까지 없애는 설정은 아니다. 따라서 공개 읽기 전용 미러라는 사실만으로 이번 CPU 고갈 위험을 제외할 수 없다. 이는 공식 권고와 데몬 옵션의 의미를 함께 적용한 운영상 판단이다. rsyncd.conf의 read only

SSH를 사용한다는 사실 역시 패치 확인을 대신하지 않는다. 접근 가능한 상대를 좁히는 것과, 연결된 상대가 제공하는 데이터를 안전하게 처리하는 것은 각각 확인할 사항이다.

2. 실행 파일과 공급자 패치를 함께 확인한다

아래는 현재 셸에서 찾는 실행 파일과 버전을 조회하는 예시다. 설치나 전송을 수행하지 않는다.

출력이 없거나 command not found가 나오면 그 셸에서 실행 파일을 찾지 못한 것이다. 해당 머신 전체에 rsync가 없다는 결론까지 내리지는 않는다. 작업이 실행되는 계정, 컨테이너, CI 러너, 별도 설치 경로가 다를 수 있다.

Debian·Ubuntu 계열에서는 설치된 패키지 빌드도 따로 확인할 수 있다.

RPM 계열의 조회 예시는 다음과 같다.

버전 숫자 하나만으로 최종 판정하지 않는 것이 중요하다. 배포판이나 NAS 공급자가 기존 버전에 수정을 백포트했다면, 공급자의 보안 권고에서 CVE-2026-119741 수정 여부와 해당 패키지 빌드를 대조해야 한다. 반대로 패키지를 갱신했어도 예약 작업이 다른 경로의 rsync를 실행하면 대응은 끝나지 않는다.

다음 정보를 한 줄씩 묶어 기록하면 확인이 쉬워진다.

작업 이름 → 송신 위치 → 실행 파일 경로 → 패키지·이미지 식별자 → 패치 근거 → 실제 적용 확인

장시간 실행 중인 데몬은 디스크의 파일 교체와 실행 중인 프로세스의 교체를 구분한다. 진행 중인 백업과 복원에 미치는 영향을 확인하고, 정해진 운영 절차로 새 바이너리를 사용하도록 전환한다.

3. 당장 갱신하기 어렵다면 노출을 줄이고 잔여 위험을 남긴다

공식 권고가 제시하는 기본 대응은 수정 버전으로의 업그레이드다. 패치 대기 중에는 서비스 요구사항에 맞춰 불필요한 공개 접근을 줄이고, 접속 가능한 상대와 동시 연결 수를 검토할 수 있다.

데몬의 hosts allow는 접속 호스트를 제한하고, max connections는 동시 연결 수를 제한한다. 후자의 기본값 0은 무제한이다. 다만 이 설정들은 체크섬 계산 자체를 수정하지 않으며, 제한값을 과하게 낮추면 정상 백업도 거절될 수 있다. 환경을 보지 않고 그대로 복사할 만능 설정값은 없다. 접근·연결 제한의 공식 설명

CPU 사용률과 작업 시간, 실패·재시도 횟수를 함께 관찰하되 CPU 상승만으로 공격이라고 단정하지 않는다. 큰 파일이나 정상 작업의 동시 실행도 원인이 될 수 있다. 완화 조치를 했다면 “해결 완료” 대신 패치 대기, 접근 제한 적용, 남은 대상을 기록하는 편이 정확하다.

4. 체크섬 옵션과 dry-run을 패치 증거로 혼동하지 않는다

--checksum 또는 -c는 전송 전에 파일 변경 여부를 판단하는 방식을 바꾸는 옵션이다. 이를 사용하지 않는다는 이유만으로 전송 내부의 체크섬 처리 문제가 사라졌다고 판단하면 안 된다.

또한 --dry-run은 실제 파일 데이터를 보내지 않는다. 복사 방향과 변경 예정 목록을 검토하는 데는 유용하지만, 실제 전송 경로의 안전성이나 CPU 고갈 수정 여부를 증명하는 검사가 아니다. checksum과 dry-run의 동작

업데이트 후에는 공격 입력 대신 통제된 테스트 데이터와 허가된 대상으로 회귀 검사를 진행한다.

기존 작업의 옵션과 대상 경로를 검토한다. 운영 원본에 바로 시험하지 않는다.

테스트 전용 원본·대상에서 변경 예정 파일을 확인한다.

실제 소규모 전송을 수행하고 종료 상태와 파일 내용을 확인한다.

대표적인 큰 파일·희소 파일·기존 대상 파일이 있는 경우도 별도 검사한다.

백업 성공뿐 아니라 복원한 파일이 기대한 내용인지 확인한다.

이 절차는 업데이트 이후의 기능 확인이다. 취약점이 수정됐다는 근거는 공급자의 패치 정보와 실제 배포된 바이너리를 연결해서 확보해야 한다.

5. 같은 릴리스의 전송·출력 변경도 검토한다

3.5.2 NEWS에는 중단된 --append·--inplace 전송의 마지막 버퍼 중복 기록 수정과, 기존 목적지 파일이 있을 때의 rrsync 업로드 수정이 포함된다. 이 경로를 쓰는 작업은 재개·복원 시나리오를 우선 점검할 만하다. 공식 3.5.2 변경 내역

사람이 읽는 출력 형식도 바뀐다. 전송률·바이트 수의 단위와 숫자 구분이 달라질 수 있으므로, 콘솔 문자열을 잘라 지표로 쓰는 스크립트가 있다면 파서의 가정도 확인한다. 새 우선순위 옵션이 추가됐다고 해서 우선순위 조정이 이번 보안 패치를 대신하는 것은 아니다.

대응 완료의 기준

패치 근거 확인, 실제 송신 바이너리 갱신, 운영 전환, 대표 작업·복원 검사를 따로 완료 표시하자. “백업 서버 업데이트 완료”라는 한 문장보다, 어떤 방향의 어떤 작업까지 확인했는지 남기는 편이 다음 점검에 도움이 된다.

이 글은 November 6, 2026 한국 시간 기준 공식 자료를 확인한 운영 가이드다. 예시 명령은 조회 방법을 설명하기 위한 것으로, 작성 환경에는 rsync가 없어 전송 실행 검증을 하지 않았다. 취약점 재현이나 실제 서비스 패치 적용도 수행하지 않았다. 배포 직전에는 공급자의 최신 보안 권고와 패키지 제공 상태를 다시 확인해야 한다.