PHP2Shell, PHP 엔진에서 나온 원격 코드 실행 취약점

2026년 10월 21일, PHP 개발팀이 8.5.12, 8.4.27, 8.3.36, 8.2.35 보안 업데이트를 한꺼번에 내놓았습니다. 고친 것은 PHP 엔진 자체의 취약점 두 개입니다. 로그인 없이 보낸 요청 하나로, 웹사이트 코드가 돌기도 전에 서버에서 공격자의 코드가 실행될 수 있는 원격 코드 실행원격 코드 실행(RCE). 공격자가 서버에 직접 접속하지 않고 네트워크 요청만으로 그 서버에서 원하는 프로그램을 돌릴 수 있는 취약점입니다. 보안 취약점 가운데 가장 위험한 종류로 꼽힙니다. 취약점입니다. 처음 찾아낸 Wiz Research(새 탭에서 열림)는 이 둘을 묶어 PHP2Shell이라고 불렀습니다.

PHP는 서버 쪽 언어가 알려진 웹사이트의 약 69%(새 탭에서 열림)가 쓰는 언어입니다(W3Techs, 2026년 10월 23일 기준). 워드프레스와 그누보드도 PHP로 돌아갑니다. 다음 날 과학기술정보통신부와 KISA는 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 올렸습니다.

사흘의 타임라인

• 10월 20일: KISA는 이날을 취약점 정보가 바깥으로 새 나간 날로 봅니다. 그래서 이날 이후의 서버 기록을 모두 점검하라고 안내합니다.
• 10월 21일: PHP 보안 업데이트와 공식 공지(새 탭에서 열림)가 나왔습니다. 같은 날 미국 사이버보안·인프라보안청(CISA)이 경보(새 탭에서 열림)를 냈고, KISA 보호나라에도 업데이트 권고(새 탭에서 열림)가 올라왔습니다. 보안 업체 watchTowr는 자사 허니팟허니팟. 공격자를 끌어들이려고 일부러 열어 둔 미끼 서버입니다. 실제 서비스가 아니라서, 여기 들어온 공격을 보면 지금 어떤 공격이 돌고 있는지 알 수 있습니다.에서 두 취약점을 노린 공격을 관측했다고 밝혔습니다.
• 10월 22일: 과기정통부와 KISA가 12시부로 경보를 '주의'로 올렸고, 보호나라에 기업 보안 대응 수칙(새 탭에서 열림)을 따로 게시했습니다.

두 가지 결함

두 취약점 모두 PHP로 짠 웹사이트 코드가 아니라, 그 코드를 돌리는 PHP 엔진 안에서 생겼습니다. 공격 방법은 빼고 원리만 적습니다.

메모리가 모자랄 때

첫째는 CVE-2026-109618입니다. PHP는 요청 하나를 처리하다 정해진 메모리를 다 쓰면 그 요청을 그 자리에서 끊고 정리 단계로 건너뜁니다. 문제는 메모리를 막 잡으려던 순간에 끊기는 경우입니다. 아직 아무 값도 채우지 않은 메모리가 남는데, 정리 단계는 이 메모리를 제대로 만들어진 것으로 믿고 읽습니다. 그 안에 무엇이 들어 있느냐에 따라 정리 과정이 엉뚱한 곳으로 흘러가고, 코드 실행까지 이어질 수 있습니다.

앞 요청이 남긴 흔적

둘째는 CVE-2026-109619입니다. PHP-FPMPHP-FPM. PHP를 웹 서버와 떼어 따로 돌리는 방식입니다. 미리 띄워 둔 여러 '워커'가 요청을 나눠 받고, 워커 하나가 요청을 여러 번 이어서 처리합니다. 요즘 PHP 서버에서 가장 흔한 방식입니다. 같은 방식에서는 워커 하나가 요청을 여러 번 이어 받습니다. 요청이 끝나면 그 요청이 쓰던 메모리는 비워지는데, 일부 전역 상태가 비워진 메모리를 여전히 가리킨 채 남았습니다. 같은 워커가 다음 요청을 받으면, 초기화되기 전에 그 낡은 상태를 그대로 씁니다. 비운 메모리를 다시 쓰는 해제 후 사용해제 후 사용(use-after-free). 프로그램이 이미 돌려준(비운) 메모리를 계속 쓰는 결함입니다. 그 자리에 다른 데이터가 들어오면 프로그램이 남의 데이터를 자기 것인 줄 알고 쓰게 됩니다. 결함입니다.

왜 심각한가

• 로그인이 필요 없습니다. 평범한 HTTP 요청이면 됩니다.
• 웹사이트 코드가 돌기 전, PHP 엔진 단계에서 터집니다. 어떤 프레임워크를 쓰든, 코드를 얼마나 잘 짰든 막아 주지 못합니다.
• PHP 개발팀은 Apache의 mod_phpmod_php. PHP를 Apache 웹 서버 안에 모듈로 넣어 돌리는 옛 방식입니다. 웹 서버와 PHP가 한 프로세스를 같이 씁니다.에서 인증 없는 요청이 애플리케이션 코드보다 먼저 공격을 일으키는 것을 실제로 확인했다며, mod_php가 가장 위험하다고 평가했습니다.

위험도 점수는 기준에 따라 다릅니다. PHP 개발팀이 매긴 CVSSCVSS. 취약점의 위험도를 0~10점으로 매기는 국제 기준입니다. 9.0 이상이 '치명(Critical)'입니다. 3.1판과 4.0판은 계산 방식이 조금 달라 같은 취약점도 점수가 다를 수 있습니다. 4.0 점수는 두 건 모두 9.2(치명)입니다. 미국 국립 취약점 데이터베이스(NVD)의 CVSS 3.1 점수로는 109618이 9.8(새 탭에서 열림), 109619가 8.1(새 탭에서 열림)입니다. 109619는 공격 조건이 더 까다롭다고 본 것입니다.

해당 범위

2026년 10월 23일 기준으로 지원 중인 PHP 계열과 고쳐진 버전입니다.

PHP를 웹 요청에 붙이는 방식(SAPISAPI(Server API). PHP가 바깥과 연결되는 방식입니다. 웹 서버와 붙는 PHP-FPM·mod_php·CGI, 명령줄에서 쓰는 CLI 등이 있습니다.)은 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed가 모두 해당합니다. 사실상 웹에서 PHP를 돌리는 거의 모든 방식입니다.

얼마나 많은 서버가 해당하는지는 정확히 알 수 없습니다. 팔로알토 네트웍스의 위협 분석팀 Unit 42는 인터넷에 노출된 PHP 가운데 이 취약점에 해당할 수 있는 곳(새 탭에서 열림)이 2,260만 개가 넘는다고 밝혔습니다. 버전 정보로 '해당할 수 있다'고 센 수이지, 실제로 뚫린 수는 아닙니다.

실제 공격 여부

공개 직후라 말이 엇갈립니다.

미끼 서버에 공격이 들어오는 것까지는 확인됐지만, 실제 서비스가 뚫렸다는 공식 사례는 아직 나오지 않았습니다. 다만 KISA는 정보가 이미 새 나갔다며, 업데이트를 마친 서버도 이상 접속 기록과 웹셸웹셸. 공격자가 서버에 몰래 올려 두는 작은 프로그램입니다. 웹 브라우저로 그 파일에 접속하면 서버를 원격으로 조종할 수 있습니다. 설치 여부를 확인하라고 합니다.

내 서버 확인

버전을 볼 때 흔히 놓치는 것이 몇 가지 있습니다.

• 명령줄과 웹은 다를 수 있습니다. php -v는 명령줄용 PHP의 버전입니다. 웹사이트가 실제로 쓰는 PHP-FPM이나 Apache 모듈은 다른 버전일 수 있으니 php-fpm -v(배포판에 따라 php-fpm8.3 -v처럼 버전이 붙음)나 패키지 관리자로 따로 확인합니다.
• 배포판 번호는 낮아 보여도 고쳐졌을 수 있습니다. 우분투나 데비안 같은 배포판은 보안 수정을 옛 버전 번호에 덧대어 내보냅니다. 8.3.6-0ubuntu0.24.04.13처럼 뒤에 꼬리표가 붙은 번호는 위 표가 아니라 배포판 보안 페이지에서 확인해야 합니다.
• 보이지 않는 PHP도 있습니다. 컨테이너 이미지, 호스팅 업체가 고른 PHP, 다른 제품 안에 들어 있는 PHP도 같이 봅니다.
• 업데이트 뒤에는 다시 시작합니다. KISA는 업데이트 후 반드시 웹 서비스를 재시작하라고 안내합니다. 이미 떠 있는 워커는 옛 PHP로 계속 돕니다.

바로 업데이트할 수 없을 때

PHP 개발팀은 업로드 크기 제한을 줄이는 등 몇 가지 설정을 임시 조치로 안내했지만, "일부 공격 경로를 줄일 뿐 설치를 안전하게 만들지는 않는다"고 분명히 적었습니다. 정해진 설정값은 공식 공지(새 탭에서 열림)를 따르는 것이 좋습니다.

CISA와 KISA가 권하는 것은 이렇습니다.

• 인터넷에 열린 서버부터 업데이트합니다.
• 바로 업데이트할 수 없거나 8.1 이하라면, 업데이트할 때까지 그 시스템을 내리는 것도 검토합니다(CISA).
• 웹 방화벽WAF(웹 방화벽). 웹 요청을 서버 앞에서 검사해 공격으로 보이는 요청을 걸러 내는 장치입니다. 알려진 공격 모양만 막을 수 있어서 근본 대책은 아닙니다.은 보조 수단일 뿐입니다. PHP 워커가 셸을 띄우거나 파일을 내려받는 움직임이 있는지 지켜봅니다(CISA).
• 업데이트를 마쳤어도 10월 20일 이후의 기록을 모두 점검하고, 침해 흔적이 나온 서버는 교체하고 인증 정보도 바꿉니다. 피해가 의심되면 KISA에 신고합니다(KISA).

지난 사건과의 차이

PHP에 큰 보안 사건이 처음은 아닙니다.

• 2019년 10월, CVE-2019-11043: nginx와 PHP-FPM을 함께 쓰는 서버에서, 조작한 주소 하나로 FPM이 메모리 경계를 넘어 쓰게 만드는 취약점(새 탭에서 열림)이었습니다. 이를 이용해 워커의 PHP 설정을 바꾸면 인증 없이 코드를 실행할 수 있었고, 설정이 바뀐 워커는 다음 요청에도 그 상태를 안고 갔습니다. 다시 쓰이는 워커에 앞 요청의 흔적이 남는다는 점에서 이번 두 번째 결함과 가장 닮았습니다. 점수는 9.8점이었지만 특정 nginx 설정에서만 통했습니다.
• 2021년 3월, 소스 저장소 침해: PHP의 공식 git 서버가 뚫려 유지관리자 이름으로 백도어 커밋(새 탭에서 열림) 두 개가 올라갔습니다. 곧 발견돼 되돌렸고, PHP는 이후 정본 저장소를 GitHub로 옮겼습니다. 코드에 누군가 나쁜 것을 심은 공급망 사고였습니다.
• 2024년 6월, CVE-2024-4577: 윈도우에서 PHP를 CGI로 돌릴 때, 특정 언어 설정의 문자 변환 때문에 요청 내용이 PHP 옵션으로 해석되는 취약점(새 탭에서 열림)이었습니다. 9.8점에 KEV에도 올랐지만, 조건이 '윈도우 + CGI'로 좁았습니다.

이번 PHP2Shell은 2021년처럼 누가 심은 코드가 아니라 엔진 자체의 결함이고, 2019년이나 2024년처럼 특정 설정이나 운영체제에 묶이지도 않습니다. 웹에서 PHP를 돌리는 거의 모든 방식에 걸쳐 있어서 범위가 훨씬 넓습니다.

AI가 함께 찾은 취약점

이번 취약점은 AI 모델이 함께 찾은 것으로 알려졌습니다. 구글은 자사 모델 Gemini 4 Argon이 취약점 발견, 익스플로잇 개발, 공격 탐지, 패치 검증에 큰 기여를 했다고 밝혔습니다(새 탭에서 열림). 발견한 Wiz는 연구 내내 자사 도구 Wiz Atlas와 Gemini 4 Argon, GPT-5.6 Sol을 함께 썼다고 적었습니다. 어느 모델이 얼마나 기여했는지는 각 회사의 설명이고, 따로 확인할 방법은 없습니다.

마치며

이번 일은 내가 짠 코드가 아니라 그 코드를 돌리는 엔진에서 터졌습니다. 그래서 확인할 것도 코드가 아니라 서버입니다. 웹이 실제로 쓰는 PHP의 버전, 업데이트 뒤 재시작, 그리고 10월 20일 이후의 기록입니다. 배포판을 쓴다면 번호보다 배포판 보안 페이지를 먼저 봅니다.