# 총리가 X 에 '가장 긴급하다'고 썼던 밤, PHP 에서 무슨 일이 일어났는지

> https://bookfactory.kr/board/news/23399
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-23T09:38:14.300Z

---

10 월 21 일 밤 10 시 이전에 총리의 X(트위터) 계정에 '오늘 밤에 대응해달라는 매우 긴급한 요청'이라는 게시물이 올라왔습니다. 그 내용은 프로그래밍 언어 'PHP'의 수정 패치에 관한 것이었습니다. 처음에는 총리가 소프트웨어 업데이트를 호소하는 것이 어떤 상황인지 궁금했습니다. 이어 자신이 관여하고 있는 사이트 중 PHP 로 작동하는 것이 무엇인지, 그 버전을 어느 정도인지 바로 대답할 수 없다는 사실을 깨달았습니다.

> 
> 
> 모든 분께, 오늘 밤 반드시 대응해 주셔야 할 매우 긴급한 요청입니다. 많은 웹사이트에서 사용되고 있는 PHP 에 대해 PHP 보안 팀이 중대한 2 건의 취약점에 대해 경보를 발령했습니다. …— 타카이치 사나에 (@takaichi_sanae) 2026 년 10 월 21 일
> 

같은 장소에 머무는 사람이 많다고 생각합니다. 코드몬과 베이스가 멈췄고, 사쿠라와 엑스 서버가 유지보수에 들어갔다는 뉴스가 계속 흘러옵니다. 하지만 "그렇다면自分は 무엇을 해야 할까?"에 답하는 글은 의외로 적습니다. 엔지니어를 위한 설명은 설정값부터 시작되고, 일반인을 위한 글은 "무섭군요"로 끝나는 경우가 많습니다.

이 글에서는 어떤 일이 발생했는지 정리하고, PHP 의 단일 결함이 왜 이토록 많은 서비스를 동시에 정지시켰는지를 구조적으로 분석한 뒤, 각자의 상황에 따른 대응 방안을 제시합니다. 본 내용은 10 월 22 일 오후까지 확인된 범위이며, 상황이 시간 단위로 변하고 있으므로 이를 전제로 읽으시길 바랍니다.

## 무슨 일이 일어났는지

## 두 가지 취약점과 'php2shell'이라는 이름

PHP 개발 팀이 10 월 21 일에 공개한 보안 권고에 따르면, 문제가 2 건입니다.

![画像](https://assets.st-note.com/img/1792654909-mse3wGZ0VxDSEt8Qikf5M14q.png?width=1200)

CVE-2026-109618 과 CVE-2026-109619 의 심각도는 모두 CVSS v4.0 기준으로 9.2 로, 만점 10 점에 가까운 '긴급' 수준입니다. 연구자와 보안 기업 사이에서는 이 두 취약점을 함께 'php2shell'이라고 부릅니다.

위험한 점을 한 문장으로 요약하면, 로그인하지 않은 외부 사용자가 조작된 접근 요청만 보낼 때 해당 서버에서 원하는 명령어를 실행할 수 있다는 것입니다. 전문 용어로는 '원격 코드 실행'이라고 합니다. 사이트의 뒷문을 열리는 것보다, 서버의 조작석에 직접 앉히는 것과 더 유사한 이미지입니다.

구조가 상당히 기술적이므로 비유로 설명드리겠습니다. PHP 를 주문 (웹 접속) 을 차례로 처리하는 주방으로 생각하시면 됩니다.

1. CVE-2026-109618: 메모리가 부족해진 순간에 반찬을 버리고 다음으로 이동해버립니다. 정리청소 담당자는 그 반찬을 '완제품'으로 착각하여 처리하고, 그곳에서 내용물이 파손됩니다.

2 번째 사례 (CVE-2026-109619): 이미 폐기해야 할 이전 손님의 영수증이 작업대에 남아있어, 같은 요리사가 다음 주문을 처리할 때 해당 영수지를 참조해버리는 상황입니다.

둘 모두 '중간중간한 상태가 남아있고, 이후의 처리가 이를 신뢰하게 된다'는 점에서 근본적으로 동일하다. GMO Flatt Security 의 설명에서도 두 건은 공통적으로 부적절한 상태 관리에서 비롯되었다고 정리하고 있다. 비유이므로 세부 사항은 정확하지는 않지만, 방향성은 이렇다고 생각하시면 된다.

문제는 이 주방이 '요리의 내용'이 아닌 '주방 그 자체'라는 점이다. PHP 공식은 사이트 측 프로그램이 실행되기 전에 공격이 성공한다는 것을 증명했으므로, 이 부분을 가장 위험하다고 지적한다. 아무리 사이트 프로그램을 세밀하게 만들어도, 그 전에 무너진다.

## 72 시간 시계열

시간은 일본 시간으로 조정되었습니다.

![画像](https://assets.st-note.com/img/1792654947-tmnlhGeUCkHFQRLVMEP7rogD.png?width=1200)

10 월 17 일: 아마존 위협 인텔리전스가 자체 유인 서버 네트워크에서 php2shell 을 표적으로 한 공격 시도를 관측했습니다. 공개 4 일 전으로, 공격자가 정보를 어디서 얻었는지는 아직 불분명하다고 밝혔습니다.

10 월 21 일 0 시 경: 2 개의 CVE 번호가 포럼과 SNS 에서 유포되기 시작함. PHP 재단에 따르면, 이 시기에 유출된 것은 번호와 잘못된 공개 시간, 잘못된 심각도 (10.0) 이며, 기술적 세부사항은 포함되지 않았음.

동일 날 오후 4 시 반 경 PHP 개발 팀이 "23 시에 수정판을 배포한다"고 예고했다. 원래 22 일 공개 예정이었으나 하루 앞당겨 발표되었다.

동일 날 오전 5 시경: 취약점을 보고한 보안 기업 중 하나인 칼리프가 공격 코드가 작동하는 모습을 담은 영상을 실수로 공개했습니다. 삭제 후에도 복제본이 확산되었습니다.

동일 시간 16 시 41 분: 사전에 수정 내용을 확보하고 있던 배포 사업자 중 하나인 Chainguard 가 합의보다 6 시간 이상 일찍 수정이 포함된 결과물을 공개했습니다. PHP 재단은 이를 공격자가 수정 내용을 먼저 분석할 수 있는 상황을 조성했다는 이유로 비판하고 있습니다.

동일 날 낮과 밤: 국내 기업과 관공서가 차례로 서비스와 사이트를 중단한다.

동일 날 21 시 55 분 경: 총리가 X 를 통해 호소했다. 국가 사이버 통제실도 패치가 즉시 적용되지 않는 경우 사이트 정지를 통해 리스크를 낮추는 방법 중 하나로 호소했다.

동일 날 밤 23 시 전후: 수정판이 공개됩니다.

10 월 22 일 아침: 사쿠라 렌탈 서버는 6 시 30 분에 PHP 업데이트 완료 사실을 알렸고, 엑스 서버는 6 시 45 분에 PHP 8.2~8.5 대상 서버 전체 적용 완료 사실을 알렸습니다.

## 바라야 할 버전과, 바라지 않을 버전

수정판은 다음 네 가지입니다.

・PHP 8.5.12

・PHP 8.4.27

・PHP 8.3.36

・PHP 8.2.35

PHP 8.1 이전에는 공식 지원이 종료되어 공식 수정 버전을 배포하지 않았습니다. PHP 보안 팀은 사태의 심각성을 고려해 7.4~8.1 대상에 최소한의 수정 코드를 공개했으나, 이는 개발자가 소스 코드로 직접 컴파일해야 하는 형태로, 비개발자가 바로 사용할 수 있는 형태는 아닙니다. 영향 범위에 대해 발견을 주도한 Calif 는 해당 버그가 PHP 5.4.0 코드까지 상향되도록 추적되었다고 밝혔습니다.

즉, 세상 속 PHP 는 '최신 버전으로 업그레이드만 하면 되는 경우'와 '업그레이드 경로 자체가 좁은 경우'로 나뉜다.

## 왜 PHP 하나만으로 이렇게 많은 것이 멈췄을까

소프트웨어의 취약점은 매주 발견되고 있습니다. 그럼에도 이번에는 유치원 연락 앱부터 게임, 온라인 쇼핑몰, 중앙행정기관 웹사이트까지 같은 밤에 모두 멈췄습니다. 이는 하나의 원인 때문이 아니라, 최소한 네 가지 요인이 겹쳤다고 생각합니다.

## PHP 는 '집'이 아닌 '지반'이었다.

먼저 규모에 대해 말씀드리겠습니다.

![画像](https://assets.st-note.com/img/1792654991-Wq2seiN617Xd5xrh0GAJQOyb.png?width=1200)

W3Techs 의 웹 기술 활용 현황 조사에 따르면, 사용 가능한 언어로 구분되는 웹사이트 중 PHP 를 사용하는 사이트는 약 70% 입니다. 집계 날짜에 따라 69% 대에서 70% 대 후반까지 변동되므로, 이 수치는 대략적인 범위로 이해해 주십시오. 세계 웹사이트의 상당 부분은 PHP 로 작동하는 WordPress 를 사용하고 있으며, VirusTotal 의 분석에 따르면 인터넷에서 PHP 가 작동하는 것으로 식별된 IP 주소는 약 510 만 개에 달했습니다.

다만 규모만 본다면 "잘 쓰이는 소프트웨어에 구멍이 있었다"로 끝날 수 있다. 이번에는 구멍의 위치가 핵심이었다.

대부분의 뉴스가 되는 취약점은 WordPress 플러그인이나 특정 서비스에 고유한 프로그램과 같은 '집'의 측면에 있습니다. 집의 결함이라면 그 집의 소유자가 고치면 되며, 영향도 집의 수로 제한됩니다. 이번 문제는 지반의 측면에 있었습니다. Check Point 가 지적한 바와 같이, WordPress 나 Magento, Drupal 등의 애플리케이션 측을 최신 버전으로 업데이트하더라도 이 문제는 해결되지 않습니다. 지반이 균열을 일으키면 그 위에 세워진 집은 설계의优劣와 관계없이 모두 기울어집니다. 다양한 산업과 규모를 가진 서비스들이 같은 밤에 모두 멈췄다는 것은 이렇게 생각하면 설명이 됩니다.

## ②「直す前にバレた」から、止めるしかなかった

두 번째는 순서 문제입니다.

심각한 취약성은 일반적으로 발견자가 개발자에게 비밀로 보고하고, 개발자가 수정 버전을 만들어 Linux 배포판이나 클라우드 등 PHP 를 배포하는 기업들에게 사전에 전달한 후, 모든 준비가 완료된 시점에서 '취약성 공개'와 '수정 버전 공개'를 동시에 진행합니다. 이를 통해 공격자가 취약점의 존재를 알게 되는 순간, 방어 측도 이미 대응 수단을 보유하게 됩니다.

이번에는 순서가 뒤바뀌었다. 수정판이 나올 전까지 번호가 누락되었고, 공격이 실행되는 동영상이 유포되며 일부 업체가 약속보다 일찍 수정 버전을 공개했다. 또한 Amazon 의 관측을 믿는다면, 발표 4 일 전부터 누군가 공격을 시도했을 것이다. '취약점이 있다'는 것은 전 세계가 알고 있지만, 이를 막는 도구는 아직 없다. 이 공백이 거의 하루를 이어갔다.

그 사이 설정을 변경하지 못했는지. PHP 공식은 즉시 업데이트가 불가능한 경우의 설정 변경 몇 가지를 제시했지만, 이는 특정 공격 경로의 노출을 줄이는 것뿐이며 환경을 안전하게 만드는 것이라고 명시하고 있습니다. GMO Flatt Security 역시 설정 변경으로 완전히 회피할 수 없으며, 단지 일시적인 방편일 뿐이라고 주장합니다.

확실한 방어 수단이 없으며 공격의 흔적이 감지된다면, 남은 확실한 선택지는 '표면에서 보이지 않게 만드는 것', 즉 차단하는 것뿐이다. 국가 사이버 통제실과 총리가 패치가 어렵다면 사이트의 일시 정지가 유효한 대안이라고 명시한 것은 바로 이 상황을 가리키는 것으로 보인다.

피야로로그의 요약에 따르면, 각社の公告을 통해 21 일 22 시까지 확인된 조직만으로도 54 개가 서비스를 중단하거나 사이트 운영을 멈추거나 긴급 유지보수 조치를 발표했습니다. 반면, 22 일 오후 현재 이 취약점으로 인해 침해당했다고 공표한 국내 조직은 확인되지 않았습니다. 중단된 이유는 '당했다'가 아니라 '당할 전에'였기 때문입니다. 뉴스의 표면적 모습은 대규모 장애처럼 보이지만, 본질은 대규모 예방 조치였다는 이야기입니다.

과거 사례조차 이 판단이 과장되었다고 단정할 수 있음을 보여줍니다. 2024 년에 발견된 PHP 의 또 다른 중대한 취약점 (CVE-2024-4577) 은 수정 후 6 일 만에 미국 CISA 의 '실제로 악용된 취약점' 목록에 포함되었으며 랜섬웨어에도 악용되었습니다.

## ③ 2 년 전에는 징후가 있었습니다. 멈추게 된 것은 기술이 아니라 합의 과정이었습니다.

세 번째는 개인적으로 가장 깊은 생각과 반향을 불러일으킨 부분이다.

PHP 재단은 수정판 공개 당일 배경을 설명하는 긴 글을 발표했습니다.

![画像](https://assets.st-note.com/img/1792655113-2R6z3QLD4M5oK1ObdqVChWFu.png?width=1200)

이에 따르면, 첫 번째 근본 원인인 문제의 징후는 이미 2024 년에 발견되었습니다. 독일의 공공 기관인 Sovereign Tech Agency 의 자금으로 수행된 외부 보안 감사에서 지적된 사항을 바로잡는 과정 중, 기구가 계약한 PHP 의 핵심 개발자가 메모리 부족 관련 문제를 발견했습니다.

그렇다면 왜 두 년 동안 고치지 못했을까요. 재단의 설명에 따르면, 고치기 위한 후보안들은 여러 가지가 마련되었습니다. 다만 어떤 제안은 기존 시스템과의 호환성을 무너뜨렸고, 다른 제안은 새로운 서비스 정지 가능성을 초래했으며, 또 다른 제안은 수많은 외부 확장 기능을 수정하도록 강요했습니다. 조정 자체가 불가능해 보였습니다. 보안 팀은 모두 동의해야만 움직이며, 잘못된안을 출시하는 것을 두려워해 결정을 내릴 수 없었습니다. 당시에는 해킹까지 이어지는 구체적인 경로도 발견되지 않았고, 엔진의 심층 구조를 이해하고 있는 소수의 개발자들은 다른 업무도 부담스러워 있었습니다. 결과적으로 수정 작업은 수 개월 동안 멈추고 다시 시작하는 것을 반복했습니다. 재단은 이 지연을 의사결정 체계와 인력 부족이라는 두 가지 요인에 의한 '구조적 실패'라고 스스로 인정하고 있습니다.

중단된 것은 기술이 아니라 합의 형성 그 자체였으며, 그 합의 형성을 뒷받침하는 인원이었음을 의미합니다.

이를 주도한 것은 AI 였습니다. 재단은今年 Alpha-Omega 와 협력하여 Anthropic 의 Claude Mythos 를 통해 PHP 를 분석했고, 이후 OpenAI 의 도구들도 보고서 검증에 참여했습니다. OpenAI 의 'Patch the Planet' 프로그램 일환으로, 보안 기업 Calif 가 7 월 30 일 PHP 감사 작업을 시작했고, 8 월 11 일에는 2024 년 문제의 동일한 근원으로부터 무조건적인 탈취 공격을 보고했습니다. 같은 날 OpenAI 도 독립적으로 동일한 근본 원인을 보고했으며, 8 월 24 일에는 Wiz 가 다른 공격 경로를 보고했습니다. 재단에 따르면, 이제야 문제의 전체 양상이 명확해졌고, 8 월 11 일 이후부터는 수정 작업이 최우선으로 진행되고 있습니다.

이곳에서 관찰되는 것은 발견 속도와 수정 속도의 괴리라고 생각합니다. 재단에 따르면 AI 를 활용한 조사가 확대됨에 따라 보안 팀은 7 월 1 일 이후 15 개의 CVE 를 발표했으며, 무효이거나 중복되거나 재현이 불가능한 것까지 포함하여 100 건 이상의 보고를 처리하고 있습니다. 발견 속도는 기계에 의해 몇 배로 증가합니다. 그러나 오래된 엔진 설계에 어떻게 수정을 가할 것이며, 호환성을 어느 정도 희생해야 하는지를 결정하고 수정 사항을 검토하는 것은 인간이 해야 하며, 이를 담당할 사람은 적습니다. 재단은 글의 마지막 부분에서 PHP 로 제품을 개발하는 기업, 호스팅 제공자, 행정 기관에 자금 지원에 대한 협력을 명확히 요청하고 있습니다.

재단의 주장 내용을 살펴보면 구조가 명확해집니다. 정부 서비스, 은행, 온라인 쇼핑몰까지 모두 포함되는 이 기반의 안전은 재단에 고용된 소수의 인원과 일부 자원봉사자들만 유지하고 있습니다. 그 위에 사업을 영위하는 대부분의 당사자들은 이 기반 유지 비용을 거의 부담하지 않고 있습니다. 이는 특정 누군가가 잘못했다는 이야기라기보다, 무료로 사용할 수 있는 것들의 유지 비용을 누가 부담할 것인지가 결정되지 않은 시스템의 문제입니다. 이번 2 년간의 정체 현상은 바로 그 시스템이 가장 취약한 형태로 드러난 결과라고 생각합니다.

## ④「누가 고칠 것인가」라는 표현은 사용처에 따라 완전히 다른 의미를 가집니다.

네 번째는 대응 책임 소재에 관한 이야기로, 이는 비엔지니어에게 가장 실무적으로 중요한 부분입니다.

![画像](https://assets.st-note.com/img/1792655146-9WHh8UrwakZumPRx74XisGFL.png?width=1200)

동일한 'PHP 로 작동하는 사이트'라 해도 PHP 본체 업데이트 책임 소재는 서버 임대 방식에 따라 달라집니다.

공용 렌탈 서버 (사쿠라, 엑스 서버, 로리ポップ 등) 의 경우 PHP 업데이트는 사업자 업무이며, 이용자가 서버에 접속하여 재설치할 필요가 없습니다. 실제로 사쿠라나 엑스 서버는 22 일 아침까지 대응을 고지하고 있습니다.

VPS, 클라우드, 자체 서버: PHP 업데이트는 자체 또는 유지보수를 맡긴 회사의 업무입니다. 누군가가 이를 처리하지 않는 한 오래된 상태로 계속 남습니다.

SaaS(예를 들어 BASE 나 코도몬과 같은 외부 서비스): 제공된 기업의 업무입니다. 사용자는 기본적으로 할 수 있는 일이 없습니다.

문제는 경영자가 스스로 이 세 가지 중 어느 것이 해당하는지 파악하지 못하는 경우가 많다는 것입니다. 본문 초반에 언급한 저 역시 바로 그 상태였습니다.

또한, 지원 종료된 오래된 버전에 대한 문제도 있습니다. VirusTotal 의 분석 결과, PHP 가 실행 중이라고 식별된 약 5,100 만 개의 IP 주소 중 최소 75 만 8,000 개가 지원 종료 버전이었음을 알 수 있습니다. Cisco Talos 는 취약한 PHP 환경의 약 절반에 패치가 도달하지 않을 가능성이 있다고 추정하고 있습니다. 이는 식별된 숫자일 뿐, 그대로 '취약한 서버의 수'라고 단정할 수 없다는 점을 유의하시기 바랍니다. 그럼에도 불구하고, 공식 수정 버전을 출시하지 않은 버전에서도 여전히 운영 중인 사이트가 상당수 있다는 점은 읽을 수 있습니다.

이후부터는 제 예측에 따라 읽어보시기를 바랍니다. 일본에서 소외되기 쉬운 사이트는 몇 년 전 제작사에 제작을 맡겼고 유지보수 계약을 맺지 않은 채도 계속 운영 중인 중소기업의 사이트라고 생각합니다. 공유 서버라면 사업자 측이 오래된 버전에도 어느 정도 개입을 해주지만 (X 서버는 공식 수정 버전을 제공하지 않는 오래된 버전용에 독자적인 수정을 시작하고 있음), VPS 나 자체 서버로 '제출된 그대로' 유지되는 경우라면, 누구도 인지하지 못한 채 방치될 가능성이 있습니다. 이는あくまで 가설일 뿐이며, 실제 데이터를 바탕으로 한 말씀은 아닙니다.

## 역할에 따라 지금 해야 할 일

## 사이트나 서비스를 보유한 사람

경영자나 기술 전문가가 아닌 담당자를 대상으로 작성합니다.

![画像](https://assets.st-note.com/img/1792655168-6kRU14J8e3HpsdSNtfioTGmj.png?width=1200)

먼저, 회사의 사이트나 시스템 중 PHP 로 작동하는 것을 확인하세요. WordPress 로 만든 사이트라면 거의 확실히 PHP 입니다. 알 수 없다면 제작한 회사나 유지보수를 담당하는 회사에 문의하는 것이 가장 빠릅니다.

다음으로 해당 사항이「공용 렌탈 서버」「VPS 나 클라우드, 자체 서버」「외부 서비스」중 어느 하나인지 확인합니다. 이 단계에서 누가 문제를 해결할지 결정됩니다.

공유 렌탈 서버라면 사업자 공지사항을 확인하여 사용 중인 사이트의 PHP 버전이 수정 대상인지 파악하세요. 오래된 버전을 사용하고 있다면, 사업자가 대응된 버전으로 전환할 것을 안내하는 경우가 많습니다.

VPS 나 자체 서버의 경우, 아래 질문을 그대로 관리 담당자에게 보내주세요.

바로 수정이 불가능하다면, 일시적으로 중단하는 것도 선택지로 고려해야 한다. 국가 사이버 통제실과 미국 CISA 역시 수정이 불가능한 경우 중단하거나 인터넷과 단절하는 것을 권고하고 있다.

제작사나 인사팀에 보내는 질문은 이 정도로 충분하다고 생각합니다.

세 번째 항목에 대해 보충하면, 아마존은 조사의 시작점을 공표일로 하지 않고 최소한 10 월 17 일로 설정하도록 권고하고 있습니다. "패치를 적용했으니 끝났다"가 아니라, 적용 전 해당 패치가 적용되지 않았는지 확인하는 것이 대응책입니다.

그 이후 PHP 공식에서 제시한 설정 변경은 업데이트 지연을 위한 것뿐입니다. "설정을 통해 대응했습니다"라는 보고를 받으면 반드시 업데이트가 언제 이루어질지 물어보셔야 합니다.

## 서비스만 이용하는 사람들

스마트폰이나 컴퓨터에 설치나 설정이 필요 없습니다. 대응은 서비스를 운영하는 측의 책임입니다.

각社の 유지보수 및 정지는 기본적으로 예방 조치였으며, 22 일 오후 기준 국내에서 이 취약점으로 인한 침해가 공개된 조직은 확인되지 않았습니다.

사용 중인 서비스에서 개인정보 관련 안내가 도착하면 해당 지침을 따르시면 됩니다. 현재 단계에서는 모든 비밀번호를 변경해야 한다고 단정할 수는 없습니다.

이 부분은 저의 예측일 수 있지만, 이번 사태를 악용한 위조 메일에는 "유지보수가 완료되었으므로 다시 로그인해 주세요"나 "취약점 대응을 위해 확인을 부탁드립니다"와 같은 문구가 포함될 것이라고 생각합니다. 평소 사용하던 앱이나 북마크를 통해 메일 링크를 열던 습관을 이번 기회에 다시 한번 의식해 보시는 것이 손해일 것이 없습니다.

## 반대편에서 보면

그렇다면, 동시에 중단한 것이 정말로 옳았을까요. 먼저, 과도한 반응이었을지도 모른다는 견해가 있습니다. 보육원 연락 앱이나 온라인 쇼핑몰이 한밤중에 멈추면 이용자와 판매자 모두 실질적인 피해가 발생합니다. 결과적으로 침해 사실의 공표가 제로가 된다면, 그 정도까지 할 필요는 없었을지도 모른다는 목소리가 나오는 것은 자연스러운 일입니다. 다만, 21 일 오후 당시 각 기업이 보유하고 있던 정보는 "취약점이 있다는 것은 확실하지만, 이를 막는 도구는 아직 없으며, 공격의 기미가 있다"는 것이었습니다. 나중에 보았을 때 침해가 발생하지 않았다는 사실과 그 당시 중단 판단이 타당했는지는 별개의 문제이며, 전자를 근거로 후자를 비난하는 것은 공정하지 않다고 생각합니다. 그럼에도 불구하고, 정말로 피해가 발생하지 않았는지는 앞으로 몇 주간의 로그 조사에서 밝혀질 문제이며, 현재로서는 평가하기 어렵습니다.

다음으로, "PHP 는 이미 위험하므로 다른 언어로 전환해야 한다"는 해석입니다. 이는 틀린 것 같습니다. GMO Flatt Security 의 블로그를 보면, 올해 7 월에 Ruby on Rails 에서 'KindaRails2Shell', WordPress 에서 'wp2shell'과 같이 인증 없이 침입에 이르는 긴급 취약점이 잇따라 보고되었습니다. 이번 구조는 "PHP 에서 발생한 것"이라기보다는, AI 가 취약점을 찾는 속도가 빨라져 모든 언어와 소프트웨어에서 오래된 설계의 구멍이 잇따라 드러나는 흐름의 일부라고 생각합니다. 전환한 곳에서도 같은 일이 발생할 수 있습니다.

일본에도 고유한 맥락이 있습니다. 총리의 게시물에 대해 ITmedia 는 엔지니어로부터 "경영진에게도 리스크가 전달된다"는 평가가 나온다고 전하고 있습니다. 평소에는 정보보안팀이나 개발팀 내에서만 마무리되는 논의가, 한밤중에 경영자의 눈에 도달했다는 것은 분명히 큰 일입니다. 반면, 이러한種の 호소력은 매번 가능한 것은 아닙니다. 다음에 비슷한 규모의 취약점이 발견될 때, 총리의 게시물 없이는 움직이지 않는 조직이 남는다면, 그것은 또 다른 약점이 될 것이라고 생각합니다.

그리고 이 사건은 오늘로 끝나는 이야기가 아닙니다. 지원이 종료된 버전으로 작동하는 서버는 쉽게 사라지지 않으며, 침입 조사도 막 시작되었을 뿐입니다. 몇 주 후에 "사실 침입당해 있었다"는 발표가 나올 가능성은, 솔직히 말해 부정할 수 없습니다.

## 지반의 위치를 알고 계신가요?

시작 부분에서 제가 관여하는 사이트의 PHP 버전을 즉시 대답할 수 없었음을 적었습니다. 이번 일을 추적해 보니, 그 대답의 불가능함이 바로 이 사태의 가장 큰 구조였음을 깨닫게 되었습니다.

웹의 70% 를 지탱하는 기반을 지키는 것은 소수의 개발자들이 거의 손에 들고 일하는 형태로 지키고 있습니다. 그 위에 집을 짓고 있는 우리 대부분은 그 기반이 어디에 있고, 균열이 생겼을 때 누가 수리할지 모릅니다. 2 년간의 정체성도, 수정 버전이 없는 오래된 버전의 긴 꼬리도 그 뿌리는 같은 곳에 있습니다.

소프트웨어의 안전성은 코드 품질보다 먼저 '누가 수정할 책임이 있는가'를 파악하고 있는지에 따라 결정됩니다. 이번 사건이 가르쳐 준 것은 아마도 바로 그 때문이라고 생각합니다.

(본 내용은 2026 년 10 월 22 일 오후까지 확인된 공개 정보를 바탕으로 합니다. 최신 상황은 PHP 공식 보안 안내, 정보보호진흥원, 국가사이버안전관리센터, 사용 중인 서버 사업자에서 발표하는 공지사항을 통해 확인하시기 바랍니다.)

**출처:** [note 원문](https://note.com/gokumagai/n/n2e3aad8d604d)

*번역: Qwen 3.5(.48) 초벌 + 교정 53청크*

[원문 보기](https://note.com/gokumagai/n/n2e3aad8d604d) | 출처: note.com