PHP2Shell이란? PHP 원격코드실행 취약점 2건 총정리｜영향 버전·패치 버전·웹사이트 운영자 대응법

깨진 자물쇠가 빛나는 서버실로 표현한 PHP2Shell 취약점 - AI 생성 이미지

 

전 세계 웹사이트의 상당수를 움직이는 프로그래밍 언어 PHP에서 심각한 원격 코드 실행(RCE) 취약점 2건이 공개됐습니다. 보안업계는 이 취약점에 'PHP2Shell'이라는 이름을 붙였고, PHP 프로젝트는 원래 일정보다 하루 앞당긴 10월 21일(현지시간) 긴급 보안 업데이트를 내놓았습니다.

한국 Google Trends에서도 지난 24시간 동안 'php', 'php2shell', 취약점 번호 'cve-2026-109618'이 함께 급상승했습니다. 블로그·쇼핑몰·회사 홈페이지를 직접 운영하는 사람이라면 "내 사이트도 해당되나?", "무엇부터 해야 하나?"가 가장 궁금할 것입니다.

이 글에서는 PHP2Shell이 무엇인지 쉬운 말로 설명하고, 영향 범위와 패치 버전, 운영자가 지금 확인할 순서, 그리고 이번 사건에서 AI가 어떤 역할을 했는지까지 정리합니다. 공격 방법은 다루지 않고 방어와 점검에 필요한 정보만 담았습니다.

📌 한눈에 보기: 취약점 CVE-2026-109618·CVE-2026-109619 · PHP 공식 평가 CVSS v4.0 9.2(치명적) · 인증 없이 원격 코드 실행 가능 · 패치 버전 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 · 8.1 이하는 공식 패치 없음. (출처: The Hacker News·Help Net Security·SC Media 2026.10.21 보도, 로그프레소 대응 권고)

왜 PHP2Shell이 갑자기 검색되나

발단은 정보 유출이었습니다. The Hacker News 보도에 따르면 10월 20일 한 온라인 커뮤니티에 취약점 번호와 '10월 22일 공개 예정'이라는 일정이 먼저 올라왔고, 같은 날 한 연구팀이 개념 증명 영상을 실수로 공개했습니다. PHP 프로젝트는 그날 저녁 사전 공지를 내고 패치 공개를 10월 21일로 앞당겼습니다.

패치 공개 직후 보안업체 watchTowr는 두 취약점을 노린 공격 시도가 관측된다고 밝혔고, Cloudflare도 초기 공격을 확인했다고 전했습니다. 미국 사이버보안·인프라보안청(CISA)은 PHP 기반 웹사이트를 운영하는 모든 조직에 즉시 패치를 권고했습니다. 다만 10월 21일 보도 시점까지 실제 침해가 확인된 사례는 공개되지 않았습니다.

핵심 팩트: 무엇이 확인됐나

항목	내용	상태
취약점 번호	CVE-2026-109618, CVE-2026-109619	확정
심각도	PHP 공식 평가 CVSS v4.0 9.2(Critical). 일부에서 퍼진 10.0은 공식 점수가 아님	확정
유형	인증 없이 서버에서 원격 코드 실행 가능. 애플리케이션 코드가 실행되기 전 단계에서 발생	확정
영향 버전	PHP 5.4 이후 대부분의 버전(보도 기준)	보도
패치 버전	8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (10월 21일 공개)	확정
지원 종료 버전	8.1 이하는 PHP 프로젝트의 공식 패치 없음. 7.4·8.0·8.1용 소스 백포트와 리눅스 배포판 자체 패치 존재	확정
악용 현황	공격 시도 관측(watchTowr·Cloudflare). 실제 침해 확인 사례는 보도 시점 기준 미공개	진행 중

출처: The Hacker News·Help Net Security·SC Media(2026.10.21), 로그프레소 보안 권고(2026.10.21). 상황이 빠르게 바뀌고 있어 최신 내용은 php.net 공지와 각 배포판 보안 공지를 확인하세요.

쉽게 설명: PHP2Shell은 어떤 문제인가

① PHP는 웹사이트의 '엔진'입니다

PHP는 웹페이지를 만들어 보내 주는 서버 쪽 프로그래밍 언어입니다. 워드프레스, 드루팔, 줄라 같은 홈페이지 제작 도구와 우커머스 같은 쇼핑몰 솔루션이 PHP 위에서 돌아갑니다. 국내에서 널리 쓰이는 게시판·홈페이지 빌더 중에도 PHP 기반이 많습니다. SC Media는 전체 웹사이트의 약 70%가 PHP로 작성된 프로그램을 쓰고 있다고 전했습니다.

② 이번 문제는 '앱'이 아니라 '엔진'에 있습니다

보통 웹사이트 보안 사고는 워드프레스 플러그인처럼 그 위에서 돌아가는 프로그램(애플리케이션)의 허점에서 생깁니다. PHP2Shell은 다릅니다. 취약점이 PHP 실행 환경(런타임) 자체에 있어서, 사이트 코드를 아무리 안전하게 짜도 영향을 받을 수 있습니다.

그래서 중요한 주의점이 하나 생깁니다. 워드프레스나 플러그인을 최신 버전으로 업데이트해도 PHP 런타임은 업데이트되지 않습니다. 서버에 설치된 PHP 자체를 패치 버전으로 올려야 합니다.

③ 원리는 '앞 손님의 흔적이 남은 작업대'에 가깝습니다

PHP 서버는 '워커'라는 작업자가 요청을 하나씩 받아 처리합니다. 보도된 설명에 따르면 두 취약점은 메모리가 부족해 처리가 중간에 끊기거나, 앞선 요청이 쓰던 내부 정보가 정리되지 않은 채 남는 상황과 관련이 있습니다. 비유하자면 앞 손님의 재료가 치워지지 않은 작업대에서 다음 손님의 주문을 처리하다 엉뚱한 결과가 나오는 셈입니다.

이 틈을 이용하면 공격자가 서버에서 원하는 명령을 실행하거나, 코드 실행까지 가지 않더라도 워커 메모리에 남아 있던 다른 요청의 정보(로그인 토큰, 비밀번호, API 키 등)를 읽어 낼 수 있다는 분석이 나왔습니다.

요청 사이에 남은 메모리 조각을 작업대 비유로 표현한 개념도 - AI 생성 이미지

내 서버는 해당될까: 운영 방식별 위험도

운영 방식	보도된 위험도	비고
Apache + mod_php	가장 높음	단일 요청으로 공격이 시연된 환경
PHP-FPM(Nginx 등)	영향 있음	한 취약점은 애플리케이션 동작에 따라 코드 실행까지 가능하다는 분석
php-cgi · FrankenPHP · LiteSpeed	영향 있음	웹 요청을 처리하는 PHP 설치는 모두 점검 대상
공유·웹호스팅	호스팅사 패치에 좌우	직접 패치가 어려우므로 호스팅사 공지 확인

출처: Help Net Security·The Hacker News(2026.10.21) 보도 정리. 세부 위험도는 설정과 애플리케이션에 따라 달라질 수 있습니다.

웹사이트 운영자가 지금 할 일

보안업계 권고를 종합하면 순서는 단순합니다. 버전 확인 → 패치 → 재시작 → 흔적 점검입니다.

• 1. 버전 확인: 서버에서 php -v로 버전을 확인합니다. 리눅스 배포판 패키지는 버전 번호가 낮아 보여도 보안 수정이 들어간 경우가 있으니 패키지 변경 기록에서 CVE 번호를 확인합니다.
• 2. 패치 적용: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 이상으로 올리거나, 배포판·LTS 업체의 보안 패키지를 설치합니다. 도커를 쓰면 수정된 이미지로 다시 빌드합니다.
• 3. 재시작: 패치 후 Apache, PHP-FPM, 오래 실행되는 워커를 모두 재시작해야 적용됩니다.
• 4. 지원 종료 버전: 8.1 이하는 공식 패치가 없으므로 배포판 백포트를 쓰거나 지원 버전으로 업그레이드 일정을 서둘러야 합니다. 보도에 따르면 PHP 8.2도 2026년 12월 31일 지원이 끝납니다.
• 5. 임시 조치: 당장 패치가 어렵다면 session.upload_progress.enabled=0 설정, 요청 크기 제한 강화, 웹방화벽(WAF) 규칙 적용이 권고됐습니다. 이는 패치를 대신하지 못하는 부분 조치입니다. 영국 NCSC는 패치가 불가능한 시스템은 오프라인 전환을 고려하라고 권고했습니다.
• 6. 흔적 점검: PHP 워커의 비정상 종료나 500 오류 급증, 업로드 기능이 없는 경로로 들어온 대용량 multipart 요청, 웹 디렉터리의 낯선 PHP 파일, 웹서버 프로세스의 이상한 외부 연결을 확인합니다.

웹사이트를 운영하지 않는 일반 이용자가 직접 할 수 있는 일은 많지 않습니다. 다만 이용 중인 사이트에서 비밀번호 변경 안내가 오면 따르고, 중요한 계정에는 2단계 인증을 켜 두는 것이 좋습니다.

비교·배경: 이번 사건에서 AI가 맡은 역할

PHP2Shell이 유독 주목받는 이유 중 하나는 AI가 양쪽 모두에 등장했다는 점입니다. 보도에 따르면 이번 취약점은 Wiz 연구팀과 OpenAI 보안팀 등 여러 연구진이 보고했고, 수정 과정에는 PHP 보안팀과 함께 구글 제미나이 팀이 참여했습니다. 2024년 외부 감사에서 메모리 결함의 흔적이 처음 발견됐지만 당시에는 실제 공격으로 이어지지 않았다는 점도 전해졌습니다.

반대로 Wiz는 최신 AI 모델이 취약점을 실제 공격 코드로 바꾸는 데 드는 노력을 크게 줄였다고 지적했습니다. 취약점 정보가 유출된 지 하루 만에 공격 시도가 관측된 것도 이런 흐름과 맞물려 해석됩니다. 패치가 나오고 공격이 시작되기까지의 시간이 점점 짧아지고 있다는 뜻입니다.

AI가 보안 위협의 속도를 어떻게 바꾸는지는 AI 자기복제는 어디까지 가능할까? AI 웜·IoT 보안에서, 오래된 설비가 공격 경로가 되는 사례는 프랑스 냉장고 해킹 사건 분석에서 함께 볼 수 있습니다.

규모도 문제입니다. 인터넷 스캔 결과 외부에 노출된 PHP 서비스가 약 440만 개로 집계됐고, PHP 사이트의 약 80%가 지원이 끝난 버전을 쓴다는 연구 결과도 보도됐습니다. 보안 연구자 할 포머란츠는 패치되지 않은 임베디드 장비와 '잊힌 서버'의 긴 꼬리를 경고했습니다.

서버를 패치하고 방어막을 세우는 대응 과정을 표현한 장면 - AI 생성 이미지

한국 독자에게 의미

첫째, 소규모 사이트가 가장 취약할 수 있습니다. 대기업은 보안팀이 바로 대응하지만, 오래전에 만든 회사 홈페이지나 동호회 게시판, 개인 쇼핑몰은 관리자가 PHP 버전조차 모르는 경우가 많습니다. 외주 업체나 호스팅사에 맡겨 둔 사이트라면 이번 주 안에 패치 여부를 직접 물어보는 것이 좋습니다.

둘째, 쇼핑몰은 결제 정보 위험을 따로 봐야 합니다. 로그프레소 권고는 전자상거래 사이트의 결제 페이지에 카드 정보를 가로채는 스크립트가 삽입될 수 있다며 우선 점검을 권했습니다.

셋째, 이번 사건은 '지원 종료(EOL) 소프트웨어'의 비용을 보여 줍니다. 공식 패치가 나와도 지원이 끝난 버전은 받을 수 없습니다. 이번 기회에 서버 소프트웨어의 지원 기한을 정리해 두면 다음 사고 때 대응 시간을 줄일 수 있습니다.

앞으로 볼 포인트

• 실제 침해 사례 공개 여부: 현재는 공격 시도 단계로 보도되고 있습니다. 침해 확인이나 CISA의 '실제 악용 취약점(KEV)' 목록 등재 여부가 다음 신호입니다.
• 국내 기관 공지: 한국인터넷진흥원(KISA) 보호나라 등 국내 기관의 보안 공지와 호스팅사 안내를 확인할 필요가 있습니다.
• 지원 종료 버전 대응: 8.1 이하를 쓰는 서버가 얼마나 빨리 업그레이드되는지가 피해 규모를 좌우할 수 있습니다.
• 추가 패치: 패치에 강화된 메모리 제한이 들어가면서 일부 애플리케이션 동작이 달라질 수 있다는 안내가 있어, 후속 수정 릴리스가 나올 수 있습니다.

자주 묻는 질문(FAQ)

Q1. 워드프레스를 최신 버전으로 업데이트하면 해결되나요?

아닙니다. 문제는 워드프레스가 아니라 그 아래의 PHP 런타임에 있습니다. 서버의 PHP를 패치 버전으로 올리고 재시작해야 합니다.

Q2. 패치된 버전은 무엇인가요?

PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 리눅스 배포판 패키지는 번호가 다를 수 있으니 보안 공지에서 CVE-2026-109618·109619 반영 여부를 확인하세요.

Q3. 웹호스팅을 쓰는데 제가 할 일이 있나요?

공유 호스팅은 사업자가 PHP를 관리하는 경우가 많습니다. 호스팅사 공지를 확인하고, 관리 화면에서 PHP 버전을 고를 수 있다면 지원되는 최신 버전으로 바꾸는 것이 좋습니다.

Q4. 일반 이용자도 위험한가요?

직접 서버를 운영하지 않는다면 할 수 있는 조치는 제한적입니다. 이용하는 사이트의 비밀번호 변경 안내를 따르고, 2단계 인증을 켜 두는 정도가 현실적인 대비입니다.

※ 이 글은 2026년 10월 21일 공개된 PHP 보안 업데이트와 보안업계 보도를 바탕으로 정리했습니다. 상황이 빠르게 바뀌는 사안이므로 실제 조치 전 php.net과 사용 중인 배포판·호스팅사의 최신 공지를 확인하세요.