일본의 총리까지 긴급 대응을 촉구한, 인증 없이도 원격 코드를 실행할 수 있게 하는 두 가지 취약점. 세계적으로 발생한 사례, 기업이 직면한 리스크, 그리고 AI 시대에 맞는 보안 대책을 고찰합니다.
2026 년 10 월 21 일, 일본 국내에서 많은 웹 서비스가 갑자기 긴급 점검에 들어갔습니다.
우리 일본 총리 고시 사네의 웹사이트 (https://www.sanae.gr.jp/) 도 긴급 유지보수로 인해 완전히 마비될 정도로입니다.
게임, 온라인 쇼핑, 보육 시설용 서비스, 동영상配信 등 평소 이용하던 다양한 서비스가 일시적으로 중단되었습니다.
해외에서도 유럽 각국 정부 기관, 병원, 공공 서비스 등이 웹사이트를 중단하는 움직임이 확산되고 있습니다.
그 원인은 PHP 라는 프로그래밍 언어에서 발견된 두 가지 중대한 취약점 때문입니다.
이 취약성은 'php2shell'이라고 불립니다.
일본에서는 21일 21 시 55 분경 고시 사오미 총리가 X(트위터)에서 긴급 주의보를 발령하고 수정 프로그램의 적용을 촉구했습니다.
모든 분께, tonight 대응해 주셔야 하는 매우 긴급한 요청입니다. 많은 웹사이트에서 사용되고 있는 PHP 에 대해 PHP 보안 팀이 중대한 2 건의 취약점에 대한 경보를 발령했습니다. …— 타카이치 사나에 (@takaichi_sanae) 2026 년 10 월 21 일
총리가 PHP라는 구체적인 기술명과 수정 프로그램의 공개 시점을 명시하고, 대응이 어렵다면 웹사이트 일시 정지까지 고려할 수 있다고 촉구한 점은 주목할 만한 일이었다.
그렇다면, 정확히 어떤 일이 일어났을까요.
이번에는 보안에 익숙하지 않은 분도 이해하실 수 있도록 이번 문제의 작동 원리와 위험성을 정리해 드립니다.
그리고 왜 전 세계 기업과 정부 기관이 긴급 대응에 몰두해야 했는지, 그리고 이번 사건을 통해 향후 보안에 대해 무엇을 고려해야 하는지 살펴보겠습니다.
※본 기사는 2026 년 10 월 22 일 아침 현재 확인된 정보를 바탕으로 작성되었습니다. 향후 공격 상황이나 각 서비스의 대응 상황이 변경될 수 있습니다.
왜 전 세계적으로 웹사이트가 멈췄는지
이번 상황을 이해하기 위해 먼저 짚어두어야 할 점이 있습니다.
많은 웹사이트가 중단된 것은 공격을 받아 작동하지 않았기 때문일 수도 있습니다.
오히려 공격을 받기 전에 서비스를 중단하는 예방적 판단이 확산된 것이 큰 특징입니다.
일본에서는 예를 들어 다음과 같은 서비스를 통해 긴급 유지보수가 이루어졌습니다.
- 우마가ール Pretty Derby, 그란 블루 판타지 등 게임
- 픽시브, 니코니코, DMM 등의 서비스
- 네트샵 제작 서비스 BASE
- 유치원 및 교육 시설용 ICT 서비스 '코도몬'
- 사쿠라 인터넷 등 일부 서비스
그 중에서도 코도몬은 보호자용 앱 포함 모든 서비스를 중단한다고 발표했습니다.
공식 공지에서는 이용자의 정보와 서비스 안전을 보호하기 위한 예방 조치임을 밝히며, 이번 취약점으로 인한 불법 접근이나 정보 유출은 확인되지 않았다고 설명했습니다.
우마녀 역시 PHP 취약점 대응을 위해 21 일 23 시경부터 유지보수를 실시한다는 발표를 했습니다.
이러한 움직임은 해외에서도 확산되었습니다.
루터스는 독일, 프랑스, 벨기에, 네덜란드, 핀란드, 체코 등에서 정부 관련 웹사이트와 공공 서비스가 예방적으로 중단되었다는 보도를 했습니다.
유럽연합의 사이버보안 기관인 ENISA 또한 유럽위원회, CERT-EU, Europol 등과 공동으로 조직에 즉각적인 대응을 촉구했습니다.
이러한 움직임들을 보면 전 세계적으로 대규모 사이버 공격이 성공하여 수많은 사이트가 마비된 것처럼 느껴질 수 있습니다.
하지만 여기서는 구별이 필요합니다.
"공격받을 위험이 있다"는 것과 "실제로 공격되어 피해가 발생했다"는 것은 별개의 문제입니다.
이번에는 전 세계적으로 두드러진 것은 심각한 취약점이 드러나 피해 방지를 위해 서비스를 일시 중단한 대응이었습니다.
그렇게까지 경계해야 했던 이유는 무엇이었을까요.
PHP 는 무엇인가? 왜 이 언어가 수많은 웹사이트에 영향을 미쳤는가
PHP 는 웹사이트나 웹 서비스의 백엔드에서 처리를 수행하는 프로그래밍 언어입니다.
예를 들어, 우리가 온라인 쇼핑몰에서 상품을 구매할 때는 화면에 상품 정보를 표시하는 것뿐만 아니라 재고를 확인하거나 주문 정보를 입력하고 회원 정보를 조회해야 합니다.
웹 서버 측에서 이러한 처리를 수행하기 위한 기술 중 하나가 PHP 입니다.
특히 유명하고 잘 알려진 것은 워드프레스입니다.
워드프레스는 블로그나 기업 사이트 등 널리 사용되며, 그 실행 기반에는 PHP 를 사용합니다.
클라우드플레어에 따르면 PHP 는 전 세계 웹사이트 중 약 70% 에서 사용되고 있어 매우 널리 퍼진 기술입니다. 다만 이 비율은 조사 대상이나 서버 측 언어를 판별할 수 있는 사이트 등 집계 조건에 따라 달라질 수 있습니다.
중요한 점은 PHP 가 특정 서비스만을 위한 기술이 아니라는 것입니다.
기업의 홈페이지부터 대규모 웹 서비스까지 전 세계의 시스템에서 활용되고 있습니다.
이번 문제는 WordPress 와 같은 애플리케이션 고유의 결함이 아닙니다.
PHP 프로그램을 실행하는 방식 자체에 심각한 문제가 발견되었습니다.
비유하자면, 집의 문이나 창문의 열쇠가 아니라 집을 지탱하는 기초 자체에 결함이 발견된 상태입니다.
각 방의 잠금 장치를 확인해도 기초 측면의 문제는 해결되지 않습니다.
이에 따라 WordPress 의 기본 프로그램이나 플러그인을 최신 버전으로 업데이트하더라도 이번 취약점을 해결할 수 없습니다.
이번 취약점으로 인해 어떤 일이 벌어질 수 있는가
이번에 공개된 취약점은 다음 두 가지입니다.
- CVE-2026-109618
- CVE-2026-109619
모든 취약점은 CVSS v4.0 평가 기준에 따라 점수가 10 점 만점 중 9.2 점으로, 심각도는 Critical로 분류됩니다.
특히 위험한 것은 조건이 충족되면 공격자가 로그인하지 않았더라도 외부에서 서버상에서 악성 프로그램을 실행할 수 있다는 가능성입니다.
이것은 RCE(리모트 코드 실행)라고 불립니다.
일반적으로 웹사이트에 접속한 이용자는 해당 사이트에서 제공하는 기능만 사용할 수 있습니다.
그러나 RCE 가 발생하면 공격자가 웹사이트를 통해 서버 측에 의도하지 않은 처리를 실행시킬 수 있습니다.
그 결과, 다음과 같은 피해가 발생할 수 있습니다.
개인정보 및 기밀정보 유출
서버 내부에 저장된 파일이나 데이터베이스 연결 정보 등이 추출될 수 있으며, 이를 이용해 회원 정보나 고객 정보가 유출될 수도 있습니다.
웹사이트의 변조
웹 페이지의 내용이 변경되거나, 가짜 로그인 화면이 노출되거나 사기 사이트로 유도될 수 있습니다.
서버를 다른 공격에 악용당함
不正なプログラムを設置され、他のシステムへの攻撃や迷惑メールの送信などに悪用される可能性があります。
서비스 정지 및 랜섬웨어 피해
서버가 정상적으로 작동하지 않거나 침해가 확대될 경우 파일 암호화 등 피해로 이어질 수 있습니다.
하지만 이 모든 일이 반드시 발생하는 것은 아닙니다.
실제 피해 규모는 PHP 실행 권한, 서버 구성, 저장된 정보 및 기타 방어 조치에 따라 달라집니다.
RCE 가 성립되었다고 해서 반드시 OS 의 관리자 권한까지 즉시 획득되는 것은 아닙니다.
그럼에도 불구하고 인터넷에 공개된 웹 서버는 인증 없이 들어오는 요청으로부터 악성 코드를 실행될 수 있어 매우 심각한 문제입니다.
기술적으로 문제가 된 것은 무엇이었을까요
이후에는 조금 기술적인 내용으로 넘어갑니다.
이번 두 가지 취약점은 공통된 특징을 보입니다.
PHP 가 메모리나 에러를 처리할 때 내부 상태를 안전하게 다루지 못할 수 있다는 문제입니다.
CVE-2026-109618: 메모 부족 상황에서의 처리에 문제가 있습니다.
PHP 은 프로그램을 실행할 때 필요한 데이터를 메모리에 보관합니다.
그러나 처리 중 메모리 사용량이 상한에 도달하여 비정상 종료되는 경우, 내부 데이터 초기화가 완전히 수행되지 않은 채 후속 정리 처리로 넘어가는 경우가 있습니다.
그때, 비정상적인 상태의 데이터를 정상적인 것으로 처리하여 메모리를 파괴할 수 있습니다.
전문적으로는 메모리 파괴를 유발하는 OOM(Out Of Memory) 관련 문제입니다.
특히 Apache 의 mod_php 구성에서는 인증이 필요한 요청이 아닌 경우에도 애플리케이션 코드가 실행되기 전에 공격이 성공할 수 있다는 것이 입증되었습니다.
또한 PHP-FPM 에서도 애플리케이션 측의 처리 경로를 통한 RCE 가 확인되었습니다.
CVE-2026-109619: 해제된 메모리를 재사용하는 취약점
이러한 문제는 치명적 오류 등으로 인해 처리가 중단되었을 때, 이미 해제된 메모리에 대한 정보가 남아있는 문제를 의미합니다.
그 후, 동일한 워커 프로세스가 다른 요청을 처리하면 이전 요청에서 사용된 잘못된 참조를 잘못 활용할 수 있습니다.
이러한 문제를 Use-After-Free라고 합니다.
이 역시 Apache 의 mod_php 환경에서 실제 애플리케이션을 대상으로 원격 코드 실행이 입증되었습니다.
왜 애플리케이션 측면만으로는 방어할 수 없는지
이 부분이 이번 문제의 핵심입니다.
SQL 인젝션 등의 경우, 애플리케이션 측에서 데이터를 적절히 처리함으로써 공격을 예방할 수 있습니다.
하지만 이번에는 PHP 실행 엔진이 내부적으로 메모리나 에러를 처리할 때 발생하는 문제입니다.
개발자가 인증이나 입력 검증을 올바르게 구현하더라도, 그 자체로는 방어할 수 없는 공격 경로가 존재합니다.
특히 mod_php 를 통해 확인된 경우처럼 애플리케이션 코드가 실행되기 전에 문제가 발생하면 애플리케이션 측의 방어 조치로는 대응할 수 없습니다.
하지만 모든 PHP 환경에서 공격이 동일하게 성공하는 것은 아닙니다.
웹 서버의 구성, PHP 실행 방식, 활용 기능 등에 따라 발생 조건과 위험도가 달라집니다.
그렇기에 PHP 실행 환경을 직접 업데이트해야 합니다.
2026 년 10 월 21 일, 어떤 일이 벌어졌는지
이번 일을 시간 순서대로 정리해 보겠습니다.
2024 년: 문제의 징후가 드러남
PHP Foundation 은 주권 기술 기관의 자금 지원을 받아 Quarkslab 의 외부 보안 감사 를 실시했습니다.
그 감사 과정에서 보고된 다른 문제를 수정하는 과정에서 PHP 의 핵심 개발자가 이번 OOM 문제와 관련된 징후를 발견했습니다.
그러나 당시에는 실제로 공격이 성공할 수 있는 구체적인 경로가 명확하지 않았습니다.
수정 방법에도 호환성이나 성능 측면에서 해결이 어려운 문제가 있어 대응이 진전되지 않는 상황이 이어지고 있습니다.
2026 년 8 월: 원격 코드 실행의 위험성이 명확히 드러남
캘리포니아의 연구자들과 OpenAI, Wiz 등이 동일한 근본 원인과 관련된 문제나 공격 경로를 보고했습니다.
이를 통해 기존에 인식되어 왔던 문제들이 실제로 심각한 RCE 로 이어질 수 있음을 명확히 했습니다.
2026 년 10 월 20 일: 취약성 관련 정보가 유출됨
초기에는 수정판이 10 월 22 일에 공개될 예정이었습니다.
그러나 CVE 번호 등이 먼저 인터넷상에 퍼져 나갔고, 일부 공격 증명에 관한 정보도 유출되었습니다.
PHP 개발 팀은 일정을 변경하여 수정판을 하루 일찍 공개했습니다.
2026 년 10 월 21 일: 전 세계에 긴급 대응이 시작됩니다.
일본에서는 IPA 와 국가 사이버 통제실 등이 주의 경보를 발령했고, 기업과 서비스 제공업체들은 긴급 유지보수를 실시했습니다.
동일 날 밤 21 시 55 분경에는 고시 총리도 X 에서 대응을 촉구했습니다.
개정판 공개 예정 시간은 일본 시간 23 시였습니다.
또한 ENISA 의 기록에 따르면 실제 공개는 UTC 21 일 13 시 40 분, 일본 시간 22 시 40 분이었습니다.
그리고 PHP 8.2~8.5 각 버전군에 대해 수정 버전이 공개되었습니다.
이와 같이 이번 긴급 대응의 배경에는 취약점의 중대성뿐만 아니라, 공개 전 정보 유출과 수정판을 안전하게 배포하기 위한 시간적 제약도 있었습니다.
현재 실제 공격이 발생하고 있는가
2026 년 10 월 22 일 아침, 이번 취약점을 표적으로 한 공격 시도는 확인되었습니다.
클라우드플레어는 PHP Foundation 등과의 협력으로 웹 애플리케이션 방화벽(WAF) 방어 규칙을 배포했으며, 실제 공격을 시도하는 통신을 관측했다고 발표했습니다.
또한 공격자가 방어를 우회하기 위해 전송하는 데이터를 변조하는 사례도 보고되었습니다.
이것은 단순히 이론적 위험성이 지적된 단계에 머무는 것을 넘어선다는 뜻입니다.
또한 다음 세 가지를 혼동해서는 안 됩니다.
- 공격이 기술적으로 가능하다는 사실
- 공격 시도 통신이 관측되고 있다는 사실이 확인되었다.
- 공격이 성공하여 실제로 정보 유출 등의 피해가 발생한 경우
현재 1 과 2 에 대해서는 구체적인 근거가 있습니다.
그러나 이 기사가 작성된 시점에서 세계적으로 수많은 서버가 침해되었다고 단정할 수 있는 정보는 확인되지 않았습니다.
이번에 전 세계적으로 발생한 서비스 중단 사례의 대부분은 예방 조치였습니다.
다만, 향후 실제 침해 피해가 발생하거나 보고될 가능성은 있습니다.
수정판이 공개됨에 따라 공격자가 수정 전후의 프로그램을 비교하여 공격 방법을 연구할 수 있을 것입니다.
취약성이 공개되어 위험이 사라지는 것은 아니며, 수정 버전을 공개해도 업데이트되지 않은 시스템에는 위험이 계속 남습니다.
기업이나 웹사이트 운영자가 무엇을 해야 하는가
이후에는 실제 대응 방안을 정리합니다.
가장 중요한 것은 우리가 관리하는 시스템에 PHP 가 사용되고 있는지, 그리고 이번 수정이 적용되어 있는지 확인하는 것입니다.
PHP 버전과 수정 내역을 확인합니다.
2026 년 10 월 21 일에 공개된 수정 버전은 다음과 같습니다.
PHP 시리즈 수정판: PHP 8.58.5.12, PHP 8.48.4.27, PHP 8.38.3.36, PHP 8.28.2.35
PHP 8.1 이전에는 PHP 프로젝트의 일반 지원이 종료되었습니다.
그러나 이번 사건의 중요성으로 인해 PHP 개발 팀은 예외적으로 PHP 7.4, 8.0, 8.1 에 대한 최소한의 수정 소스도 제공했습니다.
Linux 배포판이나 유료 LTS 서비스를 제공하는 업체가 구버전에도 수정 내용을 반영한 '백포트'를 제공하는 경우도 있습니다.
따라서 버전 번호만으로 수정 여부를 판단할 수 없는 환경도 존재합니다.
사용 중인 운영체제와 호스팅 제공업체의 보안 정보도 확인해야 합니다.
또한 PHP 8.2 는 2026 년 12 월 31 일 공식 보안 지원이 종료될 예정입니다. 이번 대응과 함께 향후 버전 업데이트도 고려해 보아야 할 것입니다.
② WordPress 업데이트만으로는 안심할 수 없다
WordPress 를 사용 중이라면, WordPress 자체나 플러그인 업데이트만으로는 이번 문제를 해결할 수 없습니다.
WordPress 공식도 이번 취약점이 WordPress 고유의 문제라기보다 PHP 실행 환경의 업데이트가 필요하다고 설명했습니다.
WordPress 관리 화면에서는 일반적으로 [도구] → [사이트 헬스] → [정보] → [서버]로 이동하여 PHP 버전을 확인할 수 있습니다.
WordPress 공식에 대한 주의사항
다만, 렌탈 서버 등의 경우 사용자가 PHP 본체를 직접 업데이트할 수 없는 경우도 있습니다.
이 경우 호스팅 제공자가 이번 수정을 적용하고 있는지 확인하세요.
③ 즉시 업데이트가 불가능한 경우, 게시 중단도 선택 사항으로 고려하세요.
PHP 공식은 이번 취약점에 대해 업데이트를 제외하고는 완전한 대응책이 없다고 밝혔습니다.
일시적인 대응책으로는 특정 설정 변경이나 요청 제한 안내도 제공되지만, 그것만으로는 안전해지지 않습니다.
클라우드플레어와 같은 WAF 도 공격 방지를 위한 추가 방어 수단으로 활용됩니다.
하지만 WAF 를 도입한다고 해서 PHP 본체에 존재하는 취약점이 수정되는 것은 아닙니다.
업데이트가 불가능하거나 공격 위험을 충분히 낮출 수 없는 경우에는 웹사이트 일시 정지나 외부 접근 제한을 고려해야 합니다.
④ 수정 후에도 공격되지 않았는지 확인합니다.
또 하나 잊지 말아야 할 점이 있습니다.
패치를 적용하더라도 이미 침해가 발생해 있다면 그 피해까지 자동으로 해결되지 않습니다.
수정판 업데이트와 침해 여부 확인은 별개의 작업입니다.
따라서 위험도에 따라 액세스 로그, 오류 로그, 의심스러운 파일 생성, 프로세스의 비정상 종료, 외부로 의심스러운 통신 등을 확인해야 합니다.
침해가 의심되는 경우라면, 서비스를 재시작하는 것만으로는 부족하며, 증거를 보존하고 영향 범위를 조사하는 것이 중요합니다.
⑤ PHP 를 사용하지 않는다고 생각하는 기업도 확인이 필요한 경우가 있습니다.
회사에서 개발한 시스템이 Java 나 Node.js 로 동작하므로 이번 문제는 무관하다고 생각할 수 있습니다.
사실상 PHP 를 사용하지 않는 시스템은 이번 취약점의 직접적인 대상이 될 수 없습니다.
하지만 전체 시스템을 살펴보면 어떨까요.
메인 시스템에서 PHP 를 사용하지 않더라도, 관리 화면, 기존 내부 도구, 외부 제품에 통합된 웹 기능 등에서 PHP 가 사용되고 있을 수 있습니다.
이번에 ENISA 는 사용자가 PHP 를 사용한다고 인식하지 못하는 제품에도 영향을 미칠 수 있다는 점을 경고했습니다.
중요한 것은 메인 애플리케이션뿐만 아니라 주변 시스템이나 외부 제품까지 어떤 소프트웨어가 실행되고 있는지 파악하는 것입니다.
이번 취약성은 2024 년부터 문제의 징후가 이미 인지되었음을 의미합니다.
이후부터는 이번 사건에서 제가 특히 주목한 부분입니다.
PHP Foundation 은 이번 취약점 발견과 수정에 이르는 과정을 상세히 설명하고 있습니다.
이 문서에서는 OOM 문제의 징후가 2024 년에 이미 인식되었음에도 수정 작업이 장기간 미비되었음을 밝히고 있습니다.
왜 바로 수정할 수 없었을까요.
그 이유는 PHP 가 매우 널리 쓰이는 소프트웨어이기 때문입니다.
PHP 내부 구조를 변경하면 기존 애플리케이션과의 호환성이 깨지거나 성능이 저하되며, 다양한 확장 기능에 영향을 줄 수 있습니다.
수정하려는 의도였지만, 오히려 다른 문제를 야기할 위험이 있습니다.
또한 개발 팀의 의사결정 구조와 대응 가능한 인력 및 자원의 부족도 영향을 미쳤다고 설명되었습니다.
PHP Foundation 은 이 수정 지연이 조직적 문제였음을 인정하고 대응 프로세스 개선을 추진하고 있습니다.
이 부분에서 알 수 있는 것은 심각한 취약점이 발견되어도 이를 안전하게 수정하고 전 세계 사용자에게 배포하는 것은 쉽지 않다는 것입니다.
소프트웨어의 보안성은 코드 품질만으로 결정되는 것이 아닙니다.
이러한 개발 체계, 자금, 검증 환경, 의사결정 메커니즘 등도 그 유지에 기여하고 있습니다.
무료로 사용하는 오픈소스 소프트웨어라도 그 안전성을 보장하려면 많은 사람과 시간이 필요합니다.
AI 를 통해 취약점 발견은 어떻게 변할까
이번에는 AI 가 지닌 또 다른 중요한 의미가 있습니다.
PHP 취약성 조사는 Calif, OpenAI, Wiz 등의 연구자와 기업이 참여했습니다.
칼리프는 오픈AI 의 GPT-5.6 솔을 활용한 조사에서 중대한 문제를 발견했습니다.
또한 PHP Foundation 은 Anthropic 의 Claude Mythos 를 활용한 분석이나, OpenAI 의 Daybreak Red 를 통한 보고서 및 공격 시뮬레이션 검증 등에도 참여해 왔다고 설명했습니다.
OpenAI 또한 이번 취약점 대응에 관한 공식 기사에서, AI 가 널리 활용되는 소프트웨어의 심각한 결함을 발견할 수 있게 되었으며, 동일한 능력이 공격자에도 악용될 수 있다는 점을 지적했습니다.
OpenAI「플래닛 패치」
이번 문제의 핵심은 이를"AI 가 위험한 취약점을 만들었다"고 규정하지 않는다는 점입니다.
문제의 근본 원인은 PHP 내부에 이미 존재해 있었습니다.
AI 는 해당 문제를 조사하고 실제 공격으로 이어질 가능성을 규명하기 위한 수단 중 하나로 활용되었습니다.
이것은 방어 측에게 큰 진보입니다.
이러한 이유로 지금까지 발견하기 어려웠던 문제를 더 초기 단계에서 찾아낼 수 있는 가능성이 있기 때문입니다.
반면, 공격하는 측도 AI 를 동일하게 활용할 수 있습니다.
취약성 조사, 공개된 수정 사항 분석, 공격 방법 검토 등이 기존보다 단축된 시간 내에 진행될 수 있습니다.
물론, AI 가 등장했더라도 모든 사람이 고도의 공격을 쉽게 수행할 수 있게 된 것은 아닙니다.
이러한 메모리 파괴 문제를 실제 원격 코드 실행 (RCE) 으로 연결하려면 고급 기술과 특정 조건이 필요합니다.
그러나 AI 를 통해 조사와 검증이 지원될 수 있는 범위가 확대되는 것은 간과할 수 없는 변화라고 생각합니다.
또한 유사한 보안 리스크가 재발할 수 있는가
저는 이번 일을 일시적인 PHP 문제라고 끝내야 한다고 생각하지 않습니다.
이는 향후 유사한 문제가 다른 소프트웨어에서도 발견될 수 있기 때문입니다.
실제로는 같은 날인 10 월 21 일에 Node.js 와 Java 의 취약점이 공개되었습니다.
과거에도 이러한 취약성에 대해 발표와 대응책이 마련되었으나, AI 시대에는 특히 다음 4 가지 변화에 주목하고 있습니다.
장기간 사용되어 온 소프트웨어에서 중대한 문제가 발견되었습니다.
이번 PHP 와 같이 오랫동안 사용되어 온 소프트웨어라도 알려지지 않은 취약점이 존재할 수 있습니다.
과거에는 공격하기 어렵다고 여겨졌던 문제가 새로운 분석 기술을 통해 실제로 악용될 수 있다는 사실이 밝혀질 가능성이 있습니다.
즉, 오랫동안 사용되어 왔다고 해서 안전하다고 단정할 수는 없습니다.
이 문제는 PHP 만이 아니라 Java, JavaScript 실행 환경, 데이터베이스, 웹 서버, 라이브러리 등에서도 공통적으로 발생합니다.
이번 취약성은 PHP 고유의 문제이지만, 알려지지 않은 취약성이 잠재해 있다는 의미에서는 다른 기술들도 무관하지 않습니다.
취약점이 발견된 후 공격이 시작될 때까지의 시간이 단축될 가능성
이번에 PHP 수정 패치가 원래 계획보다 일찍 공개되었습니다.
배경에는 공개 전 정보 유출이나 공격 기법에 대한 정보가 유출된 사례가 있습니다.
앞으로 AI 를 활용한 분석이 발전함에 따라 취약점 공개부터 공격 기법 연구 및 개발까지의 시간이 단축될 가능성이 있습니다.
과거 '다음 주에 유지보수를 통해 수정하겠습니다'라고 판단했던 사항들도, 그 판단으로는 더 이상間に合わない 사례가 늘어날 수 있습니다.
③ 낡은 시스템이 공격자에게 계속 노골된다
이번 수정 패치가 공개되었다고 해서 전 세계 PHP 환경이 일제히 업데이트되는 것은 아닙니다.
일부 기업에서는 오래된 PHP 버전으로만 작동하던 기존 업무 시스템이 남아있는 경우도 있습니다.
수정의 영향을 확인하는 시간이 부족하거나, 유지보수를 담당하던 개발사가 사라진 경우 등도 고려해야 합니다.
이러한 시스템에서는 취약점이 공개되더라도 위험이 장기간 지속될 수 있습니다.
공격자에게는 수정되지 않은 시스템이 존재하는 한 공격 대상이 될 수 있습니다.
④ AI 를 통해 개발 속도가 빨라지더라도, 운영과 유지보수의 책임은 사라지지 않습니다.
AI 를 활용하면 과거보다 단기간에 웹 서비스나 애플리케이션을 개발할 수 있습니다.
저 역시 AI 를 활용한 개발에 매일 노력하고 있습니다.
하지만 개발 속도가 빨라졌다고 해서 완성된 시스템의 보안 대책이 자동으로 해결되는 것은 아닙니다.
프로그램이 정상적으로 작동하고 있더라도, 사용 중인 라이브러리나 실행 환경에 취약점이 발견될 수 있습니다.
그리고 해당 문제의 책임은 서비스를 계속 제공하며 지속됩니다.
앞으로 소수 인원이나 개인이 시스템을 개발하고 운영하는 사례가 늘어나면, 개발뿐만 아니라 지속적인 취약점 관리를 어떻게 수행할지에 대한 중요성이 더욱 커질 것이라고 생각합니다.
앞으로의 보안 대책에서 정말 필요한 것들
이번 문제에 대해 모든 기업이 고도화된 보안 제품을 도입해야 한다는 주장은 아닙니다.
가장 필요한 것은 기본적인 대응책을 지속적으로 실행할 수 있는 상태를 만드는 것입니다.
예를 들어, 다음과 같은 경우입니다.
사용 중인 소프트웨어를 파악합니다.
어떤 서버에서, 어떤 언어, 프레임워크, 라이브러리가 실행되고 있는지, 어떤 제품을 외부 업체에 맡기고 있는지.
이 부분을 이해하지 못하면 취약성 정보가 공개되어도 우리 회사가 영향을 받을지 판단할 수 없습니다.
적용 가능한 운영 체제를 구축해야 합니다.
패치를 적용하기 위해 누가 영향을 조사하고, 누가 중단 여부를 결정하며, 누가 수정 후 동작을 확인해야 하는지.
평상시를 미리 결정하지 않으면 응급 상황에 대응이 늦어집니다.
일시적으로 서비스를 중단할 수 있는 판단을 내릴 수 있다는 점입니다.
서비스 정지는 고객에게 영향을 주거나 매출 감소로 이어집니다.
그러나 위험한 상태로 계속 공개해 두면 정보 유출이나 시스템 침해가 발생할 경우 더 큰 피해가 초래될 수 있습니다.
멈추는 것이 항상 정답은 아니지만, 멈추는 선택지를 갖는 것은 중요합니다.
업데이트뿐만 아니라 공격의 징후를 확인할 수 있습니다.
접근 로그와 시스템 상태를 확인하고, 이상한 활동을 조사할 수 있는 체계를 마련하는 것도 필요합니다.
취약성을 수정하고 피해가 이미 발생하지 않았는지 확인하는 것은 별개의 업무입니다.
그리고 마지막으로 하나 더.
보안을 개발 단계에만 국한하지 마십시오.
시스템은 공개 즉시 완성되는 것이 아닙니다.
공개 이후에도 새로운 취약점이 발견되고, 해당 소프트웨어의 지원이 종료되며, 공격 기법도 변화합니다.
따라서 보안은 지속적인 운영 과정에서 고려해야 합니다.
결론: 2026 년 10 월 21 일은 보안의 어떤 변화를 가져왔는가
2026 년 10 월 21 일, PHP 의 중대한 취약점을 계기로 전 세계 웹 서비스들이 긴급 대응에 몰두했다.
일본에서는 총리가 직접 경고를 내렸으며, 기업과 서비스 운영자가 야간 긴급 유지보수를 실시했습니다.
해외에서도 정부 기관과 공공 서비스의 정지가 확대되고 있습니다.
널리 사용되고 있는 소프트웨어에 인증 없이 원격 코드를 실행할 수 있는 취약점이 발견되었습니다.
하지만 이번 일을"PHP 가 위험한 언어였다"는 결론으로 끝내기는 잘못이라고 생각합니다.
저가 중요하다고 생각하는 것은 오히려 그 이후입니다.
과거에는 무사히 작동하던 소프트웨어라도 알려지지 않은 취약점이 존재할 수 있습니다.
그리고 AI 의 발전으로 인해 과거에는 발견하기 어려웠던 문제들이 더 빠르게 드러날 수도 있습니다.
그것은 우리가 사용하는 소프트웨어의 안전성을 높이기 위한 진보이기도 합니다.
반면, 방어하는 쪽이 대응할 수 있는 시간은 과거보다 더욱 제한될 수 있습니다.
앞으로의 보안 대책에서는 취약점을 완전히 제거한다는 관념뿐만 아니라, 취약점이 발견되었을 때 영향을 얼마나 신속하게 파악하고 필요한 대응을 즉시 실행할 수 있는지가 점점 더 중요해지고 있는지도 모릅니다.
AI 를 통해 시스템 구축 속도가 빨라졌습니다.
하지만, 만든 시스템을 안전하게 유지해 나가는 책임까지 사라진 것은 아닙니다.
이번 PHP2Shell 사건은 다시 한번 그 사실을 생각하게 만든 일이었다.
참고 자료
- PHP 공식: 2026 년 10 월 21 일 보안 업데이트
- PHP Foundation: 취약점 발견 및 수정 과정
- PHP 보안 취약점 공개 전 사전 경고
- ENISA: PHP 의 중대한 취약점에 관한 공동 성명
- 클라우드flare: php2shell 을 통한 WAF 방어 및 공격 감시
- WordPress 공식: 중요한 PHP 보안 업데이트
- 오픈AI: 지구를 치유하다
- NCSC-NL: php2shell 관련 정보
관찰된 공격 상황과 실제 침해 피해는 구분하여 관리합니다. 또한 임시 설정 변경은 모든 공격 경로를 차단하지는 않습니다. 구체적인 대응 방법은 PHP 공식 사이트 및 사용 중인 운영체제와 호스팅 제공업체의 최신 정보를 확인하시기 바랍니다.
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 149청크
원문 보기 | 출처: note.com