AI 보안 취약점 PHP2Shell 사태: 웹사이트가 내려간 이유와 점검법

2026년 10월 웹사이트가 줄줄이 내려간 사건의 정체는 AI 보안 취약점 탐지로 실제 공격 경로가 드러난 PHP 엔진 결함, 일명 PHP2Shell(CVE-2026-109618, CVE-2026-109619)이에요. 해커가 사이트를 대거 무너뜨린 것이 아니라, 각국 보안기관이 "바로 패치할 수 없다면 시스템을 내리는 것도 검토하라"고 권고하면서 정부·공공기관·언론사가 예방 차원에서 페이지를 멈춘 것이 대부분이었어요. 이 글은 2026년 10월 26일 기준으로 PHP 공식 공지, PHP 재단, 미국 CISA, 영국 NCSC 자료를 읽고 정리했어요. 무엇이 발견됐는지, 왜 서비스가 멈췄는지, AI가 어떤 역할을 했는지, 그리고 사이트 운영자와 일반 이용자가 각각 확인할 점을 순서대로 설명해요.

AI 보안 취약점 PHP2Shell, 무엇이 발견됐나요

PHP는 서버에서 웹페이지를 만들어 내는 프로그래밍 언어예요. 워드프레스 같은 콘텐츠 관리 시스템, 쇼핑몰, 게시판, 호스팅 관리 화면 등이 PHP 위에서 돌아가요. 이번 결함은 특정 사이트의 코드가 아니라 PHP 엔진 자체에 있었기 때문에, 사이트를 아무리 꼼꼼하게 만들었어도 엔진을 업데이트하지 않으면 영향을 받을 수 있었어요. PHP 보안 공지는 두 결함이 인증 없는 원격 코드 실행(RCE)을 허용할 수 있다고 밝혔고, 두 건 모두 CVSS v4.0 기준 9.2로 평가됐어요.

PHP 프로젝트는 위험 대상을 웹 요청을 처리하는 모든 PHP 설치로 봤어요. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed가 모두 포함되고, 그중 mod_php의 위험을 가장 높게 평가했어요. 두 결함은 거의 모든 요청이 거치는 메모리 관리와 오류 처리 영역에 있어서 심각했고, 같은 이유로 호환성과 성능을 해치지 않고 고치기도 어려웠다고 PHP 재단은 설명했어요.

영향 범위 숫자는 어디까지 믿을까요

보도에는 "인터넷의 약 70%"라는 숫자가 자주 등장해요. BBC에 따르면 이는 보안 회사 Wiz의 추정이며 BBC도 직접 검증하지 못했다고 밝혔어요. PHP를 쓰는 사이트 비율과 실제로 공격 가능한 사이트 비율은 다른 개념이에요. 설치 방식, 버전, 앞단 프록시 설정에 따라 노출 정도가 달라지므로 숫자 하나로 피해 규모를 단정하지 않는 것이 좋아요.

패치가 나왔는데 왜 웹사이트가 줄줄이 내려갔나요

원래 계획은 조용한 조율 공개였어요. PHP 재단에 따르면 리눅스 배포판과 LTS 업체가 미리 패치를 받아 포장하고, 공개 시점에 모두가 동시에 업데이트할 수 있게 준비 중이었어요. 그런데 공개 이틀 전 CVE 번호가 잘못된 점수(10.0)와 함께 온라인에 퍼지면서 일정이 앞당겨졌어요. 아래는 공식 자료로 확인한 흐름이에요(시각은 UTC).

서비스 중단의 직접적인 계기는 보안기관 권고였어요. 영국 NCSC는 업데이트도 임시 완화도 바로 적용할 수 없다면 완전히 조치될 때까지 시스템을 오프라인으로 두는 것을 검토하라고 했어요. 미국 CISA도 즉시 업데이트할 수 없거나 지원이 끝난 8.1 이하를 쓰는 조직은 패치 전까지 PHP 기반 시스템을 내리라고 권고했어요. BBC 보도에 따르면 핀란드 정부의 공공 웹 서비스, 네덜란드 사이버보안 기관 웹사이트, 에든버러 시의회, 일부 BBC 페이지가 내려갔고, 위키미디어 재단도 일부 시스템을 예방 차원에서 내렸어요.

패치가 나왔는데도 바로 복구되지 않은 이유는 '어디에 PHP가 있는지' 찾는 일이 생각보다 어렵기 때문이에요. CISA는 PHP가 다른 소프트웨어의 부품으로 들어가 있어 직접 보이지 않을 수 있다고 지적했어요. 외주로 만든 사이트, 오래 방치된 테스트 서버, 네트워크 장비 관리 화면, 컨테이너 이미지 속 PHP까지 확인하려면 시간이 걸려요. 확인을 마치기 전까지 내려 두는 편이 침해 후 복구보다 비용이 적다고 판단한 기관이 많았던 셈이에요. 게다가 BBC는 Cloudflare 최고기술책임자가 초기 공격이 나타나고 있다고 밝혔다고 전해, 서두를 이유가 실제로 있었어요.

AI 취약점 탐지는 무엇을 바꿨고 무엇은 못 바꿨나요

이번 사건이 'AI가 찾은 취약점'으로 불리는 이유는 결함의 실제 위력을 확인하는 단계에 AI가 깊이 쓰였기 때문이에요. PHP 재단은 Anthropic의 모델로 PHP를 스캔한 적이 있고, 이후 OpenAI 도구를 보고서와 익스플로잇 검증에 활용했다고 밝혔어요. BBC가 인용한 Wiz 블로그는 최신 모델 덕분에 여러 애플리케이션에 맞춰 작동하는 익스플로잇을 몇 시간 만에 개발·적용할 수 있었다고 했어요. 2024년에는 이론에 머물던 문제가 2026년 여름 몇 주 만에 별도 조건 없이 작동하는 RCE로 확인된 셈이에요.

• 바뀐 것: 오래 묻혀 있던 결함의 공격 가능성을 확인하는 속도. 연구자들이 사람 손으로는 실용적이지 않았던 복잡한 단계를 AI로 검증했어요.
• 바뀐 것: 보고 건수. PHP 재단은 7월 1일 이후 CVE 15건을 공개했고, 무효·중복·재현 불가로 판명된 보고도 100건 넘게 처리했다고 밝혔어요.
• 못 바꾼 것: 수정 방식 결정. 호환성·성능·서드파티 확장과의 절충을 판단하고 패치를 검토하는 일은 여전히 엔진을 깊이 아는 소수의 개발자가 맡았어요.
• 못 바꾼 것: 공개 일정 관리. 이번 혼란을 키운 것은 AI가 아니라 CVE 번호 유출, 실수로 올라간 시연 영상, 엠바고 위반 같은 사람의 조율 실패였어요.

따라서 "AI가 위험을 만들었다"보다는 "AI가 방어자와 공격자 모두의 속도를 높였다"가 더 정확한 해석이에요. PHP 재단은 도구가 방어자와 공격자 모두에게 그 어느 때보다 빠르게 버그를 찾아 주고 있으며 보고 건수는 계속 늘 것이라고 봤어요. 취약점 공개부터 악용까지의 시간이 줄어들수록, 운영자에게 필요한 것은 더 빠른 자산 파악과 업데이트 체계예요. AI 보안 이슈의 흐름을 따라가고 싶다면 더따리의 AI 텔레그램 트렌드와 블로그 트렌드 대시보드에서 관련 화제가 어떻게 퍼지는지 살펴볼 수 있어요. 다만 이런 화제 지표는 공식 보안 공지를 대신하지 않으니, 조치 여부는 반드시 PHP·보안기관 원문으로 판단하세요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

페이지 참고

트렌드theddari.com›트렌드블로그 대시보드네이버 블로그 활동량 랭킹

사이트 운영자가 확인할 점검 순서

NCSC와 CISA의 권고, PHP 공식 공지를 합치면 대응 순서는 비교적 분명해요. 핵심은 '최신 버전이니 괜찮다'는 가정을 버리는 거예요. NCSC는 모든 버전이 영향을 받을 수 있으니 구버전만 찾지 말고 PHP 설치 전체를 확인하라고 했어요.

1. 1

   PHP가 도는 곳을 전부 찾아요

   인터넷에 노출된 서버부터 목록을 만들어요. 외주 사이트, 테스트 서버, 관리 화면, PHP가 내장된 장비·솔루션, 컨테이너 이미지도 포함해요. NCSC가 안내한 네덜란드 NCSC-NL의 영향 소프트웨어 목록도 참고할 수 있어요.

2. 2

   수정 버전으로 올리고 재시작해요

   PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상으로 업데이트해요. 배포판 패키지를 쓴다면 배포판 공지를 확인하고, 업데이트 후 모든 워커를 재시작해 실제 적용 여부를 확인해요. 8.1 이하는 지원 버전으로의 전환을 계획해요.

3. 3

   바로 못 올리면 임시 조치나 오프라인을 판단해요

   PHP 공지는 memory_limit=-1(애플리케이션이 덮어쓰지 못하게), 낮은 post_max_size, session.upload_progress.enabled=0 같은 임시 설정을 안내했지만 이는 특정 경로만 줄일 뿐이에요. 이마저 어렵다면 NCSC 권고대로 오프라인을 검토해요.

4. 4

   침해 흔적을 점검해요

   CISA는 PHP 워커 프로세스가 셸을 실행하거나 도구를 내려받는 활동을 감시하라고 했어요. 웹 폴더의 새 PHP 파일, 알 수 없는 외부 연결, 비정상적인 메모리 부족 오류와 반복된 서버 오류를 확인하고, 이상이 의심되면 서버를 끄기 전에 로그부터 보존해요.

5. 5

   후속 공지를 계속 확인해요

   PHP는 10월 23일 세션 업로드 진행 기능과 관련한 추가 정보 공지를 내고, 해당 설정을 비활성화한 채 다음 정기 릴리스를 기다리라고 안내했어요. 서드파티 제품에 들어 있는 PHP의 업데이트도 계속 추적해요.

일반 이용자가 알아둘 점과 남은 위험

일반 이용자가 PHP를 직접 업데이트할 일은 거의 없어요. 서버 쪽 문제이기 때문이에요. 다만 자주 쓰는 서비스가 일시적으로 접속되지 않는다면 대개 예방 점검일 가능성이 높으니, 서비스의 공식 공지 채널을 확인하고 '보안 확인'을 핑계로 로그인 정보를 요구하는 메일이나 문자는 피하세요. 큰 보안 이슈 직후에는 이를 미끼로 한 피싱이 늘기 쉬워요. 여러 사이트에 같은 비밀번호를 쓰고 있다면 이번 기회에 바꾸고, 가능한 곳에서는 패스키나 2단계 인증을 켜 두는 것이 좋아요.

남은 위험도 있어요. 첫째, 지원이 끝난 구버전 PHP를 쓰는 작은 사이트와 장비는 한동안 노출된 채 남을 수 있어요. 둘째, 공개 전부터 악용 시도가 있었다는 보고가 있어 업데이트만으로 이미 들어온 공격자를 내보낼 수는 없어요. 셋째, AI 도구로 취약점 검증이 빨라진 만큼 비슷한 규모의 공개가 다시 나올 수 있어요. 국내 운영자라면 KISA 보호나라의 보안공지도 함께 확인하고, 본인 서비스의 PHP 버전·업데이트 일자·점검 결과를 기록해 두면 다음 공지 때 훨씬 빨리 대응할 수 있어요. 정리하면 이번 사태는 AI가 공격을 일으킨 사건이 아니라, AI가 앞당긴 취약점 확인 속도에 패치·공개 체계가 따라가지 못한 순간이었어요.