오늘 정오를 기점으로 정부가 민간 분야 사이버위기 경보를 ‘관심’에서 ‘주의’로 올렸습니다. 경보 단계가 하나 올라갔다는 말이 얼핏 대수롭지 않게 들릴 수 있는데, 이유를 들여다보면 마냥 넘길 일이 아니에요. 서버에 로그인하지 않은 사람이, 비밀번호 한 글자 모르는 사람이, 인터넷 요청 하나만 잘 조작해서 서버에 명령을 내릴 수 있는 구멍이 PHP 자체에서 발견됐다는 겁니다.
PHP라는 이름이 낯설게 느껴지는 분도 계실 텐데, 우리가 매일 드나드는 쇼핑몰, 학원 홈페이지, 동네 병원 예약 페이지, 회사 게시판 중 상당수가 이 언어 위에서 돌아갑니다. 워드프레스로 만든 블로그와 그누보드로 만든 커뮤니티도 마찬가지고요.
뉴스 제목을 보면서 저는 두 가지가 동시에 궁금했습니다. 내 서버는 괜찮을까 하는 현실적인 걱정이 하나, 그리고 이런 구멍을 도대체 누가 어떻게 찾아냈을까, 혹시 요즘 말 많은 AI가 찾은 건 아닐까 하는 호기심이 또 하나였어요. 이 글에서는 두 질문 모두 최대한 솔직하게 정리해 보겠습니다.
22일 정오, 정부가 경보 단계를 올린 이유
사건의 흐름부터 짚어볼게요. PHP 개발팀은 21일(현지시간) 인증 없이 원격 코드 실행이 가능한 치명적인 취약점 2건을 고친 긴급 보안 업데이트를 배포했습니다. 모든 사용자에게 즉시 업데이트하라는 권고도 함께 나갔고요. 같은 날 한국인터넷진흥원도 보안 권고문을 올렸고, 과학기술정보통신부와 KISA는 22일 긴급 대응을 요청하면서 정오부터 ‘주의’ 경보를 발령했습니다.
여기서 눈여겨볼 건 경보를 올린 근거예요. 정부는 이미 대규모 침해가 벌어졌다고 확정한 게 아닙니다. 취약점이 악용될 가능성과 피해가 번질 위험에 앞서 대응하겠다는 취지예요. 다만 배경훈 부총리 겸 과기정통부 장관이 공격 코드까지 이미 공개됐다고 언급한 만큼, 시간이 우리 편이 아니라는 신호로는 충분합니다.
정부는 약 2만8000개 CISO 신고기업, 111개 주요정보통신기반시설, 1068개 ISMS 인증기업, 약 5900개 사이버위협정보 공유체계 회원사에 관련 정보를 긴급 전파했고, 웹호스팅사와 데이터센터 등 688곳에도 조치를 요청했습니다. 숫자가 이렇게 크다는 건 영향권이 그만큼 넓다고 보고 있다는 뜻이겠죠.
비밀번호 없이 서버가 뚫린다는 말의 진짜 의미
제목에 나온 “비밀번호 없이 뚫린다”는 표현이 과장처럼 들릴 수 있어서, 정확히 어떤 상황인지 풀어보겠습니다. 이번 취약점은 원격 코드 실행, 영어로는 RCE라고 부르는 유형이에요. 공격자가 특수하게 조작한 인터넷 요청을 취약한 서버로 보내면, 로그인 같은 인증 절차를 거치지 않고도 서버 안에서 자기가 원하는 코드를 돌릴 수 있게 되는 겁니다.
집에 비유하면 이렇습니다. 보통의 해킹은 현관 도어락 비밀번호를 알아내거나 열쇠를 훔치는 일에 가까워요. 그런데 이번 건은 도어락과 상관없이 벽 자체에 구멍이 나 있는 상황에 더 가깝습니다. 아무리 비밀번호를 복잡하게 바꿔놨어도 소용이 없는 거죠.
공격이 성공하면 그다음 수순도 뻔합니다. 웹셸이라는 원격 조종용 프로그램을 심어서 서버를 마음대로 만지고, 저장된 고객 정보를 빼가고, 홈페이지를 바꿔놓거나 먹통으로 만드는 일로 이어질 수 있어요. 쇼핑몰이라면 회원 정보와 주문 내역이, 병원이나 학원 홈페이지라면 예약자 연락처가 위험해지는 셈입니다.
두 취약점을 쉬운 말로 풀어보면
이번에 공개된 취약점은 CVE-2026-109618과 CVE-2026-109619, 두 건입니다. 둘 다 공통 취약점 평가체계 4.0 기준 9.2점으로, 최고 위험 등급인 치명적 단계에 들어가요.
첫 번째는 메모리가 부족한 상황을 처리하다가 생기는 문제입니다. PHP는 요청을 처리하다 메모리 사용 한도에 닿으면 작업을 멈추는데, 그 정리 과정에서 내부 데이터가 제대로 초기화되지 않은 채로 마무리 절차가 돌아갈 수 있다고 해요. 이삿짐을 싸다 말고 급하게 집을 비우는데, 바닥에 물건이 반쯤 흩어져 있는 걸 모르고 문을 닫아버리는 상황을 떠올리시면 됩니다. 공격자는 이 어수선한 틈을 파고들어 코드를 실행하려 시도할 수 있어요.
두 번째는 이전 요청에서 쓰던 내부 상태 정보가 깨끗이 지워지지 않고 남아서 생기는 문제입니다. 메모리를 풀어준 뒤에도 관련 상태가 살아 있으면, 다음 요청이 엉뚱한 메모리 상태를 그대로 물려받을 수 있거든요. 식당에서 앞 손님이 쓰던 접시를 안 치우고 다음 손님 상을 차리는 것과 비슷해요. 이걸 이용한 원격 코드 실행 가능성이 확인됐다고 합니다.
개발팀이 특히 위험한 구성으로 꼽은 건 아파치의 mod_php 환경입니다. 웹 애플리케이션 코드가 실행되기도 전 단계에서, 인증되지 않은 요청만으로 공격이 성립한 사례가 확인됐다고 해요. PHP-FPM, php-cgi, 프랑켄PHP, 라이트스피드 같은 다른 실행 환경도 영향을 받을 수 있다고 하니, “나는 mod_php 안 쓰니까 괜찮겠지” 하고 넘어가는 건 위험합니다.
워드프레스와 그누보드를 최신으로 올렸는데도 불안한 이유
여기서 가장 많이 오해하실 만한 지점이 하나 있습니다. 워드프레스나 그누보드를 최신 버전으로 잘 관리하고 계신 분들이 “나는 업데이트 꼬박꼬박 했는데?” 하고 안심하기 쉬워요.
이번 취약점은 워드프레스나 그누보드 같은 제작 도구의 결함이 아닙니다. 그 도구들을 실행해 주는 PHP 자체의 문제예요. 그러니까 위에 올라앉은 프로그램이 아무리 최신이어도, 그 밑바닥의 PHP 실행 환경이 취약한 버전이면 위험이 그대로 남습니다. 건물 외벽 페인트를 새로 칠했는데 기초 공사가 부실한 경우와 같죠.
반대로 PHP를 쓴다고 해서 전부 이미 뚫렸다거나 똑같은 조건으로 공격이 성공한다는 뜻도 아닙니다. 실제 위험은 PHP 버전, 서버 구성, 외부 노출 여부에 따라 달라져요. 괜히 겁부터 먹을 필요는 없지만, 확인은 반드시 해보셔야 합니다.
더 신경 쓰이는 건 관리 대상에서 빠져 있는 오래된 시스템들이에요. 회사 공식 홈페이지는 깔끔하게 관리하면서, 몇 년 전 행사용으로 만든 사이트나 외주 개발사가 넘겨준 관리자 페이지, 테스트 서버가 구석에서 구버전 PHP로 돌고 있는 경우를 저도 종종 봤습니다. 담당자가 퇴사했는데 서버만 남아 있는 곳도 있고요. 공격자는 정문이 아니라 이런 잊힌 뒷문을 노립니다.
지금 당장 확인해야 할 것들
정부가 안내한 보안 업데이트 적용 기준은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상입니다. 내가 쓰는 버전 계열에 맞춰 이 숫자 이상으로 올라가 있어야 해요. 서버에 접속할 수 있다면 터미널에서 php -v 명령으로 버전을 바로 확인할 수 있습니다.
문제는 PHP 8.1 이하입니다. 이쪽은 이미 공식 보안 지원이 끝나서 이번 취약점에 대한 업데이트가 제공되지 않아요. 패치를 적용하는 방식으로는 해결이 안 되고, 지원되는 상위 버전으로 아예 옮겨가야 합니다. 참고로 8.2도 2026년 12월 31일에 공식 지원이 끝나기 때문에, 이번 기회에 상위 버전 이전 계획을 같이 세워두시는 게 좋겠어요.
패치를 끝냈다고 일이 끝나는 것도 아닙니다. 업데이트 후에는 PHP 실행 서비스와 웹서비스를 다시 시작해서, 실제로 돌고 있는 프로세스에 수정 사항이 반영됐는지 확인해야 해요. 파일만 새 버전으로 바뀌어 있고 메모리에는 옛 프로세스가 그대로 떠 있는 경우가 의외로 흔하거든요.
그리고 한 가지 더, 이미 공격을 받았을 가능성도 열어두고 봐야 합니다. 평소와 다른 접속 기록이 없는지, 낯선 파일이 생기지 않았는지, 웹셸이 심어진 흔적이 없는지 살펴보세요. 패치는 앞으로의 문을 닫아주는 일이지, 이미 들어온 사람을 내보내 주는 일이 아니니까요.
호스팅 업체를 통해 사이트를 운영하는 소상공인이라면 직접 서버를 만질 일은 없을 겁니다. 이럴 때는 업체에 PHP 보안 업데이트를 적용했는지 문의하는 게 가장 빠릅니다. 즉시 업데이트가 어려운 시스템은 외부 접속을 막거나 서비스를 잠시 내리는 것까지 검토하라는 게 정부 입장이에요. 웹방화벽 규칙이나 접근 제한은 위험을 줄여주는 임시방편일 뿐이고, 근본 해결책은 어디까지나 보안 패치라는 점도 기억해 두세요.
그래서 이 취약점, AI가 찾았을까
이제 이 글을 클릭하신 진짜 이유일 질문으로 넘어가 보겠습니다. 이번 취약점을 찾아낸 게 AI였을까요.
결론부터 말씀드리면 지금 공개된 정보로는 알 수 없습니다. 보도된 내용에도, PHP 공식 안내를 다룬 내용에도 누가 어떤 방식으로 이 구멍을 처음 발견했는지는 나와 있지 않아요. 제가 따로 찾아봤을 때도 발견자를 확인할 수 있는 자료는 나오지 않았습니다. 그러니 “AI가 찾았다”는 말도, “사람이 찾았다”는 말도 지금은 근거 없는 추측이 되는 셈이에요.
다만 이런 의심이 나오는 배경은 충분히 이해가 갑니다. 최근 보안 업계에서는 AI의 도움으로 취약점을 대량으로 찾아냈다는 소식이 심심치 않게 들려요. 구글이 크롬 보안 버그를 AI로 대거 찾아 고쳤다는 발표도 있었고, 대규모 코드 점검을 AI로 빠르고 싸게 해냈다는 사례도 나오고 있습니다. 코드를 읽고 패턴을 찾는 일은 AI가 꽤 잘하는 영역이니까요. 이번 PHP처럼 메모리 처리 과정의 미묘한 허점은 사람이 놓치기 쉽고 기계가 끈질기게 파고들기 좋은 유형이기도 하고요. 그러니 AI가 한 역할을 했을 가능성 자체를 배제할 이유는 없습니다.
하지만 발견 방법이 무엇이든 우리가 해야 할 일은 달라지지 않아요. 구멍이 있고, 공격 코드가 공개됐고, 고치는 방법이 나왔다는 사실이 핵심입니다. 누가 찾았는지는 호기심의 영역이지만, 내 서버를 고치는 건 의무의 영역이에요.
AI는 이 사건에서 방패이자 창입니다
정작 이번 기사에서 AI가 등장하는 대목은 발견이 아니라 대응 쪽입니다. 정부는 취약점을 사람이 수동으로 점검하고 며칠 뒤에 패치하는 방식으로는 공격을 막기 어렵다고 강조했어요. 인터넷에 노출된 자산을 즉시 차단하고, 웹방화벽 규칙을 선제적으로 적용하는 자동화된 대응 체계가 필요하다는 얘기입니다.
방어자 입장에서 AI가 쓸모 있는 지점은 분명해요. 서버에 쌓이는 방대한 접속 기록과 네트워크 트래픽에서 사람 눈으로는 놓칠 비정상 패턴을 걸러내고, 취약점 악용이 의심되는 움직임을 일찍 알아채는 일에 도움이 됩니다. 수십 대, 수백 대 서버의 로그를 사람이 일일이 읽는 건 현실적으로 불가능하니까요.
문제는 같은 도구가 반대편에도 열려 있다는 점입니다. 기사에서도 공격자가 생성형 AI로 공격 코드를 분석하고 변형하고 준비 과정을 효율화할 가능성을 짚었어요. 공개된 개념증명 코드를 AI가 받아서 손쉽게 변형하고 자동화하면, 예전에는 숙련된 해커만 하던 대규모 공격 시도가 훨씬 낮은 문턱에서 가능해질 수 있습니다.
그래서 이번 사태에서 “AI 무섭다”는 감정은 반쯤 맞고 반쯤은 방향이 다릅니다. AI가 구멍을 만든 건 아니에요. 구멍은 오래된 코드 어딘가에 원래 있었습니다. 달라진 건 그 구멍을 찾고, 악용하고, 막는 속도예요. 공격이 빨라진 만큼 방어도 빨라져야 하는 시대가 됐다는 게 더 정확한 표현일 겁니다.
속도가 보안 실력이 되는 시대
저는 서버를 직접 굴려본 입장에서 이번 권고에서 가장 와닿은 문장이 “수일 뒤 패치하는 방식으로는 부족하다”였습니다. 예전에는 보안 업데이트가 나오면 주말에 시간 내서 천천히 올리는 게 흔했어요. 그런데 공격 코드가 취약점과 거의 동시에 풀리는 상황에서는 그 며칠이 곧 공격자에게 주어진 시간이 됩니다.
그래서 앞으로 기업의 보안 역량은 얼마나 튼튼한 장비를 샀느냐보다, 취약점 공개 후 영향받는 시스템을 얼마나 빨리 찾아내느냐로 갈릴 가능성이 커요. 내 조직이 인터넷에 어떤 서버를 열어놨는지 항상 파악하고 있고, 취약점이 나오면 즉시 해당 시스템을 식별하고, 자동으로 패치를 배포하면서 침해 징후까지 함께 탐지하는 체계. 말은 거창하지만 결국 자산 목록을 정리해 두는 기본기에서 출발합니다.
개인 블로거나 소상공인이라고 예외는 아니에요. 규모가 작을수록 서버 관리를 호스팅 업체에 맡기는 경우가 많으니, 최소한 “우리 업체는 이번 PHP 패치를 언제 적용하나요”라고 물어볼 수 있어야 합니다. 질문 하나가 가장 저렴한 보안 점검이에요.
마무리, 오늘 해야 할 일과 기억할 점
정리하겠습니다. PHP 개발팀이 21일 치명적인 원격 코드 실행 취약점 2건을 고친 긴급 업데이트를 배포했고, 정부는 22일 정오부터 민간 분야 사이버위기 경보를 ‘주의’로 올렸습니다. 두 취약점은 CVSS 4.0 기준 9.2점의 최고 위험 등급이고, 인증 없이 조작된 요청만으로 서버 명령 실행이 시도될 수 있어요. 워드프레스나 그누보드를 최신으로 유지하고 있어도 밑바닥의 PHP가 취약하면 위험이 남습니다.
확인 기준은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상이고, 8.1 이하는 패치가 없으니 상위 버전으로 옮겨야 합니다. 업데이트 후에는 서비스를 재시작하고 접속 기록과 웹셸 흔적까지 확인하는 것까지가 한 세트예요. 아직 대규모 침해가 확인된 건 아니지만, 공격 코드가 공개된 만큼 서두를수록 좋습니다.
그리고 AI가 찾았느냐는 질문에는 이렇게 답하고 싶어요. 지금은 확인된 바가 없고, 확인되지 않은 걸 사실처럼 말하지 않는 게 맞습니다. 대신 분명한 건 AI가 이 싸움의 속도를 바꾸고 있다는 점이에요. 방어하는 쪽도 공격하는 쪽도 같은 도구를 쥐게 된 지금, 가장 확실한 보험은 거창한 기술이 아니라 내 서버의 PHP 버전을 오늘 한 번 확인해 보는 일입니다.