웹사이트 70%가 쓰는 PHP에 '로그인 없이 서버 장악' 구멍 — PHP2Shell 전말과 지금 할 일 (AI 24시 핫클립 특집)

전 세계 웹사이트의 약 70%를 떠받치는 프로그래밍 언어에서, 로그인 한 번 없이 서버를 통째로 넘겨받을 수 있는 결함이 공개됐습니다. 이름은 PHP2Shell입니다.

더 눈길을 끄는 건, 이론으로만 있던 이 구멍을 실제로 터지는 공격 코드로 완성하는 데 AI가 큰 몫을 했다는 점입니다. 여파로 네덜란드는 디지털 신분증 DigiD의 웹사이트를, 프랑스는 파리 경찰청을 비롯한 도청 사이트들을 멈췄고, 위키백과를 운영하는 위키미디어 재단도 일부 시스템을 스스로 내렸습니다. 오늘은 사건의 전말과 팩트체크, 그리고 지금 내 서버를 지키는 법까지 한 번에 정리합니다.

한 줄 요약 — 공식 패치는 10월 21일 밤 이미 나왔습니다. 8.5.12·8.4.27·8.3.36·8.2.35 이상으로 올리고, 반드시 재시작하세요.

1. PHP가 뭐길래 — 인터넷의 기둥

PHP는 웹사이트에서 로그인하고, 글을 쓰고, 결제할 때 뒤에서 일하는 서버 언어입니다. 워드프레스, 위키백과의 미디어위키, 국내에서 많이 쓰는 그누보드와 라이믹스가 모두 PHP 위에서 돌아갑니다. 웹 통계 사이트 W3Techs 기준으로 서버 언어가 확인되는 사이트의 약 70%가 PHP를 씁니다.

한국 시간 10월 21일 밤 11시, PHP 팀은 8.2부터 8.5까지 긴급 패치를 내고 결함 두 건(CVE-2026-109618·109619)을 고쳤습니다. 위험도는 최신 기준(CVSS 4.0) 9.2점, 미국 NVD의 예전 기준으로는 9.8점입니다. 사전에 돌던 10.0점은 틀린 값이라고 PHP 재단이 밝혔습니다. 결함은 PHP 5.4(2012년) 무렵부터 10년 넘게 코드 속에 숨어 있었습니다.

2. 원리 — 앞사람이 남긴 설거지 거리

식당 테이블을 떠올리면 쉽습니다. PHP는 요청(손님)이 올 때마다 메모리라는 테이블을 잠깐 빌려줬다가 치웁니다. 그런데 메모리 한도 초과 같은 에러가 나면, 황급히 정리하느라 뒷정리를 건너뛰는 길이 있었습니다.

그래서 찌꺼기가 남습니다. 109618은 덜 만든 데이터에 '완성됨' 딱지가 붙은 채 남아 마감 정리 때 그대로 쓰이는 문제이고, 109619는 이미 돌려준 그릇을 계속 가리키는 낡은 장부가 남아 같은 일꾼(워커)의 다음 손님 때 사고를 내는 문제입니다. 공격자는 일부러 메모리를 꽉 채워 에러를 내고, 그 빈자리에 악성 명령어를 끼워 넣습니다.

무서운 이유 세 가지

1. 로그인이 필요 없습니다. 아파치에 PHP를 모듈(mod_php)로 붙인 흔한 기본 설정에서는 내 사이트 코드가 한 줄 돌기도 전에 공격이 먹힙니다.
2. 내 코드를 아무리 깨끗하게 짜도 소용없습니다. 구멍이 PHP 엔진 자체에 있어서 '안녕하세요'만 띄우는 페이지도 위험합니다.
3. 서버를 뺏기지 않더라도 메모리 속 비밀번호·토큰·API 키가 새어 나갈 수 있습니다.

PHP 재단은 위험이 가장 큰 곳이 mod_php라고 했고, PHP-FPM 환경에서 109618의 완전한 공격은 공개 시점에 아직 입증되지 않았다고 밝혔습니다. 그렇다고 FPM이 안전하다는 뜻은 아니니 업데이트는 똑같이 필요합니다. 위즈가 '5.4 이후 거의 모든 버전이 위험하다'고 한 건 병에 걸린 버전을, 한국인터넷진흥원이 '8.2 이상을 업데이트하라'고 한 건 약이 나온 버전을 말한 것입니다.

3. AI는 정확히 무엇을 했나

오픈AI와 트레일 오브 비츠가 이끄는 보안 점검 프로그램에서 보안업체 캘리프가 7월 30일 PHP 점검을 시작해 8월 11일 원격 코드 실행 결함을 신고했습니다. 같은 날 오픈AI도 따로 같은 뿌리를 찾아 신고했습니다. 구글 소속이 된 보안업체 위즈는 자체 도구 위즈 아틀라스에 제미나이 4 아르곤과 GPT-5.6 Sol을 붙여 8월 19일 독자적으로 결함을 찾았고 8월 24일 신고했습니다.

핵심은 AI가 없던 버그를 만든 게 아니라, 사람 눈으로는 '설마 터지겠어?' 싶던 복잡한 버그를 실제로 작동하는 공격 코드로 완성했다는 점입니다. 위즈는 세계 최고 팀이 몇 달 걸릴 일을 연구원 한 명이 AI와 일주일 만에 끝냈다고 했고, 구글은 제미나이가 큰 기여를 했다고 밝혔습니다. 둘 다 회사의 자체 발표라는 점은 감안해야 합니다.

4. 왜 진작 안 고쳐졌나 · 어떻게 터졌나

경고등은 2024년에 이미 켜졌습니다. 외부 보안 감사(소버린 테크 에이전시 자금, OSTIF 조직, Quarkslab 수행) 때 결함을 고치던 PHP 개발자가 메모리 문제의 첫 징후를 봤지만, 공격 경로를 찾지 못했고 고치는 방법마다 호환이 깨지거나 새로운 서비스 거부 위험이 생겨 몇 달씩 멈췄다 다시 하기를 반복했습니다. PHP 재단은 이를 '구조적 실패'라고 스스로 평가했습니다.

원래 공개일은 10월 22일이었습니다. 그런데 10월 20일 결함 번호가 포럼과 SNS로 새면서 하루 앞당겨졌고, 캘리프가 공격 시연 영상을 실수로 올렸다가 지웠지만 복사본이 이미 퍼졌습니다. 보안업체 체인가드는 공식 공개보다 6시간 넘게 먼저 고친 판을 배포해 '일방적으로 약속을 깼다'는 비판을 받았고, 체인가드는 다른 업체들이 실제 공격을 알려 왔다고 반박했습니다(증거는 공개하지 않음).

5. 실제 공격은 있었나 — '시도'와 '성공'은 다르다

아마존(AWS)은 해커를 유인하는 미끼 서버(허니팟) 기록에서 공식 발표 나흘 전인 10월 17일에 이미 공격 시도를 확인했습니다. 지금도 시도는 쏟아지고 있습니다. 다만 워치타워는 '시도를 관측했다'고만 했고, 아마존도 성공 여부는 알 수 없다고 했습니다. 미국 사이버보안청(CISA)의 실제 악용 목록에도 아직 없고, 국내 공식 침해 신고도 아직 없다는 보도입니다.

그래도 방심은 금물입니다. 과학기술정보통신부는 10월 22일 낮 12시 민간 분야 사이버 위기 경보를 '관심'에서 '주의'로 올렸고, 안랩은 국내 취약 서버를 약 11만 대(세계 6위 수준)로 추산했습니다.

6. 찬반 논쟁 — 방패인가, 창인가

긍정론은 AI 덕분에 10년 묵은 결함을 먼저 찾아 고쳤다고 말합니다. 하지만 공개 나흘 전 공격 흔적이 나온 이상 '무조건 해커보다 빨랐다'고 하긴 어렵습니다. 비관론은 속도를 걱정합니다. 아마존은 AI로 패치 내용을 공격 코드로 바꾸는 비용이 싸져, 기술 내용이 풀리면 몇 시간, 심지어 몇 분 안에 공격이 움직일 수 있다며 '7일·30일 안에 패치'라는 기준은 이제 시간 단위로 다시 재야 한다고 했습니다.

오픈AI의 그렉 브록먼 사장은 정부 같은 허가받은 방어자가 극단적인 경우 남의 서버를 원격으로 고쳐 주는 방안까지 화두로 던졌습니다. PHP 보안팀은 7월 이후 무효·중복·재현 불가 신고를 106건이나 걸러야 했다며, 기업과 정부에 함께 부담해 달라고 호소했습니다. 반대로 '호들갑은 금물'이라는 시각도 있습니다. 안랩 집계로 깃허브의 공격 코드 저장소는 100개 남짓인데 제대로 도는지 불확실하고, 일부는 AI로 썼다고 스스로 밝힌 것들입니다.

루머 바로잡기 — 'AI가 Next.js까지 털었다'는 소문은 반만 맞습니다. Next.js의 9.5점 원격 코드 실행 결함 2건은 10월 14일 이미 패치된 별개 사건이고, AI가 찾았다는 근거는 없습니다. Next.js는 16.4.1 또는 15.5.28 이상으로 올리면 됩니다. 한편 10월 21일에는 AI 라이브러리 LiteLLM 1.107.0에 API 키를 빼돌리는 악성코드가 두 시간 가까이 배포됐고, 클라우드 서비스 Railway도 보안 사고를 알렸습니다.

7. 지금 당장 해야 할 일

카페24·가비아 같은 대형 호스팅은 패치를 적용했다고 밝혔으니 공지부터 확인하세요. 서버를 직접 관리한다면 지금 터미널을 여세요.

1. 버전 확인: php -v 또는 관리자 화면
2. 업데이트: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 이상
3. 재시작: 아파치나 PHP-FPM을 재시작해야 구버전이 메모리에서 내려갑니다
4. 워드프레스: 플러그인 업데이트만으로는 안 됩니다. PHP 엔진 자체를 올리세요
5. 8.1 이하: 공식 업데이트 판이 없습니다(7.4~8.1은 소스 최소 패치만). 버전을 올리거나 호스팅사 보안 패치를 쓰세요. 체크포인트 집계로 버전이 드러난 서버의 약 59%가 이런 구버전이고, 8.2도 2026년 12월 31일 지원이 끝납니다
6. 흔적 점검: 업로드 직후 메모리 오류·500 에러 반복, 크거나 깨진 세션 쿠키, 혼자 재시작되는 프로세스(확증은 아니지만 신호)

오늘의 꿀팁 — 당장 업데이트를 못 할 때 — PHP 공식 안내의 임시 설정입니다. ① memory_limit = -1 로 PHP 자체 한도를 풀고(앱이 못 바꾸게 고정), 메모리는 컨테이너·cgroup 같은 운영체제 쪽에서 묶습니다. RLIMIT_AS·RLIMIT_DATA 로 묶으면 안 됩니다. ② 업로드가 필요 없다면 post_max_size = 8M, 웹 서버에서 요청 크기·파일 조각 수를 제한합니다. ③ session.upload_progress.enabled = 0, PHP 8.5는 fatal_error_backtraces = 0 으로 끄고 재시작합니다. 단, 공식 안내는 '노출을 줄일 뿐 안전하게 만들지는 않는다'고 못 박았습니다. 답은 정식 업데이트입니다.

자주 묻는 질문 — Q. 호스팅을 쓰는데 제가 할 일이 있나요?

A. 카페24·가비아는 패치 적용을 밝혔습니다. 공지에서 내 상품의 PHP 버전과 조치 여부를 확인하세요.

Q. PHP-FPM을 쓰면 괜찮나요? A. 위험이 가장 큰 건 mod_php이지만 FPM도 업데이트 대상입니다. 업데이트 뒤 재시작까지 하세요.

Q. 임시 설정만 해 두면 되나요? A. 아닙니다. 공식 안내도 노출을 줄일 뿐이라고 했습니다. 정식 업데이트가 답입니다.

오늘의 3줄 요약

1. PHP2Shell(9.2점)은 로그인 없이 서버를 넘겨줄 수 있는 PHP 엔진 결함 — 공식 패치는 10월 21일에 나왔다
2. AI는 버그를 만든 게 아니라 '작동하는 공격 코드'의 난이도를 바닥으로 끌어내렸다 — 시도는 쏟아지지만 성공 사례는 아직 확인되지 않았다
3. php -v → 8.5.12·8.4.27·8.3.36·8.2.35 이상 → 재시작. 임시 설정은 진통제일 뿐

출처

• php.net 보안 공지(2026-10-21)
• PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security", 2026-10-21
• PHP Foundation, "How the PHP security team handles your reports", 2026-10-14
• GitHub 보안 권고 GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp (php/php-src)
• NVD CVE-2026-109618 · CVE-2026-109619
• Wiz, "PHP2Shell"
• Google Cloud 블로그, "Responding to core PHP vulnerabilities"
• AWS Security Blog, Amazon Threat Intelligence(MadPot), 2026-10-21
• AhnLab ASEC: https://asec.ahnlab.com/ko/95943/ · Check Point 블로그(2026-10-20)
• Wikimedia Diff(2026-10-21) · rijksoverheid.nl(2026-10-21) · W3Techs
• LiteLLM 보안 사고 공지(2026-10-21) · Netlify changelog(2026-10-14, Next.js)
• 국내 보도: 서울신문·강원도민일보·머니투데이방송(2026-10-22)

※ 이 글은 AI 24시 핫클립 특집 영상을 바탕으로 원문과 대조해 정리했습니다. 인용은 요지입니다. 보안 설정은 정보 제공용이며, 운영 서버 변경 전에는 백업과 담당자 확인을 거치세요. 영상 내레이션은 AI 음성(Gemini TTS)이고, 배경 영상은 AI로 만든 것입니다(Grok·Kling, 시작 그림 시온바나나). 도표는 직접 그렸고, 웹 화면은 2026.10.22 공개 페이지 캡처입니다.