블로그, 쇼핑몰, 학원·병원 홈페이지… 우리가 매일 들르는 웹사이트의 상당수는 PHP라는 프로그래밍 언어 위에서 돌아가요. 워드프레스도, 그누보드도, 우커머스 쇼핑몰도 모두 PHP로 움직이죠. 그런데 바로 그 PHP 자체에서 아주 심각한 구멍 두 개가 발견됐고, 원래 공개하기로 한 날보다 먼저 소식이 새어 나가 전 세계 서버 관리자들이 오늘 하루 비상이 걸렸습니다. 연구자들이 붙인 별명은 ‘PHP2Shell(PHP투셸)’이에요.
PHP 개발팀은 한국 시간 오늘(10월 21일) 밤 11시에 긴급 보안 업데이트를 내놓겠다고 예고했어요. 보안 회사 산섹(Sansec)은 “패치가 나오고 15분 안에 대량 공격이 시작될 것”이라고 내다봤고요. 오늘은 이게 무슨 일인지, 왜 이렇게 다들 긴장하는지, 그리고 내 사이트가 있는 분·없는 분 각각 무엇을 하면 되는지를 초보 기준으로 차근차근 풀어 볼게요.

한 줄 요약부터
| 질문 | 짧은 답 |
|---|---|
| 무슨 일이에요? | 웹사이트 언어 PHP에서 치명적 취약점 2개(CVE-2026-109618, CVE-2026-109619)가 발견됐어요. PHP 보안팀 평가는 둘 다 CVSS 9.2(10점 만점 중 ‘긴급’ 등급) |
| 얼마나 위험해요? | 연구자들은 로그인 없이 바깥에서 서버에 명령을 실행(원격 코드 실행, RCE)할 수 있는 구멍으로 보고 있어요. 서버를 통째로 빼앗길 수 있는 종류예요 |
| 어디가 영향받아요? | 연구자·CERT-EU 등은 PHP 5.4 이후 거의 모든 버전이 해당될 수 있다고 봐요. 공식 영향 범위는 패치와 함께 발표돼요 |
| 패치는 언제? | 10월 21일 14:00 UTC = 한국 시간 밤 11시 예정. 공격이 확인되면 더 앞당길 수 있다고 했어요 |
| 어떤 버전으로? | 미리 알려진 예상 번호는 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 (PHP가 아직 공식 확인 전) |
| 8.1 이하는? | 지원이 끝난 버전이라 공식 패치가 없어요. 지원 버전으로 올리는 게 사실상 유일한 해법 |
| 나는 뭘 해요? | 사이트가 없다면 평소처럼 이용하되 수상한 메일·문자 주의. 사이트가 있다면 오늘 밤~내일 PHP 업데이트를 꼭 확인하세요 |
PHP가 뭐길래 이렇게 난리일까
식당에 비유해 볼게요. 손님(방문자)이 주문서를 내면, 주방에서 요리사가 레시피대로 음식을 만들어 내보내죠. 웹사이트에서 주문서는 방문자의 요청, 레시피는 워드프레스 같은 프로그램, 그리고 레시피를 읽고 실제로 요리하는 요리사가 PHP예요. 이번 구멍은 레시피(워드프레스)가 아니라 요리사 자체에 있어요. 그래서 어떤 레시피를 쓰든, 요리사가 같으면 모두 영향을 받을 수 있는 거예요.
| 구분 | 식당 비유 | 웹사이트에서는 |
|---|---|---|
| 방문자의 요청 | 손님이 낸 주문서 | 글 보기, 로그인, 사진 올리기 같은 요청 |
| 워드프레스·그누보드·라라벨 | 레시피 책 | 어떤 화면을 어떻게 보여 줄지 적어 둔 프로그램 |
| PHP | 레시피를 읽고 요리하는 요리사 | 프로그램을 실제로 실행하는 엔진. 이번 구멍이 여기 있어요 |
| 웹 서버(Apache·Nginx) | 주문을 받아 주방에 넘기는 홀 직원 | 요청을 받아 PHP에 전달 |
| 호스팅 업체 | 식당 건물·주방을 빌려주는 곳 | 서버와 PHP를 관리해 주는 곳(카페24·가비아·해외 호스팅 등) |
규모도 커요. 웹 기술 조사 업체 W3Techs 기준으로, 서버 언어가 확인되는 웹사이트의 69.3%가 PHP를 써요. 보안 연구자들의 대략적 추산으로는 인터넷에 직접 노출된 PHP 서버만 130만~190만 대에 이르고요.
‘셸(Shell)’을 넘겨준다는 게 무슨 뜻?
‘셸’은 서버에 명령을 내리는 조종석이에요. 이름 그대로 ‘PHP2Shell’은 “PHP를 통해 서버 조종석을 차지한다”는 뜻이죠. 아직 공식 기술 설명은 없지만, 연구자들이 공개된 단서로 추정한 내용은 이래요.
| 항목 | 지금까지 알려진 것 | 확실도 |
|---|---|---|
| 버그 종류 | use-after-free(이미 치운 메모리를 다시 쓰는 실수) 같은 메모리 오류로 추정 | 추정(연구자) |
| 관련 기능 | 파일 업로드 진행률을 기록하는 Session Upload Progress, 파일 업로드 요청(multipart) 처리 부분이 의심돼요 | 추정(GMO Flatt Security·Flare 등) |
| 필요 조건 | 로그인 필요 없음, 특별한 설정 없이도 가능하다는 주장 | 주장(공식 미확인) |
| 재현 여부 | 보안 회사 워치타워(watchTowr)가 CVE-2026-109618을 재현했다고 밝힘 | 업체 발표 |
| 실제 공격 | 클라우드플레어 CTO가 21일 “초기 공격이 보이기 시작했다”고 언급, 다른 업체들은 아직 확인 못 함 | 엇갈림 |
| 공격 도구 | ‘PHP2Shell’이라는 도구 화면 캡처가 유출, PHP 5.4.0부터 통한다고 주장 | 유출 자료 |
쉽게 말해 “손님이 주문서 한 장을 이상하게 써서 내밀면, 요리사가 헷갈린 틈에 손님이 주방 열쇠를 가져가 버리는” 상황이에요. 열쇠를 가진 공격자는 사이트에 악성코드를 심거나, 회원 정보를 빼가거나, 서버를 코인 채굴·스팸 발송에 쓸 수 있어요.

왜 ‘새어 나간’ 게 문제였을까: 시간표로 보기
보안 구멍은 보통 “고치는 약(패치)과 구멍 소식을 같은 날 함께 공개”하는 게 원칙이에요(이걸 엠바고라고 불러요). 그런데 이번엔 약이 나오기 전에 구멍 소식이 먼저 퍼졌어요. 도둑에게 “이 동네 현관문이 다 고장 났다”는 소문만 먼저 돈 셈이죠.
| 시각(한국 시간) | 일어난 일 |
|---|---|
| 원래 계획 | 10월 22일(목) 공개 예정이었다고 워치타워가 밝힘 |
| 10월 20일(현지 시각) | 해커뉴스(HN) 게시판에 “PHP에 RCE 2건, CVSS 10, PHP 5부터 전부 해당”이라는 글이 올라오고 CVE 번호가 퍼짐. 워치타워가 “실제로 존재한다”고 확인 |
| 10월 21일(수) 새벽 4시 33분 | PHP 보안팀이 공식 사전 공지: “21일 14:00 UTC에 긴급 보안 릴리스, 지금 준비하세요” |
| 10월 21일 오후 | CERT-EU·영국 NCSC·일본 IPA 등이 잇따라 준비 권고. 클라우드플레어가 무료 요금제까지 임시 방어 규칙(WAF) 적용 |
| 10월 21일 오후 4시 43분 무렵 | 산섹이 “클라우드플레어가 PHP 사이트를 노린 초기 공격을 보고했다”고 전함 |
| 10월 21일 밤 11시 | PHP 긴급 패치 공개 예정(더 일찍 나올 수도 있음) |
| 패치 공개 직후 | 고친 부분을 거꾸로 분석해 공격법을 알아내는 경쟁이 시작될 가능성. 산섹은 “15분 안에 대량 공격” 예상 |
마지막 줄이 중요해요. 패치가 나오면 공격자도 “어디를 고쳤는지”를 보고 구멍 위치를 역으로 찾아내요. 그래서 이번 건은 “패치가 나왔으니 이제 안심”이 아니라 “패치가 나온 순간부터 진짜 시작”이라고 보는 게 맞아요.

내 PHP 버전은 무엇을 받게 될까
| PHP 버전 | 지금 최신(9월 24일) | 오늘 밤 예상 패치 | 지원 상태 |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | 정식 지원(2027년 12월 31일까지) |
| 8.4 | 8.4.26 | 8.4.27 | 정식 지원(2026년 12월 31일까지) |
| 8.3 | 8.3.35 | 8.3.36 | 보안 수정만(2027년 12월 31일까지) |
| 8.2 | 8.2.34 | 8.2.35 | 보안 수정만(2026년 12월 31일까지, 곧 종료) |
| 8.1 · 8.0 · 7.x · 5.x | – | 공식 패치 없음 | 지원 종료. 리눅스 배포판이 따로 고쳐 줄 수는 있지만 보장 안 됨 |
예상 패치 번호는 보안 연구자 케빈 보몬트와 알파인 리눅스 등이 미리 알린 값이고, PHP가 패치와 함께 공식 확정할 예정이에요. 걱정스러운 숫자도 하나 있어요. 보안 업체 맬러리(Mallory)가 20일 쇼단(인터넷 기기 검색 엔진)으로 세어 보니, 버전을 드러낸 PHP 서버 약 150만 대 가운데 약 88만 4천 대(59%)가 8.1 이하, 즉 공식 패치를 못 받는 버전이었어요(배너 기준이라 실제 취약 여부와는 다를 수 있어요).
나는 어느 쪽일까: 상황별로 할 일
| 나는… | 위험도 | 할 일 |
|---|---|---|
| 웹사이트가 없는 일반 이용자 | 직접 할 건 거의 없음 | 자주 쓰는 사이트에서 ‘개인정보 유출 안내’ 메일·문자가 오면 확인. 링크 대신 앱·즐겨찾기로 직접 접속 |
| 호스팅에 워드프레스·그누보드 블로그/쇼핑몰 운영 | 높음 | 호스팅 업체 공지 확인 → 내 PHP 버전 확인 → 업체가 언제 업데이트하는지 문의. 8.1 이하라면 버전 올리기 예약 |
| 직접 서버(VPS·클라우드) 운영 | 매우 높음 | 오늘 밤 11시 패치 즉시 설치 → PHP-FPM·Apache 재시작 → 로그 확인 |
| 회사 IT 담당 | 매우 높음 | PHP가 들어간 모든 시스템 목록화(관리 콘솔·장비·사내 도구 포함) → 인터넷에 열린 것부터 패치 |
| 홈 NAS·공유기 관리 화면 사용 | 제품마다 다름 | 제조사 펌웨어 업데이트 공지 주시. 관리 화면은 외부 인터넷에 열어 두지 않기 |
내 사이트 PHP 버전, 1분 만에 확인하는 법
| 방법 | 어디서 | 보이는 것 |
|---|---|---|
| 워드프레스 관리자 | 관리자 화면 → 도구 → 사이트 건강 → 정보 탭 → ‘서버’ 항목 | PHP 버전(예: 8.3.35) |
| 호스팅 관리 페이지 | 카페24·가비아 등 호스팅 관리 화면, 또는 cPanel의 PHP 버전 선택 메뉴 | 현재 버전·바꿀 수 있는 버전 목록 |
| 직접 서버(터미널) | php -v 명령 |
설치된 PHP 버전 |
| 웹 서버가 여러 PHP를 쓸 때 | php-fpm8.3 -v처럼 버전별 확인, 또는 phpinfo() 임시 페이지(확인 후 꼭 삭제) |
실제 사이트가 쓰는 버전 |
팁 하나: 터미널에서 본 php -v와 실제 사이트가 쓰는 PHP가 다를 수 있어요. 워드프레스 ‘사이트 건강’ 화면이 가장 정확한 “사이트 기준” 답이에요.
오늘 밤 11시 전에 할 수 있는 준비
PHP 핵심 개발자 지나 피터 바냐드는 “유일한 대책은 패치·업그레이드”라고 못 박았어요. 아래는 패치 전까지 버티는 임시방편일 뿐, 패치를 대신하지 못해요.
| 임시 조치 | 효과 | 부작용·주의 |
|---|---|---|
| 호스팅 업체에 “패치 나오면 바로 적용해 달라” 요청 | 가장 현실적 | 공유 호스팅은 내가 직접 PHP를 못 바꾸는 경우가 많아요 |
| 클라우드플레어 사용 중이면 WAF 규칙 확인 | 알려진 공격 경로 일부 차단(무료 요금제 포함) | 클라우드플레어를 거치는 트래픽만 보호. 업체도 ‘임시방편’이라고 밝힘 |
| 웹 서버에서 파일 업로드 요청(multipart/form-data) 차단 | 의심 경로를 아예 막음 | 사진 업로드·일부 결제 폼이 멈춰요. 패치 후 반드시 원상복구 |
session.upload_progress.enabled=0 설정 |
일부 완화 가능성 | GMO Flatt Security가 “단독으론 완전한 대책 아님”으로 정정. PHP 측도 “ini 설정으론 못 막는다” |
| 하루 정도 사이트 잠시 내리기·외부 차단 | 가장 확실한 차단 | 방문자 불편. CERT-EU·영국 NCSC는 즉시 패치가 어렵다면 고려하라고 권고 |
| 백업 한 벌 받아 두기 | 최악의 상황 대비 | 백업 파일을 서버 안에만 두지 말고 내 PC·클라우드에도 보관 |
참고로 워드프레스 ‘유지보수 모드’는 도움이 안 돼요. 화면만 가릴 뿐 PHP는 여전히 요청을 읽거든요.

패치가 나오면: 업데이트 순서
| 순서 | 할 일 | 왜 |
|---|---|---|
| 1 | PHP 공식 발표에서 영향 버전·수정 버전 확인 | 예상 번호가 바뀔 수 있어요 |
| 2 | 인터넷에 열린 서버부터 업데이트 | 공격은 바깥에서 들어와요 |
| 3 | PHP-FPM·Apache·큐 워커 재시작 | 오래 켜진 프로세스는 옛 PHP를 메모리에 그대로 들고 있어요 |
| 4 | 사이트 건강 화면이나 php -v로 새 번호 확인 |
‘설치했는데 안 바뀐’ 경우를 잡아요 |
| 5 | 글쓰기·사진 업로드·결제 등 핵심 기능 테스트 | 업데이트 후 깨진 곳 확인 |
| 6 | 임시로 막은 업로드 차단 규칙 해제 | 임시 조치는 임시로만 |
| 7 | 며칠간 접속 기록·새 관리자 계정·낯선 파일 점검 | 패치 전에 이미 들어온 흔적이 있는지 |
설치 경로별로 다른 점
| PHP를 어디서 받았나 | 오늘 밤 상황 |
|---|---|
| 공유 호스팅(카페24·가비아 등) | 업체가 적용해요. 공지와 적용 시점을 확인하세요 |
| 우분투·데비안 ondrej PPA | 패치 직후 곧 제공 예정이라고 PHP.Watch가 안내 |
| 배포판 기본 패키지(우분투·데비안·RHEL 등) | 배포판이 자체적으로 고쳐서(백포트) 내놓을 수 있어요. 배포판 보안 공지 확인 |
| Remi 저장소(RHEL 계열에서 흔함) | 21일에는 업데이트가 안 나온다고 PHP 재단이 밝힘. 배포판 패키지로 바꾸거나 직접 빌드 필요 |
| 도커(Docker) 공식 이미지 | 패치 직후 새 이미지 공개 예정. 이미지 다시 받고 컨테이너 재생성 |
| 맥 홈브루·GitHub Actions setup-php | 패치 직후 업데이트 예정(개발용 PC는 상대적으로 덜 급해요) |
헷갈리기 쉬운 오해 바로잡기
| 오해 | 사실 |
|---|---|
| “워드프레스를 최신으로 올렸으니 괜찮다” | 이번 구멍은 워드프레스가 아니라 그 밑의 PHP에 있어요. PHP를 올려야 해요 |
| “보안 플러그인이 있으니 막아 준다” | PHP가 요청을 읽는 단계에서 터질 수 있어 플러그인이 손쓸 틈이 없을 수 있어요 |
| “PHP 7은 오래돼서 오히려 안전하다” | 반대예요. 영향 범위로 거론되는 데다 공식 패치가 없어요 |
| “내 사이트는 작아서 노릴 리 없다” | 이런 공격은 사람이 고르는 게 아니라 자동 프로그램이 인터넷 전체를 훑어요 |
| “어제 랭크매스 사건이랑 같은 얘기다” | 다른 사건이에요. 랭크매스는 특정 플러그인 배포 경로가 오염된 것이고, 이번엔 PHP 엔진 자체의 결함이에요 |
사이트 운영자를 위한 오늘 밤 체크리스트
| ✔ | 항목 |
|---|---|
| ☐ | 내 사이트 PHP 버전 확인(사이트 건강 → 정보 → 서버) |
| ☐ | 호스팅 업체 공지·고객센터에 패치 적용 일정 문의 |
| ☐ | 백업 한 벌을 서버 밖(PC·클라우드)에 보관 |
| ☐ | 8.1 이하라면 8.3 이상으로 올리는 일정 잡기(테마·플러그인 호환성 먼저 확인) |
| ☐ | 밤 11시 이후 PHP 공식 발표 확인, 수정 버전으로 업데이트 |
| ☐ | 업데이트 후 PHP 프로세스 재시작, 새 버전 번호 확인 |
| ☐ | 관리자 계정 목록에 모르는 계정 없는지, 최근 바뀐 파일 없는지 점검 |
정리하면
이번 PHP2Shell은 “웹의 요리사”에게 난 구멍이라, 어떤 레시피(워드프레스·그누보드·라라벨)를 쓰든 PHP를 쓰는 곳이면 모두 확인해야 하는 사건이에요. 사이트가 없는 분이라면 크게 걱정하실 필요는 없고, 며칠간 ‘유출 안내’나 수상한 메일만 조심하시면 돼요. 사이트를 운영하신다면 오늘 밤 11시 이후 PHP 업데이트, 그리고 8.1 이하 버전 탈출 두 가지만은 꼭 챙겨 주세요. 공식 세부 내용이 나오면 영향 범위가 더 분명해질 거예요.