# php2shell 은 구체적으로 어디가 위험한지, 두 가지 취약점으로 인해 어떤 피해가 발생할 수 있는지 (2026 년 10 월 24 일 기준)

> https://bookfactory.kr/board/news/23671
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-24T18:44:39.757Z

---

이전까지 php2shell(CVE-2026-109618/CVE-2026-109619) 의 전체 개요, 이후 추가 보고, 그리고 본인이 수행한 검증 내용을 정리했습니다. 이번에는 많은 분들이 궁금해하시는 '결국 어디가 어떻게 위험하며, 성공 시 어떤 일이 벌어지는가'를 정리합니다.

먼저 선을 그립니다. 이 글은 PHP 공식 문서 및 각 업체(GMO Flatt Security, watchTower, Amazon 등)가 공개한 범위 내에서만 '작동 원리'와 '영향'에 대해 설명합니다. 실제 공격 코드나 공격 방법도 기술하지 않습니다. 이를 기록하지 않더라도 '어떤 부분이 위험하며, 어떤 일이 발생할 수 있는가'는 충분히 설명할 수 있습니다.

작성법입니다. 엔지니어가 아니더라도 회사의 리스크와 무엇을 확인해야 하는지 이해할 수 있도록, 비유를 들어 핵심 내용을 전달합니다. 정확한 기술 용어는 [전문가용]로 구분하여 별도로 제시하므로, 엔지니어가 아닌 분은 해당 부분을 건너뛰셔도 무방합니다.

## 이 글에서 알 수 있는 점

- 두 가지 결함이 각각 구체적으로 어디에서 발생하는지 (비유를 통해)
- 왜 '로그인 없음'으로, 게다가 '비약적으로 위험한' 것이냐
- 성공했을 때 어떤 일이 벌어질까 (피해의 연쇄를 7 단계로)
- 경영 및 관리자로서 현장에 무엇을 물어봐야 하는가
- 보수자의 확인 사항 (＋종말에 용어 미니사전)

## 먼저, 두 가지 취약점의 본질 (예시로 설명하면) 을

어려운 두 가지 문제지만 그 근원은 동일하며, 한 줄로 요약하면 '후속 정리 실패'입니다. PHP라는 '조리장'이 작업 중 발생한 사고의 후속 정리를 잘못 처리하여 파손된 재료나 이전 손님들의 먹다 남은 음식을 다음 요리로 사용해 버리는 것입니다. 바로 그 점을 공격합니다.

[전문가용] PHP 공식 문서에서는 Producer/Consumer 패턴을 두 가지로 구분하며, 둘 다 부적절한 상태 관리로 인한 Use After Free 취약점으로 설명하고 있습니다 (GMO Flatt Security).

### 위험한 부분 1: CVE-2026-109618(작업의 "강제 중단" 후 처리)

요리 준비 중 작업대 (메모리) 가 가득 차 강제 종료 메시지가 발생하면 PHP 는 이 작업 중단을 중단하고 되돌립니다. 그러나 버려진 불완전한 상태를 '완벽하게 완성된 결과'로 처리해 버리는 경우가 있는데, 이것이 첫 번째 결함입니다. 공격자는 의도적으로 이러한 '강제 종료'를 유발하여 틈을 만듭니다.

그리고 이 복원 메커니즘은 십여 년 전 (PHP 5.2~5.4 시대) 에부터 크게 변하지 않았다고 합니다. 즉, 오래된 미끼입니다. 오래된 PHP 가 더 위험한 이유는 바로 이 때문입니다.

전문가용입니다. OOM 발생 시 bailout(longjmp) 으로 중단된 경우, 완료되지 않은 힙 상태가 정상 처리되어 해제되어 힙 오염이 발생할 수 있다는 지적입니다 (GMO Flatt Security).

### 위험한 부분 2: CVE-2026-109619(“이전 고객의 영수증”이 남아있음)

PHP 는 한 명의 담당자 (워커) 가 고객을 차례로 처리합니다. 문제는 이전 고객을 위해 사용했던 내부 메모가 정리된 것처럼 책상 위에 남아있다가, 다음 고객을 처리할 때 이를 다시 사용한다는 점입니다. 이것이 두 번째 결함입니다.

이 '잔류성' 대표가 파일 업로드 진행 상황을 표시하는 기능을 의미합니다. 많은 사람이 사용하지 않음에도 기본 설정에서 켜져 있는 상태입니다. 따라서 "우리에게는 상관없다"고 생각하더라도 대부분 켜져 있는 것입니다. 임시 조치로서 우선 이 기능을 끄는 것이 그 이유입니다.

[전문가용] Session 업로드 진행 상황 (ext/session) 은 알려진 Producer/Consumer 예시에서 기본값으로 활성화됩니다. 완화는 session.upload_progress.enabled=0 을 설정하는 것이지만, ini_set()/.user.ini 에서 작동하지 않으므로 php.ini 등으로 막아야 합니다 (이전 검증 기사에서 실연).

## なぜ「桁違いに危ない」のか

기존 취약점 설명보다 더 중요한 것은, 이 취약점이 실제로 발현되기 위한 조건입니다.

- 로그인 없이도 실행됩니다: 아이디와 비밀번호 없이도 외부 공격자가 서버에서 자신의 프로그램을 실행할 수 있습니다 (즉, 원격 코드 실행, RCE). 문호에 잠금을 걸어도 무관합니다.
- 앱 코드가 실행되기 전에 발생할 수 있는 위험: PHP 는 사이트의 본체 (WordPress 나 Laravel 등) 가 실행되기 전에 도착한 요청을 일단 처리합니다. 따라서 "로그인 화면만 표시되는" 사이트도 위험할 수 있습니다. 특히 웹 서버에 PHP 를 직접 연결하는 방식인 mod_php 는 가장 위험하다고 평가받습니다. 이는 바로 이 "사전 처리" 단계에서 문제가 발생할 수 있기 때문입니다.
- 웹에서 실행되는 PHP 는 거의 모든 경우에 해당하며, 실행 방식 (PHP-FPM, mod_php 등) 을 막론하고 영향을 미칩니다. 연구자들의 검증에 따르면 WordPress, Laravel, Symfony 와 같은 주요 프레임워크에서도 재현되었다고 합니다.
- WAF 만으로는 방어할 수 없습니다: WAF(=불법 통신을 걸러내는 '문지기') 의 표준 규칙만으로는 부족하며, Cloudflare 는 전용 방어를 추가했습니다. 공식 자료에서도 "설정 변경은 모두 부분적이며, 완전한 대응은 업데이트 하나뿐이다"고 명시하고 있습니다.

약간만 들여다보면——공격을 성공시키려면 먼저 메모리의'주소'를 살짝 훑어보는 과정이 필요합니다. 이를 통해 메모리 저장 위치를 매번 무작위로 변경하는 방어 기제인 ASLR 을 우회합니다. '약간의 정보를 유출시키고, 그다음 메모리를 파괴하여 코드를 실행한다'——이것이 전체적인 그림입니다 (GMO Flatt Security).

〔용어〕RCE = 원격으로 임의의 프로그램을 실행할 수 있는 가장 치명적인 취약점. ASLR = 메모리 배치를 매번 변경하여 공격을 어렵게 만드는 OS 방어 기제. WAF = 웹에 대한 악의적 접근을 감지하고 차단하는 시스템.

## 그렇다면 어떤 일이 벌어질 수 있는가 (피해의 연쇄)

이 부분이 본론입니다. 공격자의 프로그램은 "웹 서버를 실행 중인 권한이 약한 작업 계정"(기술적으로는 www-data 라고 불립니다) 으로 실행됩니다. "관리자가 아니면 큰일이 없다"고 생각하기 쉽지만, 그 서버가 다루는 모든 것이 그 약한 권한으로도 접근해버리는 것이 현실입니다. 빌의 청소원이 합동 열쇠를 가지고 있음에도 불구하고 실제로 많은 방을 열 수 있다는 식으로 생각하시면 됩니다. 무엇이 가능해지는지 단계별로 나열해 보겠습니다.

- 자신의 프로그램을 실행하게 하는 것: 공격자의 코드가 서버에서 실행되기 시작합니다. 모든 시작점이 되는 것입니다.
- “裏口”を置かれて居座られる：いつでも遠隔操作できる小さな裏口（Webシェル＝外部からコマンドを送れる不正なプログラム）を仕込まれます。
- 정보 유출: 설정 파일에 기록된 데이터베이스 연결 정보, 저장된 개인정보, API 키·토큰, 비밀번호. 또한 이 취약점은 메모리에 남아있는 다른 사용자의 접근 데이터까지 유출될 수 있는 특성을 지니고 있어, 비밀 정보 유출에 특히 경계해야 합니다.
- 좌석 점유를 고정 (영속화) 하는 것: 갱신으로 빈 공간을 막아도, 먼저 설치된 장치는 남아있는 것이 두려운 점입니다. 대표적인 방법은 전체 페이지의 첫 부분에 자신의 코드를 삽입하는 설정, 정기 실행 등록 (cron), 서버에 "합의 키" 추가 (SSH 키), 그리고 은밀하게 새로 생성하는 사용자입니다.
- 가로로 확산되는 (수평 확장): 해당 서버가 보유한 클라우드 운영 권한,社内 네트워크, 또는 동일 서버에 호스팅된 다른 사이트로의 침입이 퍼집니다. 도미노의 첫 장이 전체를 무너뜨립니다.
- 금전 피해 및 협박으로 이어질 수 있습니다: 도난당한 ID 와 비밀번호는 그 이후의 서비스에서 악용됩니다. 같은 주에 GMO 인터넷 (오네이름.com 데스크톱 클라우드) 의 외환 거래용 서버에서 저장된 계좌 로그인 정보가 탈취되어 불법 거래 발생 및 공격자로부터의 금전 요구 및 협박 사건이 발생했습니다 (※ 이 사고의 원인은 php2shell 이라고 공식 발표되지 않았습니다. 이는 단순히 '서버 침입 + 저장된 인증 정보 유출'이 어떤 결과를 초래하는지를 보여주는 사례일 뿐입니다).
- 변조 및 발판에 이용당하다: 사이트가 변조되거나 (과거에는 PHP 취약점으로 인해 파일이 변조되어 검색 결과에 위법한 페이지가 섞이는手法＝이 경우 SEO poisoning 에 악용된 사례도 있음), 타인을 공격하기 위한 '중계점'으로 이용된다.

첫 번째 단락을 통과만 하면 2~7 단락은 '시간의 문제'가 될 수 있다는 것이죠. 이것이 전 세계 조직들이 '패치가 나오기 전에 먼저 서비스를 중단한다'고 판단한 이유라고 생각합니다.

## 가장 최악의 시나리오: 실제로 어디까지 갈지

추상적인 7 단계를 하나의 '그림'으로 그려보겠습니다. 이는 발생할 수 있는 최악의 흐름일 뿐이며, 공격의 방식이 아닙니다.

> 
> 
> 深夜, 로그인도 하지 않은 외부에서 공개 중인 쇼핑몰에 한 통의 접속 요청이 도착한다. 로그인 화면 바로 앞에, PHP 가 이를 처리하는 순간 공격자의 코드가 실행된다. 몇 초 만에 작은 뒷문이 설치되어 언제든지 들어갈 수 있는 상태가 된다. 공격자는 config.php 를 읽어 고객 데이터베이스의 연결 정보를 얻고, 회원 정보를 모두 복사한다.顺便에 메모리에 남아 있던 다른 이용자의 결제 토큰도 가져간다. .user.ini 에 흔적을 남기고, 사이트를 업데이트해도 계속 머무르게 만든다. 또한 그 서버가 보유한 클라우드 키로 백업 저장소와社内 다른 시스템까지 가로막는다. 며칠 후 "공개하고 싶지 않다면 돈을 지불하라"는 협박 메일이 도착한다. 회사가 깨달은 것은 고객들이 "내가 알지 못하는 청구가 있다"는 문의가 급격히 늘어나기 시작한 때부터였다.
> 

과장된 것처럼 들릴 수 있지만, 첫 단계 (코드 실행) 만 통과하면 나머지는 모두 '그 이후'로 이어집니다. 따라서 전 세계의 조직들은 패치가 나올 전에 '일단 멈춤'을 선택했습니다. 그 이유는 최악의 상황을 이미 알고 있었기 때문입니다.

그리고 여기서 유효한 것은 바로 '권한의 약함은 방어에 도움이 되지 않는다'는 사실입니다. 진입점은 www-data라는 약한 권한으로 설정되어 있지만, 그 서버가 처리하는 데이터, 키, 연결은 모두 그 약한 권한으로 접근해버립니다. '진입점의 작음'과 '피해의 규모'는 비례하지 않습니다.

■ 기술적 세부사항을 더 알고 싶은 분들을 위한 안내 (전문가용 진입로)

이 공격은 '메모리 파괴' 계열입니다. 성공을 위한 절차는 대략 다음과 같습니다: ① ASLR(메모리 배치의 랜덤화) 을 우회하기 위해 주소를 일부 누설함 → ② 힙(작업용 메모리) 을 표적으로 파괴함 → ③ 실행 흐름을 가로채는 것입니다. 단일 실행에서는 불안정하므로, 첫 번째 '정보 유출'이 핵심입니다. 심층 분석을 위한 1 차 자료는 PHP 공식 GHSA(GitHub 애드바이저리), watchTowr 의 FAQ, GMO Flatt Security 의 설명입니다. 키워드는 Producer/Consumer, longjmp 의 bailout, Session Upload Progress 입니다. 이 내용을 추적하면 두 가지 사례가 왜 '정리 작업 실패(Use After Free)'로 귀결되는지 명확해집니다.

## 경영 및 관리자의 관점: 이 내용은 '사업'의 어떤 부분에 적용되는가

기술에 대한 이야기를 사업 리스크로 번역하겠습니다. 이번 실제 피해는 크게 두 가지 형태로 나타납니다.

- 중단 행위 자체가 손실입니다. 국내에서는 예방 차원에서 246 개 이상의 조직이 서비스를 중단했습니다. EC(전자상거래)에서는 매출 기회, SaaS(서비스형 소프트웨어)에서는 신뢰를 잃게 됩니다. '공격받지 않아도' 사업은 멈출 수 있습니다. 이것이 이번에는 가장 많이 발생한 '실질적 피해'입니다.
- 정보 유출 시의 배상과 신뢰 붕괴: 고객 정보나 인증 정보가 유출되면 통지, 배상, 조사 비용이 발생하며 브랜드 이미지에 lasting damage 가 남게 됩니다. GMO 사례는 위로금과 불법 거래에 대한 배상까지 확대되었습니다.

경영 관점에서 반드시 고려해야 할 점은 하나뿐입니다. 패치를 적용한다고 해서 안심할 수 없다는 것입니다. 업데이트는 1 단계만 막는 것일 뿐, 이미 침투한 경우의 '거주' (4 단계) 는 그대로 남기 때문입니다. 따라서 업데이트와 동시에 '침입 여부 조사', '키 재발급', '로그 보존'까지 일괄적으로 고려해야 합니다.

현장 (QSI, 개발, 벤더) 에서는 이 세 가지를 물어보세요.

- 우리 PHP 가 실제로 업데이트되었는지, 웹에서 사용 중인 것도 재시작했는지 확인했나요? (많은 경우 '업데이트했다'고 생각했습니다.)
- 표출 전인 10 월 17 일 이후, 침입 흔적을 조사하고 로그를 보존했습니까?
- 잘못된 전제 조건으로 비밀번호나 API 키를 재발급하셨나요?

이 세 가지에 대해 즉시 답변할 수 있는 능력이 곧 준비의 성숙도를 결정합니다.

## 안전한 범위 내에서 손에서 재현해 보았습니다.

어디가 위험하고 무엇을 당할지 무해한 범위 내에서 직접 구현했습니다. 취약점 자체를 타격하는 공격 코드는 작성하지 않았으며, 모두 로컬 가짜 값으로 구성되었습니다. 이전 검증 환경(포터블 PHP)을 그대로 사용했습니다.

위험한 기본값이 실제로 활성화되어 있었습니다.

CVE-2026-109619 의 취약점과 관련된 세션 업로드 진행 상태가 기본 설정에서 활성화되어 있는지 확인했습니다.

「우치는 사용하지 않는다」と 생각하더라도, 이미 설정되어 유효합니다. 임시 조치로서 가장 먼저 0 으로 설정하는 이유는 바로 이 때문입니다.

② 악용되는 '에러 처리'는 분명히 존재하며 실제로 발생한다.

CVE-2026-109618 가 공격하는 것은 메모리 부족 (OOM) 발생 시 실행이 중단되는 회피 처리 (bailout) 입니다. 메모리를 의도적으로 모두 사용하여 해당 처리가 발생하도록 테스트했습니다 (이는 일반적인 OOM 으로, 공격이 아닙니다).

이러한 '강제로 중간에 되돌리는' 기능의 취약점을 악용한 것이 첫 번째 결함입니다. 해당 기능은 이미 십여 년 전부터 존재했습니다.

③ "좌석 점유"의 수법: 전 페이지에 자신의 코드가 삽입됨

피해의 연쇄 4 단계 (영속화) 의 auto_prepend_file 를 무해한 마커로 재현했습니다. 로컬 서버를 구축하여 모든 요청의 시작 부분에 마커 코드를 삽입합니다.

어떤 페이지를 열어도 맨 앞에 공격자의 코드가 실행됩니다. 이것이 '업데이트해도 잔존하지 않는' 현상의 본질입니다. 이전 검증 4 에서 .user.ini 의 auto_prepend_file 를 찾은 것도 바로 이 현상을 찾기 위함이었습니다.

④ 코드가 작동하면 비밀 정보는 이 근처에 있습니다.

피해의 연쇄 3 단계 (정보 탈취). 코드가 웹 서버 권한으로 실행되면 해당 위치의 설정 파일에 접근할 수 있습니다 (모든 값은 가짜입니다).

「www-data 수준의 권한」이더라도, 데이터베이스 연결 정보나 API 키도 바로 옆에 있습니다. 이것이 키를 다시 발급해야 하는 이유입니다.

## 따라서 보호해야 할 대상이 확인해야 할 사항

완료해버린 일의 반전, 확인해야 할 부분입니다. 이전 검증 기사 (실제로 직접 수행) 과 그대로 대응합니다.

- 1~2 단계를 방지하기 위해 먼저 업데이트 (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) 를 적용했습니다. 웹 서버가 실제로 사용하는 PHP 버전을 확인한 후 모든 워커를 재시작했습니다.
- 3 단계: config.php 와 같은 비밀 정보는 누설된 것으로 가정하고 비밀번호나 키를 재발급합니다.
- 4 번째 단어를 찾아보세요: .user.ini 의 auto_prepend_file, cron, SSH 의 authorized_keys, 알 수 없는 신규 사용자.
- 5 단계: 해당 서버의 클라우드 권한을 재검토하여 불필요한 경우 축소합니다.
- 전체: 10 월 20 일 (UTC) 이후 로그를 보존합니다. 공격은 10 월 17 일 (공표 4 일 전)부터 관측되었습니다 (아마존).

10 월 24 일 PHP 는 또 다른 취약점인 CVE-2026-115560 을 공개했습니다 (수정 버전에서도 미해결이며, 다음 정기 릴리스에서 대응 예정으로, 발생 조건은 제한적입니다). 임시 대응책은 php2shell 과 동일하게 session.upload_progress.enabled=0 으로 설정하는 것이며, 이미 해당 설정이 비활성화되어 있다면 추가 작업이 불필요합니다.

## 저의 생각

이 취약점의 가장 우려스러운 점은 'www-data 정도의 권한'으로 시작하지만 그 깊이가 매우 깊다는 것입니다. 입구가 작아도 그 안에는 데이터베이스, 저장된 키, 클라우드 권한, 그리고 함께 호스팅되는 다른 사이트까지 모두 연결되어 있습니다.

반대로 말하면, 방어측의 대응책도 '연결'의 관점에서 접근할 수 있습니다. ① 올바른 PHP 를 업데이트한다 → ② 누락된 가정으로 인해 잠금 장치를 교체한다 → ③ 자리를 지키는 존재를 찾는다 → ④ 수평적 연결을 단절한다. 이 일련의 흐름입니다. 앞서 요약 기사에서 언급한 '어디에서, 무엇이 움직이는지 목록'은 이 네 가지 모두의 기반이 됩니다.

모든 서버가 첫 단계를 통과하더라도 두 번째 단계부터는 진행되지 않도록 대비책을 마련해 두셨나요?

## 용어 미니사전

이 글에 등장한 용어들을 정리해 보겠습니다. 이 부분만 읽어도 뉴스 이해도가 한 단계 깊어집니다.

- RCE(리모트 코드 실행): 외부 공격자가 서버에서 자신의 프로그램을 실행할 수 있게 되는 가장 치명적인 취약점.
- 웹 서버를 실행하는 권한을 제한한 작업용 계정입니다. 권한은 낮지만 사이트의 데이터나 설정에는 접근할 수 있습니다.
- 웹 쉘: 공격자가 숨겨두는 '비밀문'. 외부에서 명령을 보내 서버를 원격으로 조작하는 불법 프로그램입니다.
- 영속화: 한 번 침투한 공격자가 쫓아내지 않도록 잔여물을 남기는 기술입니다. 갱신해도 사라지지 않는 점이 귀찮습니다.
- auto_prepend_file: 전체 페이지 처리 전 지정된 PHP 코드를 자동으로 삽입하는 설정입니다. 본래는 유용한 기능이나, 영속화 악용에 이용될 수 있습니다.
- mod_php / PHP-FPM: PHP 를 실행하는 방식의 이름입니다. mod_php 는 오래된 직접 연결 방식이며, 이번에는 가장 위험하다고 평가되었습니다.
- WAF: 웹에 대한 비정상 통신을 감지하고 차단하는 '문지기'입니다. 다만 이번에는 표준 규칙만으로는 막을 수 없습니다.
- ASLR: 메모리의 위치를 매번 랜덤하게 변경하여 공격을 받기 어렵게 만드는 OS 방어 기제입니다.
- SEO 포이즈닝: 변조된 사이트를 이용해 검색 결과에 위조 페이지를 섞어 넣는 기법.
- 사용 후 방해 (Use After Free) : 이미 사용하지 않을 것으로 예상되는 메모리를 실수로 계속 사용함으로써 발생하는 오류. 이번 2 건의 근본 원인.

## 출처

- PHP 공식 보안 업데이트 (2026 년 10 월 21 일)

죄송합니다만, 제공해주신 URL(https://www.php.net/archive/2026.php)은 아직 존재하지 않거나 접근할 수 없는 링크이며, 요청하신 'note.com' 게시글의 본문 청크 96/104 와 관련된 실제 콘텐츠가 없습니다. 따라서 번역을 수행할 수 없습니다. 올바른 링크와 텍스트를 제공해 주시면 즉시 번역해 드리겠습니다.

- GMO Flatt 보안「PHP 의 중대한 취약점『php2shell』의 개요 및 대응 방안」

PHP2Shell 은 PHP 코드를 실행할 수 있는 명령어 행 (shell) 을 생성하는 라이브러리입니다.

- watchTowr「PHP 원격 코드 실행 FAQ: CVE-2026-109618」

죄송합니다. 제공된 URL(https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) 은 실제 존재하지 않는 페이지이며, 요청하신 'note.com' 게시글의 본문 청크 100/104 에 대한 구체적인 내용이 포함되어 있지 않습니다. 따라서 번역을 수행할 수 없습니다. 만약 해당 게시글의 텍스트 내용을 직접 입력해 주시거나, 실제 존재하는 다른 URL 을 알려주신다면 즉시 번역해 드리겠습니다.

- 아마존 위협 지능 (공표 4 일 전 악용 시도)

MadPot 에서 공개되기 전에 PHP2Shell 을 이용한 공격이 탐지되었습니다.

- 이전: 요약 https://note.com/gucchi123/n/n4712af8da298 ／ 검증 https://note.com/gucchi123/n/n0fdce559a663

※ 2026 년 10 월 24 일 기준 공개된 정보를 바탕으로 한 작동 원리와 영향에 대한 설명입니다. 공격 절차 및 실행 코드는 포함하지 않습니다. GMO 인터넷의 사고는 원인이 php2shell 이라는 것이 공식 발표되지 않았으며, 본 글에서는 이를 '다른 사건'으로 다루고 있습니다.

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

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

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