# 총리가 PHP 취약점을 '최우선'으로 지시하며, 내부 감사원이 지금 바로 확인해야 한다.

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

---

안녕하세요. 'IA 인사이트 라브 (IA 라보)'의 관리자 히로입니다. 저는 미국에서 GRC 및 내부 감사 전문 컨설팅 사무소의 대표로 활동하고 있습니다. 이번 시리즈에서는 공인 부정 검사사이자 공인 내부 감사로서, 사회 전반에 발생하는 부정 행위와 사고를 쉽게 설명해 드리겠습니다. 오늘은 현재 전 세계 웹 사이트를 흔들고 있는 PHP 의 중대한 취약점인 'PHP2Shell (PHP2シェル)'에 대해 설명하겠습니다.

10 월 21 일 밤, 고시 사오미 총리는 X(구 트위터) 에서 특정 프로그래밍 언어의 패치 프로그램을 즉시 배포할 수 있도록 요청했습니다. 이에 따라 보육 시설 서비스부터 은행, 각 부처 웹사이트까지 일시 정지 또는 긴급 유지보수에 들어갔습니다. 본 기사는 어떤 일이 발생했는지, 왜 이렇게 큰 혼란이 일어난지를 정리한 뒤, 내부 감사원과 정보 보안 담당자가 현재 확인해야 할 사항을 5 가지 질문으로 요약합니다.

## 목차

- 전체 글의 요약
- 1. 사건 해설: PHP2Shell 에서 어떤 일이 발생했는지
- 웹의 약 70%를 지탱하는 'PHP'
- 1-2. 漏洩から公開まで、1日足らずの攻防
- 1-3. 메모 부족 시 발생하는 '정리'의 결점
- 1-4. 왜 이렇게 큰 소란이 일어난 것일까
- 알고 있는 것, 아직 모르는 것
- 2. 본사 사례에서 배울 수 있는 것: 내부 감사인이 현재 확인해야 할 5 가지 질문
- 2-1. 질문 1: 우리 회사의 PHP 가 어디에서 실행되는지 알 수 있는가
- 2-2. 질문 2: 지원이 종료된 버전을 누가, 언제까지 사용할지 결정했는가

## 전체 글의 요약

이 글의 내용을 읽기 전에 먼저 본 기사의 요약 이미지를 게재하므로, 전체적인 이해를 돕는 데 도움이 되시길 바랍니다.

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

## 1. 사건 해설: PHP2Shell 에서 어떤 일이 발생했는지에 대한 설명

### 웹의 약 70%를 지탱하는 'PHP'

PHP 는 웹사이트 뒷편 (서버) 에서 실행되는 프로그래밍 언어입니다. 블로그나 뉴스 사이트로 잘 알려진 WordPress 를 비롯해 회원 사이트나 업무 시스템의 대부분이 PHP 로 개발되었습니다. 웹사이트 기술 사용 현황을 조사하는 W3Techs 에 따르면, 서버 측 언어를 사용하는 웹사이트 중 69.3% 가 PHP 를 사용하고 있습니다 (2026 년 10 월 22 일 기준).

건물을 비유하자면 PHP 는 많은 빌딩에 공통적으로 사용되는 '기초 공법'과 같습니다. 그 공법 자체에 결함이 발견되면 외장이나 내장 (WordPress 나 각사의 앱) 을 아무리 관리해도 결함은 남게 됩니다. 이번 발생한 일은 바로 이 기초의 결함이었습니다.

### 1-2. 유출부터 공개까지, 하루도 채 되지 않은 격전

초기에는 수정 버전의 공개가 22 일로 예정되어 있었습니다. 그러나 10 월 20 일 (일본 시간 기준 21 일 오전 0 시 경) 에 취약점 식별 번호 (CVE) 가 잘못된 공개 시간과 잘못된 심각도 (10.0) 를 함께 표시하며 인터넷에 유포되기 시작했습니다. PHP 개발 팀은 같은 날 (일본 시간 기준 21 일 새벽) 에 수정 버전의 공개를 1 일 앞당겨 21 일로 변경한다고 사전에 알렸습니다. 심각도를 나타내는 CVSS (v4.0) 는 두 가지 모두 9.2 로, 가장 높은 '긴급' 등급입니다.

개정판 (8.5.12, 8.4.27, 8.3.36, 8.2.35) 은 일본 시간 21 일 밤 11 시에 공개되었습니다.

그 사이에도 정보가 계속 유출되었습니다. PHP 운영을 지원하기 위해 설립된 PHP Foundation 에 따르면, 발견자 중 한 명이 공격 시연 영상을 실수로 공개하고 복제가 유포되었습니다. 공개일까지 내용을 숨겨야 한다는 약속을 어기며 수정된 소프트웨어를 먼저 배포한 기업도 있었습니다.

일본 국내에서는 21 일 오후부터 서비스의 예방적 정지가 확대되었습니다. 밤에는 총리가 대응을 촉구했고, 22 일에는 정보처리진행기구 (IPA) 와 일본 사이버 공격 정보를 수집하고 대응을 조정하는 조직인 JPCERT/CC 가 주의보를 발령했습니다.

### 1-3. 메모 부족 시 발생하는 '정리 작업'의 결점

원인은 메모리가 부족할 때 발생하는 정리 작업 때문입니다 (PHP 공식 가이드 참조).

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

PHP 는 웹사이트에 대한 액세스 (요청) 을 하나씩 처리합니다. 처리에 사용되는 작업 공간 (메모리) 에는 한계가 있으며, 이 한계에 도달하면 처리가 중단됩니다. 문제는 중단된 상태에서 완성되지 않은 데이터나, 이미 정리되었어야 할 곳을 여전히 가리키는 '메모'가 남게 된다는 점입니다. 같은 작업자 (워커) 가 다음 요청을 처리할 때, 그 오래된 메모를 올바른 것으로 잘못 사용하게 되는 것입니다.

호텔 객실 청소를 비유하면 이해하기 쉬울 것입니다. 청소 중 호출된 직원이 앞客人的 짐을 정리하지 않은 채 '청소 완료' 표지를 걸게 됩니다. 정리되지 않은 방은 악의적인 손님에게 완벽한 틈을 제공합니다. 공격자는 메모리를 모두 사용하게 하도록 의도적으로 빈 파일을 대량으로 전송하거나, 이러한 정리 부주의를 유발합니다. 그 결과 메모리 내용이 유출되거나 외부에서 원하는 프로그램을 실행당할 수 있습니다.

또한, 로그인은 필요 없습니다. PHP 공식은 웹 요청을 처리하는 모든 PHP(PHP-FPM, Apache 의 mod_php, php-cgi, FrankenPHP, LiteSpeed) 를 대상으로 합니다. 특히 mod_php 의 경우, 애플리케이션 프로그램이 실행되기 전에 공격이 성공한다는 것이 입증되었습니다. WordPress 나 플러그인을 최신 버전으로 업데이트해도 해결되지 않는 이유는 바로 여기에 있습니다. PHP 본체를 수정해야 하기 때문입니다.

### 1~4. 왜 이렇게 큰 소란이 일어난 것일까

그 이유는 세 가지입니다.

첫 번째는 영향의 범위입니다. PHP 자체의 결함이므로 PHP로 작동하는 사이트나 시스템은 제작자가 누구든 대상이 됩니다. 발견자인 Wiz 에 따르면, 2012 년에 나온 PHP 5.4 이후 거의 모든 버전이 적어도 1 건의 영향을 받습니다. 인터넷에서 확인 가능한 영향을 받을 수 있는 서버는 연구자의 추정에 따르면 130 만 대를 넘습니다.

두 번째 문제는 오래된 버전으로 수정이 불가능하다는 것입니다. 수정된 버전은 8.2 에서 8.5 까지 4 개 버전뿐이며, 8.1 이전에는 개발팀에서 업데이트가 제공되지 않았습니다 (7.4 에서 8.1 을 위한 최소한의 수정 코드가 공개된 것 외에는). W3Techs 의 통계에 따르면, PHP 를 사용하는 사이트의 약 3 분의 1 이 7 세기 또는 그 이전 버전으로 실행되고 있습니다. 이들은 '업데이트 버튼을 누르면 끝난다'는 것이 아니라, 마이그레이션 작업이 필요함을 의미합니다.

셋째는 수정보다 먼저 공격이 시작되었다는 점입니다. 아마존 위협 정보 팀은 공개 4 일 전인 10 월 17 일, 자체 오토 서버 네트워크에서 악용 시도를 발견했다고 발표했습니다. 공개 이후에는 여러 보안 기업이 공격 시도가 급격히 증가했다고 보고했습니다.

### 알고 있는 것, 아직 모르는 것

다만, 냉정하게 살펴봐야 할 점도 있습니다.

미국의 CISA(사이버보안·사회기반보안청)는 21 일의 주의보 발표 시점에 악용 사례가 관찰되지 않았음을 명시했습니다. PHP Foundation 역시 공개 당시 유포된 공격 코드 중 실제로 실행 가능한 것이 발견되지 않았다고 밝혔습니다. 아마존 또한 공개 전 관찰된 시도가 실제 시스템에서 성공했는지는 불확실하다고 언급했습니다. 반면该公司는 공개 이후 "광범위하게 악용되고 있다"고도 밝혔으며, 보안 기업과 공공 기관 사이에서 견해가 갈렸습니다. 제가 확인한 범위에서 22 일 현재, 이 취약점으로 인한 침입 피해에 대해 공공 기관이 발표했다는 기록은 없습니다.

일본 내에서 가장 먼저 모든 서비스를 중단한 보육 시설용 서비스 '코도몬'도 22 일 기준으로 불법 접근이나 정보 유출이 확인되지 않았다고 밝혔습니다.

> 
> 
> "공격이 시도되었다"는 것과 "침입되었다"는 것은 별개의 문제입니다. 다만 침입되지 않았다고 단정할 수는 없습니다.
> 

이러한 '조사하지 않으면 알 수 없다'는 원칙이 내부 감사 담당자와 정보 보안 담당자의 역할을 결정짓는 요소가 됩니다.

## 2. 사례에서 배울 수 있는 것: 내부 감사인이 지금 확인해야 할 다섯 가지 질문

### 2-1. 질문 1: 우리 회사에서 PHP 가 어디에서 실행되는지 알 수 있는가

이제부터는 이 사건에서 확인하고자 하는 다섯 가지 질문을 순서대로 제시합니다. 모두 '패치를 적용했습니다'라는 한 단계 더 나아가는 질문들입니다.

CISA 는 먼저 PHP 를 사용하는 시스템을 모두 파악하라고 요청했으며, PHP 가 다른 소프트웨어의 구성 요소로 자주 포함되어 있음을 경고했습니다. 자체 제작 웹사이트뿐만 아니라, 렌탈 서버의 관리 화면, 제작사에 의뢰한 캠페인 사이트, 제품에 내장된 관리 화면, 그리고 SaaS 의 백엔드에도 PHP 가 포함될 수 있습니다.

감사에서 원하는 것은「PHP 목록이 존재하는가」보다「그 목록을 통해 이번 대상 항목을 몇 시간 만에 특정할 수 있었는가」입니다. 의뢰처나 SaaS 에 대해서는 상대방이 대응을 완료했는지 확인하는 창구와 절차가 계약이나 일상 운영에 마련되어 있는지 여부도 확인합니다.

### 2-2. 질문 2: 지원이 종료된 버전을 누가, 언제까지 사용할지 결정했는가

이번에는 8.1 이전 버전에는 공식 수정판이 나오지 않았습니다. 또한 이번에는 수정된 8.2 버전도 2026 년 12 월 31 일까지 공식 지원이 종료됩니다 (PHP 공식).

지원이 종료된 버전을 계속 사용하는 것 자체가 곧바로 나쁜 것은 아닙니다. 문제는 그것이 '누군가가 결정했다'는 것이 아니라 '어느새 계속되고 있다'는 상태가 되었을 때입니다. 언제까지 사용할지, 그 사이의 리스크를 누가 감당할지, 대체 방호책 (외부 접근 제한 등) 은 무엇인지가 기록으로 남아있는지 확인해 보십시오.

IPA 를 포함한 업데이트나 마이그레이션이 어려운 경우에도, 사업 책임자나 경영진까지 포함하여 인력, 예산 및 유지보수 체계를 확보할 수 있는지 검토해달라고 요청하고 있습니다. 지원 중단은 기술적 문제 이전에 경영진의 판단 문제입니다.

### 2-3. 질문 3: 밤중에 '중단'을 결정할 수 있는가

이번에 가장 강하게 남았던 것은 멈추는 판단의 속도에 차이가 생겼다는 점입니다.

코도몬은 수정 버전이 출시될 예정인 21 일 오후 2 시경에 모든 서비스를 중단한다고 알렸습니다. 이 회사는 정보가 유출되면 피해를 막을 수 없으므로 서비스를 계속하는 중요성과 정보를 보호하는 책임을 최우선으로 하여 피해를 예방하려 한다고 설명했습니다. 수정을 통해 안전성을 확인한 뒤 22 일 오전 3 시경 주요 서비스를 재개했습니다.

IPA 역시 효과적인 임시 대응책이 어려운 경우, 피해 규모와 업무에 미친 영향을 고려하여 외부 접근 차단 또는 서비스 일시 정지 여부를 판단하도록 요청하고 있습니다. 총리의 호소 역시 즉시 수정이 불가능한 경우, 일시적으로 중단하는 것도 리스크를 줄이는 방법 중 하나라고 밝히셨습니다.

내부감사원이 확인하고자 하는 사항은 다음과 같습니다. 서비스 중단 권한은 누구에게 있으며, 해당 인원이 밤중에 연락이 닿지 않을 때 대체자는 누구인가. 서비스 중단 여부를 결정하는 기준은 사전에 문서화되어 있는가. 서비스 중단 시 이용자나 거래처에게 알리는 절차가 마련되어 있는가.

> 
> 
> 「止める」은 미리 결정하지 않으면 밤에는 결정할 수 없습니다.
> 

### 2-4. 問い4：「修正を当てた」の後に、「入られていないか」を確かめたか

방향을 수정할 수 있다면 그 이후의 침입을 막을 수 있습니다. 그러나 수정하기 전에 이미 침입당했는지 여부는 별도로 조사하지 않으면 알 수 없습니다.

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

JPCERT/CC 는 침입 유무를 확인하기 위한 단서로 세 가지를 제시했습니다. 첫째는 과거 응답에 비정상적으로 긴, 혹은 형태가 이상한 세션 ID(쿠키인 PHPSESSID) 가 없는지 여부입니다. 둘째는 의심스러운 파일 전송 (multipart/form-data 형식의 요청) 이 발생했을 때, 그 직전과 직후에 메모리 한계 관련 오류나 HTTP 500 오류가 발생하지 않았는지 여부입니다. 셋째는 PHP 작업 프로세스가 예기치 않게 중단되거나 여러 번 재시작된 흔적이 없는지 여부입니다.

이와 함께 JPCERT/CC 는 이러한 흔적이 발견되지 않더라도 공격을 받지 않았다고 단정할 수 없다고 경고했습니다. 아마존은 조사를 최소한 10 월 17 일까지 거슬러 올라가도록 권장하고 있습니다.

내부감사의 관점에서 확인해야 할 두 가지가 있습니다. 하나는 10 월 17 일 이후의 로그가 조사 가능한 형태로 보존되어 있는지, 그리고 다른 하나는 '수정 적용일'과 '조사 종료일'이 별도로 기록되어 있으며, 조사 범위와 결과가 보고되었는지입니다. '수정 적용했으니 괜찮다'는 결론으로는 부족합니다.

### 2-5. 질문 5: AI 가 '수정까지의 여유 시간'이 줄어드는 전제에 기반하고 있는지

마지막으로, 이 사건의 배경에 자리한 거대한 변화에 대해 언급하겠습니다.

이번 취약점을 공개한 것은 미국의 보안 기업 Calif 와 Wiz, 그리고 OpenAI 입니다. Calif 와 Wiz 는 둘 다 조사 과정에서 AI 를 활용했다고 공표했습니다. Wiz 는 최첨단 AI 모델과 적절한 도구를 활용하면, 세계 수준의 팀이 수 개월 동안 수행해야 할 작업을 한 명의 연구자가 단 한 주 만에 완료할 수 있다고 설명했습니다 (동사 자체의 판단에 따라 어떤 작업을 어떻게 비교했는지 명시되지 않았습니다).

중요한 점은 이 결함의 징후가 이미 2024 년 외부 감사 시 발견되었음에도 불구하고, 공격에 활용될 수 있다는 것이 입증되지 않아 수정되지 않은 채 방치되었다는 사실입니다 (발견자의 설명과 PHP Foundation 의 설명). PHP Foundation 은 수정이 수 개월 동안 멈추었다는 점을 구조적 실패로 인정했습니다. 이에 따라 보안 팀이 다수결로 결정을 내릴 수 있는 절차를 개정한 가운데, 수정이 막히면 재단 관리층에 훨씬 더 빠르게 알 수 있도록 하고 있습니다.

내부감사의 용어로 번역하면 이는 '리스크 수용'의 문제입니다. '악용 방법이 아직 발견되지 않았으므로 지금은 수정하지 않겠다'고 결정한 약점은 어느 기업에도 있을 것입니다. AI 를 통해 취약점 발견과 공격 속도가 빨라지면 그 판단의 전제가 무너집니다. 수용한 리스크 목록에 누가 판단했는지, 재검토 기한이 명시되어 있는지 확인해 보아야 할 때입니다.

> 
> 
> AI 가 취약점을 발견하는 속도는 방어자이자 공격자 모두에게 동일하게 작용합니다. '아직 악용되지 않았다'는 이미 오래 지속될 수 없는 전제입니다.
> 

## 3. 맺음말: '맞았다'로 끝내지 마라

### 3-1. 다섯 가지 질문을 내일의 한 질문으로

PHP2Shell 은 웹의 약 70% 를 지탱하는 기반의 결함이었습니다. 수정 버전이 나왔지만, 구버전에는 패치가 없었고, 패치가 적용되기 전에 이미 공격 시도가 시작되었습니다.

내부 감사관과 정보 보안 담당자가 현재 확인해야 할 사항은 다섯 가지 질문으로 요약할 수 있습니다. 회사의 어디에서 PHP 가 실행되고 있는지 알 수 있는가. 지원 종료 버전이 누구에 의해 언제까지 사용될지 결정했는가. 밤중에 정지할 수 있는가. 정지 후 침입되지 않았는지 확인했는가. AI 가 허용 시간을 줄이는 전제에 서 있는가.

내일, 먼저 한 가지 행동으로 시작한다면 정보보안 담당자에게 이번 대상 전체를 식별하는 데 소요된 시간이 몇 시간인지 물어보세요. 그 답변에 다음 큰 취약점에 대한 대비가 드러날 것입니다.

이 글은 저의 전문가로서 지속적 학습을 위한 것이며, 또한 독자各位의 학습을 위해 게시되었습니다. '좋아요'나 '팔로우'로 응원해 주시면 큰 힘이 됩니다. 그럼 다음 글에서 다시 만나요!

원본 (본문 청크 73/87): 【引用元】
1 차 번역문: [출처]
위 1 차 번역문에 미번역된 어휘가 있다면 매끄럽고 완벽한 한국어로 교정하세요. 고유명사, 인명, 수치는 원문 그대로 보존하고, 최종 한국어 결과만 출력하세요.

PHP 그룹「보안 경고: 치명적인 원격 코드 실행 취약점, 즉시 업데이트」(2026 년 10 월 21 일)

PHP 재단「오늘의 PHP 보안 릴리스 및 PHP 보안 강화 방안」(2026 년 10 월 21 일)

CISA「PHP 치명적 취약점: 즉시 패치 필요」(2026 년 10 월 21 일)

IPA「PHP 취약점 대응 방안 (CVE-2026-109618, CVE-2026-109619: PHP2shell)」（2026 년 10 월 22 일)

JPCERT/CC「PHP 다수 취약점 (CVE-2026-109618, CVE-2026-109619) 관련 주의보」(2026 년 10 월 22 일)

아마존 위협 지능이 마드포트 공개 전 PHP2Shell 악용을 사전에 식별함 (AWS 보안 블로그, 2026 년 10 월 21 일)

Wiz「PHP2Shell: AI 가 인터넷 70% 를 타격하는 치명적인 RCE 취약점을 발견함」（2026 년 10 월 21 일）

칼리프 리서치「php2shell: 두 PHP 원격 취약점의 이야기」（2026 년 10 월 21 일）

Tenable「php2shell (CVE-2026-109618, CVE-2026-109619): 중요 PHP 원격 코드 실행 취약점에 대한 자주 묻는 질문」(2026 년 10 월 21 일)

W3Techs「웹사이트용 PHP 사용 통계」（2026 년 10 월 22 일 기준）

ITmedia NEWS「PHP 취약점으로 인해 서비스 정지를 가장 먼저 선택한 코드몬: 피해 발생 이후 취소 불가한 배경」（2026 년 10 월 22 일）

ITmedia NEWS「고시 총리『PHP 패치 적용, 즉시 조치하라』X(트위터)에서 이례적 지시, 엔지니어들은『경영진에게 전달됨』을 평가 (2026 년 10 월 22 일)」

일본 경제신문 "PHP 결함으로 은행 및 통신사 서비스 정지 확대, 일부는 재개 (미즈호은행 등)" (2026 년 10 월 22 일)

# 내부 감사 #IA_Insight_Lab #사이버보안 #취약점 #PHP

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

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

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