🤪취약점 데덴찌

🔥 CrushFTP 취약점의 CVE 슈킹 사건

최근 사이버보안 커뮤니티에서 큰 화제가 되었던 이슈, 바로 CrushFTP 인증 우회 취약점과 CVE 번호를 둘러싼 논란을 소개해 드리려 합니다. 🧨 단순한 이해관계자들의 대립 이슈가 아니라, 취약점 관리 기준에 대한 보다 근본적인 질문까지 던지게 만든 사건이었죠.

단순한 해프닝이었을지, 아니면 현재의 취약점 관리 체계가 가진 구조적 결함을 보여준 사건이었을지, 지금부터 함께 살펴보시죠!

🧱 CrushFTP는 뭐하는 프로그램?

CrushFTP는 이름 그대로 FTP(파일 전송 프로토콜) 솔루션입니다. 기업 내부에서 파일 서버로 활용하거나, 외부와의 안정적인 파일 전송을 위해 사용되는데요. 사실 글로벌 기준으로 꽤 많은 기업이 이 솔루션을 사용 중이라고 해요.

SHODAN에서 찾아본 CrushFTP 서버

🕳️ CVSS 9.8… 인증 우회 취약점 등장!

2025년 3월, Outpost24라는 보안 업체가 CrushFTP에서 치명적인 인증 우회(Authentication Bypass) 취약점을 발견했습니다.

해당 취약점은 AWS S3 스타일의 인증 헤더 처리 방식의 결함이 원인이었으며, 비밀번호 없이 사용자명만으로도 인증이 가능한 크리티컬한 취약점이었습니다! 심지어 Exploit PoC도 간단하고, 악용도 활발하게 이루어지고 있었죠. 실제로 미국 CISA도 이 취약점을 정부 기관 필수 패치 목록(KEV)에 추가하며 실제 공격에 사용되고 있다고 경고했습니다. 단순한 취약점이었지만, 그만큼 악용 난이도가 낮아 파급력이 어마어마했었죠.

🧨 그런데… CVE 번호가 두 개?

그런데, 이 취약점이 논란이 되었던 이유는 단순히 치명적인 취약점이라서가 아니었습니다. 바로 하나의 취약점에 두 개의 CVE가 발급되었던 것이었죠. 사람으로 치면 주민센터 두 곳에서 다른 이름으로 출생신고를 한 것이라고 비유할 수 있는데요, 이렇게 된 이유는 무엇이었을까요?

🧾 논란의 타임라인 정리

취약점이 CrushFTP측에 전달된 이후 공식적인 취약점 공개 프로세스가 진행되고 있던 3월 26일, CNA 기관인 VulnCheck가 자체적으로 CrushFTP 취약점에 대해 CVE-2025-2825를 할당하고 보안 커뮤니티에 공개했습니다. 취약점 자체의 파급력이 컸던 만큼, CrushFTP의 취약점은 CVE-2025-2825을 달고 빠르게 보안 커뮤니티에 퍼져갔어요.

하지만, 이미 제보자인 Outpost24와 CrushFTP의 공개 프로세스에서는 CVE-2025-31161가 예약되어 있었어요. VulnCheck의 공개 하루 후, 공식적으로 CVE-2025-31161에 대한 정보가 공개됩니다. 사람들은 두 CVE가 동일한 취약점에 할당되었다는 것을 알고 혼란에 빠집니다. 같은 취약점인데, 서로 다른 이름으로 부르게 되어 취약점 관리에 차질이 빚어지는 문제도 예상되었어요.(취약점이 서로 다른 이름으로 불리면 어떤 일이 발생하는 지, 취약점의 주민등록번호, CVE에서 확인할 수 있어요!)

💢 이메일 내용 공개와 논란의 확산

논란은 CrushFTP CEO인 Ben Spink가 VulnCheck CTO에게 보낸 이메일이 공개되며 더욱 확산됩니다.

CrushFTP의 메일 캡쳐

Ben Splink는 VulnCheck이 할당한 CVE-2025-2825를 “가짜 항목”이라고 지칭하며, 보류된 취약점에 대한 무단 CVE 발급임을 경고했어요. 그러나 VulnCheck CTO는 해당 메일을 도리어 자신의 X에 공개하였고, 또 다른 VulnCheck의 직원 Patrick Garrity도 Linkedin에 임의의 CVE를 발급한 정당성을 설명하며 보안 커뮤니티에서 양측의 대립이 이어졌어요.

결국 MITRE는 VulnCheck의 CVE를 공식적으로 Reject 처리했지만, 이 과정에서 PoC가 확산되고 실제 피해가 발생하는 등의 부작용도 생겼죠.

⚖️ 양측의 주장 정리

VulnCheck과 Outpost24 & CrushFTP 양측의 주장은 Reject 이후에도 엇갈렸어요.

VulnCheck

CrushFTP & Outpost24

📌 결국 문제는 시스템?

CrushFTP 취약점은 단순히 한 제품의 문제를 넘어, 보안 커뮤니티 내부의 절차와 신뢰, 투명성에 대한 의문을 제기한 사건이었습니다.

VulnCheck의 주장처럼, CVE 관리 체계는 중앙화되고 비효율적인 면이 있으며 파급력에 기반한 유연한 정보 공유보다 경직된 절차가 우선시되는 구조는 예전부터 지적을 받고 있었어요. 그럼에도 최소한의 절차조차 없으면 근거가 부족한 무분별한 CVE 발급이 늘어나 취약점 관리 전반에 대한 신뢰가 감소할 거란 의견도 동시에 제기되고 있죠.

이 복잡한 체계를 어떻게, 어떤 기준으로 관리해야 할까요? VulnCheck의 행동은 보안 커뮤니티의 '공익'을 위한 용기였을까요, 아니면 '평판'을 위한 무리수였을까요?

구독자의 생각을 댓글에 남겨주세요! 그럼 다음 주에 더 유익한 정보로 만나요😉

구독자님, 오늘 뉴스레터는 어떠셨나요?
해킹/보안 관련 콘텐츠를 계속 받아보고 싶으시다면 구독 부탁드려요! 🙌