리눅스 RefluXFS의 새로운 취약점, 재부팅 후에도 지속되며 로그에 기록되지 않아

오늘 오후 생방송: 리눅스 패치 전문가와 함께 RefluXFS 취약점을 심층 분석합니다 . 최신 벤더 대응 현황과 재부팅 없이 이 취약점을 해결하는 방법도 다룹니다. 여기에서 시청하세요 →

요약

전체 버전으로 이동 ↓

설명: CVE-2026-64600으로 등록된 RefluXFS는 리눅스 커널의 XFS 쓰기 시 복사(copy-on-write) 경로에서 발생하는 경합 조건입니다. 이 취약점을 통해 권한이 없는 로컬 사용자가 심볼릭 링크된 복사본에 대한 쓰기 작업을 원본 파일의 물리적 디스크 블록으로 다시 리디렉션할 수 있게 되며, 결과적으로 공격자는 읽기 권한은 있지만 쓰기 권한이 없는 루트 소유 파일을 변조할 수 있습니다. 자세한 내용 보기 →

영향: 로컬 권한 상승을 통해 루트 권한 획득. Qualys는 기본 설정의 엔터프라이즈 리눅스에서 /etc/passwd 및 setuid-root 바이너리를 대상으로 이 취약점을 시연했으며, 기본 설정의 RHEL 10.2 시스템에서 단 몇 초 만에 루트 계정의 암호 보호를 해제했습니다. 이 쓰기 작업은 일반적인 inode 쓰기 경로 아래에서 이루어지기 때문에 대상 파일의 소유자, 권한, 타임스탬프 및 setuid 비트를 유지할 수 있으며, 재부팅 후에도 유지되고, Qualys의 테스트에서는 커널 로그 출력이 발생하지 않았습니다. 자세한 내용 보기 →

위험도: 이 글을 작성하는 시점에서는 공개된 CVSS 점수가 확인되지 않았습니다. 그럼에도 불구하고 이 취약점을 높은 우선순위로 취급해야 합니다. 악용이 확실하며, 일반적인 로컬 계정만으로도 충분하고, 일반적인 보안 강화 조치를 우회할 수 있으며, 지속적인 루트 권한을 획득할 수 있기 때문입니다. 레드햇은 이 취약점을 ‘중요(Important)’ 등급으로 평가하고 있습니다. 자세한 내용으로 이동 →

영향을 받는 대상: 취약한 XFS 코드가 포함되어 있으며 수정 패치가 적용되지 않은 버전 4.11 이상의 리눅스 커널에서, reflink 지원을 통해 생성된 XFS 파일 시스템 상에 읽기 전용 보호 파일과 공격자가 쓰기 권한을 가진 디렉터리가 동일한 파일 시스템을 공유하는 경우입니다. 이는 RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux 8, 9, 10은 물론, Fedora Server 31 이상, Amazon Linux 2023, 그리고 2022년 12월 이후의 Amazon Linux 1 이미지의 기본 레이아웃에 해당합니다. RHEL 7은 XFS reflink가 도입되기 전 버전으로, 이번 취약성의 기본 적용 대상에서 제외됩니다. 자세한 내용으로 이동 →

상태: 2026년 7월 22일 Qualys에 의해 공개되었으며, Anthropic의 Project Glasswing을 통해 AI의 도움을 받아 발견되었습니다. 업스트림 수정 사항은 7월 16일에 병합되었으며, 벤더들은 백포트된 커널을 배포했습니다. 일부 기업용 수정 사항은 공개 전에 일반 커널 업데이트 형태로 배포되었으므로, 업데이트에 CVE-2026-64600이 명시되지 않았더라도 호스트에 이미 수정 사항이 적용되어 있을 수 있습니다. 자세한 내용으로 이동 →

지금 바로 조치하세요: 위험이 전혀 없는 구성상의 우회 방법은 없습니다. 레드햇(Red Hat)은 SystemTap을 통한 임시 완화 조치를 공개했지만, 진정한 해결책은 패치된 커널을 적용하는 것입니다. 각 XFS 파일 시스템이 reflinks를 사용하는지 확인하고, 사용 중인 릴리스에 맞는 수정된 커널을 적용한 후 재부팅하거나, KernelCare의 재부팅 없이 적용되는 패치 (백그라운드에서 사용자에게 자동으로 배포됨)를 적용하세요. 자세한 내용 보기 →

xfs_info / | grep reflink=

reflink=1의 결과는 파일 시스템 전제 조건이 충족됨을 확인해 줍니다. 보호된 파일과 공격자가 쓰기 가능한 디렉터리를 모두 포함하고 있는 다른 마운트된 XFS 볼륨에 대해서도 이 과정을 반복하십시오.

RefluXFS는 파일 시스템이 보장하는 가장 기본적인 원칙 중 하나를 위반합니다. 즉, 보호된 파일을 읽을 수 있다고 해서 해당 파일을 다시 쓸 수 있는 것은 아닙니다.

공격자는 /etc/passwd나 setuid-root 바이너리를 쓰기 모드로 열지 않습니다. 리눅스는 이를 단호히 거부할 것이기 때문입니다. 대신 공격자는 XFS에 요청하여 자신이 제어하는 위치에 해당 파일의 참조 링크 복사본을 생성한 다음, 그 복사본을 대상으로 두 번의 직접 쓰기 작업을 동시에 시도합니다. 커널 내부의 오래된 블록 매핑으로 인해, 이 두 쓰기 작업 중 하나는 복사본이 아닌 원래의 보호된 파일에 반영될 수 있습니다. 공격자는 자신이 제어하는 파일에 쓰기를 수행하지만, 루트 소유의 원본 파일이 변경되는 것입니다.

이 하나의 프리미티브만으로도 루트 비밀번호를 지우거나, 인증 데이터를 재작성하거나, setuid-root 바이너리에 공격자 코드를 심어 루트 권한으로 실행되도록 만들 수 있습니다. 기본 설정의 RHEL 10.2 설치 환경에서 Qualys는 이를 단 몇 초 만에 수행했습니다.

특히 라이브 스트리밍 토론과 관련해 한 가지 세부 사항에 주목할 필요가 있습니다. RefluXFS는 Anthropic의 ‘Project Glasswing’에서 발견되었습니다. Qualys는 Claude Mythos Preview에게 커널을 지목하고 ‘Dirty COW’ 스타일의 레이스 조건을 찾아내도록 요청했으며, 이후 Qualys의 연구원들이 해당 결과를 재현하고 모든 주장을 검증한 뒤, 조율된 공개 절차를 진행했습니다. AI가 취약점 탐색을 가속화했고, 인간이 이를 확인하고 공개한 것입니다. 이를 단순히 버튼을 누르기만 하면 되는 악용 사례로 보지 말고, 커널 버그 발견이 앞으로 나아갈 방향에 대한 미리보기로 받아들여야 합니다.

이 정도 낮은 우선순위로 등록하고 싶은 유혹을 주는 두 가지 이유가 여전히 있습니다. 첫 번째는 원래 공급업체 업데이트의 설명 문구입니다. 이 업데이트는 단순히 “XFS 데이터 손상” 수정 사항으로 배포되었으며, 마치 데이터 무결성 관련 사소한 문제처럼 읽힙니다. 이는 신뢰할 수 있는 로컬 루트 기본 기능입니다. 두 번째는 reflink 자체인데, 이는 아무도 활성화하지 않는 생소한 옵션처럼 들립니다. 하지만 reflink는 수년 동안 RHEL 계열 루트 파일 시스템의 mkfs 기본값으로 사용되어 왔기 때문에, 기본 설정 상태의 시스템에서는 별다른 설정 없이도 이미 해당 조건을 충족하고 있습니다.

XFS의 참조 링크(reflinks)를 사용하면 데이터를 중복 저장하지 않고도 두 파일이 동일한 물리적 디스크 블록을 가리키도록 할 수 있습니다. 한 파일에 데이터가 기록될 때, XFS는 쓰기 시 복사(copy-on-write) 방식을 적용합니다. 즉, 변경된 파일에 대해 새로운 블록을 할당하고, 데이터를 복사한 뒤 해당 파일을 재매핑하며, 원래 블록의 참조 횟수를 0으로 만듭니다. 이때 원래 파일은 변경되지 않은 상태로 유지됩니다.

RefluXFS는 두 개의 쓰기 작업이 해당 순서를 동시에 처리하려고 할 때 발생하는 현상입니다.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

취약한 코드는 inode 잠금 상태에서 파일의 데이터 포크를 읽은 다음, 트랜잭션 로그 공간을 확보하기 위해 잠금을 해제합니다. 이 간극 동안, 두 번째 쓰기 작업자가 자신의 복사-쓰기(copy-on-write) 주기를 완료하고, 복제본을 새로운 블록으로 재매핑하며, 원본 블록의 참조 횟수를 1로 낮출 수 있습니다. 첫 번째 쓰기 작업자가 잠금을 다시 획득하면, 해당 블록이 여전히 공유 상태인지 재확인하지만, 잠금이 해제되기 전에 캡처한 물리적 주소를 기준으로 확인합니다. 이 주소는 더 이상 유효하지 않은 데이터 포크 매핑입니다. XFS는 참조 횟수가 1인 것을 확인하고, 해당 블록이 비공개라고 판단하여, 비록 그 블록이 이제 보호된 소스 파일에만 속해 있음에도 불구하고 그 블록에 데이터를 기록합니다.

O_DIRECT는 페이지 캐시를 우회하기 때문에 재검증이 이루어지지 않고 쓰기 작업이 디스크로 바로 전송됩니다. 이는 inode 잠금 주기를 거치는 동안 ‘검증 시점’과 ‘사용 시점’ 간의 경합 현상입니다. 권한 확인 자체는 결코 틀린 적이 없습니다. 커널이 단순히 유효 기간이 지난 블록 주소에 대해 작업을 수행했을 뿐입니다.

이 수정 사항은 XFS가 잠금이 해제된 동안 매핑이 변경되었을 가능성이 있음을 감지한 후, 데이터 포크 매핑을 다시 읽도록 합니다:

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

Qualys의 분석 보고서에 따르면, 잠금 해제 오류는 xfs_reflink_allocate_cow() 함수에서 발생합니다. “xfs: ILOCK 순환 후 데이터 포크 매핑 재샘플링”이라는 제목의 메인라인 커밋은 7월 16일에 병합되었으며, 이 커밋은 영향을 받는 CoW 헬퍼 함수에서 매핑을 재샘플링합니다. 이 커밋은 디스크 상의 형식이나 커널 데이터 구조의 레이아웃을 변경하지 않는데, 이는 나중에 재부팅 없이 패치를 적용하는 데 중요한 요소입니다.

덮어쓰기는 블록 계층에서 이루어지며, 보호된 파일의 일반적인 inode 수준 쓰기 경로를 우회합니다. 이로 인해 파일 변경 감지에 일반적으로 사용되는 여러 신호가 무력화됩니다:

• 대상 파일은 원래 소유자와 권한 모드를 그대로 유지합니다.
• setuid 비트가 그대로 유지되므로, 조작된 setuid-root 바이너리는 여전히 루트 권한으로 실행됩니다.
• 해당 타임스탬프가 변경 사항을 반영할 필요는 없습니다.
• 경로 기반 파일 활동 모니터링은 보호 대상 자체에 대한 쓰기 작업을 기록하지 못할 수도 있습니다.
• 수정된 데이터는 재부팅 후에도 디스크에 남아 있습니다.
• Qualys에서는 이에 상응하는 커널 경고나 로그 항목을 확인하지 못했습니다.

이것이 바로 RefluXFS가 일시적인 메모리 손상 버그보다 더 위험한 이유입니다. 이는 디스크 상에 영구적으로 변경을 가하는 기본 기능으로, 방어자가 예상하는 대부분의 신호를 건드리지 않습니다. 파일 내용을 해시 처리하는 파일 무결성 도구는 여전히 이를 탐지할 수 있지만, 메타데이터나 경로 기반 감사 기록, 커널 경고를 의존하는 도구들은 이를 탐지하지 못할 것입니다.

다음 세 가지 조건이 모두 충족되어야 합니다:

1. 이 시스템은 4.11 이상 버전을 기반으로 하지만, 해당 수정 사항이 적용되지 않은 취약점이 있는 리눅스 커널을 실행하고 있습니다.
2. 해당 XFS 파일 시스템은 reflink 기능을 지원하도록 생성되었습니다.
3. 읽기 전용으로 보호된 대상과 공격자가 쓰기 권한을 가진 디렉터리가 동일한 파일 시스템에 위치해 있습니다.

루트 파일 시스템과, 신뢰할 수 없는 로컬 코드가 실행될 수 있는 모든 마운트된 XFS 볼륨을 확인하십시오. 루트 볼륨이 노출되지 않았더라도 별도의 데이터 볼륨이 노출될 수 있기 때문입니다:

xfs_info / | grep reflink=

출력에 reflink=1이 포함되어 있다면, 파일 시스템 전제 조건이 충족되었음을 의미합니다.

Qualys는 Fedora Server 31 이상, Amazon Linux 2023, 그리고 2022년 12월 이후 출시된 Amazon Linux 2 AMI와 함께, RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux 8, 9, 10을 흔히 영향을 받는 엔터프라이즈 배포판으로 꼽았습니다.

데비안(Debian), 우분투(Ubuntu), SLES, openSUSE 및 페도라 워크스테이션(Fedora Workstation)은 기본적으로 루트 파일 시스템에 XFS를 사용하지 않으며, 관리자가 reflink가 활성화된 XFS를 선택한 경우에만 해당 기능이 노출됩니다. RHEL 7 파일 시스템은 XFS reflink 지원이 도입되기 이전에 개발된 것으로, 여기에서 설명하는 기본 노출 범위에 포함되지 않습니다.

“안전”하다고 스스로 합리화하려고 하지 마십시오. 이 경합은 대상 블록이 공유되지 않은 상태로 시작될 때만 발생하기 때문에, 이미 reflink로 복사한 파일은 영향을 받지 않을 것이라고 추측하기 쉽습니다. 하지만 권한이 없는 사용자도 해당 상태를 재설정할 수 있으며, setuid-root 바이너리의 경우 애초에 reflink로 복사되었을 가능성이 낮습니다. 이러한 겉보기상의 제한은 신뢰할 수 있는 안전 경계를 제공하지 않습니다.

저희 커널 팀은 다음 빌드에서 해당 취약점을 재현했으며, 해당 벤더 빌드에 수정 사항이 반영되었음을 확인했습니다:

이것들은 특정 릴리스에 대한 보안 권고입니다. 적용 범위는 각 스트림별로 다르므로, 인근 버전을 기준으로 추측하지 말고 해당 릴리스에 대한 보안 권고를 직접 확인하시기 바랍니다.

기본 엔터프라이즈 리눅스 레이아웃으로 인해 공격이 용이해진다

‘동일 파일 시스템’이라는 요구 사항은 다소 제한적으로 들릴 수 있습니다. 하지만 일반적인 기업용 설치 환경에서는 그렇지 않습니다. 기본 설정인 단일 루트 XFS 레이아웃을 사용하면 이 모든 것이 하나의 볼륨에 배치되기 때문입니다:

• /usr/bin 디렉터리 아래에 있는 루트 소유의 실행 파일
• /etc 디렉토리 아래의 인증 데이터
• 전 세계 사용 권한이 있는 /tmp
• /home 아래의 사용자 홈 디렉터리

이로 인해 권한이 없는 사용자에게도 reflink가 활성화된 동일한 파일 시스템 내에서 읽기 가능한 중요한 대상과 쓰기 가능한 임시 공간이 모두 제공됩니다. 이러한 상황이 발생할 수 있는 환경을 상상해 보세요. 공유 빌드 호스트, 최근 머지 요청에서 푸시된 내용을 실행하는 CI 러너, 컨테이너화되거나 제한된 워크로드가 동일한 호스트의 XFS 파일 시스템 내 적절한 경로에 접근할 수 있는 멀티테넌트 노드, 신뢰할 수 없는 종속성을 실행하는 개발자용 컴퓨터 등이 있습니다. 이러한 모든 경우에서, 익스플로잇을 실행하기 위해서는 일반 계정만으로도 충분합니다.

이는 호스트 로컬 권한 상승이며, 원격 코드 실행이나 게스트에서 하이퍼바이저로의 탈출이 아닙니다. 공격자는 먼저 로컬 코드 실행 권한을 확보해야 합니다. 일단 권한을 확보하면, RefluXFS는 그 발판을 이용해 호스트의 루트 권한을 획득합니다.

일반적인 리눅스 보안 강화 조치로는 이를 막을 수 없는 이유

RefluXFS는 일반적인 커널 메모리 손상 익스플로잇이 아닙니다. 이 익스플로잇은 정상적인 파일 시스템 작업을 악용하여 쓰기 작업을 잘못된 물리적 블록으로 유도하기 때문에, 많은 일반적인 방어 수단이 이를 탐지하지 못합니다:

• SELinux: Qualys는 SELinux가 ‘Enforcing’ 모드로 설정된 상태에서 이 취약점을 악용하는 과정을 재현했습니다.
• KASLR, SMEP, SMAP: 이 기능들은 파일 시스템 블록 할당이 아닌 메모리 손상 경로를 방지하므로, 절대 작동하지 않습니다.
• 커널 잠금: 권한이 없는 사용자의 일반 리플링크 또는 직접 I/O 작업에는 어떠한 제한도 가하지 않습니다.
• 컨테이너와 네임스페이스: 이들은 취약한 파일 시스템 경로에 대한 액세스를 자동으로 차단하지 않습니다.
• Seccomp: 일반적인 프로필은 공격자가 사용하는 일반적인 파일 작업을 허용합니다.
• 업데이트 없이 재부팅할 경우: 손상된 파일이 그대로 남아 있으며, 동일한 취약점이 있는 커널로 부팅하면 해당 취약점이 여전히 노출됩니다.

특별한 기능은 필요하지 않습니다. CAP_SYS_ADMIN 권한도, 특권 네임스페이스도, 특수한 하드웨어도, 사용자 정의 커널 구성도 필요하지 않습니다. XFS, reflink 및 동일 파일 시스템에 대한 전제 조건은 여전히 적용되지만, 해당 조건들은 영향을 받는 많은 엔터프라이즈 리눅스 설치 환경에서 기본적으로 충족되어 있습니다.

위험이 전혀 없는 구성상의 해결책은 없지만, 레드햇은 임시적인 런타임 완화 조치를 공개했습니다.

reflink는 XFS 파일 시스템을 생성할 때 선택됩니다. 기존 reflink=1 파일 시스템을 reflink가 적용되지 않은 파일 시스템으로 변환하는 마운트 옵션이나 sysctl은 없으며, 파일 시스템을 다시 생성하는 것은 운영 환경에서 긴급 대응책이 될 수 없습니다. su, sudo 또는 pkexec에서 setuid 비트를 제거하면 정상적인 작동이 중단되므로, 이는 적절한 해결책이 아닙니다.

Red Hat 제품 보안 팀은 XFS reflink 진입점을 차단하고 reflink 작업이 ‘지원되지 않는 작업’ 오류를 반환하도록 강제하는 임시 SystemTap 완화 조치를 발표했습니다. kprobes를 사용해도 유사한 접근 방식이 가능합니다. 이 방법은 취약한 reflink 경로를 차단하지만, 파일 시스템의 동작을 변경하므로 reflink 복제를 사용하는 애플리케이션에 영향을 미칠 수 있으므로, 먼저 테스트 환경에서 검증하시기 바랍니다. 이 조치는 즉시 패치를 적용할 수 없는 시스템을 위한 임시 보호 수단으로 간주해야 하며, 수정된 커널을 대체하는 것으로 간주해서는 안 됩니다.

진정한 해결책은 커널을 수정하는 것이며, 재부팅을 하든 안 하든 상관없습니다.

커널 패키지를 설치한다고 해서 메모리에서 이미 실행 중인 커널이 변경되지는 않습니다. 일반적인 벤더 업데이트의 경우, 사용 중인 릴리스와 정확히 일치하는 커널 업데이트를 설치한 후 재부팅하고, 해당 커널로 정상적으로 부팅되었는지 확인하십시오.

uname -r

위에 나열된 특정 스트림의 경우, 테스트를 거친 고정 빌드는 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8 및 6.12.0-211.34.1.el10_2입니다. 사용 중인 커널이 해당 배포판, 스트림 및 아키텍처에 대한 보안 권고 사항과 일치하는지 확인하십시오.

피해야 할 함정이 두 가지 있습니다. 디스크에 있는 최신 패키지를 기준으로 판단하지 말고, 실행 중인 커널을 기준으로 판단하십시오. 또한 7월 16일 이후에 빌드된 모든 커널에 수정 사항이 포함되어 있다고 가정해서는 안 됩니다. 배포판 버전 번호가 업스트림 릴리스와 일치하지 않을 수 있고, 일부 스트림에서는 이 수정 사항을 더 일찍 백포트했기 때문입니다. 해당 스트림에 대한 공급업체 권고 사항을 통해 확인하십시오. 일부 공급업체는 CVE가 공개되기 전에 수정 사항을 배포했기 때문에, CVE를 기준으로 하는 스캐너만으로는 과거 패치 상태에 대한 전체적인 상황을 파악하지 못할 수도 있습니다.

재부팅 없는 패치 적용

RefluXFS는 재부팅 없이 패치를 적용하는 데 매우 적합합니다. 이 수정 사항은 XFS 코드가 inode 잠금을 순환한 후 블록 매핑을 갱신하는 방식에 대한 집중적인 변경 사항으로, 디스크 포맷 변경이나 시스템 전반에 걸친 커널 데이터 구조 대체가 필요하지 않습니다.

Qualys의 공개 권고문은 수정된 커널을 설치하고 시스템을 재부팅할 것을 권장하며, 기존 활성 파일 시스템에서는 reflink를 비활성화할 수 없다는 점을 정확히 지적하고 있습니다.

KernelCare는 다른 수정 방식을 취합니다. 즉, reflink를 비활성화하거나 파일 시스템 구성을 변경하려고 시도하는 대신, 실행 중인 커널에 XFS 코드 수정 사항을 직접 적용합니다 .

그런 다음 취약한 CoW 경로는 유지 관리 창이나 워크로드 재시작 없이 잠금 주기 이후에 데이터-포크 매핑을 재샘플링합니다. 이는 커널 전용 버그로, 사용자 공간 라이브러리 구성 요소를 조사할 필요가 없습니다.

KernelCare 사용자들은 일반적으로 모든 새로운 수정 사항이 특정 간격(예: 4시간마다)마다 백그라운드에서 자동으로 적용되도록 패치를 설정해 둡니다. 하지만 사용자는 프로덕션 피드에 게시된 패치라면 언제든지 직접 적용할 수도 있습니다:

kcarectl --update

빌드 날짜만 믿지 말고 CVE 매핑을 확인하십시오. 7월 중순 이후에 컴파일된 커널에는 이 수정 사항이 자동으로 반영되지 않기 때문입니다:

kcarectl --patch-info | grep 'CVE-2026-64600'

해당 커널 계열의 테스트 피드를 통해 패치가 아직 배포 중인 경우, 재부팅 없이 적용 가능한지 확인하기 전에, 당분간은 수정된 벤더 커널로 재부팅하여 사용하십시오.

지금 바로 KernelCare를 다운로드하세요 →

탐지 및 사고 검토

신뢰할 수 있는 RefluXFS 지표는 단 하나도 없으므로, 다음의 각 항목을 확실한 증거가 아닌 단서로만 간주하시기 바랍니다.

가장 정교한 디스크 기반 검사는 이 버그가 가진 사각지대를 악용합니다. 즉, 파일 내용은 변경되었지만 메타데이터는 변경되지 않은 경우입니다. 패키지 검증은 파일 내용을 해시 처리하므로, mtime과 모드가 정상으로 보여도 오류가 발생합니다. 보안에 민감한 패키지의 경우, 먼저 패키지 검증을 수행하십시오:

rpm -V shadow-utils sudo util-linux polkit

검증 결과 문자열에 5가 표시되면 다이제스트 불일치를 의미합니다. setuid-root 바이너리나 핵심 구성 파일에서, 이에 상응하는 T 타임스탬프나 M 모드 변경이 없는 경우, 이는 RefluXFS가 남길 수 있는 수정 유형과 일치합니다. 데비안 계열 시스템에서는 debsums -c 명령어가 동일한 역할을 수행합니다. 패키지 검증만으로는 모든 중요한 변경 가능한 구성 파일을 다룰 수 없으므로, 신뢰할 수 있는 백업, 구성 관리 기록 및 정상으로 확인된 파일 해시 값으로 이를 보완해야 합니다.

고가치 목표물에 집중하세요:

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

그런 다음 다음과 같은 행동 신호를 확인하십시오: 예상치 못한 비밀번호 없는 계정이나 새로운 특권 계정, 변경된 루트 계정 필드, 설치된 패키지와 내용이 더 이상 일치하지 않는 setuid 프로그램, 출처가 불분명한 SSH 키, sudo, 로그인 또는 인증 이벤트와 일치하지 않는 권한 상승, 비특권 프로세스에서 발생하는 동시 직접 I/O 급증, 보호된 파일을 사용자가 쓰기 가능한 위치로 복사하는 reflink 클로닝 등입니다.

일반적인 타임스탬프나 변경되지 않은 권한 모드만으로는 파일이 삭제된 것으로 간주할 수 없습니다. 노출 기간 동안 취약한 호스트에서 신뢰할 수 없는 코드가 실행된 경우, 이를 무결성 침해의 가능성으로 간주하고, 안전성을 입증하는 증거로 조용한 커널 로그를 해석하기보다는 계정, 인증 구성 및 서비스를 더욱 면밀히 조사해야 합니다.

RefluXFS가 중요한 이유

RefluXFS는 세 가지 세부 사항이 모두 제약으로 들리기 때문에 쉽게 과소평가되기 쉽습니다. 원격이 아닌 로컬 기반이며, XFS가 필요하고, reflinks가 필요합니다.

엔터프라이즈 리눅스에서 이 세 가지 요소는 기본 환경을 나타내며, 이에 해당하는 시스템은 바로 타인의 코드를 실행하는 시스템, 즉 테넌트, 빌드 파이프라인, 컨테이너, 플러그인, 보안이 침해된 서비스들입니다.

이 취약점은 또한 이례적인 방식으로 보안 경계를 우회합니다. 보호된 파일에 직접 쓰기 작업도 없고, 우회해야 할 SELinux도 없으며, 커널 메모리 페이로드도 없습니다. 커널은 단순히 공격자가 제어하는 유효한 데이터를 잘못된 디스크 블록에 기록할 뿐이며, 그 결과는 지속적이고 루트 권한을 가지며, 아무런 흔적도 남기지 않습니다.

여기에도 프로세스 관련 교훈이 하나 있는데, 바로 이 교훈을 트라이아지 대기열에 반영해야 한다는 점입니다. 많은 관리자의 경우, 공개적으로 조치를 취할 수 있는 첫 번째 신호는 CVE 공개 이전에 배포되었고 XFS 데이터 손상 수정 사항으로 설명된 평범한 벤더 커널 업데이트였을 수 있습니다. 이것이 바로 ‘먼저 수정하고 나중에 CVE 등록’이라는 조용한 패턴이며, 보안 에러타만을 기준으로 하는 대기열이라면 루트 권한을 가진 로컬 LPE를 일상적인 유지보수 작업으로 분류했을 것입니다. 보안으로 표시된 것뿐만 아니라 모든 커널 버그 수정 권고 사항을 주시하십시오.

기존 방식의 패치 적용 시스템의 경우, 공급업체 업데이트를 설치하고 시스템이 실제로 해당 업데이트로 부팅되는지 확인하십시오. 긴급 재부팅 자체가 운영상의 위험을 초래할 수 있는 대규모 시스템 환경의 경우, KernelCare의 재부팅 없이 적용되는 패치를 사용하면 노드를 중단시키거나 워크로드를 방해하지 않고도 실행 중인 커널 내의 취약한 XFS 경로를 차단할 수 있습니다.

지금 바로 KernelCare를 다운로드하세요 →

연표

참조

• Qualys, “RefluXFS: XFS 환경에서 루트 권한으로의 리눅스 커널 로컬 권한 상승 (CVE-2026-64600),” 2026년 7월 22일: https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Qualys 기술 자문 보고서, “RefluXFS: XFS reflink 직접 I/O 경합을 통한 로컬 권한 상승”, oss-security 2026/q3, 2026년 7월 22일
• 레드햇 제품 보안팀의 SystemTap 임시 대응 조치, oss-security 메일링 리스트 (CVE-2026-64600 관련 스레드)
• 레드햇 CVE 페이지, CVE-2026-64600: https://access.redhat.com/security/cve/cve-2026-64600
• 레드햇 보안 에라타 RHSA-2026:39179 및 RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• 업스트림 수정 사항, “xfs: ILOCK 순환 후 데이터 포크 매핑 재샘플링” (커밋 2f4acd0), 2026년 7월 16일 병합됨
• 버그를 유발하는 커밋 3c68d44a2b49, “xfs: iomap_begin에서 직접 I/O COW 블록 할당” (Linux 4.11)
• The Hacker News, “9년 전부터 존재해 온 RefluXFS 리눅스 취약점으로 인해 기본 설정의 RHEL 설치 환경에서 로컬 사용자가 루트 권한을 획득할 수 있다”: https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• AlmaLinux, Rocky Linux, Oracle Linux, Fedora 및 Amazon Linux에 적용되는 배포판 보안 공지