APT CVE-2026-109518, Ubuntu 22.04·24.04 수정 버전

먼저 확인할 내용

• 릴리스·apt 설치 버전과 HTTP 저장소 경로를 확인한다.
• 수정판 설치 중에는 공식 권고대로 재시도를 일시적으로 끈다.
• 설치 후 같은 릴리스의 수정 버전과 다시 비교한다.

패키지를 검증하는 APT에서 왜 root RCE가 가능한가?

문제는 검증을 끄는 옵션이 아니라, 검증한 파일이 설치 전에 달라질 수 있다는 데 있다. Max Justicz가 발견한 이 취약점은 HTTP 리다이렉트와 다운로드 재시도가 겹칠 때 발생하는 하드링크 처리 오류다.[1][3][4]

HTTP 리다이렉트로 서로 다른 패키지 다운로드가 같은 URI를 가리킬 수 있다. 여기에 일시적인 HTTP 서버 오류가 발생해 APT가 다운로드를 재시도하면, 기존 하드링크를 통해 검증이 끝난 패키지 파일까지 공격자가 정한 내용으로 덮어쓸 수 있다. 그 결과 검사를 통과한 파일과 실제로 설치하는 파일의 내용이 달라진다. .deb 패키지 설치 과정에서 스크립트는 root 권한으로 실행되므로 원격 코드 실행으로 이어질 수 있다.[4][5]

업스트림 수정은 대상 파일을 배타적으로 열어 기존 파일을 그대로 덮어쓰지 않도록 한다. 이어받기에 필요한 내용은 새 파일로 복사해 하드링크를 통한 다른 파일의 변경을 차단한다.[7]

Ubuntu는 우선순위를 High, CVSS v4.0 기본 점수를 7.7로 제시한다. 업스트림 메일의 “critical file verification bypass”는 검증 우회에 대한 표현이며, 이를 Ubuntu의 공식 심각도 등급으로 바꿔 읽으면 안 된다.[2][4]

어떤 서버부터 영향 여부를 확인해야 하나?

수정 전 APT를 쓰고, HTTP 통신 조작과 다운로드 재시도가 가능한 서버부터 확인한다. 재시도 기본값은 APT 2.3.2부터 3이며, Ubuntu 22.04 LTS와 Debian 12부터 이 기본값이 적용된다. 이전 릴리스도 관리자가 설정이나 실행 옵션으로 재시도를 켰다면 영향 범위에 들어갈 수 있다. 오래된 릴리스라는 이유만으로 제외하지 않는다.[1][2][6]

다음 세 가지를 함께 점검한다.

• 릴리스와 apt 버전: 해당 릴리스의 수정 버전을 설치했는지 확인한다. 다른 Ubuntu 릴리스의 버전 숫자와 비교하지 않는다.
• 재시도 설정: Acquire::Retries가 0이 아닌지, 자동화 스크립트가 실행 옵션으로 값을 주는지 확인한다.
• 저장소 연결: 패키지를 받는 구간이 HTTP인지, HTTPS인지 확인한다. 경로상 공격자에는 중간자뿐 아니라 악성 미러나 프록시도 포함된다.[2]

이 문제는 APT 라이브러리의 HTTP 백엔드에 있으므로 apt 대신 apt-get이나 aptitude, 그래픽 패키지 관리 도구를 사용한다고 피할 수 있는 것은 아니다. snap은 다른 패키지 관리 체계를 사용하므로 이번 취약점의 대상이 아니다.[1]

다음은 릴리스와 재시도 설정을 보는 보조 점검 명령이다. 아래 두 명령은 이 글의 점검 절차이며 Ubuntu의 해당 CVE 공식 확인 명령과는 구분한다.

cat /etc/os-release
apt-config dump | \
  grep -i Acquire::Retries

apt-config dump에서 값이 출력되지 않는다고 0으로 판정하면 안 된다. 출력에 드러나지 않는 기본 동작과 실제 실행 시 전달하는 옵션을 함께 살펴야 한다. 특히 예약 작업이나 배포 스크립트에 별도의 재시도 옵션이 있는지 확인한다. 이 출력만으로 자동 업데이트의 안전 여부까지 판단하지 않는다.

저장소는 /etc/apt/sources.list와 /etc/apt/sources.list.d/ 아래의 .list, .sources 파일에서 확인한다. 사내 미러에 대한 별도 공식 권고는 확인하지 못했다. 사내망이라는 이유로 제외하기보다는 클라이언트와 미러 사이의 전송 방식, 프록시 구성, 미러의 신뢰 여부를 같은 기준으로 확인하는 편이 낫다.[1][2]

Ubuntu 릴리스별 수정 버전은 무엇인가?

Ubuntu 22.04 LTS는 2.4.15ubuntu0.1, 24.04 LTS는 2.8.4ubuntu0.1이 이번 수정 버전이다. 다른 릴리스는 아래 표에서 같은 릴리스 행과 비교한다. 표는 Ubuntu 보안 공지 USN-8996-1과 CVE 페이지를 기준으로 정리했다.[2][3]

20.04 이하에서는 표의 버전을 일반 업데이트만으로 받을 수 있다고 가정하지 않는다. 필요한 Ubuntu Pro 및 ESM 연결 상태를 확인해야 하며, 16.04와 14.04에는 Legacy 애드온도 필요하다.[1][3]

Debian 서버도 운영한다면 별도로 확인한다. 보안 추적기는 bookworm 수정 버전을 2.6.2, trixie 수정 버전을 3.0.4로 표시한다. Ubuntu용 패키지 버전을 Debian 서버에 적용하는 기준으로 쓰지 않는다.[6]

일반 apt upgrade 대신 어떤 순서로 업데이트하나?

수정판을 받는 설치 작업부터 재시도를 일시적으로 끄고, 설치 후 버전을 다시 확인한다. 패치가 끝나기 전에는 APT 자체가 여전히 취약하므로, 옵션 없는 업그레이드만으로 업데이트 도중의 위험까지 없앴다고 볼 수 없다.[1]

먼저 Ubuntu 블로그의 공식 확인 명령으로 apt 소스 패키지에서 만들어진 설치 패키지를 조회한다. 명령은 모바일에서 읽기 쉽도록 줄바꿈했으며, 줄 끝의 역슬래시는 다음 줄로 명령을 잇는 셸 문법이다.[1]

apt list --installed \
  '?source-package(^apt$)'

그다음 Ubuntu가 권고한 전체 업데이트를 실행한다. 원문의 sudo apt update && sudo apt upgrade -o Acquire::Retries=0과 같은 명령을 줄바꿈한 것이다.[1]

sudo apt update && \
  sudo apt upgrade -o Acquire::Retries=0

apt update는 저장소의 패키지 목록을 갱신하는 단계이고, 뒤의 apt upgrade가 패키지를 내려받아 설치한다. 위 명령에서 재시도를 끄는 옵션은 설치를 수행하는 upgrade에 적용된다. &&로 연결했으므로 앞 단계가 실패하면 뒤의 업그레이드는 실행되지 않는다. 패키지 변경 목록을 확인하고 서비스 운영 절차에 맞춰 설치를 진행한다.

전체 업그레이드가 어려우면 Ubuntu 블로그가 제시한 apt 계열 대상 명령을 사용할 수 있다.[1]

sudo apt update && \
  sudo apt install \
  -o Acquire::Retries=0 \
  --only-upgrade \
  '?source-package(^apt$)'

설치가 끝나면 처음의 apt list --installed 명령을 다시 실행해 apt 계열 패키지의 설치 버전을 확인한다. 같은 릴리스의 수정 버전 또는 해당 릴리스에서 그 수정을 포함한 후속 버전인지 확인하는 것이 종료 기준이다. “업데이트 명령이 성공했다”거나 “최신 상태라고 나왔다”는 메시지만으로 판단하지 않는다.

설치 버전이 표보다 낮은데 수정판이 보이지 않는다면 목록 갱신 오류, 사용 중인 저장소와 업데이트 채널, 구형 릴리스의 Pro·ESM 연결 상태를 먼저 확인한다. 미러 동기화나 서버별 정책 때문에 실제 제공 상태가 다를 수 있으므로, 원인을 확인하지 않은 채 취약점이 해소됐다고 기록하지 않는다.

Ubuntu 블로그는 자동 업데이트가 활성화돼 있으면 수정판 제공 후 24시간 안에 적용된다고 설명한다. 다만 사내에서 서비스를 끄거나 업데이트 정책을 바꿨다면 이 설명만으로 완료를 보장할 수 없다. 자동 적용을 기다리는 경우에도 최종 설치 버전은 직접 확인한다.[1]

HTTPS 전환과 Retries 0은 어디까지 도움이 되나?

HTTPS는 전송 중 통신 조작을 막는 보조 수단이고, 일시적인 재시도 비활성화는 수정판 설치 중에도 사용할 수 있는 공식 완화책이다. 어느 쪽도 수정판 설치를 대신하지는 못한다.[1]

Ubuntu는 경로상 공격 가능성을 배제할 수 없다면 보안 업데이트를 설치하기 전에 TLS를 활성화하는 방식을 설명한다. 저장소 설정을 변경할 때는 기존 파일을 백업하고, 해당 저장소가 HTTPS를 지원하는지 확인한 뒤 URL을 바꾼다. 이후 sudo apt update에서 오류가 없는지 확인한다. 일부 커뮤니티·국가별 미러는 HTTPS를 지원하지 않으며, 공식 Ubuntu 도메인만 변경해도 서드파티 저장소까지 바뀌는 것은 아니다.[1]

HTTPS로 통신한다고 미러 자체가 정상이라는 사실까지 보장되지는 않는다. Ubuntu 블로그는 업데이트 설치 중 Acquire::Retries를 일시적으로 0으로 설정하는 방법을 경로상 공격자와 잠재적인 악성 미러 모두에 대한 완화책으로 제시한다. 따라서 HTTP 경로를 바꾸는 조치와 APT 자체의 수정판 설치를 구분해야 한다.[1]

재시도를 끄면 일시적인 다운로드 실패에도 다시 받지 않으므로 작업이 실패할 수 있다. 우선 설치 명령에 일시 옵션을 적용하고, 실패하면 원인을 확인한 뒤 같은 보호 조건에서 다시 진행한다. 영구 설정 변경은 취약점 대응과 별개로 조직의 업데이트 정책에 맞춰 검토한다.

아직 확인하지 못한 내용은 무엇인가?

이번에 대조한 공식 공지와 메일에서는 실제 악용 사례나 공개 PoC의 존재를 확인하지 못했다. 이는 악용이나 PoC가 없다는 뜻은 아니다. Ubuntu 25.10의 처리 상태, NVD의 점수, Ubuntu 공지의 정확한 게시 시각, 사내 미러 전용 공식 권고도 이번 확인 범위에서는 확정하지 않았다. Ubuntu CVE·USN·블로그가 표시하는 게시일은 2026년 11월 4일이다.[1][2][3][4][5][6]

같은 업데이트에 포함된 다른 범위 밖 메모리 접근 수정 등은 이 글에서 설명한 HTTP 하드링크 검증 우회와 구분한다. 별도 수정 사항을 모두 같은 root RCE 원인으로 묶지 않는다.[4]

Ubuntu 서버의 다른 보안 항목은 패키지별로 배포 상태를 따로 확인해야 한다. 앞서 다룬 Ubuntu CVE-2026-98432, LTS 수정 커널 아직 정식 배포 전은 커널 수정판의 배포 상태를 다룬 글이다. 그 글의 당시 상태와 이번 APT 수정판 제공 여부를 혼동하지 않는다.

이번 작업은 설치 버전 확인 → 재시도를 끈 상태로 수정판 설치 → apt 계열 설치 버전 재확인으로 마무리한다. 서버별로 릴리스, 저장소 연결 방식, 설치 전후 버전을 남겨 두면 누락된 서버를 찾는 데도 도움이 된다.

출처