보안

PHP 대형 취약점 터지자 GitHub에서 벌어진 일

2026년 10월 21일, 웹 생태계의 거대한 기둥인 PHP에서 CVSS v4.0 기준 최고 심각도 9.2점의 치명적인 중대 취약점 2건(CVE-2026-109618, CVE-2026-109619)이 공개된 직후 오픈소스 코드 공유 플랫폼인 GitHub에서는 과연 어떤 일이 벌어졌을까?

이번에 터진 두 취약점은 PHP의 내부 요청 처리 메커니즘 깊숙한 곳에서 발생한 심각한 버그이다. CVE-2026-109618은 메모리 부족(OOM) 상태를 처리하는 과정에서 요청 데이터가 일부만 초기화된 채 정리되다 메모리가 오염되는 취약점이며, CVE-2026-109619는 메모리가 해제된 후에도 워커(Worker) 프로세스 내에 오래된 internal global state가 잔재로 남아 후속 요청에서 이를 재사용할 때 발생하는 상태 오염 취약점이다. 두 문제 모두 인증되지 않은 원격 공격자가 임의의 코드를 실행(RCE)할 수 있게 만들며, 특히 애플리케이션의 인증 로직이 동작하기도 전에 HTTP 요청 단계에서 직접 유발되는 mod_php 환경에서 최고 위험도를 자랑한다.

인터넷 자산 검색 기반 조사에 따르면, 취약한 PHP 버전을 사용하는 것으로 추정되는 노출 호스트는 전 세계 수십만 대에 달하며 국내에서만 약 11만 개(112,183개, 글로벌 전체의 4.35%)가 관측되었다.

공식 보안 업데이트가 배포된 바로 그 순간, GitHub는 보안 연구자와 개발자, 그리고 공격자들이 한데 뒤엉킨 긴박한 격전지로 변모했다. 단 24시간 만에 수많은 코드 저장소가 폭발적으로 생성된 그 현장 속에서 과연 무슨 일이 벌어졌을까? 방어자와 공격자가 벌인 숨 가쁜 비하인드 스토리와 보안 연구자들이 반드시 짚고 넘어가야 할 5가지 반전을 전해드린다.

방어 도구가 더 많았지만, 관심(Star)의 85%는 '공격 코드'에 쏠렸다

안랩(AhnLab)이 취약점 공개 직후 GitHub에서 'php2shell' 키워드로 검색되는 상위 100개 저장소(포크 제외)를 수집 및 분석한 결과, 뜻밖의 수치적 반전이 확인되었다. 전체 100개 저장소 중 점검, 완화, 탐지, IoC 공유 등을 목적으로 하는 방어용 저장소(46개)가 공격 PoC 및 취약 환경 재현 랩 목적의 공격용 저장소(36개)보다 수적으로 확연히 우세를 보였다. 위협이 터지자마자 글로벌 방어 생태계가 신속히 자정 작용을 시작했음을 보여주는 대목이다.

그러나 개발자와 사용자의 관심도를 상징하는 GitHub '스타(Star)' 수의 향방은 완벽히 반대 방향을 가리켰다. 전체 수집 스타 1,394개 중 무려 85%에 달하는 1,178개의 스타가 공격용 저장소(이 중 PoC·익스플로잇 저장소 27개에만 1,158개)로 압도적으로 쏠렸다. 반면 46개나 존재했던 방어용 저장소가 받은 스타의 합은 겨우 148개(약 11%)에 그쳤다.

특히 스타 상위 2개 PoC 저장소인 ikow/php2shell-poc(617개)와 eness의 PoC 저장소(333개)가 받은 스타의 합(950개)만 해도 전체 관심의 68%를 독점했다. 상위 5개 저장소까지 범위를 넓히면 전체 스타의 81%를 소수 인기 공격 코드가 싹쓸이한 셈이다.

"방어 생태계의 빠른 움직임에도 불구하고, 대중과 개발자들의 시선은 초기에 공격 가능성을 입증하는 'PoC'로 지독할 만큼 쏠렸습니다."

용도 구분	저장소 수 및 스타(Star) 분포
방어용 저장소 (점검·완화·탐지)	46개 (전체 스타의 약 11% / 148개)
공격용 저장소 (PoC·익스플로잇·재현 랩)	36개 (전체 스타의 약 85% / 1,178개)
기타 / 미분류 (기술 분석·정보 제공·무관 등)	18개 (전체 스타의 약 4% / 68개)

'원클릭 해결' 완화 스크립트? 보안 도구가 새로운 위협이 되는 이유

시급한 위협 상황이 도래하면 시스템을 클릭 한 번이나 명령어 한 줄로 즉시 보호해 준다는 공개 도구들이 인터넷에 쏟아져 나온다. 그러나 검증되지 않은 방어 도구는 그 자체로 서버를 위협하는 새로운 공격 경로(Attack Vector)가 될 수 있다.

이번 분석에서도 '한 줄 스크립트로 모든 PHP 환경 완화'를 내세운 Shell 스크립트들이 여럿 발견되었다. 이러한 완화 스크립트들은 서버의 최상위 관리자 권한인 root 권한으로 실행되는 경우가 대다수이다. 만약 내부 코드의 동작 과정을 정밀하게 검토하지 않은 채 곧바로 실행할 경우, PHP 설정 변경에 그치지 않고 전체 OS 파일 시스템 오염이나 치명적인 권한 남용으로 이어질 수 있다.

실제로 공개된 도구 중 mothproof3512 저장소의 작성자는 "이 도구는 AI를 활용해 작성되었으며 정상 동작을 전혀 보증하지 않는다"고 스스로 명시하기도 했다.

최근 'AI가 즉석 생성한 원클릭 완화 스크립트'가 보안 커뮤니티에 무검증 상태로 유통되는 사례가 늘고 있다. 코드 동작에 대한 검증 프로세스 없이 관리자(root) 권한을 선뜻 부여하는 행위는 보안 조치가 아니라 외부의 검증되지 않은 주체에게 최상위 통제권을 통째로 넘겨주는 위험천만한 행위이다.

공개된 공격 코드(PoC)의 절반은 가짜이거나 무용지물이었다

GitHub에 대량으로 우후죽순 생성된 공격 코드(PoC)들의 기술적 실효성을 살펴본 결과, 저장소마다 주장하는 내용이 무서울 정도로 엇갈렸다.

원격 코드 실행(RCE)이 완전히 성공한다고 호언장담하는 저장소 (dinosn, 3em0)
RCE까지는 도달하지 못하고 단순 내부 상태 손상(Crash/Corruption)만 재현된다고 솔직하게 밝힌 저장소 (allureluoli)
여러 차례 시도했으나 공격 재현에 아예 실패했다고 기록을 남긴 저장소 (VKKKV)

기술적 완성도 문제뿐만 아니라 인기 저장소의 README 설명글을 토시 하나 틀리지 않고 그대로 복제해 배포한 사례(AsviS/PHP2Shell 저장소가 ikow/php2shell-poc의 설명을 그대로 복사)도 확인되었다.

대형 CVSS 이슈가 터질 때마다 GitHub 스타 수와 트래픽을 끌어모으기 위해 타인의 설명을 복제한 뒤, 내부 코드에 악성 페이로드를 은밀히 훔쳐 넣는 'PoC 사칭 공격(Fake PoC Attack)'은 보안 연구자들을 노리는 클래식하면서도 위협적인 수법이다.

"GitHub 스타 수나 화려한 설명이 코드의 완성도나 안전성을 보증하지는 않습니다."

공개 3일 전부터 시작된 움직임... 위협은 미리 감지되었다

PHP 보안팀의 공식 취약점 발표 및 패치 공지는 10월 21일에 이루어졌다. 하지만 저장소 생성 타임라인을 뜯어보면, 위협 인텔리전스 생태계는 공식 발표 훨씬 이전부터 움직이고 있었다.

최초의 탐지 규칙 저장소(Corelight의 Zeek/Suricata 탐지 규칙)는 공식 공지 발표 사흘 전인 10월 18일 06시 43분(UTC)에 이미 만들어졌다. 이는 주요 보안 벤더와 전문 기관 사이에서 공식 발표 전 사전 정보 공유(Embargo/Pre-disclosure)가 밀도 있게 진행되었음을 증명한다. 첫 PoC 저장소(dinosn) 역시 발표 하루 전인 10월 20일 19시 16분(UTC)에 등장했다.

사전 탐지 규칙 배포로 조용히 고조되던 분위기는 공식 발표일인 10월 21일 15시(UTC, 한국 시간 22일 00시)에 이르러 단 1시간 동안 19개의 저장소가 한꺼번에 쏟아져 나오는 폭발적 피크를 기록했다.

사용된 언어는 Python(47개)과 Shell(24개)이 대다수를 차지했으며, 설명글 역시 영어뿐만 아니라 중국어, 프랑스어, 러시아어, 포르투갈어, 스페인어, 네덜란드어 등 다국어로 작성되었다. 이는 전 세계의 방어자와 공격자가 동시에 전면에 뛰어들었음을 보여준다. 한편, 수집된 저장소 중 절반이 넘는 51개는 오픈소스 라이선스조차 명시되지 않은 상태였다.

취약점 정보가 사전 공유에서 대중 공개로 전환되는 수 시간 동안, GitHub 상에서는 'PoC 노이즈'와 '무라이선스 코드'가 범남하는 구조적 혼란이 발생한다. 타임라인 초기일수록 공식 보안 채널 외의 파편화된 소스에 의존하는 행위는 매우 위험하다.

임시 방편은 없다... 오직 '패치'만이 살길이다

일부 인터넷 가이드에서는 session.upload_progress.enabled = Off 옵션 설정을 임시 완화책으로 제시하고 있다. 하지만 PHP 보안팀과 보안 연구진에 따르면, 이 설정은 CVE-2026-109619(상태 재사용 버그)의 특정 공격 경로만 부분적으로 차단할 뿐이며, 메모리 오염 버그인 CVE-2026-109618을 막기 위해서는 별도의 HTTP 요청/메모리 제한 설정이나 fatal_error_backtraces=0(PHP 8.5) 등의 추가 조치가 필요하다. 즉, 설정 변경만으로는 완전한 방어가 불가능하다.

시스템 운영자와 보안 엔지니어가 지금 즉시 실행해야 할 필수 대응 액션 플랜 4가지를 명확히 정리한다.

PHP 공식 수정 버전 패치 (최우선 과제): 운영 중인 PHP 버전을 파악하고 official 보안 업데이트 버전인 8.5.12, 8.4.27, 8.3.36, 8.2.35로 신속히 패치하라. 특히 인증 없이 외부 요청만으로 직접 공격에 노출되는 mod_php 환경을 최우선적으로 조치해야 한다. (참고: PHP 8.2 버전 계열은 2026년 12월 31일에 공식 지원이 종료(EOL)되므로, 장기적 수명 주기를 고려한 이관 계획 수립이 병행되어야 한다.)
구버전(7.4, 8.0, 8.1) 환경 대응: 이미 지원이 종료된(EOL) 구버전은 공식 릴리스가 제공되지 않는다. PHP 보안팀이 제공한 minimal backport 소스 브랜치(PHP-7.4-CVE-2026-109618-109619 등)를 검토하여 직접 빌드에 반영하거나, OS 벤더의 백포트 패치 여부를 확인하고 조속히 지원 버전으로 이관 체계를 수립해야 한다.
침해 여부 전수 조사 (DFIR 절차): 글로벌 보안업체 watchTowr의 분석 결과에 따르면, 10월 21일 당일부터 자사 허니팟 네트워크에서 해당 취약점을 노린 실제 익스플로잇 시도가 관측되었다. 패치 적용 전에 인터넷에 노출되어 있던 서버는 이미 침해되었을 가능성을 배제할 수 없다. 웹 서버 로그에서 비정상적인 multipart 요청을 정밀 전수 조사하고, 웹 루트 디렉터리 내 의심스러운 웹쉘 생성 여부 및 웹 서버 계정(www-data, apache 등)으로 실행된 이상 프로세스를 반드시 점검하라.
공개 도구 실행 및 다루기 원칙: GitHub 등에서 입수한 PoC나 검증 스크립트는 절대로 운영 서버나 로컬 관리자 환경에서 곧바로 실행해서는 안 된다. 코드를 직접 라인 바이 라인으로 분석·검증한 후, 완전히 격리된 샌드박스(Sandbox) 환경에서만 제한적으로 활용해야 한다.

PHP 대형 취약점 공개 직후 GitHub에 몰려든 100여 개의 저장소는 오픈소스 생태계의 놀라운 대응 속도를 보여주는 동시에, 무검증 코드와 가짜 PoC, AI가 쏟아낸 위험한 완화 스크립트가 뒤섞인 혼돈의 격전지였다. 위협의 홍수 속에서 인기도나 자극적인 소문에 휩쓸리지 않고, 공식 보안 공지와 검증된 위협 인텔리전스를 선별해 내는 안목이야말로 현대 보안 체계의 핵심이다.

새로운 취약점이 터졌을 때 여러분의 조직은 소문 속 '원클릭 오픈소스 도구'를 신뢰하고 있는가, 아니면 검증된 공식 패치 체계를 갖추고 있는가?