PHP 8.3을 쓰는 서버라면 8.3.36 이상, 8.4는 8.4.27 이상이어야 이번 취약점에서 벗어납니다. 과학기술정보통신부와 한국인터넷진흥원(KISA)은 PHP 자체에서 치명적 보안 취약점 2건이 공개됐다며 10월 22일 정오부로 민간 분야 사이버위기 경보를 ‘관심’에서 ‘주의’로 올렸습니다. 같은 날 개인정보보호위원회도 PHP로 웹서비스를 운영하는 사업자에게 개인정보 유출 예방조치를 당부했습니다.
호스팅을 쓰면 업체 확인이 먼저, 직접 운영하면 오늘 업데이트
PHP는 홈페이지, 쇼핑몰, 게시판, 관리자 화면을 만드는 데 널리 쓰이는 언어이고 워드프레스·그누보드도 PHP로 동작합니다. 누가 서버를 관리하느냐에 따라 할 일이 갈립니다.
| 상황 | 할 일 |
|---|---|
| 일반 이용자(사이트 방문만) | 직접 조치할 것 없음. 백신·보안 업데이트 등 기본 수칙 유지 |
| 호스팅 업체로 홈페이지 운영 | 호스팅 업체에 보안 업데이트 적용 여부 확인 |
| 외주 제작 쇼핑몰·홈페이지 | 제작·유지보수 업체에 PHP 버전과 조치 여부 확인 요청 |
| 서버를 직접 운영 | 즉시 업데이트, 웹 서비스 재시작, 로그 점검 |
| PHP 8.1 이하 사용 | 공식 업데이트 없음. 지원 버전으로 전환 계획 |
과기정통부 안내에서 놓치기 쉬운 대목은 “오래전에 만들어 두고 관리하지 않는 홈페이지”와 장비 관리 화면입니다. 이벤트용으로 만든 사이트, 테스트 서버, 네트워크 장비의 관리 화면, PHP가 포함된 설치 패키지에도 PHP가 들어 있을 수 있어, 자산 목록이 아니라 실제로 돌아가는 서버를 기준으로 확인하라고 했습니다.
이번 취약점이 특히 위험한 이유
KISA가 ‘PHP2Shell’로 부르는 이번 취약점(CVE-2026-109618, CVE-2026-109619)은 공격자가 아이디·비밀번호 없이 인터넷으로 조작된 요청을 보내 서버에서 원하는 명령을 실행할 수 있게 합니다. 성공하면 원격조종 파일(웹셸) 설치, 고객 정보 유출, 홈페이지 변조나 마비, 내부망 침투까지 이어질 수 있습니다.
두 가지가 대응을 급하게 만듭니다. 첫째, 홈페이지 프로그램이 아니라 PHP 자체의 문제라 사이트를 안전하게 만들었어도 영향을 받습니다. 둘째, 보안 업데이트가 나오기 전에 취약점 정보가 유출됐고 공격 시도가 해외에서 보고되고 있습니다. 유럽연합 사이버보안기관(CERT-EU)과 영국·네덜란드·독일 기관도 ‘치명적’ 등급으로 평가했다고 과기정통부는 밝혔습니다.
해결 버전과 확인할 때 헷갈리는 점
PHP 개발팀은 10월 21일(현지시각) 보안 업데이트를 배포했습니다. 해결 버전은 다음과 같습니다.
업데이트 자체보다 확인 단계에서 실수가 나기 쉽습니다. 과기정통부 대응 수칙이 짚은 내용을 순서대로 옮기면 이렇습니다.
- 재시작 — PHP-FPM, Apache mod_php 등 PHP를 실행하는 웹 서비스를 다시 띄워야 합니다. 하지 않으면 메모리에 남은 이전 버전이 계속 동작합니다
- 버전 확인 위치 — 명령어(php -v)로 보이는 버전과 웹 서비스가 실제로 쓰는 버전이 다를 수 있습니다. 한 서버에 PHP가 여러 개면 각각 봅니다
- 배포판 패키지 — 리눅스 배포판이 패치를 적용하면 버전 번호가 그대로일 수 있어, 패키지 변경 이력에서 CVE 반영 여부를 확인합니다
- 8.2 사용자 — 8.2.35로 막을 수 있지만 8.2는 2026년 12월 31일 보안 지원이 끝날 예정이라 8.3 이상 전환이 권장됩니다
컨테이너(도커 등)로 운영한다면 새 이미지를 다시 배포해야 반영됩니다. 소프트웨어 개발을 업으로 하는 입장에서 보면, 이 목록 가운데 재시작과 실제 사용 버전 확인이 빠지면 “업데이트했다”는 보고와 실제 상태가 달라지는 지점입니다.
업데이트가 끝이 아니다, 로그와 비밀번호
취약점 정보가 유출된 10월 20일 이후의 기록은 업데이트를 마친 서버라도 점검 대상입니다. 수칙이 제시한 점검 항목은 비정상적으로 큰 요청 뒤 반복된 서버 오류(HTTP 500), 원인 모를 PHP 프로세스 비정상 종료, 웹 폴더·업로드 폴더에 새로 생긴 PHP 파일, 결제 페이지에 몰래 추가된 외부 스크립트, 알 수 없는 외부 주소로의 새 연결입니다.
이 취약점은 서버 메모리에 있는 비밀번호와 인증값, API 키를 유출시킬 수 있다고 안내됐습니다. 그래서 업데이트 전까지 인터넷에 노출됐던 서버는 DB 비밀번호, 외부 서비스 연동 키, 관리자 비밀번호를 바꾸는 것이 권장되고, 침해 흔적이 있으면 반드시 바꿔야 합니다.
개인정보위가 따로 강조한 것은 데이터베이스입니다. phpMyAdmin 같은 DB 관리도구가 외부에 열려 있으면 대량 유출로 번질 수 있으므로 인터넷 직접 접근을 막고, 웹서비스 계정의 DB 권한을 최소화하고, 대량 조회·반출 같은 비정상 접근을 점검하라고 했습니다. 외주·수탁업체가 운영하는 시스템도 점검 범위에 넣어야 합니다.
침해가 의심되면 순서가 중요합니다. 서버를 끄거나 재시작하지 말고 외부 접속만 차단한 뒤, 보호나라(boho.or.kr)의 침해사고 신고로 신고하고, 로그와 실행 중인 프로그램 목록, 네트워크 연결 정보를 보존한 다음에 업데이트와 웹셸 제거를 합니다. 재시작하면 메모리에 남은 공격 흔적이 사라지기 때문입니다.
당장 업데이트가 어려울 때와 가짜 공격 코드
업데이트를 바로 못 하는 서버에는 임시 조치가 안내됐습니다. 웹 방화벽이나 웹 서버에서 요청 크기를 제한하고, 파일 업로드가 필요 없는 서비스는 업로드 요청을 차단하고, PHP 설정에서 업로드 진행률 기능(session.upload_progress.enabled)을 끄는 방식입니다. 다만 임시 조치는 공격을 완전히 막지 못하므로, 이것도 어렵다면 업데이트 전까지 외부 접속 차단이나 서비스 일시 중단을 검토하라는 것이 과기정통부 권고입니다.
인터넷에는 ‘공격 시험 코드(PoC)’라며 도는 파일이 있는데, 악성코드가 숨은 가짜가 많다고 경고됐습니다. 내 서버가 취약한지는 그런 코드를 실행해서가 아니라 버전 확인과 기록 점검으로 판단합니다. 호스팅을 쓰는 소상공인이라면 업체 답변을 받아 두는 것으로 충분하고, 서버를 직접 운영한다면 업데이트·재시작·로그 점검·비밀번호 교체까지를 한 번에 끝내는 것이 이번 경보에 대한 대응입니다.
관련 글: 개인정보 보호법 9월 11일 시행, 회사별 해당 항목 판단 · 안심차단서비스 3종, 개인정보 유출 뒤 무엇부터 걸까
참고한 자료
과학기술정보통신부, 「웹사이트 개발 언어 ‘PHP’ 보안 취약점 관련 긴급 보안 업데이트 및 기술적 조치 당부」 보도자료·붙임 기업 보안 대응 수칙 (2026-10-22) — 원문
개인정보보호위원회, 「PHP 보안 취약점 관련 개인정보 유출 예방조치 당부」 보도자료 (2026-10-22) — 원문
한국인터넷진흥원 보호나라, 「PHP 제품 보안 업데이트 권고」 보안공지 (2026-10-21) — 원문
PHP 공식 누리집, 2026-10-21 보안 업데이트 공지 — 원문