웹호스팅 이용자에게 최근 잇따라 도착한 '긴급 보안 점검' 안내 메일의 배경이 확인됐다. 전 세계 웹사이트 10곳 중 7곳가량이 쓰는 PHP에서 로그인 없이 서버 명령을 실행할 수 있는 치명적 취약점이 발견된 것이다. PHP 개발진은 21일(현지시간) 긴급 보안 업데이트를 배포했고, 국내외 호스팅·클라우드 업체들도 자체 패치와 고객 통지에 나섰다.

웹 요청을 처리하는 서버실. 인증 없이 이런 서버에 명령을 실행할 수 있다 / 출처: Torkild Retvedt, Flickr 

인증 없이 서버를 뚫는 'PHP2Shell'

이번 취약점은 두 건으로, CVE-2026-109618과 CVE-2026-109619다. 위험도는 CVSS v4.0 만점 10점에 9.2점의 '치명적' 등급이며, 보안업계는 둘을 묶어 'PHP2Shell'이라 부른다. PHP에서 서버 명령 실행 권한으로 곧장 이어질 수 있다는 뜻이다.

위험성을 키운 건 인증이 필요 없다는 점이다. 공격자는 대상 사이트의 계정이 없어도 웹 요청이 서버에 닿기만 하면 된다. 명령 실행 권한을 얻으면 웹사이트 정보를 빼내거나 서버를 장악할 수 있다. 워드프레스는 물론 국산 도구인 그누보드와 라이믹스도 PHP 기반이어서 기업 홈페이지, 중소 쇼핑몰, 공공기관과 학교 사이트까지 점검 대상이다.

공개 일정도 순탄하지 않았다. PHP 보안팀은 20일 수정 릴리스를 예고했지만 정보가 예정일보다 먼저 유출되면서 배포를 하루 앞당겼고, 클라우드플레어는 이를 겨냥한 공격 트래픽과 차단 회피 시도까지 관측했다고 밝혔다. 실제 악용이 시작된 상태다.

PHP 언어 코어의 취약점이라 응용 코드와 무관하게 적용된다 / 출처: NegativeSpace 

메모리 관리 오류가 낳은 연쇄 오류

두 취약점 모두 PHP의 메모리 처리에서 비롯된다. CVE-2026-109618은 메모리 부족(OOM) 오류가 요청 처리 중에 발생하면 데이터가 온전히 초기화되지 않은 채 정리 루틴으로 넘어가고, 잘못된 상태를 처리하는 과정에서 코드 실행 경로가 만들어진다. CVE-2026-109619는 해제된 메모리 주소를 내부 전역 상태가 간직하고 있다가 같은 워커가 이후 요청을 받을 때 그 낡은 참조를 먼저 읽는 '사용 후 해제(use-after-free)' 유형이다.

연구자들은 이 과정에서 워커 메모리 내용이 노출되는 현상도 재현했다. 노출 메모리에는 비밀번호, 인증 토큰, API 키가 담겨 있을 수 있다. 영향은 웹 요청을 처리하는 PHP 전반이다. 특히 아파치 mod_php는 애플리케이션 코드가 실행되기 전에 공격 경로가 성립할 수 있어 최우선 점검 대상이고, PHP-FPM도 세션 처리 조건에서 원격 코드 실행이 검증됐다. php-cgi·FrankenPHP·LiteSpeed도 구성에 따라 영향을 받는다.

"PHP2Shell은 애플리케이션 코드와 관계없이 서버 전체를 위험에 빠뜨릴 수 있는 최고 위험도의 취약점이다."

― 티오리 임준오 AI&사이버리서치팀 수석연구원

패치 적용 전 서버는 공격 시도에 계속 노출돼 있다 

전 세계 2,260만 개 노출…국내 11만 건 추정

원격 측정 결과 인터넷에 노출된 잠재 취약 PHP 인스턴스는 2,260만 개가 넘는 것으로 파악됐다. 쿼리스(Qualys) 분석으로는 PHP 설치가 1억 6,700만 건에 달하고 이 가운데 73%가 인터넷에 직접 노출됐다. 버전 확인이 가능한 1억 5,500만 건 중 71%는 5.4~8.1처럼 지원이 끝난 버전이라 공식 패치를 받을 수 없으며, 지원 중인 8.2~8.5를 쓰면서 패치가 안 된 설치도 4,400만 건이다. 공개 후 첫 12시간 동안 패치를 마친 곳은 19만 9천 건에 그쳤다. 미국 사이버보안·인프라보안국(CISA)은 즉시 패치를 강력히 권고했고, 유럽의 한 정부는 예방 차원에서 웹사이트를 일시 오프라인으로 전환했다.

국내에서는 보안업체 안랩이 취약 버전 설치 추정 서버를 약 11만 건으로 집계해 세계 여섯 번째 규모로 파악됐고, 패치 배포 전부터 공격 시도가 관측됐다. 카페24는 PHP 보안 패치를 적용하고 고객에게 공지했다. 가비아는 22일 새벽 패치 작업을 시작해 취약 버전 전반의 보안 조치를 마쳤고, 지원 종료 버전에는 백포트와 완화 조치를 적용했다. NHN클라우드는 전수조사와 고객 안내를 검토 중이며, 에버스핀은 웹 방화벽에 공격 차단 규칙을, 티오리는 취약점 재현·검증에 이은 긴급 대응 가이드를 내놨다. 22일까지 국내 침해 사고 접수는 확인되지 않았지만, 보안업계는 점검을 서두르라고 권고하고 있다.

사이트 운영자가 지금 할 일

근본 대책은 업데이트뿐이다. PHP 개발팀은 8.2.35, 8.3.36, 8.4.27, 8.5.12 네 가지 수정 버전을 내놓았다. 업데이트 후에는 PHP 프로세스를 모두 재시작하고, 컨테이너라면 이미지를 다시 빌드해야 한다. 운영체제 패키지로 설치한 경우 버전 번호는 그대로 두고 수정 내역만 심는 경우가 많으니 변경 로그에서 해당 CVE 번호를 확인하는 것이 확실하다. 8.1 이하는 지원 버전으로 올리는 게 원칙이며, PHP 프로젝트는 7.4·8.0·8.1에 한정해 소스 백포트를 제공한다.

당장 업데이트가 어렵다면 세션 업로드 진행 기능을 끄고(session.upload_progress.enabled=0) 메모리 상한을 무제한으로 바꾸는(memory_limit=-1) 두 설정을 응용 프로그램이 못 바꾸게 함께 적용한 뒤 워커를 재시작하라는 임시 완화책이 있다. 파일 업로드용 multipart/form-data 요청을 차단하고 허용 크기(post_max_size)를 낮추면 방어 폭이 넓어진다. 다만 완화책은 노출을 줄일 뿐 완전한 해법이 아니다. 침해 점검 항목으로는 대용량 multipart 요청 뒤 메모리 부족·500 오류 반복, 비정상적인 PHPSESSID 쿠키, 설명 없는 워커 재시작, 웹셸·새 관리자 계정·수정된 PHP 파일·낯선 외부 연결이 꼽힌다. 메모리 유출 가능성을 배제할 수 없으므로 노출 서버의 비밀번호와 API 키, 토큰 교체도 권장된다.

교훈은 분명하다. 인터넷의 기반이 되는 언어의 코어 취약점은 수천만 대의 서버를 동시에 위험에 빠뜨릴 수 있고, 정작 대다수 설치는 패치조차 받을 수 없는 구버전에 머물러 있다. 호스팅 이용자라면 자신의 PHP 버전을 먼저 확인하고, 업체 공지를 살펴본 뒤, 서버 로그의 이상 징후와 인증 정보 교체 여부를 점검하는 것이 당분간의 기본 수칙이 될 전망이다.