3줄 요약
-
오디오 디코더 라이브러리 두 개 (minimp3 · dr_libs) 를 수기 코드 리뷰하다가 메모리 안전성 이슈 두 건을 발견했다.
-
벤더 공조와 MITRE 절차를 거쳐 CVE-2026-37715 · CVE-2026-37716 두 개의 CVE ID를 할당받았다.
-
퍼저에만 의존하지 않고 "사람 눈으로 읽어야 보이는 결함"이 여전히 많다는 걸 몸으로 배웠다.
시작하며
▎ 참고 GitHub 이슈
▎ - minimp3: https://github.com/lieff/minimp3/issues/140
▎ - dr_libs: https://github.com/mackron/dr_libs/issues/300
▎
▎ ※ 본 글 작성 시점 기준 두 이슈 모두 공개 제보 상태이며, CVE 레코드는 MITRE에 예약(RESERVED) 상태 입니다. 세부 기술 내용은 공식 공개 시점까지 의도적으로 생략했습니다.어느 날 밤에 "오래된 헤더온리 라이브러리들은 새 퍼저 돌려도 결과 안 나오는 영역이 많지 않을까"라는 생각이 들었다. 최근 10년간 수많은 프로젝트에 박혀있지만 정작 이 라이브러리 자체에는 큰 관심이 모이지 않은, 그런 포지션의 코드들.
특히 오디오/이미지 디코더류는 대부분 1개 파일짜리 "drop-in" 라이브러리다. 빌드 한 번만 되고 나면 업스트림 쪽에서 잘 쳐다보지 않는다. 근데 그 안에서 처리되는 데이터는 사용자가 주는 파일이다. 공격 표면이 크다는 뜻이다.
그래서 타겟 몇 개를 골라서 그냥 코드를 읽기 시작했다. 자동화 퍼저 없이, IDE 하나 열어놓고.
왜 수기 리뷰였는가
퍼저는 강력하다. 특히 메모리 오류 찾는 데는. 근데 퍼저가 잡지 못하는 영역이 분명 있다.
-
퍼저는 "깊이"가 필요한 결함에 약하다. 특정 헤더 필드가 특정 경로를 따라 수십 번의 함수 호출을 거쳐서 결국 어떤 계산식에 쓰이는데 거기서 문제가 나는, 그런 체인.
-
퍼저는 "의미"를 모른다. 이 필드가 "프레임 개수"인지, 이 다른 필드가 "청크 크기"인지. 그냥 비트를 뒤집을 뿐이다.
-
사람이 읽으면 "어? 이 필드는 사용자가 제공하는데 여기서 검증 없이 곱셈에 들어가네?" 같은 게 보인다.
두 라이브러리 모두 이런 타입의 결함이었다. 퍼저가 혹시 찾았을 수도 있는데, 최근 이 타겟들에 대한 퍼징 보고가 거의 없었다. 아무도 최근에 안 봤다는 뜻이다.
어떤 결함이었는가
자세히는 쓰지 않겠다. 두 건 모두:
-
사용자가 제공하는 파일 헤더의 특정 필드가 있고
-
그 필드가 검증 없이 내부 연산에 쓰이면서
-
결과적으로 메모리 안전성이 깨지는 구조였다.
한 건은 서비스 거부 (DoS) 계열, 다른 한 건은 더 심각한 메모리 훼손 계열이다.
공통점은 재현 파일이 아주 작다는 것. 수십 바이트 수준. 이게 의미하는 바는 — 이 결함이 실제로 트리거되는 데 특별한 조건이 필요 없다는 뜻이다. 그냥 잘못 만들어진 파일 한 개면 된다.
벤더 공조와 CVE 절차
코드 리뷰로 "이거 결함인 것 같은데?" 싶은 게 보이면 바로 PoC를 만들어본다. 해당 라이브러리만 단독으로 빌드해서, 최소 크기의 파일을 넣어서 재현되는지 확인한다. 재현되면 이슈 올린다.
GitHub 이슈로 먼저 벤더와 소통하고, 상세 기술 내용을 정리한 보고서를 공유했다. 이후 MITRE에 CVE ID 할당 요청을 넣었고 — 두 건 다 할당 완료. 다만 NVD 공식 발행은 벤더 패치·공개 타이밍에 맞춰 이뤄지기 때문에, 지금 시점에는 RESERVED 상태로
남아있다.이 과정에서 깨달은 건, CVE는 기술적 성취가 아니라 행정 절차의 결과라는 점이었다. 결함을 찾는 건 기술이지만, CVE ID를 받아내는 건 "정확하게 쓰인 보고서 + 책임 공개 절차 준수 + 벤더 커뮤니케이션"이다. 이쪽이 오히려 시간이 더 걸렸다.
어려웠던 점
-
"이거 진짜 결함 맞나?"를 스스로 의심해야 한다
코드 읽다가 수상한 부분을 발견해도, 그게 실제로 악용 가능한지는 PoC로 실증하기 전까지 확신할 수 없다. "컴파일러가 알아서 처리해주지 않나?" "상위 계층에서 걸러지지 않나?" 같은 자기 반박이 계속 든다.
그래서 무조건 PoC부터 만들었다. 가장 작은 재현 파일을 만드는 데 시간이 많이 들었다. "정확히 이 바이트가 이 필드에 들어가면 이 경로를 타고 이 연산에 쓰여서 이 에러가 난다"를 바이트 단위로 증명하는 게 진짜 검증이다.
-
리포트 쓰는 게 생각보다 오래 걸린다
영어로, 재현 단계를 누구나 따라할 수 있게, 영향받는 버전을 특정하고, 근본 원인을 설명하고, 가능하면 패치 방향까지 제안하는 글을 써야 한다. 기술보다 이쪽이 훨씬 체력 소모 크다.
특히 "패치 제안"이 까다롭다. 라이브러리의 전체 맥락을 모르는 상태로 함부로 패치를 제안했다가 다른 부분을 깨뜨릴 수도 있다. 그래서 "이 지점에서 이런 검증이 필요해 보이지만, 최종 패치는 메인테이너 판단에 맡긴다"는 식으로 톤을 조심했다.
-
RESERVED 상태에서의 침묵
CVE ID 받고 나서 "야호 CVE 받았다!" 올리고 싶은데, 패치 릴리스 전까지는 기술 세부 공개가 금지다. 이 글도 그 침묵의 일부다. 블로그에 기록은 남겨두되 재현 가능한 내용은 비워두는 식으로 썼다.
배운 점
-
"오래된 라이브러리" 는 의외로 미탐지 영역이다
정확히 말하면, 오래됐지만 여전히 현역에서 쓰이는 헤더온리 라이브러리들. minimp3·dr_libs 같은 것들은 수많은 제품에 박혀있지만, 코드베이스가 한 파일이라 별도의 CI·CodeQL·정기 감사가 안 붙어있는 경우가 많다. 여기 시간을 투자할 가치가 있다.
-
수기 리뷰는 여전히 경쟁력이다
"요즘은 퍼저·AI가 다 잡지 않나"라는 말을 많이 듣는다. 아니다. 사람이 코드를 "이해"해서 찾는 결함은 여전히 많다. 특히 의미론적 결함 (= 비트 단위가 아닌 값의 의미가 틀어지는 결함) 은 수기 리뷰의 영역이다.
-
PoC → 리포트 → 벤더 → MITRE, 이 플로우 자체가 기술이다
처음 해보면 한 건에 몇 주 걸린다. 두 번째 건은 일주일로 줄었다. 이 "절차를 익히는 것" 자체가 별도의 스킬이다. 기술만으로는 못 간다.
-
과장하지 않는 것이 가장 강한 언어다
"완전한 RCE!" "치명적 취약점!" 같은 수식어 없이, "이 파일을 주면 이 결함이 재현되고, 그 결과는 이러하다" 라는 바이트 단위 사실만 쓴다. 메인테이너와 MITRE 모두 이런 톤에 반응이 훨씬 좋았다.
마치며
CVE 한두 개를 받는 게 커리어의 큰 전환점은 아니다. 근데 이 과정을 거치면서 체득되는 건 분명 있다:
-
"코드를 의심하는 눈" — 어떤 코드를 봐도 신뢰 가능한 경로인지 아닌지 자동으로 분리해서 보게 된다.
-
"결함을 증명하는 습관" — 감으로 말하지 않고 바이트로 말한다.
-
"책임 공개의 매너" — 찾았다고 자랑하기 전에 패치를 먼저 생각한다.
퍼저가 놓친 구석에서, 오래된 라이브러리 한 파일을 몇 시간 읽다가 발견한 것들이다. 앞으로도 이 영역에서 더 찾아낼 게 많을 것 같다. 다음 글에서는 공개 타이밍이 맞으면 세부 기술 내용도 같이 쓸 수 있을 듯.
▎ 작성자: HoHK (AN_HoHk)
▎ 관련 CVE: CVE-2026-37715 · CVE-2026-37716 (둘 다 RESERVED, 공식 공개 대기 중)
▎ 참고 이슈:
▎ - https://github.com/lieff/minimp3/issues/140
▎ - https://github.com/mackron/dr_libs/issues/300
