전 세계 웹을 흔든 PHP2Shell

🐚 도어락은 멀쩡한데 문틀이 부서졌어요

구독자님 안녕하세요! 🐥

현관에 아무리 비싼 도어락을 달아도, 문틀이 통째로 부서져 있으면 아무 소용이 없겠죠. 지난 10월 전 세계 웹사이트에서 딱 이런 일이 벌어졌어요. 수많은 사이트가 비밀번호를 강화하고 보안 장비를 들여놨는데, 정작 그 아래 바닥이 부서져 있었거든요.

그 바닥의 이름은 PHP예요. 웹사이트를 움직이는 엔진 같은 프로그램인데, 전 세계 웹사이트 10곳 중 7곳가량이 이 엔진 위에서 돌아가요. 그런데 바로 그 엔진에서 심각한 결함 두 개가 발견됐어요. 이름하여 PHP2Shell입니다 😰

😮 로그인도 필요 없이 가능하다?

2026년 10월 21일, PHP 개발팀이 긴급 보안 업데이트를 내놨어요. 여러 연구팀이 비슷한 시기에 각자 찾아낸 결함 두 개를 급히 막기 위해서였죠. 처음 발견해 동작하는 익스플로잇까지 만든 건 8월 초 보안 기업 Calif의 Ryan Austin(@lcfr_hax)이었고 (https://www.calif.io/research/php2shell), 뒤이어 Wiz와 OpenAI도 독립적으로 같은 뿌리의 문제를 제보했어요 (https://www.wiz.io/blog/php2shell-php-rce). 이 둘을 묶어 PHP2Shell이라는 이름을 붙인 건 Wiz인데, 굳이 옮기면 “PHP에서 곧장 셸까지”라는 뜻이에요. 이름부터 결론을 말해주고 있죠.

이 사고가 유독 시끄러웠던 이유는 두 가지예요. 하나는 로그인이 필요 없다는 점이에요. 보통 해킹이라고 하면 아이디와 비밀번호를 알아내는 단계부터 떠올리는데, 이번엔 그 과정이 통째로 생략돼요.

다른 하나는 더 당황스러워요. 내가 만든 사이트 코드에 아무 문제가 없어도 똑같이 당할 수 있어요. 워드프레스로 만들었든 직접 개발했든 상관이 없거든요. 문제가 내 코드가 아니라 그 아래 엔진에 있으니까요. 😶

얼마나 심각한지는 숫자로도 나왔어요. 위험도 점수 10점 만점에 9.2점, 등급으로는 '치명적'을 받았습니다. 그렇다면 멀쩡히 돌아가던 엔진에서 왜 이런 일이 생긴 걸까요?

🍳 엔진이 뒷정리를 깜빡했다?

여기부터는 조금 이야기처럼 풀어볼게요. 어려운 말은 최대한 덜어낼게요. 🙂

웹사이트 엔진은 손님이 올 때마다 주방에서 요리하듯 일을 처리해요. 재료를 꺼내고, 손질하고, 다 쓰면 정리하죠. 이번 사고는 바로 그 정리 과정에서 났어요.

첫 번째 결함은 이래요. 요리사가 재료를 손질하다가 작업대가 꽉 차서 중간에 멈춰버렸어요. 그런데 뒤따라 들어온 정리 담당이 반쯤 손질된 재료를 보고는 다 끝난 완성품인 줄 알고 그대로 손님상에 올려버린 거예요. 😵

두 번째 결함은 사물함에 비유할 수 있어요. 손님이 사물함을 쓰고 나가면서 번호표를 반납하지 않고 들고 나가버렸어요. 사물함은 이미 비워져서 다음 손님에게 넘어갔는데, 엔진이 그 옛날 번호표를 그대로 들고 사물함을 열어버려요. 열어보니 남의 물건이 들어 있는 거죠.

왜 이런 일이 가능할까요? 웹사이트 엔진은 손님 한 명마다 새로 켜지는 게 아니라, 창구 직원 한 명이 여러 손님을 연달아 받는 구조이기 때문이에요. 앞 손님의 흔적이 깨끗이 지워지지 않으면 바로 다음 손님이 그걸 집어들게 돼요. 여기서 꼭 기억하실 게 하나 있어요. 이 사고는 누가 나쁜 데이터를 집어넣어서 생긴 게 아니라, 엔진이 뒷정리를 제때 못 해서 생긴 일이에요. 그래서 수상한 데이터를 걸러내는 보안 장비만으로는 막기 어렵고, 엔진 자체를 고쳐야 해결돼요. 🙅

그럼 실제로 이 결함을 노린 공격도 있었을까요?

🔥 패치 이전 공격이 먼저 사용되고 있었다

네, 안타깝게도 있었어요. 그런데 더 서늘한 건 순서입니다. 🥶

아래 그래프가 그 순서를 그대로 보여줘요. 세로선이 패치가 공개된 시점인데, 그보다 왼쪽에서 이미 공격 IP가 올라오고 있어요.

출처: CrowdSec

패치가 세상에 나오기도 전에 이미 누군가는 이 결함을 알고 쓰고 있었다는 뜻이에요. 보안 업데이트 소식을 듣고 그때부터 대응을 시작했다면 이미 나흘이 늦었던 셈이죠.

10월 24일 사례는 특히 뼈아파요. 공격당한 서버가 쓰던 버전은 8.4.26이었고 안전한 버전은 8.4.27이었거든요. 딱 한 칸 차이였어요. 😭

🕵️ 북한 연계로 보이는 움직임

위협 분석 업체 CYFIRMA는 북한 연계로 추정되는 집단의 움직임을 포착했다고 밝혔어요. 21개 거점을 돌려가며 한국, 미국, 일본, 인도 등 12개국에서 아직 업데이트하지 않은 서버 216곳을 추려내고 있었다는 내용이에요. 정부기관과 금융, 물류, 항공 분야가 표적에 들어 있었고요.

다만 이건 아직 표적을 고르는 단계까지 확인된 것이고, 분석 업체도 확신 수준을 '중간'이라고 밝혔어요. 실제 피해로 이어졌다는 보고는 아니라는 점도 같이 알아두시면 좋겠어요. 🙏

⚖️ 과열된 보도의 가능성

이번 사건은 보도가 과열된 면도 있었어요. 한 대형 보안업체가 "유럽의 정부기관이 공격 두 시간 만에 핵심 인증정보까지 털렸다"고 발표해 크게 번졌는데요. 이 발표는 이후 해당 업체가 "이번 취약점과 연관됐다고 확인할 수 없다"며 스스로 거둬들였어요. 국내 기사 중에도 정정 전 내용을 그대로 옮긴 곳이 꽤 있으니, 혹시 인용하실 일이 있다면 꼭 확인하고 쓰시길 권해요 .⚠️

그렇다면 규모는 실제로 어느 정도였을까요? 한 대학 연구팀은 70개국 600여 개 주소에서 5만 건이 넘는 공격 시도를 추적했다고 밝혔어요. 인터넷에 열려 있으면서 위험한 버전을 쓰던 서비스는 10월 22일 기준 약 3,670만 개로 집계됐고요. 실제로 호주 사이버보안센터를 비롯한 일부 해외 정부 사이트는 아예 홈페이지 문을 잠시 닫기도 했어요 📊

그럼 우리나라는 어땠을까요?

🇰🇷 우리나라는 어떻게 대응하고 있는가?

출처: KISA 보호나라(https://boho.or.kr/)

국내 대응은 꽤 빨랐어요. 과학기술정보통신부가 10월 22일 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 올렸어요. 웹사이트 엔진 하나 때문에 국가 경보 단계가 올라가는 일은 흔치 않습니다 (https://byline.network/2026/10/22-618/).

한국인터넷진흥원도 21일과 22일에 걸쳐 업데이트 권고와 기업용 대응 수칙을 연달아 내놨어요. 공격에 성공하면 웹셸 설치로 이어질 수 있다고 설명했는데, 웹셸은 공격자가 서버에 몰래 심어두는 원격 조종용 파일이에요. 한번 심기면 고객정보 유출이나 홈페이지 변조, 내부망 침투까지 갈 수 있어요. 😨

국내 보안기업들도 빠르게 움직였어요. 🛠️

그리고 의외의 사각지대가 하나 있어요. 보안업체 지니언스는 인터넷에 드러난 웹서버보다 사무실 안쪽에 조용히 놓여 있는 장비가 더 위험할 수 있다고 경고했어요. 사내 자료 보관함으로 쓰는 NAS, 공유기, 방화벽 같은 것들이요. 이런 장비 안에도 PHP가 들어 있는 경우가 많은데 보통 '우리 서버 목록'에는 안 잡히거든요. 🔍

여기까지 읽으셨다면 가장 궁금한 건 하나일 거예요. 그래서 지금 뭘 하면 될까요?

🛡️ 우리는 지금 뭘 하면 되는가

입장에 따라 할 일이 달라요. 두 갈래로 나눠 볼게요.

🙋 사이트를 직접 운영하지 않는다면

사실 직접 하실 수 있는 건 많지 않아요. 다만 자주 쓰는 사이트에서 "비밀번호를 변경해 주세요"라는 안내 메일이 오면 미루지 말고 바꿔주세요. 이번 취약점은 서버 메모리에 잠깐 떠 있던 비밀번호까지 흘릴 수 있어서, 예방 차원에서 교체를 안내하는 곳이 나올 수 있거든요. 여러 사이트에 같은 비밀번호를 쓰고 계셨다면 이번 기회에 나눠두시는 걸 권해요. 🔑

🧑‍💻 사이트나 서버를 운영하신다면

우리 사이트가 영향권인지부터 확인하고 싶으시다면, 스틸리언이 무료 점검 서비스를 열어뒀어요. 사이트 주소만 넣으면 PHP 버전을 읽어서 알려주는데, 공격을 시도하지 않고 응답 헤더만 확인하는 방식이에요. 본인이 관리하는 사이트만 점검해주세요. 🔎

가장 중요한 건 하나예요. 임시 조치로는 완전히 막을 수 없고, 업데이트만이 해결책이에요. PHP 개발팀도 한국인터넷진흥원도 똑같이 강조한 부분입니다. ‼️

① 버전 올리기

8.1 이하는 공식 지원이 이미 끝나서 정식 업데이트가 없어요. 지원되는 버전으로 옮기셔야 해요. 참고로 8.2도 올해 12월 31일에 지원이 끝나니, 이왕이면 8.3 이상으로 가시는 걸 권해요. 📅

② 재시작하기

업데이트만 하고 끝내면 안 돼요. 기존에 떠 있던 프로그램이 그대로 돌고 있으면 예전 상태 그대로거든요. 꼭 재시작까지 해주세요.

③ 로그 확인하기

10월 20일 이후 기록을 살펴보세요. 유독 큰 요청이 들어온 뒤 오류가 난 흔적, 서버가 영문 없이 재시작된 기록, 업로드 폴더에 못 보던 파일이 생긴 흔적이 신호예요. 다만 로그가 깨끗하다고 해서 안전이 보장되는 건 아니라고 진흥원은 못 박았어요.

④ 인증정보 바꾸기

업데이트 전까지 인터넷에 열려 있던 서버라면, 데이터베이스 비밀번호와 각종 연동 키, 관리자 계정 비밀번호를 바꿔두시는 게 좋아요.

⑤ 이상하면 끄지 말기

침해가 의심되면 서버를 끄거나 재시작하고 싶어지는데, 그러면 메모리에 남아 있던 증거가 사라져요. 외부 접속만 차단하고 보호나라에 신고하신 뒤 로그와 접속 기록부터 보존해주세요. 🚑

마지막으로 인터넷에 돌아다니는 공격 코드 중에는 악성코드를 숨겨둔 가짜가 많다고 진흥원이 경고했어요. 취약한지 확인하겠다고 그걸 실행해보시면 안 돼요. 버전 확인과 로그 점검으로 판단하시는 게 안전합니다.

🐥 마무리

이번 사건이 유독 아팠던 이유는, 고장 난 곳이 각자의 집이 아니라 모두가 딛고 선 바닥이었기 때문이에요. 내 사이트를 아무리 꼼꼼히 관리해도 그 아래 엔진이 뚫리면 방법이 없다는 걸 비싸게 확인한 셈이죠. 😮‍💨

하나 더 곱씹어볼 지점이 있어요. 이 결함들은 10년 넘게 조용히 잠들어 있던 것들인데, Wiz는 이걸 실제 공격으로 바꾸는 문턱을 최신 AI 모델이 크게 낮춰줬다고 밝혔어요. 오래 묻혀 있던 버그를 AI가 깨우기 시작했다는 신호로 읽히는 대목이에요. 🤖

그리고 이게 끝이 아닐지도 몰라요. PHP 재단은 이미 세 번째 결함을 언급했거든요. 다만 이쪽은 특정 조건이 겹쳐야 하는 경우라 정기 업데이트에 포함될 전망이에요. 소식이 더 나오면 다음 호에서 또 가져올게요 👀

읽어주셔서 감사합니다! 🐤

참고 자료

구독자님, 오늘 뉴스레터는 어떠셨나요?
해킹/보안 관련 콘텐츠를 계속 받아보고 싶으시다면 구독 부탁드려요! 🙌