PHP 취약점 'PHP2Shell' 2건, 우리 홈페이지도 해당될까 — 8.1 이하는 수정 버전 없음: 그누보드·워드프레스·호스팅 사용자 확인법과 버전별 할 일
목차
10월 21일 밤 11시(한국 시간), 웹사이트를 만드는 데 가장 널리 쓰이는 프로그래밍 언어 PHP의 개발팀이 치명적 취약점 2건을 고친 긴급 보안 업데이트를 내놓았습니다. 보안업계는 이 취약점을 'PHP2Shell'이라고 부릅니다. 로그인 없이 밖에서 서버에 명령을 내릴 수 있는 결함이라, 유럽연합 사이버보안 대응조직(CERT-EU)은 "업데이트를 바로 못 하면 웹사이트를 오프라인으로 돌리는 것까지 검토하라"고 권고했습니다.
결론부터 말하면, 회사·가게 홈페이지나 쇼핑몰을 PHP로 돌리고 있다면 오늘 할 일은 두 가지입니다. ① 실제로 웹사이트를 돌리는 PHP 버전이 수정 버전(8.2.35·8.3.36·8.4.27·8.5.12 이상)인지 확인하고, ② 아니면 호스팅 업체나 제작 업체에 패치 일정을 물어보는 것입니다. 특히 8.1 이하 구버전은 공식 수정 버전 목록에 아예 없습니다. 버전을 올리는 것 말고는 길이 없다는 뜻입니다.
💡 핵심 요약 (10월 22일 기준)
- 취약점: CVE-2026-109618, CVE-2026-109619 (별칭 PHP2Shell). 둘 다 CVSS 4.0 기준 9.2점 '치명적'
- 위험: 인증 없는 원격 코드 실행. 데이터 탈취·홈페이지 변조·서버 장악으로 이어질 수 있음
- 수정 버전: PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
- 주의: 게시판·워드프레스 플러그인 업데이트로는 해결 안 됨. PHP 자체를 올려야 함
- 해당 없음: PHP를 쓰지 않는 사이트(예: Next.js 정적 사이트), 네이버 블로그·티스토리처럼 플랫폼이 서버를 운영하는 서비스
PHP2Shell은 무엇이 문제인가?
웹사이트 프로그램이 돌기도 전에, 요청 하나로 서버에 코드를 심을 수 있다는 점이 문제입니다. 데일리시큐가 정리한 PHP 개발팀 발표에 따르면 두 결함은 모두 PHP가 웹 요청을 처리하면서 메모리를 다루는 과정에서 생깁니다.
| 구분 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 생기는 곳 | 메모리 부족 오류를 처리할 때 | 요청 처리가 끝난 뒤 메모리를 정리할 때 |
| 원리 | 요청 준비가 끝나기 전에 처리가 멈추면, 마무리 단계에서 망가진 메모리를 정상 데이터처럼 사용 | 해제된 메모리의 내부 상태가 남아, 같은 프로세스가 다음 요청을 처리할 때 그 상태를 참조 |
| 확인된 공격 | 아파치 mod_php 일반 구성에서 인증 없는 HTTP 요청으로 코드 실행 검증 | 후속 요청을 통한 코드 실행 |
| 심각도 | CVSS 4.0 9.2 | CVSS 4.0 9.2 |
연합뉴스가 인용한 월스트리트저널·로이터 보도에 따르면 이 결함은 인공지능(AI)을 활용해 찾아냈고, 10년 넘게 드러나지 않았던 것으로 평가됩니다. 원래 패치 공개일은 22일이었지만 전날 관련 정보가 온라인에 유출돼 일정이 당겨졌다는 보도(이데일리)도 있습니다. 공격 방법이 알려지기 전에 서둘러 막아야 하는 이유입니다.
PHP 개발팀은 PHP-FPM, 아파치 mod_php, PHP-CGI, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 PHP 환경을 모두 점검 대상으로 꼽았고, 그중 mod_php의 위험을 가장 높게 봤습니다. 다만 실행 방식과 설정에 따라 공격 조건이 달라서 모든 PHP 서버가 똑같이 뚫린다고 단정할 수는 없다고 덧붙였습니다.
우리 홈페이지가 PHP인지 어떻게 아나?
개발자가 아니어도 아래 단서로 대략 가늠할 수 있습니다. 하나라도 해당하면 PHP일 가능성이 높으니 관리 업체에 확인하는 것이 안전합니다.
| 단서 | 예시 | PHP 가능성 |
|---|---|---|
주소 끝이 .php | board.php?bo_table=notice, index.php | 매우 높음 |
| 그누보드·영카트로 만든 게시판·쇼핑몰 | 주소에 bbs/board.php, 관리자 주소 /adm | 매우 높음 (PHP 기반) |
| 워드프레스 사이트 | 관리자 주소 /wp-admin, 이미지 주소에 /wp-content/ | 높음 (PHP 기반) |
| XE·라이믹스, 제로보드 등 국내 게시판 솔루션 | 오래된 커뮤니티·동호회 사이트 | 높음 |
| 웹호스팅(리눅스) 상품에 직접 올린 사이트 | FTP로 파일을 올려 운영 | 높음 — 호스팅 관리화면에서 PHP 버전 확인 |
| 네이버 블로그·티스토리·스마트스토어 등 플랫폼 | 서버를 플랫폼이 운영 | 운영자가 할 일 없음 |
이미지 주소에 /wp-content/가 보여도 예전 워드프레스 시절 경로만 남긴 정적 사이트일 수 있습니다. 반대로 주소에 .php가 안 보여도 PHP로 도는 사이트는 많습니다. 확실한 답은 서버 관리자나 호스팅 관리화면에서 나옵니다.
박세준 티오리 대표는 "예전에 만들어 두고 잊은 사이트, 외주로 만든 쇼핑몰, 장비 관리 페이지에도 PHP가 숨어 있을 수 있다"고 말했습니다(뉴시스). 국내에는 그누보드 기반 사이트나 오래된 쇼핑몰처럼 PHP 5·7 같은 구버전을 쓰는 곳이 많다는 지적도 함께 나왔습니다.
내 PHP 버전이면 무엇을 해야 하나? 버전별 정리
8.2~8.5는 같은 계열의 최신 버전으로 올리면 되고, 8.1 이하는 더 큰 폭의 업그레이드가 필요합니다. 아래는 PHP 개발팀이 밝힌 수정 버전 목록을 기준으로 직접 정리한 표입니다.
| 지금 쓰는 버전 | 공식 수정 버전 | 할 일 | 난이도 |
|---|---|---|---|
| 8.5.x | 8.5.12 | 8.5.12 이상으로 업데이트 후 재시작 | 낮음 |
| 8.4.x | 8.4.27 | 8.4.27 이상으로 업데이트 후 재시작 | 낮음 |
| 8.3.x | 8.3.36 | 8.3.36 이상 (또는 배포판 보안 패키지) | 낮음 |
| 8.2.x | 8.2.35 | 8.2.35 이상으로 업데이트 후 재시작 | 낮음 |
| 8.1 이하 (7.x, 5.x 포함) | 목록에 없음 | 8.2 이상으로 업그레이드. 그누보드·플러그인 호환성 점검 필요 | 높음 — 제작 업체와 상의 |
리눅스 배포판의 PHP는 버전 숫자를 그대로 두고 보안 수정만 넣는 '백포트' 방식으로 고치기도 합니다. 예를 들어 우분투 24.04 LTS의 수정 패키지는 8.3.6-0ubuntu0.24.04.13입니다. 이 경우 숫자가 8.3.36보다 낮아 보여도 패치된 것이므로, 앞자리 숫자보다 배포판 패키지 전체 버전을 확인해야 합니다.
'php -v'로 확인하면 끝일까?
아닙니다. 가장 많이 하는 실수입니다. php -v 명령은 서버 명령창에서 쓰는 PHP 버전만 보여 줍니다. 웹사이트는 PHP-FPM이나 아파치 모듈처럼 별도로 설치된 PHP로 돌아가는 경우가 많아서, 두 버전이 다를 수 있습니다. 가상호스트마다 다른 PHP를 쓰거나, 컨테이너 이미지·호스팅 업체 제공 PHP·장비에 내장된 PHP라면 각각 따로 확인해야 합니다.
업데이트한 뒤에는 PHP-FPM·웹서버를 재시작하거나 컨테이너를 다시 배포해야 합니다. 이전 프로세스가 계속 떠 있으면 파일은 바뀌었어도 취약한 코드가 그대로 돌아갑니다.
당장 업데이트를 못 하면?
임시 설정은 일부 공격만 막습니다. 근본 대책은 패치뿐입니다. PHP 개발팀은 session.upload_progress.enabled=0 설정과 프로세스 재시작이 확인된 공격 경로 일부를 막지만 다른 변형까지 막지는 못한다고 밝혔습니다. PHP 8.5의 fatal_error_backtraces=0 설정도 특정 경로에만 효과가 있습니다.
그래서 CERT-EU와 국내 보안업계는 패치를 못 하는 동안 해당 사이트의 외부 접속을 임시로 막는 방안까지 권고했습니다. 쓰지 않는 옛 홈페이지라면 이번 기회에 내리는 것도 방법입니다.
패치했으면 끝인가? 이미 뚫렸는지도 봐야 한다
패치는 앞으로의 침입을 막을 뿐, 이미 들어온 공격자를 내보내지는 않습니다. 로그프레소 등 보안업계는 패치와 함께 다음 흔적을 점검하라고 권고했습니다(뉴시스).
- PHP 프로세스가 비정상 종료된 기록이 갑자기 늘었는지
- 서버를 원격 조종하는 악성 파일 '웹셸'이 업로드 폴더 등에 생겼는지
- 최근 수정된 적 없는 파일이 바뀌었거나 낯선 관리자 계정이 생겼는지
이상한 흔적이 보이면 한국인터넷진흥원(KISA) 보호나라나 118 상담센터에 신고하고, 고객 정보가 있는 쇼핑몰이라면 제작·관리 업체와 함께 대응하는 것이 좋습니다.
PHP2Shell 대응 체크리스트
- ☐ 우리 회사·가게가 운영하는 홈페이지·쇼핑몰·관리 페이지 목록을 적었다 (잊고 있던 옛 사이트 포함)
- ☐ 각 사이트가 PHP로 도는지 호스팅·제작 업체에 확인했다
- ☐ 웹서비스용 PHP(FPM·아파치 모듈) 버전이 8.2.35·8.3.36·8.4.27·8.5.12 이상이다
- ☐ 배포판 패키지라면 두 CVE가 수정된 패키지 버전인지 확인했다
- ☐ 업데이트 뒤 PHP-FPM·웹서버를 재시작했다
- ☐ 8.1 이하라면 업그레이드 일정을 업체와 잡았다 (그 전까지 외부 접속 차단 검토)
- ☐ 웹셸·비정상 종료·낯선 관리자 계정 등 침입 흔적을 점검했다
자주 묻는 질문
워드프레스를 최신으로 업데이트했는데 그걸로 충분한가요?
아닙니다. 워드프레스 보안업체 워드펜스는 워드프레스 자체 업데이트와 PHP 보안 업데이트는 별개라고 강조했습니다. 워드프레스 관리화면의 '사이트 건강' 메뉴나 호스팅 관리화면에서 PHP 버전을 따로 확인해야 합니다.
웹호스팅을 쓰는데 제가 직접 해야 하나요?
공용 웹호스팅은 보통 업체가 서버의 PHP를 관리하지만, 상품에 따라 고객이 PHP 버전을 직접 고르기도 합니다. 호스팅 관리화면에서 지금 쓰는 PHP 버전과 업체의 패치 공지를 확인하고, 구버전을 골라 두었다면 수정 버전으로 바꿔야 합니다.
개인 블로그(네이버·티스토리)도 위험한가요?
네이버 블로그나 티스토리처럼 플랫폼이 서버를 운영하는 서비스는 이용자가 PHP를 관리하지 않으므로 할 일이 없습니다. 직접 서버나 호스팅을 빌려 설치형 워드프레스·그누보드를 운영하는 경우에만 해당합니다.
방문자인 저도 조심해야 하나요?
이번 취약점은 웹사이트를 운영하는 서버의 문제라 방문자가 따로 설치할 업데이트는 없습니다. 다만 해킹된 사이트가 악성 파일을 내려받게 하거나 개인정보를 빼돌릴 수 있으니, 평소처럼 출처가 불분명한 파일은 내려받지 않는 것이 좋습니다.
출처: 데일리시큐(PHP 개발팀 보안 업데이트 정리, 10월 21일), 뉴시스·연합뉴스·파이낸셜뉴스·이데일리(10월 21일), CERT-EU 보안 권고.
