웹사이트가 최신이어도 PHP는 취약할 수 있다10월 21일, PHP 개발팀이 두 건의 치명적인 보안 취약점을 수정한 긴급 업데이트를 내놓았다. 공통 취약점 식별번호(Common Vulnerabilities and Exposures, CVE)로는 CVE-2026-109618과 CVE-2026-109619가 부여됐다. 두 취약점 모두 공통 취약점 평가체계(Common Vulnerability Scoring System, CVSS) 4.0 기준 9.2점이다. 공격 조건이 맞으면 로그인하지 않은 외부인이 서버에서 임의 코드를 실행할 수 있다.
PHP(PHP: Hypertext Preprocessor)는 WordPress 같은 웹사이트를 서버에서 실행할 때 쓰는 프로그래밍 언어다. 이번 결함은 특정 WordPress 플러그인이 아니라 PHP 자체의 메모리 처리 과정에서 발견됐다. 기업이 확인할 대상은 홈페이지의 업데이트 알림뿐 아니라, 그 아래에서 실제로 작동하는 PHP 버전과 배포 환경이다.
EVENT SNAPSHOT
사건 · PHP2Shell로 불리는 핵심 PHP 취약점 두 건의 긴급 공개 및 패치
공개·패치 · 2026년 10월 21일
위험 · 인증 없는 원격 코드 실행(Remote Code Execution, RCE), 메모리 정보 노출 가능성
우선 조치 · 인터넷에 연결된 PHP 서버부터 패치하고, 이미 발생한 공격 징후를 점검
1. PHP2Shell은 어떻게 공개됐고, 무엇이 달라졌나
PHP2Shell은 두 취약점을 묶어 부르는 이름이다. 10월 20일 PHP 보안팀은 예정에 없던 보안 릴리스를 예고했고, 다음 날 패치를 배포했다. 한국인터넷진흥원(KISA)도 10월 21일 영향을 받는 버전과 해결 버전을 정리한 국내 보안 공지를 게시했다.
보안 연구기업 Wiz는 인공지능(Artificial Intelligence, AI) 모델을 활용한 보안 분석 과정에서 취약점을 발견했다고 발표했다. OpenAI 역시 Calif의 별도 발견과 Wiz의 독립적인 신고, PHP 유지보수팀의 수정 작업 및 여러 업체의 사전 대응을 설명했다. AI가 발견 과정에 기여했다는 것은 연구 참여 기관의 공개 자료로 확인되지만, 모든 공격이 AI로 자동 수행됐다는 뜻은 아니다.
2026.10.20
PHP 보안팀, 치명적 취약점 두 건에 대한 긴급 업데이트 예고
2026.10.21
수정 버전 8.2.35·8.3.36·8.4.27·8.5.12 공개, KISA와 해외 보안기관 패치 권고
2026.10.22 점검 시점
공개 공격 코드와 공격 시도 관측 보고가 나온 상태. 개별 기업의 실제 침해 여부는 각 서버의 기록으로 판단해야 함
Cloudflare는 자사 네트워크에서 관련 공격 트래픽을 관측했다고 밝혔다. 이는 공격 시도에 대한 관측이지, PHP를 사용하는 웹사이트 전체가 침해됐다는 증거는 아니다. 보안팀은 이 두 상태를 구분하면서 패치와 침해 조사에 나설 필요가 있다.
2. PHP 보안 취약점의 원인: 메모리를 정리하는 순간 벌어진 일
웹사이트에 접속하면 서버는 요청을 받고 PHP 코드를 실행한 뒤 결과를 돌려준다. 이 과정에서 입력값과 작업 상태를 저장할 메모리를 확보하고, 처리가 끝나면 정리한다. PHP2Shell은 요청 처리에 오류가 생겼을 때 이 정리 절차가 안전하게 마무리되지 않는 문제와 연결돼 있다.
CVE-2026-109618: 메모리 부족 오류가 잘못된 정리로 이어진다. PHP가 메모리 부족(Out of Memory, OOM) 상황을 처리하다 작업을 중단하면, 일부 내부 데이터가 완전히 초기화되지 않은 상태로 남을 수 있다. 이후 종료·정리 과정에서 이를 정상 데이터로 취급하면서 메모리 손상과 코드 실행이 가능해진다. PHP의 공식 보안 권고는 비정상적인 다중 부분 업로드 요청 등이 이런 조건을 유발할 수 있다고 설명한다.
CVE-2026-109619: 끝난 요청의 메모리 상태가 다음 요청에 남는다. 서버의 PHP 작업 프로세스가 이전 요청의 상태를 제대로 비우지 못하면, 이미 해제된 메모리를 다음 요청에서 다시 참조할 수 있다. 이를 해제 후 사용(Use After Free, UAF)이라고 한다. 오래된 메모리 참조가 공격자가 조작한 값과 만나면 정보 노출 또는 임의 코드 실행으로 이어질 수 있다.
핵심 구조
외부 HTTP 요청 → PHP가 입력과 메모리 처리 → 오류 발생 시 잘못된 정리 또는 오래된 상태 참조 → 웹서버 작업 프로세스 권한으로 코드 실행 가능
이 때문에 일반적인 로그인 기능이나 애플리케이션 입력 검증만으로 위험을 없앨 수 없다. 특히 Apache와 PHP를 직접 연결한 mod_php 구성에서는 애플리케이션 코드가 실행되기 전 단계에서 가능한 공격이 검증됐다. PHP FastCGI Process Manager(PHP-FPM)도 안전하다고 단정할 수 없지만, 구체적인 공격 경로는 애플리케이션 동작과 설정에 따라 차이가 있다.
3. WordPress·기업 웹사이트 중 무엇이 영향을 받나
PHP로 작동하는 WordPress, Drupal, Joomla, 쇼핑몰, 예약 시스템, 관리자 페이지 등이 검토 대상이다. 다만 특정 제품을 사용한다는 사실만으로 침해가 확정되지는 않는다. 서버가 사용하는 PHP 버전, 운영체제의 보안 패치, 외부 노출 여부, 실행 방식을 함께 확인해야 한다.
| PHP 계열 | 취약한 버전 | 공식 수정 버전 |
|---|---|---|
| 8.5 | 8.5.12 미만 | 8.5.12 이상 |
| 8.4 | 8.4.27 미만 | 8.4.27 이상 |
| 8.3 | 8.3.36 미만 | 8.3.36 이상 |
| 8.2 | 8.2.35 미만 | 8.2.35 이상 |
| 8.1 이하 | PHP 프로젝트 공식 지원 종료 | 지원 버전으로 이전 또는 공급사의 검증된 보안 수정 적용 |
자료: PHP 개발팀·KISA, 2026년 10월 21일. 공급사의 보안 수정이 이전 패키지 버전에 반영된 경우에는 해당 보안 공지로 패치 여부를 확인한다.
PHP 8.2는 이번에 수정 버전이 나왔지만 2026년 12월 31일 PHP 프로젝트의 보안 지원이 끝난다. 8.2.35를 적용한 조직도 차기 버전으로 옮길 일정을 잡아야 한다. 8.1 이하라면 서버 제공업체의 장기 지원 패키지나 보안 수정 코드 적용 여부를 확인하고, 가능하면 지원되는 버전으로 전환하는 편이 안전하다.
연구진은 WordPress·Drupal·Joomla를 사용하는 시험 환경에서 공격 가능성을 시연했다. 이는 각 서비스의 최신 애플리케이션 코드가 잘못됐다는 결론과 다르다. 웹사이트 프로그램을 업데이트해도 서버에 남아 있는 취약한 PHP 실행 환경은 별도로 수정해야 한다.
4. PHP 보안 업데이트는 어떤 순서로 진행해야 할까
가장 먼저 할 일은 PHP 설치 목록을 만드는 것이다. 기업 대표 사이트만 확인하면 프로모션 사이트, 오래된 관리자 화면, 개발용 도메인, 컨테이너 내부에 남은 설치본을 놓치기 쉽다. 도메인별로 실제 운영 서버와 관리 주체를 연결해 확인한다.
① 대상 파악 · 서비스 주소, PHP 버전, mod_php/PHP-FPM 등 실행 방식, 운영체제·컨테이너·호스팅 사업자, 관리 담당자 기록
② 우선순위 · 외부에 공개된 웹사이트, 고객정보·결제·관리자 기능이 있는 시스템, 구형 PHP 순서로 긴급 점검
③ 수정 적용 · 공식 PHP 보안 릴리스 또는 운영체제·호스팅 공급사의 검증된 패키지 사용, PHP 작업 프로세스 재시작과 재배포
④ 확인·감시 · 실제 웹 요청을 처리하는 PHP에서 수정 코드가 실행 중인지 확인하고, 주요 기능 점검과 공격 흔적 조사 수행
직접 서버를 관리하는 팀이라면 아래 명령으로 초기 단서를 확인할 수 있다. 다만 명령줄에서 보이는 PHP 버전과 웹서버가 실제 호출하는 PHP 버전은 다를 수 있다. 별도의 PHP-FPM 풀이나 여러 컨테이너를 운영한다면 각각 확인해야 한다.
php -v
php --ini
ps -ef | grep -E 'php-fpm|apache2|httpd|lsphp'운영체제가 보안 수정 코드를 이전 버전 번호의 패키지에 이식하는 경우도 있다. 따라서 버전 문자열만으로 안전·취약 여부를 단정하지 말고 배포판 보안 공지와 설치 패키지의 수정 내역을 대조해야 한다. 자체 이미지에 PHP를 포함한 컨테이너는 기본 이미지를 교체하고 애플리케이션을 다시 빌드·배포해야 하며, 호스트 PHP만 바꿔서는 해결되지 않는다.
패치 전에는 백업·롤백 계획과 주요 기능 시험 항목을 정한다. 배포 후에는 로그인, 주문·결제, 파일 업로드, 외부 API 연결, 예약 등 핵심 기능을 점검한다. 의심스러운 침해 흔적이 이미 발견됐다면 바로 파일을 지우거나 서버를 초기화하기보다 보안 담당자가 우선 격리하고 증거를 보존해야 한다.
5. 당장 패치할 수 없다면: 방화벽과 설정 변경의 한계
PHP 보안팀은 두 취약점을 완전히 해결하는 일반적인 설정 변경 방법은 없다고 설명한다. 웹 애플리케이션 방화벽(Web Application Firewall, WAF), 업로드 기능 제한, 접근 통제는 공격 가능성을 낮추는 보조 조치다. PHP 실행 환경에 대한 보안 패치를 대신하지 못한다.
Cloudflare는 관련 공격을 탐지·차단하기 위한 관리형 방화벽 규칙을 배포했다. 해당 서비스를 사용한다면 보안 규칙의 적용 및 차단 상태를 확인할 수 있다. 다른 WAF도 공급사 공지를 살펴야 하며, 규칙이 적용됐다는 이유로 서버 패치 일정을 미뤄서는 안 된다.
설정 변경을 패치로 오해하지 말 것
session.upload_progress.enabled=0은 확인된 일부 공격 경로를 줄일 수 있지만 다른 취약 경로까지 없애지는 못한다. PHP 8.5의 fatal_error_backtraces=0 역시 관련 공격 경로에 한정된 임시 조치다. 설정을 바꿨다면 작업 프로세스 재시작이 필요하다.
공식 권고에는 특정 취약 경로를 줄이기 위해 memory_limit 조정을 검토하는 설명도 있다. 그러나 메모리 제한을 없애면 서비스 거부 및 자원 고갈 위험이 커질 수 있으므로 일반적인 긴급 처방으로 일괄 적용해서는 안 된다.
업데이트가 지연되는 외부 공개 서버는 업무 영향을 평가한 뒤 외부 접근을 차단하거나 일시적으로 서비스를 중단하는 선택도 검토해야 한다. 영국 국가사이버보안센터(NCSC)와 유럽 보안기관도 패치가 어려운 시스템의 격리를 권고했다.
이미 침해됐는지 확인할 때는 웹서버·PHP 오류 기록에서 반복적인 메모리 부족 오류와 비정상 종료, 특이한 다중 부분 HTTP 요청, PHP 작업 프로세스가 예기치 않게 실행한 하위 명령, 최근 생성된 알 수 없는 PHP 파일·예약 작업을 살핀다. 이런 신호가 없다 해도 침해되지 않았다고 확정할 수는 없다. 패치는 앞으로의 공격 경로를 막지만 이미 설치된 악성 파일까지 제거하지는 않는다.
6. 기업은 누가 패치하고 누가 확인하는지 정해야 한다
PHP2Shell은 유지보수 계약의 빈틈도 드러낸다. 마케팅팀은 WordPress 관리자 화면에서 업데이트를 확인하지만, PHP는 호스팅 업체가 관리할 수 있다. 개발 대행사는 사이트 기능을 맡고 서버 이미지는 별도 인프라 팀이 유지하는 경우도 있다. 이때 각 팀이 '다른 쪽에서 처리했을 것'이라고 생각하면 패치가 남는다.
기업 웹사이트 보안의 세 가지 확인선
웹사이트 운영자 · 어떤 도메인과 서비스가 PHP를 쓰는지, 고객정보와 매출에 미치는 영향은 무엇인지 파악
개발·인프라·호스팅 담당자 · 실제 PHP 실행 환경의 버전, 공급사 패치 적용, 재시작·재배포, 운영 검증에 대한 증빙 제출
보안·사업 책임자 · 공격 징후 조사, 서비스 일시 중단 여부, 고객정보 관련 후속 절차와 재발 방지 결정
호스팅 업체에 문의할 때는 '보안 업데이트했나요?'보다 구체적으로 물어야 한다. 우리 도메인을 처리하는 PHP의 버전과 실행 방식은 무엇인지, 두 CVE의 수정이 포함된 패키지가 언제 적용됐는지, 실제 작업 프로세스가 재시작됐는지, 침해 흔적은 조사했는지를 확인하는 편이 낫다. 가능하면 공급사의 패치 공지나 변경 기록도 받아 두자.
AgencyTimes 관점에서 이번 사건의 운영 지표는 패치 공지를 읽은 사람의 수가 아니다. 외부에 노출된 PHP 서비스 가운데 수정이 검증된 비율, 관리 주체가 확인되지 않은 서비스 수, 최초 공지부터 패치 완료까지 걸린 시간, 패치 이후 침해 점검 완료율을 함께 봐야 한다.
PHP2Shell은 PHP 실행 환경의 메모리 처리에서 발생하는 치명적 취약점 두 건이다. PHP 8.5.12·8.4.27·8.3.36·8.2.35에 수정이 포함됐으며, 구형 PHP는 공급사의 수정 패키지 또는 지원 버전으로의 이전이 필요하다. WordPress와 플러그인 업데이트만으로 해결되지 않는다. 기업은 인터넷에 공개된 서비스부터 실행 환경을 확인하고 패치, 재시작·재배포, 침해 여부 조사까지 완료해야 한다.
FAQ
자주 묻는 질문
Q. PHP2Shell이란 무엇인가요?
PHP 자체의 메모리 처리 결함에서 발생하는 CVE-2026-109618과 CVE-2026-109619를 묶어 부르는 이름입니다. 취약한 서버에서는 로그인 없이도 코드 실행 또는 정보 노출이 가능하므로 PHP 실행 환경의 보안 업데이트가 필요합니다.
Q. WordPress만 최신 버전으로 업데이트하면 해결되나요?
아닙니다. 이번 문제는 WordPress 내부 기능이 아닌 PHP 실행 환경에서 발견됐습니다. WordPress·테마·플러그인의 보안을 관리하면서 서버 또는 호스팅 업체의 PHP 패치 상태를 별도로 확인해야 합니다.
Q. PHP 8.1 이하를 쓰면 어떻게 해야 하나요?
PHP 프로젝트의 공식 보안 지원이 종료된 버전이므로 지원되는 PHP로 이전하는 것이 기본 방향입니다. 이전이 즉시 어렵다면 운영체제·장기 지원 공급사의 검증된 보안 수정이 있는지 확인하고, 공개 접근을 제한할 필요가 있는지 판단해야 합니다.
Q. WAF를 켜두면 PHP 패치는 나중에 해도 되나요?
WAF는 알려진 공격 요청을 탐지·차단하는 추가 방어 수단이지만 모든 취약 경로를 없애지는 못합니다. PHP 개발팀이 배포한 수정 코드나 공급사의 검증된 패키지를 적용하는 것이 우선이며, 이미 공격을 받았을 가능성도 별도로 조사해야 합니다.
TERMINOLOGY
본문의 주요 용어
PHP 실행 환경(Runtime) · 웹 애플리케이션의 PHP 코드를 서버에서 실제로 실행하는 소프트웨어. 애플리케이션과 별도 패치가 필요할 수 있다.
RCE · 원격 코드 실행. 네트워크를 통해 서버에서 공격자가 의도한 코드를 실행하는 위험을 가리킨다.
UAF · 해제 후 사용. 이미 반환된 메모리를 다시 읽거나 조작하면서 발생하는 소프트웨어 결함.
PHP-FPM / mod_php · PHP를 웹서버와 연결하는 실행 방식. 위험이 드러나는 조건과 패치·재시작 대상이 달라질 수 있다.
백포트(Backport) · 새 버전에서 수정한 보안 코드를 이전 버전의 배포 패키지에 적용하는 방식. 버전 번호뿐 아니라 공급사의 수정 내역 확인이 필요하다.
References
- [1] PHP Group | Critical remote code execution vulnerabilities, update now
- [2] PHP Security Advisory | CVE-2026-109618: RCE via OOM corruption
- [3] PHP Security Advisory | CVE-2026-109619: RCE via stale global state
- [4] KISA 보호나라 | PHP 제품 보안 업데이트 권고
- [5] PHP Group | Supported Versions
- [6] Cloudflare | Cloudflare deploys protections against php2shell vulnerability
- [7] Wiz Research | PHP2Shell: AI uncovers critical RCE vulnerabilities
- [8] OpenAI | Patch the Planet: global response coordination
- [9] UK NCSC | Critical security issue affecting PHP
- [10] ENISA | Joint statement on critical PHP vulnerabilities
댓글
댓글 쓰기