PHP 취약점 PHP2Shell 총정리 — 보안 업데이트 버전·점검·대응법

어제까지 멀쩡하던 쇼핑몰이나 회사 홈페이지를 두고 “우리 사이트도 PHP라는데 괜찮은 거냐”는 질문을 받으셨다면, 이번 사태의 한가운데에 계신 겁니다. 10월 21일 PHP 프로젝트가 긴급 보안 업데이트를 내놓으며 시작된 이번 PHP 취약점 사태, 일명 PHP2Shell은 로그인 없이 원격에서 서버 코드를 실행할 수 있는 수준의 결함이라 유럽 일부 정부 기관이 웹사이트를 예방 차원에서 내리기까지 했습니다. 다만 “전 세계 웹사이트 70%가 해킹됐다” 같은 과장된 이야기도 함께 퍼지고 있어서, PHP 공식 공지와 KISA 보호나라 권고를 기준으로 사실과 대응 방법만 추려 정리했습니다.

PHP2Shell, 무슨 일이 있었나

PHP2Shell은 PHP 코어에서 발견된 원격 코드 실행 취약점 2건을 묶어 부르는 비공식 별칭입니다. PHP 프로젝트가 붙인 이름은 아니며, 2021년 전 세계를 흔든 Log4Shell을 떠올리게 하는 이름이라 빠르게 퍼졌습니다.

처음 유출된 정보에는 10.0점으로 적혀 있었지만, PHP 재단은 이를 잘못된 점수라고 밝혔습니다. 공식 평가는 두 건 모두 9.2점입니다.

📅 날짜별로 보는 사태 흐름

1. 2026년 8월 11일: 보안 업체 Calif가 PHP에 첫 원격 코드 실행 문제를 보고합니다. 이후 Wiz(8월 24일), OpenAI(9월 18일)도 추가 공격 경로를 보고했습니다.
2. 10월 17일: 아마존은 나중에 자사 허니팟 기록에서 이날부터 공격 시도를 발견했다고 밝혔습니다. 성공 여부는 확인되지 않았습니다.
3. 10월 20일: CVE 번호와 “CVSS 10.0” 정보가 Hacker News 등에 유출되자, PHP는 패치 공개를 하루 앞당긴다고 사전 경고했습니다.
4. 10월 21일 23시(한국 시간): 수정 버전 4개가 공식 공개됐고, KISA도 같은 날 보안 업데이트 권고를 냈습니다.
5. 10월 22일: KISA가 기업 대응 수칙을 게시했고, 언론에 따르면 과학기술정보통신부는 민간 분야 사이버위기 경보를 ‘주의’로 올렸습니다.
6. 10월 23일: PHP가 별도의 추가 취약점(CVE-2026-115560)에 대한 권고를 냈습니다.

🤖 정말 AI가 찾아냈을까

“AI가 14년 된 버그를 찾았다”는 제목이 많았는데, 절반만 맞는 이야기입니다. Calif는 과거 취약점을 잘 아는 연구자가 조사 방향을 잡고, AI 모델의 도움을 받아 코드를 검토했다고 설명합니다. AI가 사람 없이 혼자 PHP를 훑어 버그를 찾아낸 것은 아닙니다. 오히려 PHP 재단은 2024년 외부 감사 때 이미 문제의 징후를 봤지만 수정이 늦어졌다며, 스스로 “구조적 실패”라고 인정했습니다.

영향 범위와 PHP 보안 업데이트 버전

PHP 보안 업데이트의 기준이 되는 수정 버전은 아래와 같습니다. 이보다 낮은 버전이라면 모두 영향을 받습니다.

🔹 지원이 끝난 구버전은 어떻게 되나

이번 사태가 심각하다 보니 PHP 보안팀이 이례적으로 7.4·8.0·8.1용 최소 백포트를 내놨습니다. 다만 일반 사용자가 바로 설치하는 새 릴리스가 아니라 소스 수정본이라서, 실제로는 Debian·Red Hat 같은 배포판이나 호스팅사가 패키지로 만들어 줘야 쓸 수 있습니다. Red Hat은 RHEL 9·10용 수정 패키지를 10월 21일에 냈고, Debian도 보안 공지(DSA-6574-1)를 발행했습니다.

여기서 흔히 하는 실수가 있습니다. 배포판이 보안 수정을 백포트하면 PHP 버전 숫자는 그대로인데 패치는 들어가 있는 경우가 많습니다. 버전 숫자만 보고 “아직 취약하다” 혹은 “안전하다”고 판단하지 말고, 패키지 변경 이력에 두 CVE가 반영됐는지 확인해야 합니다.

🔹 어떤 서버 구성이 위험한가

• Apache mod_php: PHP가 가장 위험한 구성으로 꼽았습니다. 애플리케이션 코드가 실행되기도 전에 공격이 가능한 경로가 확인됐습니다.
• PHP-FPM: 안전하다고 볼 수 없습니다. 애플리케이션 코드를 거치는 공격 경로가 확인됐습니다.
• php-cgi·FrankenPHP·LiteSpeed: 웹 요청을 처리하는 한 모두 대상입니다.
• 로그인 페이지가 있는 사이트: 일부 경로는 로그인 확인 전에 발생하므로, 회원 전용 사이트라고 안심할 수 없습니다.

🔹 ‘웹사이트 70%’ 숫자의 진실

“PHP가 전 세계 웹사이트의 약 70%에 쓰인다”는 것은 보안 업체의 사용 비중 추정치입니다. 70%가 이번 취약점으로 공격 가능하다거나, 70%가 해킹됐다는 뜻이 아닙니다. 실제 위험은 설치된 버전, 실행 방식, 패치 여부에 따라 사이트마다 다릅니다. 국내에서 보도된 “약 11만 건”도 취약한 PHP가 설치된 것으로 추정되는 인터넷 자산 수이지, 피해 건수가 아닙니다.

국내외 정부·기관은 어떻게 대응했나

핀란드 정부 ICT 기관은 10월 21일 공공 인터넷 서비스를 예방적으로 중단하고 같은 날 PHP 업데이트 설치에 들어갔습니다. 네덜란드, 프랑스 등에서도 일부 사이트가 예방 차원에서 내려갔습니다. 중요한 점은 예방적 중단이 곧 해킹 피해를 뜻하지는 않는다는 것입니다.

국내에서는 KISA가 가장 빠르게 움직였습니다.

• 10월 21일: 보호나라에 「PHP 제품 보안 업데이트 권고」를 게시하고, 수정 버전과 구버전 전환을 안내했습니다.
• 10월 22일: 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」을 게시했습니다. 재시작, 컨테이너 재배포, 로그 점검, 인증정보 교체, 침해 신고까지 담겼습니다.
• 긴급 전파: 보도에 따르면 중요 정보통신기반시설, ISMS 인증 기업, 웹호스팅사에 직접 전파했습니다.

호스팅사 중에서는 가비아가 10월 22일 새벽 PHP 7.4·8.4·8.5 대상 긴급 작업을 공지했고, 카페24도 보안 패치를 적용하고 고객 공지를 낸 것으로 보도됐습니다. 다만 지원 종료 버전에는 완전한 패치 대신 백포트나 임시 완화가 적용된 경우도 있어, 내 상품에 정확히 무엇이 적용됐는지는 따로 확인하는 것이 좋습니다.

내 서버 점검과 PHP 버전 확인 방법

PHP 버전 확인에서 가장 중요한 원칙은 “설치된 PHP”가 아니라 “실제로 웹 요청을 처리하는 PHP”를 확인하는 것입니다. php -v는 명령줄용 PHP만 보여주기 때문에, 웹 서비스가 쓰는 PHP-FPM이나 Apache 모듈은 버전이 다를 수 있습니다.

1. 🔍 직접 운영하는 서버라면

아래는 버전과 패키지를 확인하는 기본 명령입니다.

# 명령줄 PHP 버전과 위치
php -v
command -v php

# 실행 중인 PHP·웹서버 프로세스
ps -eo pid,args | grep -E 'php-fpm|apache2|httpd|lsphp|frankenphp'

# Debian·Ubuntu 계열 설치 패키지
dpkg-query -W 'php*'

# RHEL 계열 설치 패키지
rpm -qa | grep -E '^php'

KISA 대응 수칙을 바탕으로 한 업데이트 순서는 다음과 같습니다.

1. 인터넷에 노출된 자산부터 찾습니다. 외주로 만든 사이트, 이벤트·테스트 서버, 관리자 페이지, 장비에 내장된 PHP, 컨테이너까지 포함합니다.
2. 사용 중인 배포판의 수정 패키지를 확인하고, 테스트 후 적용합니다.
3. PHP를 실행하는 모든 서비스를 재시작합니다. 패키지만 바꾸고 기존 워커가 살아 있으면 옛 코드가 계속 돌아갑니다. 컨테이너는 새 이미지로 다시 배포합니다.
4. 웹 환경에서 실제 버전과 주요 기능이 정상인지 다시 확인합니다.

2. 🏠 호스팅을 쓰고 있다면

카페24·가비아 같은 호스팅을 쓰고 있다면 서버를 직접 고칠 수는 없으니, 고객센터나 공지에서 아래 네 가지를 확인하세요.

• 수정 여부: CVE-2026-109618과 109619가 모두 수정됐는가
• 조치 방식: 정식 업데이트인가, 백포트인가, 임시 완화인가
• 적용 시각: 언제 적용했고 서비스 재시작까지 끝났는가
• 구버전 계획: 내 상품이 PHP 7.x라면 언제 상위 버전으로 옮겨야 하는가

3. ⏳ 당장 패치가 어렵다면

PHP의 공식 입장은 “업데이트만이 완전한 해결책”입니다. 아래 조치는 일부 경로를 줄여 줄 뿐이니, 업데이트 전까지 버티는 용도로만 쓰세요.

• 요청 제한: 웹서버·프록시·WAF에서 요청 크기와 입력 구조를 제한합니다.
• 업로드 차단: 파일 업로드가 필요 없는 서비스는 PHP 앞단에서 multipart 요청을 막는 것을 검토합니다.
• 업로드 진행률 끄기: session.upload_progress.enabled=0을 php.ini나 FPM 설정에 넣고 모든 워커를 재시작합니다. ini_set()이나 .user.ini로는 효과가 없습니다.
• 최후 수단: 이것도 어렵다면 KISA는 업데이트 전까지 외부 접속 차단이나 서비스 일시 중단을 검토하라고 권고합니다.

이미 침해됐는지 점검하는 법

아마존이 10월 17일부터 공격 시도를 관측했다고 밝혔기 때문에, 로그 점검은 10월 17일 또는 그 이전부터 보는 것이 좋습니다.

📌 확인할 흔적

• 웹·WAF 로그: 비정상 요청 뒤에 반복되는 HTTP 500 오류가 있는지 시간순으로 봅니다.
• PHP·Apache 오류 로그: 원인 모를 메모리 부족, segfault, 워커 비정상 종료가 있었는지 확인합니다.
• 프로세스: 웹서버가 sh, bash, 다운로드 도구를 실행한 흔적이 있는지 봅니다.
• 파일: 웹·업로드·임시 폴더에 새로 생기거나 바뀐 PHP 파일, 결제 페이지에 끼워 넣어진 외부 스크립트가 있는지 확인합니다.
• 네트워크: 웹서버에서 예상하지 못한 외부 연결이 나갔는지 점검합니다.

🔴 침해가 의심되면 순서가 다릅니다

침해 흔적이 보이면 바로 패치하고 재시작하고 싶어지지만, KISA는 외부 접속 격리 → 신고 → 로그·프로세스 등 증거 확보 → 업데이트·웹셸 제거·인증정보 교체 순서를 권고합니다. 증거를 남기기 전에 서버를 끄거나 재시작하면 원인 분석이 어려워집니다. 신고는 보호나라 또는 국번 없이 118로 할 수 있습니다.

유출 논란과 Log4Shell 비교

이번 사태가 유독 혼란스러웠던 이유는 정보가 정해진 순서대로 공개되지 않았기 때문입니다. 원래 PHP는 배포판과 호스팅사가 패키지를 준비할 시간을 주려고 10월 22일 공개를 계획했습니다. 그런데 공개 전에 여러 사건이 겹쳤습니다.

• CVE 번호 유출: 10월 20일 CVE 번호와 잘못된 점수가 포럼과 SNS에 돌았습니다. PHP 재단은 이때 기술 세부 내용은 새지 않았다고 설명합니다.
• 시연 영상 오공개: 같은 날 발견 업체 Calif가 실수로 시연 영상을 올렸다가 지웠지만, 복제본이 퍼졌습니다.
• 조기 패치 이미지 공개: 10월 21일 오전, 보안 업체 Chainguard가 수정 내용이 담긴 이미지를 공식 발표보다 먼저 공개했습니다. PHP 재단은 엠바고 위반이라고 비판했고, Chainguard는 실제 공격 징후가 있어 먼저 배포했다고 반박했습니다.

다만 아마존이 유출 전인 10월 17일 공격 시도를 이미 관측했기 때문에, “유출 때문에 공격이 시작됐다”고 단정할 근거는 없습니다.

🔹 Log4Shell만큼 위험할까

이름이 비슷해 Log4Shell과 자주 비교되지만, 피해 규모나 공격 성공률이 같은 수준이라는 근거는 아직 없습니다. PHP2Shell은 실행 방식과 패치 상태에 따라 위험도가 크게 달라집니다. 대신 두 사태의 대응 과제는 닮았습니다. 숨은 자산을 찾고, 제품에 내장된 런타임을 확인하고, 제조사 패치를 추적하고, 재시작과 침해 점검까지 끝내야 비로소 대응이 마무리됩니다.

총평: 패치보다 중요한 건 ‘어디서 PHP가 도는지’ 아는 것

이번 PHP 취약점 사태가 남긴 교훈은 단순히 “PHP를 업데이트하라”가 아닙니다. 외주 사이트, 잊힌 테스트 서버, 장비에 숨어 있는 PHP처럼 내가 모르는 PHP가 어디서 돌고 있는지를 아는 조직만 제대로 대응할 수 있었습니다. 또 AI를 활용한 연구로 취약점을 찾는 속도가 빨라지면서, 수정과 배포가 그 속도를 따라가지 못하면 이번처럼 유출과 혼란이 반복될 수 있다는 점도 드러났습니다.

정리하면 PHP2Shell 대응은 세 단계입니다. 실제 웹 요청을 처리하는 PHP 버전을 확인하고, PHP 보안 업데이트(8.5.12·8.4.27·8.3.36·8.2.35 또는 백포트 패키지)를 적용한 뒤 서비스를 재시작하고, 10월 17일 이후 로그에서 침해 흔적을 점검하는 것입니다. 추가 권고나 국내 피해 소식이 나오면 이 글에 계속 업데이트하겠습니다.