PHP 원격 코드 실행 취약점 긴급 패치에 각국 사이트 중단…'6시간 조기 공개' 공방 뒤엔 2024년부터 못 고친 결함

무엇이 고쳐졌나

PHP2Shell이 무거운 이유는 결함이 개별 홈페이지가 아니라 PHP 엔진 자체에 있다는 데 있다. 홈페이지 코드를 안전하게 짰어도 그 밑에서 도는 PHP가 취약하면 공격에 노출된다. 워드프레스나 플러그인을 업데이트해서는 이 결함이 고쳐지지 않는다. PHP 개발진은 설정을 바꾸는 임시 조치는 확인된 공격 경로 일부만 막을 뿐이라며 업데이트만이 완전한 해결책이라고 밝혔다. 각국 당국의 권고가 '당장 업데이트하고, 못 하면 사이트를 내리라'로 모인 것은 이 때문이다. 미국 국가안보국(NSA)은 즉시 업데이트할 수 없는 시스템은 조치를 마칠 때까지 오프라인으로 돌리라고 권고했다. 21일 하루 동안 네덜란드·핀란드·독일·프랑스·벨기에·체코의 정부 사이트와 네덜란드의 항만·병원 웹사이트가 잇달아 멈췄다. 한국 정부는 22일 낮 12시 민간 사이버위기 경보를 '관심'에서 '주의'로 올렸다. 삼성전자는 PHP 기반 웹사이트 접속을 막은 뒤 패치를 적용했다.

'웹사이트 70%'는 피해 규모가 아니다

이런 장면 때문에 'PHP가 뚫렸다'는 인상이 퍼졌지만, 자주 인용되는 '전 세계 웹사이트의 70%'는 공격받을 수 있는 서버의 비율이 아니다. 웹 기술 통계 서비스 W3Techs가 서버 쪽 언어를 알아낼 수 있는 웹사이트를 세었더니 그중 69.3%가 PHP를 쓰더라는 사용률이다. 패치를 했는지, PHP를 어떤 방식으로 돌리는지는 이 숫자에 들어 있지 않다.

공격이 실제로 성립하는 조건은 PHP를 웹서버에 붙이는 방식에 따라 다르다. PHP 개발진은 웹 요청을 처리하는 설치 전반을 위험 대상으로 지정하면서도, 위험이 가장 큰 곳으로 Apache 웹서버에 PHP를 모듈로 붙이는 mod_php 방식을 꼽았다. 이 방식에서는 홈페이지 프로그램이 실행되기도 전에, 기본 설정 그대로 공격이 통한다는 것이 검증됐다. 널리 쓰이는 또 다른 방식인 PHP-FPM에서는 공격이 홈페이지 프로그램의 동작에 기대는 경로로 좁혀진다. 공식 지원이 끝난 8.1 이하 버전도 영향을 받는다. 개발진은 이 가운데 7.4·8.0·8.1용으로 최소한의 수정 코드를 따로 내놨다.

공격 시도는 이미 있었다. 아마존웹서비스(AWS)는 공개 나흘 전인 10월 17일 자사 유인 서버에 PHP2Shell 공격 시도가 기록됐다고 밝혔다. 보안업체 VulnCheck도 21일 유인 서버에서 웹셸(서버를 원격 조종하는 악성 파일) 설치 시도를 관측했지만, 그 시도는 실패로 끝났다. 그러나 이 결함으로 실제 서비스가 침해되거나 데이터가 빠져나간 사례는 지금까지 나온 자료에서 확인되지 않는다. 사이트 중단도 예방 조치였다. 핀란드 정부 웹서비스를 운영하는 Valtori는 중단이 침해 사고의 결과가 아니라고 설명했다. 삼성전자도 해킹 피해를 본 웹사이트는 없는 것으로 알려졌다. 지금의 그림은 'PHP가 뚫렸다'보다 '뚫릴 수 있는 구멍을 공격자와 방어자가 거의 동시에 알게 됐다'에 가깝다. 그렇게 된 데에는 공개 과정이 흔들린 사정이 있다.

공개 일정은 어떻게 흔들렸나

이번 결함은 원래 '공조 공개'로 처리될 예정이었다. 발견자가 결함을 비공개로 신고하면, 개발진이 수정을 만들어 리눅스 배포판과 장기지원 업체에 미리 나눠 주고, 정해진 시각에 모두가 함께 공개하는 방식이다. 이 약속을 엠바고라고도 부른다. 결함 내용이 알려지는 순간 이용자가 곧바로 업데이트할 수 있게 하려는 장치다. 공개 예정 시각은 한국시각 10월 22일 밤 11시였다. 아래 시각은 모두 한국시각이다.

공개 직전 이틀 동안 이 계획은 연달아 흔들렸다. PHP 개발과 보안 업무에 돈을 대는 PHP 재단의 경위 설명에 따르면, 21일 0시 무렵 두 결함의 식별번호가 온라인 게시판과 SNS에 퍼졌다. 기술 정보는 없었지만 PHP 개발진은 공개를 하루 앞당겨 21일 밤 11시로 바꿨다. 곧바로 공개하지 않은 이유로는 배포판들이 아직 수정 패키지를 만들고 있어, 바로 공개하면 많은 이용자가 쉽게 업데이트할 길이 없다는 점을 들었다. 개발진은 이때 낸 사전 공지에 기술 세부 정보가 공개되거나 실제 공격 증거가 나오면 더 일찍 배포할 수 있다고 적었다. 몇 시간 뒤에는 결함을 신고한 보안기업 캘리프가 여러 대상에 공격이 통하는 시연 영상을 실수로 올렸다가 지웠다. 재단은 퍼진 사본이 다른 공격 코드 개발을 앞당겼다고 평가했다.

재단이 결정타로 지목한 것은 체인가드다. 체인가드는 서버 프로그램을 바로 실행할 수 있게 묶어 둔 꾸러미(컨테이너 이미지)를 보안을 강화해 공급하는 기업이다. 다른 배포업체처럼 수정 코드를 미리 받아 둔 처지였다. 체인가드는 21일 오후 4시 41분, 공동 공개보다 6시간 19분 앞서 수정이 들어간 이미지를 고객만이 아니라 누구나 받을 수 있게 공개했다. 재단은 체인가드가 일방적으로 엠바고를 깼다며 "다른 모든 PHP 이용자가 아직 공개를 기다리는 동안 어떤 공격자든 바이너리 형태의 수정을 연구할 수 있게 됐다"고 비판했다. 국내 보도가 '숨죽인 6시간'이라고 부른 것이 이 간격이다.

체인가드 최고경영자 댄 로렌크는 유출이 아니라 판단이었다고 맞섰다. 그는 다른 보안업체들이 실제 공격을 확인했고, 자사가 결함을 쉽게 다시 찾아 공격까지 재현할 수 있었으며, 이미 많은 정보가 퍼져 있었다는 점을 근거로 들었다. 다른 연구자들과 영상통화를 한 뒤 배포를 결정하고 곧바로 그룹에 알렸다고 했다. 실제 공격 증거가 나오면 먼저 배포할 수 있다는 공조 공개 지침을 따랐다는 설명이다. 그는 재단과 관리자들에게 사과하면서도 다시 해도 같은 결정을 하겠다고 말했다. 재단의 경위 설명을 쓴 닐스 아더만은 로렌크의 해명에 대해, 공유된 것은 탐색과 공격 시도였을 뿐 성공한 공격 보고는 없었고 로렌크가 PHP 팀과 상의하지 않고 혼자 정했다고 반박했다.

6시간은 공격의 출발점이 아니었다

시간표를 놓고 보면, 체인가드의 6시간은 공격자에게 처음 길을 열어 준 시간이 아니다. AWS는 17일에 이미 공격 시도를 기록했다. 21일 오전 11시 무렵부터는 공개된 공격 코드 여러 개와 여러 공격자의 시도를 확인했다. 이 시도의 시작은 체인가드가 이미지를 내놓은 오후 4시 41분보다 다섯 시간 넘게 앞선다. 로렌크의 말대로라면 체인가드도 16일(금)에 원래 발견자 중 한 사람에게서 PHP에 뭔가 온다는 말을 전해 들었다. 엠바고는 체인가드가 깨기 전에 이미 여러 곳에서 새고 있었다. 체인가드의 공개로 공격자가 수정 코드를 분석할 수 있게 됐다는 재단의 지적은 사실이다. 그러나 그 6시간을 이번 위험의 출발점처럼 다루는 것은 시간표와 맞지 않는다.

그렇다고 체인가드의 결정이 옳았다는 뜻은 아니다. 양쪽이 내세우는 원칙은 같다. PHP 개발진은 사전 공지에서 실제 공격 증거가 나오면 일찍 배포할 수 있다고 했고, 로렌크도 같은 원칙을 따랐다고 말한다. 갈린 것은 공격 '시도'를 증거로 볼지, 그리고 그 판단을 누가 내리는지다. 여러 주체가 함께 정한 시각을 참여자 한 곳이 혼자 바꿀 수 있다면, 다른 참여자도 저마다 판단해 먼저 내놓을 수 있다. 그러면 공조 공개는 성립하지 않는다. 이 점에서 혼자 정했다는 재단의 비판은 타당하다. 판단을 바꿀 수 있는 정보도 남아 있다. 재단은 공개 시점까지 작동하는 공개 공격 코드는 확인하지 못했다고 했다. AWS의 17일 관측이 체인가드 결정 전에 공조 채널에 공유됐는지도 확인되지 않는다. 당시 돌던 공격 시도가 실제로 성공할 수준이었다면 로렌크의 판단은 더 무게를 얻는다. 어느 쪽이든 6시간의 잘잘못은 절차의 문제이고, 위험은 그보다 훨씬 전에 시작됐다.

더 큰 실패는 2024년에 시작됐다

이번 사태에서 PHP 재단이 스스로 인정한 실패는 몇 시간이 아니라 몇 년에 걸친 일이다. PHP는 2024년 독일 공공기관 Sovereign Tech Agency의 지원으로 외부 보안 감사를 받았다. 재단에 따르면 이때 감사 지적을 고치던 재단 계약 개발자가 이번 메모리 결함의 첫 징후를 발견했다. 하지만 실제 공격 경로는 찾지 못했다. 게다가 수정안마다 대가가 따랐다. 기존 프로그램과의 호환성이 깨지거나, 서비스를 마비시킬 새로운 위험이 생기거나, 외부 확장 모듈을 대거 고쳐야 했다. 만장일치로 결정하는 보안팀은 안을 고르지 못했고, 엔진을 깊이 아는 개발자도 적었다. 작업은 수개월 동안 멈췄다 다시 시작하기를 반복했다. 재단은 이를 의사결정 과정과 자원 부족에 따른 구조적 실패라고 인정했다.

이 정체를 끝낸 것은 외부 신고였다. 2026년 8월 캘리프와 AI 기업 오픈AI가 같은 원인의 결함을 각각 신고했고, 구글 계열 보안기업 위즈가 공격 경로를 더했다. 실제 원격 코드 실행이 가능하다는 것이 분명해지자 수정은 재단 보안 인력 전체의 최우선 과제가 됐다. 2024년에 징후를 본 결함의 수정판은 2026년 10월에야 나왔다. 공개 시각을 둘러싼 혼선은 이 긴 지연 끝에, 결함이 바깥에서 여러 번 다시 발견된 뒤에 벌어진 일이다.

재단은 원인을 사람과 돈의 부족에서 찾고 처방도 그쪽에 둔다. 보안팀이 다수결로 결정하고, 복잡한 수정이 막히면 지도부가 더 일찍 개입하도록 절차를 바꾸고 있다고 밝혔다. 웹의 큰 부분을 떠받치는 PHP의 보안 작업이 여전히 재단이 돈을 대는 소수 개발자와 약간의 자원봉사에 기대고 있다고도 했다. 그러면서 PHP로 제품을 만드는 기업, 호스팅 업체, PHP로 공공 서비스를 돌리는 정부에 재정 지원을 요청했다. 이 진단은 경과와 들어맞는다. 2024년에는 소수 인력이 다른 업무와 함께 붙들고 있던 문제를, 2026년 8월 이후에는 여러 사람이 전담해 두 달여 만에 고쳤다.

AI가 줄인 시간

2024년의 지연이 이번에 혼란으로 번진 데에는 AI가 결함을 찾는 속도를 바꿔 놓은 사정이 겹쳤다. 캘리프의 연구자 라이언 오스틴은 오픈AI의 모델 GPT-5.6 Sol과 과거 PHP 취약점에 관한 자기 지식을 함께 써서 8월 1일 첫 공격 경로를 찾았다. 위즈는 AI 덕분에 공격 대상별 공격을 몇 시간 단위로 만들 수 있었다고 밝혔다. 한 연구자가 일주일 동안 예전 최상급 팀이 몇 달 걸릴 일을 해냈다는 자체 평가도 내놨다. 로렌크는 PHP에 뭔가 온다는 말만 듣고 그날 밤 자사 AI 도구에 'PHP에서 나쁜 취약점을 찾아라'라는 기본 지시를 넣어 같은 결함을 찾아냈다고 했다.

결함이 있다는 사실만 알려져도 누군가 다시 찾아낼 수 있다면, 엠바고가 지켜 줄 수 있는 시간은 짧아진다. 아마존의 보안 책임자 CJ 모지스는 "엠바고는 다른 누군가가 같은 버그를 찾을 때까지만 방어자를 보호한다"고 썼다. 그는 AI 분석 덕분에 수정 코드나 권고문을 작동하는 공격으로 바꾸는 비용이 싸졌다고 했다. 그래서 세부 정보가 나온 뒤 몇 시간, 빠르면 몇 분 안에 움직이는 공격자가 늘었다는 것이다. 인터넷에 노출된 시스템의 치명적 결함이라면 패치 기한을 날이 아니라 시간 단위로 잡으라는 권고도 덧붙였다. 오픈AI는 반대쪽 효과를 강조했다. 자사가 아는 범위에서는 AI가 공격자보다 먼저 결함을 찾아 방어 측에 준비할 시간을 줬다는 것이다. 이번 일은 두 말이 모두 맞다는 것을 보여 준다. AI는 방어자에게 결함을 먼저 알려 줬지만, 같은 결함을 다시 찾아 공격에 쓰기까지의 시간도 줄였다.

한국에서 남은 일

이제 위험은 수정판이 실제 서버에 닿는 속도에 달려 있다. 한국에서 그 속도가 가장 느릴 곳은 관리할 사람이 없는 작은 사이트다. 정부는 21일 한국인터넷진흥원(KISA)의 업데이트 권고를 시작으로, 22일 국가안보실 주재 민·관·군 긴급회의와 경보 상향까지 움직였다. 과학기술정보통신부는 업데이트가 어려운 운영자에게 외부 접속 차단이나 서비스 중단을 검토하라고 안내했다. 호스팅을 쓰는 소상공인에게는 업체가 업데이트를 적용했는지 확인하라고 했다. 호스팅 업체 카페24는 21일 밤 정식 패치 작업에 들어갔고, 가비아는 22일 새벽 패치하면서 지원이 끝난 버전에도 수정 코드나 완화 조치를 적용했다. 대기업 가운데 SK 계열사들은 인터넷에 노출된 자산부터 패치를 진행하고 있었고, 포스코그룹은 긴급대응반을 꾸렸다.

빈틈은 이런 대응 체계 바깥에 있다. 나루씨큐리티 대표 김혁준은 보안 공지는 받았어도 PHP가 어디 설치돼 있는지, 업데이트를 누가 맡는지 모르는 경우를 걱정했다. 유지보수 계약이 끝난 홈페이지나, 오래된 프로그램과의 호환성 때문에 PHP 업그레이드를 미뤄 온 곳이 여기에 해당한다. 보안기업 Mondoo의 최고보안책임자 패트릭 뮌히는 수정판이 배포판, 호스팅 업체, 소프트웨어 공급자를 거쳐 서버에 닿기까지 단계마다 시간이 걸린다고 지적했다. 그 단계들 역시 작은 팀과 자원봉사자에 기대는 경우가 많다고 했다.

홈페이지를 운영한다면 할 일은 분명하다. 쓰고 있는 PHP 버전을 확인하고 수정판 이상으로 올린다. 업데이트한 뒤에는 PHP를 돌리는 서비스를 다시 시작해야 실제로 반영된다. 8.1 이하라면 지원되는 버전으로 옮기거나 배포판·호스팅 업체가 제공하는 수정을 받는다. 호스팅을 쓴다면 업체에 적용 여부를 묻는다. 정부는 업데이트를 마쳤더라도 20일 이후 접속 기록과 악성 파일 설치 여부를 점검하라고 권고했다. 다만 AWS가 공격 시도를 처음 기록한 날은 17일이다. 거슬러 볼 기간은 그날부터 잡는 편이 안전하다.

그래서 무엇이 문제였나

PHP2Shell은 웹에 넓게 깔린 엔진의 결함이라 패치 말고는 답이 없는 심각한 사안이다. 하지만 지금까지 확인된 것은 공격 시도와 예방적 사이트 중단이고, 침해 피해는 확인되지 않았다. 체인가드의 6시간을 겨냥한 비판은 여러 주체의 약속을 한 업체가 혼자 깼다는 점에서는 맞다. 그러나 이번 위험의 크기를 설명하지는 못한다. 엠바고는 그보다 먼저 새고 있었고, 그 바탕에는 2024년에 본 결함을 인력과 의사결정의 한계로 고치지 못한 PHP의 사정이 있었다. AI가 같은 결함을 다시 찾아내는 데 드는 시간을 줄인 지금, 몇 시간 차이의 공개 순서보다 중요한 것은 결함을 안 뒤 고치기까지 걸리는 시간이다. PHP 재단의 요청대로라면 그 시간을 줄이는 몫은 재단 혼자가 아니라 PHP로 서비스를 돌리는 기업과 정부, 그리고 수정판을 서버까지 실어 나르는 호스팅 업체에도 있다.