PHP2Shell 취약점 — 낡은 PHP 홈페이지·앱, 패치만으로 끝날까? 플러터 전환까지

무슨 일이 생겼나 — PHP2Shell 사태 요약

2026년 10월 21일, PHP 프로젝트가 CVE-2026-109618과 CVE-2026-109619 두 건의 원격 코드 실행(RCE) 취약점에 대한 긴급 패치를 배포했습니다. 보안업계에서는 이 공격 체인을 PHP2Shell이라고 부릅니다. 원래 22일 공개 예정이었지만 정보가 먼저 새어 나가 하루 앞당겨 배포됐고, 패치 공개 전부터 공격 시도가 관측됐습니다.

이번 사태 핵심 숫자

9.2/10

CVSS v4.0 — Critical 등급 (두 건 모두)

5.4~8.5

영향받는 PHP 버전 범위

0회

공격에 필요한 로그인 횟수 — 인증 불필요

10년+

코드에 숨어 있던 기간

출처: PHP 보안 공지, Tenable·The Hacker News 정리, KISA 보안공지(2026-10-21). 웹사이트의 약 70~75%가 PHP를 쓴다는 통계(W3Techs)가 함께 인용됐습니다.

어떤 문제인가 — 둘 다 PHP 엔진의 메모리 처리 결함입니다. 하나는 메모리 부족 상황에서 내부 데이터가 반쯤 초기화된 채 정리되는 문제, 다른 하나는 세션 업로드 진행률 기능 경로의 해제 후 사용(Use-After-Free) 문제입니다. 공격자가 워커 메모리를 읽어 비밀번호·토큰·API 키를 빼내거나, 코드 실행까지 이어갈 수 있습니다.
누가 대상인가 — PHP-FPM, Apache mod_php, php-cgi, LiteSpeed 등 웹 요청을 받는 모든 PHP 설치. 특히 mod_php는 애플리케이션 코드가 실행되기도 전에 요청 한 번으로 뚫릴 수 있어 가장 위험합니다.
어떻게 발견됐나 — Calif, Wiz, OpenAI 보안팀이 AI 모델의 도움으로 찾아냈습니다. 연구진은 "AI 없이는 찾기 어려웠을 가장 심각한 AI 발견 취약점"이라고 평했고, 앞으로 이런 발견이 급증할 것이라고 예고했습니다. 즉, 오래된 코드일수록 앞으로 더 자주 털린다는 뜻입니다.
국내 대응 — KISA가 10월 21일 보안 업데이트를 권고했고, 카페24는 같은 날 11:30부터 전 서버에 임시 조치를 순차 적용하며 고객에게 PHP 버전 업그레이드를 권고했습니다. 정부도 "매우 심각하게 보고 대응 중"이라고 밝혔습니다. 미국 NSA·FBI는 업데이트가 불가능하면 사이트를 내리라고까지 권고했습니다.

내 사이트가 해당되는지 3분 안에 확인하기

"우리는 워드프레스가 아니라 괜찮다", "외주 맡겨 만든 쇼핑몰이라 모른다"가 가장 위험한 상태입니다. 아래 순서로 확인하세요.

해당 여부 확인 4단계

PHP를 쓰는지부터주소가 .php로 끝나거나, 워드프레스·그누보드·XE·제로보드·카페24 독립형·자체 제작 쇼핑몰·관리자 페이지·앱 API 서버라면 거의 PHP입니다.

버전 확인호스팅 관리 화면의 PHP 버전 메뉴, 또는 서버에서 php -v. 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 미만이면 취약. 8.1 이하는 공식 지원 종료라 패치 자체가 없습니다.

호스팅 공지 확인카페24·가비아·닷홈 등 호스팅을 쓰면 업체가 서버 측 임시 조치를 했는지 공지를 확인. 단, 임시 조치는 완전한 방어가 아닙니다.

잊고 있던 사이트 목록화안 쓰는 옛 홈페이지, 이벤트 페이지, 장비 관리 페이지, 외주사가 떠난 뒤 방치된 관리자 사이트 — 이런 곳이 실제 침입 통로가 됩니다.

보안업계가 특히 경고한 대상이 "잊힌 사이트, 외주로 만든 쇼핑몰, 장비 관리 페이지"입니다. 방치된 PHP가 한 대만 있어도 같은 서버·같은 DB가 함께 뚫립니다.

지금 당장 할 것 — 패치가 유일한 완전 조치

PHP 측은 업데이트만이 유일한 완전한 수정이라고 못 박았습니다. 임시 설정은 위험을 줄일 뿐입니다.

구분	조치	비고
완전 조치	PHP를 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 이상으로 업데이트 후 워커 전부 재시작	리눅스 배포판 패키지는 버전 번호가 낮아 보여도 패치가 포함될 수 있으니 변경 로그에서 CVE 번호 확인
임시 완화	`session.upload_progress.enabled=0`, `memory_limit=-1`(앱이 덮어쓰지 못하게), `post_max_size` 축소, 웹서버·프록시에서 요청 크기 제한	확인된 경로만 막음. 세션 기능 오류 가능. 완전 방어 아님
침해 점검	비정상 multipart 요청 뒤 메모리 한도 오류·반복 500 응답, 비정상적으로 큰 PHPSESSID 쿠키, 원인 모를 PHP 워커 재시작, 웹셸·수상한 외부 접속	패치 전 노출됐다면 비밀번호·API 키·인증서 교체까지
최후 수단	업데이트가 불가능하면 외부 접근 차단 또는 사이트 일시 중단	NSA·FBI·CERT-EU 권고

EOL 버전이면 여기서 막힙니다. PHP 7.4·8.0·8.1은 소스 백포트만 있고 공식 릴리스가 없으며, 5.4~7.3은 아예 수정이 없습니다. 오래된 그누보드·제로보드·외주 쇼핑몰은 대부분 이 구간입니다. "패치하면 된다"가 통하지 않는 사이트가 국내에 많습니다.

패치해도 끝나지 않는 이유 — 레거시 PHP의 구조적 문제

이번 일이 처음이 아닙니다. 2024년 PHP-CGI 취약점(CVE-2024-4577), 2019년 PHP-FPM 취약점(CVE-2019-11043)은 랜섬웨어에 실제로 쓰였고, 이번 PHP2Shell은 2004년 연구에서 뿌리가 시작된 10년 넘은 코드에서 나왔습니다. 앞으로 AI가 오래된 코드의 틈을 훨씬 빨리 찾아내는 시대입니다.

왜 오래된 PHP 사이트가 반복해서 위험해지나

EOL 버전 — 패치 자체가 없음

가장 큼

개발사 연락 두절 — 올릴 사람 없음

큼

버전 올리면 옛 코드가 깨짐

중간~큼

서버 OS·웹서버·PHP를 직접 관리

중간

플러그인·테마·게시판 모듈 취약점

상시

경험 기반 상대 표현이며 측정 수치가 아닙니다. 핵심은 "패치할 수 없거나, 패치할 사람이 없거나, 패치하면 깨지는" 세 가지가 겹친다는 점입니다.

PHP 자체가 나쁜 언어라서가 아닙니다. 최신 PHP를 꾸준히 올리며 운영하는 서비스는 이번에도 하루 만에 패치했습니다. 문제는 "만들고 방치된 PHP" — 서버·언어·프레임워크·플러그인 네 겹을 전부 내가(또는 연락 안 되는 외주사가) 책임져야 하는 구조입니다. 저희도 수백 세대 관리 PHP 플랫폼을 넘겨받아 운영하며 이 네 겹을 매번 손으로 챙겨 왔습니다.

플러터 + 관리형 백엔드로 바꾸면 뭐가 달라지나

플러터(Flutter)는 구글이 만든 앱·웹 프레임워크로, 한 코드로 iOS·안드로이드 앱과 웹을 동시에 만듭니다. 여기에 백엔드를 파이어베이스(Firebase) 같은 관리형 서비스로 두면, 내가 패치해야 할 서버 런타임이 사라집니다.

구조 비교 — 책임 범위가 어떻게 바뀌나

왼쪽은 네 겹 전부를 직접 챙겨야 하고, 오른쪽은 아래 두 겹을 플랫폼이 맡습니다. 내 책임이 "앱 코드 + 보안 규칙"으로 줄어듭니다.

보안 관점 비교

레거시 PHP 웹·앱

서버에 PHP 런타임이 항상 열려 있음 → 이번 같은 엔진 취약점에 직접 노출
OS·웹서버·PHP·플러그인 패치를 전부 직접
EOL 버전이면 패치 자체가 없음
외주사가 떠나면 올릴 사람이 없음
버전 올리면 옛 코드가 깨져 사실상 재개발

플러터 + 관리형 백엔드

앱은 네이티브로 컴파일 — 서버 스크립트 런타임 노출 없음
인증·DB·저장소·서버 패치를 구글(Firebase)이 자동 운영
보안 규칙(Firestore 규칙)·API 키만 잘 관리하면 됨
iOS·안드로이드·웹 한 코드 — 유지보수 대상이 하나
최신 프레임워크라 업데이트가 점진적·예측 가능

"보안 걱정 제로"가 아니라 "내가 챙길 겹이 넷에서 둘로 줄고, 나머지는 자동"이 정확한 표현입니다. 새 영역(보안 규칙·키 관리)은 저희 Firebase 보안 체크리스트로 점검합니다.

PHP 사이트를 플러터로 옮기는 순서

한 번에 갈아엎지 않습니다. 서비스를 멈추지 않고 DB → 핵심 화면 → 나머지 순으로 옮기는 게 안전합니다.

전환 5단계

긴급 봉합 + 자산 확보먼저 패치 또는 임시 완화·접근 차단으로 출혈을 멈추고, 소스·DB·도메인·계정을 확보합니다(인수 체크리스트).

기능·화면 목록화실제로 쓰는 화면만 추립니다. 10년 된 사이트는 안 쓰는 기능이 절반 — 옮기지 않으면 비용이 줄어듭니다.

데이터 이전MySQL 회원·게시글·주문을 Firestore(또는 관리형 DB)로 옮기고, 비밀번호는 재설정 흐름으로 안전하게 전환.

핵심 화면부터 플러터로로그인·메인·주문처럼 가장 많이 쓰는 화면을 먼저 출시(앱 + 웹 동시). 나머지 화면은 옛 PHP를 차단한 상태에서 순차 전환.

PHP 서버 폐기 + 월정액 운영옛 서버를 내리고, 이후 OS 업데이트·규칙 점검·스토어 대응을 월정액 유지보수로.

저희는 플러터 앱 이전과 레거시 PHP 운영을 둘 다 해 왔기 때문에, 옛 구조의 함정을 알고 새 구조로 옮깁니다.

비용·기간 현실 — 패치 vs 버전 업 vs 재구축

세 가지 선택지의 상대적 부담을 솔직하게 비교하면 아래와 같습니다.

선택지	가능한 경우	장점	한계
① 패치만	PHP 8.2 이상 + 올릴 사람이 있음	가장 빠르고 쌈. 오늘 끝남	다음 취약점 때 또 반복. EOL이면 불가
② PHP 버전 업	소스가 있고 코드가 비교적 최근	구조 유지, 당분간 지원 받음	옛 코드·플러그인이 깨져 사실상 수정 개발. PHP 8.2도 2026-12-31 지원 종료
③ 플러터 재구축	EOL PHP, 외주사 두절, 앱도 필요	런타임 패치 책임 소멸, 앱+웹 한 코드, 이후 유지비 예측 가능	초기 비용·기간이 가장 큼. 데이터 이전 작업 필요

초기 부담 vs 이후 반복 부담 (상대 비교)

① 패치만 — 초기

매우 낮음

① 패치만 — 매번 반복

높음(계속)

② 버전 업 — 초기

중간

③ 플러터 재구축 — 초기

높음

③ 플러터 재구축 — 이후 반복

낮음·예측 가능

경험 기반 상대 표현이며 금액이 아닙니다. 정확한 비용은 현재 화면·기능 목록을 받아 산정합니다. 판단 기준은 리뉴얼 vs 새로 만들기를 참고하세요.

이런 분께 재구축을 권합니다. PHP 7.x 이하 사이트를 쓰고 있다 / 만든 업체와 연락이 안 된다 / 어차피 모바일 앱도 필요했다 / 최근 1년 안에 "서버 이상해요"를 한 번 이상 들었다. 넷 중 둘 이상이면 패치가 아니라 구조를 바꿀 때입니다.

자주 묻는 질문

PHP2Shell 취약점은 워드프레스·그누보드 같은 특정 프로그램만 해당되나요?

아닙니다. 프로그램(워드프레스·그누보드·자체 제작 쇼핑몰 등)이 아니라 PHP 엔진 자체의 문제라서, PHP로 돌아가는 모든 웹서비스가 대상입니다. PHP 5.4부터 8.5까지 거의 모든 버전이 영향을 받고, 로그인 없이도 공격이 가능합니다.

호스팅 업체(카페24 등)가 패치했다면 저는 아무것도 안 해도 되나요?

호스팅사가 서버 쪽 임시 조치·패치를 적용했다면 당장의 위험은 줄어듭니다. 다만 업체 공지에서도 PHP 버전 자체를 최신으로 올리라고 권고합니다. 특히 지원이 끝난(EOL) PHP 버전을 쓰고 있다면 이번 패치를 공식적으로 받을 수 없으니 버전 전환이나 재구축을 검토해야 합니다.

플러터로 바꾸면 PHP 취약점 문제가 완전히 사라지나요?

플러터 앱은 PHP 실행 환경 없이 동작하고, 백엔드를 파이어베이스 같은 관리형 서비스로 옮기면 서버 OS·언어 런타임 패치를 직접 챙길 일이 없어집니다. 그래서 이번 같은 '런타임 취약점' 계열 위험은 사라집니다. 다만 보안 규칙·API 키 관리 같은 새 영역의 관리는 필요하므로 '보안 걱정 제로'가 아니라 '관리 포인트가 줄고 자동화된다'가 정확한 표현입니다.

PHP 사이트를 플러터로 다시 만들면 기간과 비용은 얼마나 드나요?

화면 수·회원·결제·관리자 기능에 따라 달라집니다. 정보형 홈페이지는 짧게, 회원·결제·관리자까지 있는 쇼핑몰·플랫폼은 단계적으로 옮깁니다. 기존 DB를 먼저 옮기고 가장 많이 쓰는 화면부터 순서대로 전환하면 서비스를 멈추지 않고 진행할 수 있습니다. 정확한 범위와 금액은 현재 사이트 기능 목록을 받아 무료 점검에서 산정해 드립니다.

내 PHP 사이트, 해당되는지 무료로 점검해 드립니다

사이트 주소만 알려주시면 PHP 버전·노출 여부·EOL 여부를 확인하고, 패치로 끝낼 수 있는지 / 플러터로 옮기는 게 맞는지 범위와 순서를 먼저 알려드립니다. 외주사와 연락이 끊긴 사이트도 인수해서 진행합니다.

무료 점검 문의 → appmonster.co.kr

문의: appmonster.kr@gmail.com