PHP로 만든 홈페이지나 쇼핑몰을 운영하고 계신다면 이번 주에 반드시 한 번은 서버 상태를 확인하셔야 합니다. 핵심만 먼저 정리하면 다음과 같습니다.
- 2026년 10월 21일 PHP 개발진이 로그인 없이 서버를 장악할 수 있는 치명적 취약점 2건(CVE-2026-109618, CVE-2026-109619)을 고친 보안 버전을 내놓았습니다.
- 해결 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상이며, 8.1 이하는 공식 패치가 없어 지원 버전으로 옮겨야 합니다.
- 정부는 10월 22일 정오부터 민간 분야 사이버 위기 경보를 '관심'에서 '주의'로 올렸고, KISA는 업데이트 후 재시작·로그 점검·비밀번호 교체까지 권고했습니다.

PHP 취약점, 무엇이 발표됐나
PHP는 회사 소개 홈페이지, 게시판, 워드프레스 같은 콘텐츠 관리 시스템, 온라인 쇼핑몰 등을 만들 때 널리 쓰이는 서버 쪽 프로그래밍 언어입니다. 화면에는 드러나지 않지만, 방문자가 페이지를 열 때마다 서버 안에서 PHP가 돌아가며 회원 정보나 주문 정보를 처리합니다. 그래서 PHP 자체에 구멍이 생기면 그 위에 올라간 사이트 전체가 위험해집니다.
한국인터넷진흥원(KISA)이 2026년 10월 21일 보호나라에 올린 'PHP 제품 보안 업데이트 권고'에 따르면, 이번에 고쳐진 취약점은 두 가지입니다. 하나는 예외 상황을 제대로 처리하지 못하는 결함(CVE-2026-109618)이고, 다른 하나는 이미 반납한 메모리를 다시 참조하는 결함(CVE-2026-109619)입니다. PHP 공식 사이트의 보안 공지는 두 건 모두 인증 없이 원격에서 코드를 실행할 수 있는 치명적(Critical) 등급이며, CVSS 4.0 기준 9.2점으로 평가했다고 밝히고 있습니다. 특히 Apache 웹 서버에 PHP를 모듈로 붙여 쓰는 mod_php 환경은 애플리케이션 코드가 실행되기도 전에 요청만으로 공격이 가능한 것으로 시연돼 위험도가 가장 높다고 설명합니다.
KISA는 다음 날인 10월 22일 'PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙'을 따로 냈습니다. 이 문서는 보안 업데이트가 배포되기 전에 취약점 정보가 먼저 새어 나갔고, 해외 보안업체를 중심으로 실제 공격 시도가 보고되고 있다고 적고 있습니다. 공격이 성공하면 웹셸(서버를 원격 조종하는 악성 파일) 설치, 고객정보 유출, 홈페이지 변조, 내부망 침투까지 이어질 수 있다는 것이 KISA의 설명입니다.
같은 날 과학기술정보통신부와 KISA는 민간 분야 사이버 위기 경보를 '관심'에서 '주의'로 한 단계 올렸습니다. 언론 보도에 따르면 과기정통부는 기업 정보보호최고책임자(CISO)에게 긴급 보안 조치를 요청했고, 웹호스팅 업체와 데이터센터(IDC) 등에도 긴급 안내를 보냈습니다. 안랩은 인터넷에 공개된 서버 정보를 분석해 취약한 버전을 쓰는 것으로 추정되는 국내 서버가 약 11만 건이라고 집계했다고 서울신문이 2026년 10월 23일자로 보도했습니다. 다만 이 수치는 추정치이며 세부 산출 기준은 공개되지 않았습니다.
내 사이트가 해당되는지 버전으로 확인하기

가장 먼저 할 일은 내 사이트가 PHP를 쓰는지, 쓴다면 몇 버전인지 확인하는 것입니다. KISA 권고문에 실린 영향 범위를 정리하면 아래 표와 같습니다(2026년 10월 23일 기준).
| 사용 중인 PHP 계열 | 취약한 버전 | 해결 버전 | 비고 |
| PHP 8.5 | 8.5.12 미만 | 8.5.12 이상 | KISA는 임시 조치 시 fatal_error_backtraces = 0 추가 안내 |
| PHP 8.4 | 8.4.27 미만 | 8.4.27 이상 | - |
| PHP 8.3 | 8.3.36 미만 | 8.3.36 이상 | - |
| PHP 8.2 | 8.2.35 미만 | 8.2.35 이상 | 2026년 12월 31일 보안 지원 종료 예정, 8.3 이상 전환 권장 |
| PHP 8.1 이하(7.4·8.0 포함) | 공식 업데이트 없음 | 지원 버전으로 전환 | 전환 전까지 배포판·LTS 업체 패치나 PHP 보안팀 소스 패치를 임시 적용 |
버전을 확인하는 방법은 운영 형태에 따라 다릅니다. 호스팅 서비스를 쓰고 있다면 호스팅 관리 화면의 PHP 설정 메뉴에서 현재 버전을 볼 수 있는 경우가 많고, 워드프레스라면 관리자 화면의 사이트 상태 정보에서 서버의 PHP 버전을 확인할 수 있습니다. 직접 서버를 관리한다면 명령어로 버전을 볼 수 있지만, KISA는 웹 서비스가 실제로 쓰는 PHP와 명령어(php -v)로 보이는 버전이 다를 수 있다고 주의를 줍니다. 한 서버에 PHP가 여러 개 설치돼 있으면 각각 확인해야 합니다.
또 하나 놓치기 쉬운 부분은 '잊힌 사이트'입니다. KISA는 자산 목록이 아니라 실제로 돌아가고 있는 서버를 기준으로 점검하라고 강조하면서, 외주로 만든 사이트, 방치된 옛 사이트, 이벤트·테스트용 서버, 관리자 페이지까지 포함하라고 했습니다. PHP가 내장된 장비나 솔루션, 도커 같은 컨테이너 이미지도 별도로 확인 대상입니다. 몇 년 전 행사 때 만들어 두고 잊어버린 이벤트 페이지가 오히려 가장 오래된 버전으로 남아 있을 수 있습니다.
리눅스 배포판이 제공하는 패키지로 PHP를 설치한 경우에는 배포판이 보안 수정을 반영하면서도 버전 번호를 그대로 두는 경우가 있습니다. KISA는 이때 버전 숫자만 보지 말고 패키지 변경 이력에서 두 CVE가 반영됐는지 확인하라고 안내합니다.
운영 형태에 따라 해야 할 일도 다릅니다. 같은 PHP 사이트라도 누가 서버를 관리하느냐에 따라 내가 직접 해야 할 일의 범위가 달라집니다. KISA 대응 수칙은 호스팅 업체나 솔루션 제조사가 PHP를 관리하는 경우 적용 여부를 확인하고 요청하라고 안내하고 있습니다.
임대형 쇼핑몰·홈페이지 빌더를 쓰는 경우
쇼핑몰 솔루션이나 홈페이지 빌더를 월 이용료를 내고 쓰는 방식이라면 서버와 PHP는 보통 플랫폼 회사가 관리합니다. 이 경우 내가 서버를 건드릴 수는 없으므로, 플랫폼의 공지사항이나 고객센터를 통해 이번 취약점 조치가 끝났는지 확인하는 것이 핵심입니다. 헤럴드경제 보도에 따르면 카페24는 취약점 공개 직후 긴급 보안 작업에 들어가 고객 보호를 위한 완화 조치를 적용하고 있다고 밝혔습니다. 다만 쇼핑몰 관리자 계정 비밀번호나 외부 결제·배송 연동 키처럼 운영자가 직접 관리하는 정보는 별도로 점검하는 편이 안전합니다.
웹호스팅에 직접 사이트를 올린 경우
그누보드, 워드프레스 등으로 만든 사이트를 웹호스팅에 올려 쓰는 경우에는 호스팅 회사가 PHP 엔진을 업데이트하더라도 내 계정에 어떤 버전이 적용돼 있는지는 직접 확인해야 합니다. 호스팅 관리 화면에서 PHP 버전을 고를 수 있는 구조라면, 오래된 버전으로 고정해 두지 않았는지 살펴보시기 바랍니다. 버전을 올리면 오래된 테마나 플러그인이 동작하지 않을 수 있으므로 백업 후 진행하고, 판단이 어렵다면 제작을 맡긴 업체나 호스팅 고객센터에 먼저 문의하는 것이 좋습니다.
서버를 직접 운영하는 경우
클라우드 서버나 자체 서버에 PHP를 설치해 쓰고 있다면 아래에 정리한 KISA 수칙을 그대로 따라야 합니다. 업데이트, 재시작, 로그 점검, 인증정보 교체가 한 세트입니다.
업데이트 후 반드시 해야 할 4가지
이번 권고에서 가장 눈여겨볼 부분은 '업데이트만 하고 끝내면 안 된다'는 점입니다. KISA 대응 수칙을 순서대로 정리하면 다음과 같습니다.
1. PHP를 실행하는 서비스 재시작
패키지를 새 버전으로 바꿔도 이미 돌아가고 있는 PHP 프로세스는 메모리에 남은 옛 버전으로 계속 동작합니다. 그래서 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 PHP를 실행하는 웹 서비스를 모두 재시작해야 하고, 컨테이너 환경이라면 새 이미지로 다시 배포해야 합니다. 재시작 후에는 웹 서비스가 실제로 쓰는 버전이 바뀌었는지 다시 확인합니다.
2. 10월 20일 이후 로그 점검
KISA는 취약점 정보가 유출된 10월 20일 이후 기록 전체를 살펴보고, 가능하면 그 이전까지 확인하라고 권고했습니다. 주요 점검 대상은 비정상적으로 큰 요청 뒤에 반복되는 오류(HTTP 500), 원인을 알 수 없는 PHP 재시작이나 비정상 종료, 웹 서버가 셸이나 파일 다운로드 도구를 실행한 흔적, 업로드·임시 폴더에 새로 생긴 PHP 파일, 홈페이지나 결제 페이지에 몰래 추가된 외부 스크립트, 낯선 외부 주소로의 연결 등입니다. KISA는 기록에 이상이 없더라도 안전이 보장되는 것은 아니라고 덧붙였습니다.
3. 중요 비밀번호와 키 교체
이번 취약점은 서버 메모리에 있던 비밀번호, 접속 토큰, 외부 서비스 API 키까지 새어 나갈 수 있는 유형입니다. KISA는 업데이트 전에 인터넷에 노출돼 있던 서버라면 DB 비밀번호, 외부 서비스 연동 키, 관리자 비밀번호를 바꾸라고 권장했고, 침해 흔적이 있으면 반드시 교체하라고 했습니다. 쇼핑몰이라면 결제대행사·택배사·문자 발송 서비스 등과 연결된 키가 여기에 해당할 수 있습니다.
4. 인터넷에 떠도는 공격 코드는 실행하지 않기
취약 여부를 확인하겠다며 인터넷에 공개된 개념증명(PoC) 코드를 내려받아 돌려 보는 것은 피해야 합니다. KISA는 출처가 불분명한 PoC에 악성코드가 숨겨진 경우가 많다며, 취약 여부는 버전 확인과 로그 점검으로 판단하라고 안내했습니다.
당장 업데이트가 어렵다면: 임시 조치와 한계

오래된 사이트는 PHP 버전을 올리는 순간 화면이 깨지거나 기능이 멈출 수 있어 즉시 업데이트가 어려운 경우도 있습니다. KISA는 이럴 때 웹 방화벽·웹 서버·프록시에서 요청 크기를 제한하고, 파일 업로드가 필요 없는 서비스는 업로드 형식(multipart) 요청을 막으라고 안내했습니다. PHP 설정으로는 업로드 진행률 기능 끄기(session.upload_progress.enabled = 0), memory_limit = -1을 관리자 설정으로 지정, post_max_size 낮추기(업로드가 필요 없으면 8M, 필요하면 32M 수준) 등이 제시됐고, 적용 후에는 모든 PHP 프로세스를 재시작해야 합니다.
하지만 이 방법들은 어디까지나 시간을 버는 수단입니다. PHP 공식 공지는 완전한 완화 방법은 없으며 업데이트만이 안전한 선택이라고 명시했고, KISA 역시 임시 조치가 공격을 완전히 막지 못한다고 밝혔습니다. 적용할 패치도, 임시 조치도 어렵다면 외부 접속 차단이나 서비스 일시 중단까지 검토하라는 것이 KISA의 안내입니다.
침해가 의심될 때의 순서도 정해져 있습니다. KISA는 서버를 끄거나 재시작하지 말고 외부 접속만 먼저 끊은 뒤, 보호나라 누리집에서 침해사고를 신고하고, 서버 로그·실행 중인 프로그램 목록·네트워크 연결 정보를 확보하라고 안내합니다. 재시작하면 메모리에 남은 공격 흔적이 사라지기 때문에 증거 확보가 업데이트보다 먼저입니다. 상담은 국번 없이 118로 할 수 있습니다.
상황별 예시와 대응 체크리스트
아래는 이해를 돕기 위한 가정 사례입니다. 실제 사이트 구성에 따라 필요한 작업은 달라질 수 있습니다.
예시 1: 몇 년 전 외주로 만든 학원 홈페이지
예를 들어 학원 원장 A씨가 5년 전 외주 업체에 맡겨 만든 게시판형 홈페이지를 웹호스팅에서 그대로 쓰고 있고, 호스팅 관리 화면을 열어 보니 PHP 7.4로 설정돼 있다고 가정하겠습니다. 7.4는 공식 업데이트가 없는 버전이므로, 이번 해결 버전 목록에 들어 있지 않습니다. A씨가 먼저 할 일은 호스팅 회사에 이번 취약점 관련 조치 여부를 문의하고, 제작 업체에 지원 버전(8.3 이상 권장)으로 옮겨도 사이트가 정상 동작하는지 점검을 요청하는 것입니다. 전환까지 시간이 걸린다면 호스팅 측에 임시 조치 적용 여부를 확인하고, 사이트에 회원가입이나 상담 신청 기능이 있다면 관리자 비밀번호를 바꾸는 것이 좋습니다.
예시 2: 클라우드 서버에서 직접 운영하는 쇼핑몰
예를 들어 온라인 쇼핑몰을 운영하는 B씨가 클라우드 서버에 PHP 8.3.30을 설치해 쓰고 있다고 가정하겠습니다. 8.3 계열의 해결 버전은 8.3.36이므로 B씨의 서버는 영향 범위에 들어갑니다. B씨는 백업 후 8.3.36 이상으로 업데이트하고, PHP-FPM과 웹 서버를 재시작한 다음 웹 서비스가 실제로 8.3.36 이상을 쓰는지 확인해야 합니다. 이어서 10월 20일 이후 로그에서 반복된 500 오류나 업로드 폴더의 낯선 PHP 파일이 없는지 살피고, 결제 페이지 소스에 모르는 외부 스크립트가 붙어 있지 않은지 확인합니다. 업데이트 전 이미 인터넷에 노출돼 있었으므로 DB 비밀번호와 결제·배송 연동 키도 교체 대상입니다.
PHP 취약점 대응 체크리스트
아래 항목을 하나씩 확인해 보시기 바랍니다.
- ☐ 운영 중인 모든 사이트(외주·방치·이벤트·테스트·관리자 페이지 포함)의 목록을 만들었다
- ☐ 각 사이트의 PHP 사용 여부와 실제 동작 버전을 확인했다
- ☐ 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 이상인지 비교했다
- ☐ 8.1 이하라면 지원 버전 전환 계획을 세우고 임시 패치·조치를 적용했다
- ☐ 업데이트 후 PHP를 실행하는 웹 서비스를 모두 재시작했다
- ☐ 호스팅·쇼핑몰 플랫폼을 쓴다면 업체 공지나 고객센터로 조치 여부를 확인했다
- ☐ 10월 20일 이후 로그에서 이상 징후를 점검했다
- ☐ DB·관리자 비밀번호와 외부 연동 키를 교체했다
- ☐ 침해가 의심되면 서버를 끄지 않고 접속만 차단한 뒤 보호나라에 신고할 준비를 했다
혹시 점검 과정에서 고객 정보가 유출된 정황이 확인된다면, 고객에게 알리고 관계 기관에 신고하는 절차도 함께 검토해야 합니다. 개인정보 유출 시 기업이 부담할 수 있는 제재는 개인정보 과징금 매출액 10%|9월 시행 내용과 점검 항목에서, 이용자 입장에서 내 정보가 새었는지 확인하는 방법은 개인정보 유출 확인 방법|털린 내 정보 찾기부터 금융거래 차단까지에서 정리했습니다.
자주 묻는 질문
Q. 블로그 플랫폼이나 SNS만 쓰는 개인도 해당되나요?
이번 권고는 PHP로 돌아가는 서버를 직접 운영하거나 관리를 맡긴 사업자·기관을 대상으로 합니다. 서비스 회사가 서버를 운영하는 블로그나 SNS 계정만 쓰는 개인은 직접 업데이트할 대상이 없습니다. 다만 이용 중인 서비스에서 유출 안내가 오면 비밀번호를 바꾸는 등 일반적인 대응을 하시면 됩니다.
Q. 버전을 올렸는데 여전히 예전 버전으로 표시됩니다.
KISA는 업데이트 후 PHP를 실행하는 웹 서비스를 재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작한다고 설명합니다. 또 명령어로 보이는 버전과 웹 서비스가 실제로 쓰는 버전이 다를 수 있으니, 재시작 후 웹 서비스 기준으로 다시 확인해 보시기 바랍니다. 배포판 패키지라면 버전 번호 대신 변경 이력에서 CVE 반영 여부를 확인해야 할 수도 있습니다.
Q. PHP 8.2는 이번에 패치가 나왔는데 그대로 써도 되나요?
8.2.35 이상이면 이번 두 취약점은 해결됩니다. 다만 PHP 공식 공지와 KISA 모두 8.2의 보안 지원이 2026년 12월 31일에 끝난다고 밝히고 있어, 그 이후 새 취약점이 나오면 공식 패치를 받을 수 없습니다. KISA는 8.3 이상으로 전환할 것을 권장했습니다.
Q. 웹 방화벽을 쓰고 있으면 안전한가요?
웹 방화벽 차단 규칙은 위험을 줄이는 데 도움이 되지만, KISA는 임시 조치가 공격을 완전히 막지 못한다고 밝혔습니다. 최신 차단 규칙이 적용됐는지 확인하는 것과 별개로 PHP 업데이트는 반드시 진행해야 합니다.
정리
- PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 미만은 이번 치명적 취약점 2건의 영향을 받습니다(2026년 10월 21일 KISA 권고 기준).
- 8.1 이하는 공식 패치가 없으므로 지원 버전, 가능하면 8.3 이상으로 옮기는 계획이 필요합니다.
- 업데이트 후 재시작, 10월 20일 이후 로그 점검, 비밀번호·연동 키 교체까지 마쳐야 대응이 끝납니다.
- 호스팅·쇼핑몰 플랫폼 이용자는 업체의 조치 여부를 확인하고, 침해가 의심되면 보호나라 신고(상담 118)를 활용하시기 바랍니다.
이번 취약점은 AI 모델을 활용한 소스코드 점검 과정에서 발견됐다고 보도됐습니다. AI가 보안 사고의 양면에 어떻게 관여하는지는 AI 에이전트 무단 접속 사고|오픈AI 보고서와 인도 경보로 본 점검법에서도 다뤘습니다.
참고 자료
'IT·AI 소식' 카테고리의 다른 글
| 캡콤 개인정보 유출 확인과 대처|CAPCOM ID 1,177만 건 이메일 유출 (0) | 2026.10.23 |
|---|---|
| 챗GPT 대화 잠금 기능 사용법|PIN 설정과 재설정 시 삭제 주의 (0) | 2026.10.23 |
| 제미나이 구독 어디서 싸게|구글 직접 vs 통신3사 가격·해지 조건 비교 (0) | 2026.10.20 |
| 금융권 해킹 빙자 보이스피싱 구별법|경찰 경고문자와 안심차단 신청 (0) | 2026.10.20 |
| 행정서비스 제출서류 간소화 1,658개|서류 안 떼고 신청하는 법 (0) | 2026.10.20 |