# PHP2Shell 가 드러낸 것――AI 가 찾아내는 속도에 우리는 추격할 수 있을까

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

---

※본 기사는 2026 년 10 월 23 일 현재 확인된 공개 정보를 바탕으로 작성되었습니다. 공격 관측 현황 및 각 기업의 대응은 이후에도 업데이트될 수 있습니다.

## 웹의「기반」에서 발견된 두 가지 취약점

2026 년 10 월 21 일, PHP 개발 팀은 인증 없이 원격으로 코드를 실행할 수 있는 두 가지 중대한 취약점을 수정했습니다. CVE-2026-109618 과 CVE-2026-109619 로, 이 두 취약점을 합쳐 'PHP2Shell'이라고 불리며, 심각도를 나타내는 CVSS v4.0 점수는 모두 9.2 입니다. [1][2][3]

영향은 오래된 PHP 버전에만 국한되지 않습니다. 연구자들은 PHP 5.4 를 포함하여 광범위한 버전들이 적어도 하나의 문제의 영향을 받았다고 지적하고 있습니다.[4]

PHP 는 워드프레스나 드루팔, 미디어위키 등을 구동하는 기반입니다. W3Techs 의 2021 년 10 월 21 일 발표 통계에 따르면, 서버 측 프로그래밍 언어를 확인할 수 있는 웹사이트 중 약 69% 가 PHP 를 사용하고 있습니다. [4][5]

다만, 이는 '세계 웹사이트의 약 70% 가 침입당했다'는 의미는 아닙니다. 사용률과 피해 건수, 취약점의 존재와 공격 성공률은 각각 별개의 문제입니다.

이번 문제의 심각성은 특정 플러그인이나 앱이 아니라 그 아래에서 작동하는 PHP 자체에 결함이 있었기 때문입니다. 우리 코드를 세심하게 작성하더라도 그 기반이 완전히 안전하다고 보장할 수 없습니다.

또한 발견 과정에서 AI 가 활용되었고, 수정판 공개 전까지 정보가 유출되었습니다. 이는 오랜 기간 쌓아온 설계상의 문제와 AI 로 인해 변화하기 시작한攻防의 속도가 교차한 사건이라고 생각합니다.

## 발견부터 공개까지, 어떤 일이 일어났는지

Calif 과 Wiz 는 각각 AI 를 활용한 조사 과정을 공개했습니다. 아래는 두 회사의 보고서 등을 바탕으로 정리된 주요 흐름입니다. 또한 Wiz 의 수령 확인 날짜만 보고 PHP 측이 그 때까지 수정 작업을 시작하지 않았다고 해석할 수는 없습니다. [4][6][7]

2026 년 주요 사건: 8 월 상순, Calif 가 PHP 취약점 조사를 진행하며 여러 공격 경로를 발견했습니다. 8 월 11~21 일, Calif 가 두 가지 문제를 순차적으로 보고했습니다. 14 일 공격 실증 코드를 공유하고, 15 일 PHP 측이 동작을 확인했습니다. 8 월 19~24 일, Wiz 가 독립적인 조사로 문제를 발견하여 24 일 PHP 에게 보고했습니다. 조사에는 Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol 이 사용되었습니다. 9 월 21 일, Wiz 의 시간 순서 기록에 따르면 PHP 측이该公司的 보고를 확인하고 조정된 수정 코드의 개발을 시작했습니다. 10 월 17 일, AWS 가 후속 보고서에서 이날의 해니퐏트 기록에 악용 시도가 있었다고 공표했습니다. 10 월 20 일, 정보 유출이 공개 전 발생했습니다. PHP 측이 다음 날인 21 일 긴급 릴리스를 예고했습니다. 10 월 21 일, PHP 8.5.12/8.4.27/8.3.36/8.2.35 와 기술 정보를 공개했습니다. 10 월 22 일, 중국의 사이버보안국 (CSIRT) 이 업데이트를 촉구하는 성명을 발표했습니다. 네덜란드의 Logius 는 일시 정지된 웹사이트 복귀를 발표했습니다.

출처: [1][4][6][8][11][12][13]

### 파손된 것은 메모리 부족이나 오류를 처리하는 메커니즘입니다.

첫 번째 CVE-2026-109618 은 메모리 부족 대응과 관련된 문제입니다. 내부 데이터를 생성하는 과정에서 처리가 중단되면, 후속 정리 작업이 아직 완료되지 않은 데이터를 정상적인 것으로 간주할 수 있습니다. [2]

두 번째 CVE-2026-109619 의 경우, 특정 요청에서 사용된 메모리를 해제한 후에도 해당 메모리를 지칭하는 내부 상태가 남아있을 수 있으며, 동일한 워커가 다음 요청을 처리할 때 해제된 메모리를 참조하는 문제가 발생할 수 있습니다. [3]

여기서 주의해야 할 점은 모든 실행 환경에서 동일한 공격이 유효하지는 않는다는 점입니다.

PHP 공식은 웹 요청을 처리하는 PHP-FPM, Apache 의 mod_php, php-cgi, LiteSpeed, FrankenPHP 등을 포괄적으로 확인 대상으로 제시하고 있습니다. 반면, 특히 위험도가 높은 것으로 평가되는 것은 mod_php이며, 애플리케이션 코드가 실행되기 전에 공격이 성공할 수 있는 경로가 입증되었습니다.[1]

PHP-FPM 에 관해서는 공식 자문단이 일부 실행 시 공격 경로를 우회하는 동작을 설명하고 있습니다. 반면 PHP Foundation 은 애플리케이션 내 처리 경로를 통한 원격 코드 실행 (RCE) 이 확인되었다고 밝혔습니다. "FPM 이라 해서 안전하다"거나 "모든 환경이 동일한 조건으로 공격받는다고" 할 수 없습니다. [2][7]

### 공개 전 악용은 어디까지 인지하고 있는가

AWS 는 10 월 17 일 MadPot 의 관측 기록에 PHP2Shell 의 악용을 시도한 통신이 있었다고 공표했습니다. 공격 정보를 어떻게 획득했는지는 아직 밝혀지지 않았습니다. [8]

워치타워는 21 일 이후의 하니포트에서의 악용 사례를 보고했으며, 클라우드플레어는 고객들을 표적으로 한 공격 통신과 방어 회피를 위한 페이로드의 변화를 확인했다고 설명했습니다. [9][10]

다만, 공격 통신이나 악용 시도를 관측한 것과 실제 환경에서 침입에 성공한 것은 동일하지 않습니다. 공개된 정보만으로는 피해의 전체 양상이나 침입 성공 건수를 파악할 수 없습니다.

수정된 조사에서도 공개일 이후의 로그만 확인한다고 해서 충분하지는 않습니다. 이는 AWS 보고서에서 얻은 실무적으로 중요한 시사점입니다.

## 가장 어려운 것은 PHP 가 어디에서 실행되고 있는지 파악하는 것입니다.

### 표면에서 보이지 않는 PHP 찾기

대만 정보통신보안국은 명시적으로 PHP 를 사용하지 않는 소프트웨어라도 내부에서 PHP 가 실행될 수 있다는 점을 경고하고 있습니다. [11]

확인해야 할 대상은 본사 웹사이트뿐만 아니라 관리용 도구,社内 시스템, 또는 구매한 제품에 내장된 실행 환경 등도 포함됩니다. 제품명만 나열된 목록에서는 그 안에 포함된 PHP 가 발견되지 않을 수도 있습니다.

주 시스템이 Java 이라 무관하다고 단정하기 전에 주변 관리 화면, 보조 도구, 컨테이너도 확인해야 합니다.

### 지원 종료 버전에는 동일한 업데이트 경로를 제공하지 않습니다.

PHP 8.1 이전에는 공식 지원이 종료되었습니다. 다만 이번에는 PHP 측에서 예외적으로 7.4, 8.0, 8.1 을 위한 최소한의 소스 코드 수정을 제공했습니다. 배포판이나 LTS 벤더에서 수정 패키지가 있는 경우도 있습니다. [1][9]

따라서 "구형 PHP 에는 어떤 수정도 없다"는 설명은 정확하지 않으며, 이를 이유로 구형 환경에 계속 머물러도 되는 것도 아닙니다. 현재 사용하고 있는 제공업체에 수정 현황을 확인하고, 지원 중인 버전으로 전환해야 합니다.

과거에는 무사히 운영되던 시스템도 갑자기 유지보수 기한이 도래합니다. 이번과 같은 취약점은 미뤄온 업데이트 작업을 긴급 대응으로 강요합니다.

### 앱을 업데이트해도 토대가 바로잡히지 않습니다.

WordPress 자체나 플러그인을 최신 버전으로 업데이트하더라도 PHP 자체의 수정을 대체할 수는 없습니다. 특히 애플리케이션 실행 전 단계에서 발생하는 공격을 애플리케이션 내부 처리만으로 방어하는 것은 매우 어렵습니다.

WAF 를 통해 일부 공격 경로는 차단될 수 있으나, 이는 영구적인 해결책이 아닙니다. Cloudflare 역시 방어 기능을 활용하더라도 PHP 수정이 필요하다고 설명하고 있습니다.[10]

### 「更新した」と「稼働環境に反映した」は違う

컨테이너에서는 호스트 측의 PHP 만 업데이트하더라도 실행 중인 이미지 내부 구성은 변경되지 않습니다.

Google Cloud 는 자체 이미지 등을 사용하는 Cloud Run 과 GKE 에 대해 수정된 PHP 를 포함한 이미지에 대한 업데이트 및 재 배포 방법을 안내하고 있습니다. 또한 자동 업데이트 대상이 되는 환경도 있으며, 필요한 작업은 서비스와 설정에 따라 다릅니다. [12]

업데이트 후에는 PHP 워커의 재시작이 필요합니다. [9]

패키지를 가져온 것만으로는 안심할 수 없으며, 실제로 요청을 처리하는 프로세스까지 수정이 반영되었는지 확인해야 합니다. 이 확인까지가 대응입니다.

## PHP 를 사용하지 않는 서비스에도 영향을 미칩니다. 다만, 이를 별개의 관점에서 고려해야 합니다.

PHP 서버가 침해당하면 저장된 인증 정보나 네트워크 연결을 악용하여 피해가 다른 시스템으로 확산될 수 있습니다. Wiz 는 프로세스 메모리에서 비밀번호나 인증 토큰, API 키 등이 유출될 위험도 설명하고 있습니다. [4]

다만, 이는 예상되는 파급 경로에 관한 이야기입니다. 현재 PHP 를 제외한 시스템으로 실제로 피해가 얼마나 확산되었는지를 보여주는 통계는 확인되지 않았습니다.

예방적 중단 역시 동일합니다. 네덜란드의 로기우스는 10 월 21 일 MijnOverheid.nl, Logius.nl, DigiD.nl 등의 웹사이트를 일시 중단한다고 발표했습니다. 다만 DigiD 앱과 그 뒤의 인증 서비스는 계속 사용 가능하다고 명시했습니다. [13]

웹사이트 정지를 인증 기반 전체 정지나 다른 서비스 장애로 간주해서는 안 됩니다. 안전 확보를 위한 정지와 공격으로 인한 피해는 명확히 구분해야 합니다.

## 이후에는 기술만으로 해결되지 않는 문제들입니다.

이번 사례를 PHP 언어의 평가만으로 마무리하는 것은 아쉽습니다. 제가 특히 궁금해한 것은 수정이 필요하다고 판단한 후 이를 결정하고, 보고하며, 적용하는 메커니즘입니다.

### 1. 보수주의에 필요한 것은 인력뿐만 아니라 결정할 수 있는 체제입니다.

PHP 재단은 2024 년과 관련하여 OOM 문제의 징후를 파악하고 있었음을 설명했습니다. 당시에는 구체적인 공격 경로를 파악할 수 없었으며, 수정안에는 호환성 파괴, 새로운 서비스 방해 위험, 확장 기능에 대한 영향 등 여러 단점이 있었습니다. 재단은 지연의 원인으로 의사결정 체계와 자원 부족이라는 두 가지 요인을 인정했습니다. [7]

예산이 있다면 바로 고칠 수 있고, 개발자가 게을렀다고 단순화하면 핵심 부분을 놓치게 됩니다. 여러 불완전한 선택지 중에서 누가, 언제, 어떤 리스크를 감수하며 결정을 내릴 것인가. 그 메커니즘까지 포함하여 유지보수를 뒷받침해야 합니다.

많은 기업이 의존하는 기반이라면, 이를 소수의 전문가에게 맡겨 유지하는 방식은 취하지 않습니다. 지속적인 자금과 판단을 감당할 수 있는 조직이 모두 필요합니다.

### 2. AI 는 발견 속도를 높인다. 그 이후의 작업은 자동화만으로 끝난다.

Wiz 는 과거에는 증명하기 매우 어려웠던 공격 구성을 AI 가 현실적인 수준으로 만들었다고 설명합니다. [4]

다만, 칼리프의 보고서를 살펴보면 인간 연구자가 대상의 역사를 알고 가설을 세우고 AI 조사를 방향지시했다는 점도 알 수 있습니다. 아무것도 모른 채 짧은 지시를 내린다고 해서 모든 깊은 결함이 발견되는 것은 아닙니다. [6]

그럼에도 불구하고 공격 측이 동일하게 AI 를 사용할 수 있다면 수정 내용 공개 후 남은 시간은 단축될 수 있습니다. AWS 는 공개된 기술 정보와 수정 차분에서 공격을 구축하는 비용이 낮아졌고, 시간 단위로 대응해야 하는 상황으로 변해 있다고 지적했습니다. [8]

찾을 수 있는 능력이 향상될수록 검증, 수정, 배포, 적용에도 투자해야 합니다. 그렇지 않으면 발견된 사례 수는 늘어날 뿐, 이를 관리하는 쪽의 처리 능력이 따라가지 못하게 됩니다.

### 3. 조화로운 공개에는 '누설 가능성'을 고려해야 한다.

PHP Foundation 의 설명에 따르면, 정보 유출 이후 Calif 가 실증 동영상을 잘못 공개했고, Chainguard 가 합의된 공개 시간보다 먼저 수정된 이미지를 공개했습니다. 이 두 사건 모두 PHP Foundation 측의 설명으로 해석해야 하지만, 공개 전 조정 과정이 무너진 배경은 이미 공식적으로 밝혀졌습니다.[7]

반면, 배포자가 수정 버전을 준비하기 전에 정보만 공개하면 사용자는 위험을 인지할 수 있으나 즉시 업데이트를 할 수 없을 수도 있습니다.

관계자를 늘리면 배포 준비가 수월해지지만, 동시에 정보 관리의 접점이 늘어나는 모순이 발생합니다. 이러한 모순을 해결할 만능책은 없습니다. 따라서 누설이 발생했을 때 공개 시간을 어떻게 변경할지, 누가 결정할지까지 사전에 합의해야 한다고 생각합니다.

### 4. 파악되지 않은 항목은 갱신할 수 없습니다.

영국 NCSC 와 타이완의 정보통신보안국도 PHP 를 사용하는 시스템을 먼저 파악하도록 요청하고 있습니다.[11][14]

이것은 평범한 내용이지만 대응의 출발점입니다. 어떤 시스템에 어떤 실행 환경이 있고, 누가 업데이트를 담당하는지 명확히 해야 합니다. 이 부분을 모르면 긴급 알림이 들어와도 대응할 수 없습니다.

SBOM(소프트웨어 구성 요소 목록)과 자산 명부도 작성만으로는 부족하며, 운영 환경과 연계하고 담당자 및 업데이트 경로를 명확히 파악할 때 비로소 긴급 상황에서도 효과를 발휘합니다.

### 5. 안전에 멈출 수 있는 것 또한 운영의 힘입니다.

영국 NCSC 는 업데이트나 임시 대응책이間に合わない 경우, 완전한 대응이 가능할 때까지 시스템을 오프라인으로 전환할 것을 고려하도록 안내하고 있습니다.[14]

서비스 중단 결정에는 필연적으로 비용이 발생하지만, 중단 절차가 없거나 영향 범위를 파악할 수 없으며 결정을 내릴 사람이 없는 상황에서는 위험을 인지하더라도 계속 진행할 수밖에 없습니다.

일시 정지 판단 기준, 이용자 안내, 대안 마련, 복구 확인. 이러한 준비 사항들도 비즈니스 연속성 계획의 일부입니다. 멈추지 않고 움직이는 능력만큼이나, 필요한 순간에 안전하게 정지하는 능력도 중요하다고 생각합니다.

## 현재 필요한 조치

사용자 측면의 최우선 과제는 우리가 사용하는 PHP 버전과 그 수정 상태를 확인하는 것입니다. 공식 수정 릴리스는 8.5.12, 8.4.27, 8.3.36, 8.2.35 입니다. 디스트리뷰션 등의 수정 패키지를 사용할 때는 표시되는 상위 버전 번호만으로 판단하지 말고, 제공元の 안내서에서 수정 여부를 확인하시기 바랍니다. [1]

현재 상황을 확인하고 향후 대비책을 마련해야 합니다. 운영 및 보안 담당자는 외부 공개 시스템을 최우선으로 PHP 를 스캔하여 수정을 적용하고, 필요시 재시작 또는 재배포를 수행합니다. 침해 흔적을 조사하기 위해 운영 환경과 자산 명부를 연계하여 긴급 업데이트 소요 시간을 파악합니다. 경영 및 관리 담당자는 필요시 일시 정지를 결정할 수 있도록 지원합니다. 침해가 의심되는 경우 조사나 인증 정보 보호에 필요한 체계를 확립합니다. 지원 종료 제품의移行 예산을 확보하고, 정지 및 복구 결정 절차를 마련합니다. 개발자는 애플리케이션뿐만 아니라 실행 환경과 기본 이미지를 확인하며, CI 등을 통해 런타임 지원 기간과 의존 관계를 지속적으로 점검합니다. 기본 인프라를 제공하는 기업 및 플랫폼 제공자와의 책임 분담 및 업데이트 현황을 확인합니다. WAF 만으로 대응을 완료하지 말고, 중요한 오픈소스 유지보수와 다수 조직 간 공개 및 배포 체계를 지원해야 합니다.

위 표는 각 기관의 대응 안내를 바탕으로 작성자가 정리한 것입니다.

업데이트가 지연될 경우 공식 임시 대응책을 확인하고, 공개 범위 제한이나 일시 정지 여부까지 종합적으로 판단해야 합니다. 임시 대응책은 수정을 대체하여 무기한 지속되는 것이 아닙니다.

렌탈 서버나 매니지드 서비스를 사용하는 경우, 제공元の 안내에 따라 대응 현황과 사용자 측 작업을 확인하시기 바랍니다. 이는 사용자가 자체적으로 인프라를 업데이트할 수 없기 때문입니다.

## 발견의 끝까지 빠르게 도달할 수 있을까

AI 가 오랜 기간 사용된 코드에 숨겨진 문제를 발견할 수 있게 되면, 이는 안전성을 높이는 기회이기도 합니다.

하지만 발견만으로는 이용자의 서버가 안전해지지 않습니다. 수정 방안을 정하고, 동작을 검증한 뒤 배포처에 전달한 후 현장에서 적용할 때만 위험이 줄어듭니다.

이번 PHP2Shell 에서 묻는 것은, 해당 일련의 흐름을 탐지 속도에 맞춰 유연하게 조정할 수 있는지에 관한 것입니다.

다음 긴급 업데이트가 왔을 때, 우리가 어디를 수정해야 하는지 알 수 있을까요. 필요하면 멈출 수 있을까요. 그리고 수정되었는지 확인할 수 있을까요.

큰 뉴스를 읽은 뒤, 가장 먼저 집으로 가져가고 싶은 것은 이 세 가지 질문입니다.

## 참고 자료

본 문서의 번호는 다음 자료에 대응합니다. 연구 내용과 관측 결과는 각 발표 주체의 보고에 근거하였으며, 후반부의 운영 및 조직에 관한 제언은 저자의 고찰입니다.

- PHP 공식: 2026 년 10 월 21 일 보안 공지 및 수정 버전
- PHP 공식 자문위원회: CVE-2026-109618 (OOM 오류)
- PHP 공식 자문위원회: CVE-2026-109619(오래진 전역 상태)
- Wiz: PHP2Shell 조사 보고서
- W3Techs: PHP 사용 통계 (참고: 조회 시점의 수치는 변동할 수 있습니다)
- 칼리프 연구소: php2shell
- PHP Foundation: 수정의 배경과 보안 체계 강화
- AWS: 공개 전 PHP2Shell 악용 시도 관측
- watchTowr: PHP2Shell 자주 묻는 질문
- 클라우드flare: PHP2Shell 을 위한 WAF 대응 및 공격 관측
- 대만 정보통신보안국: PHP 긴급 업데이트에 대한 주의보
- Google Cloud: PHP 취약점 대응 및 재 배포 안내
- 로기우스: 예방 조치 이후 웹사이트 복구 및 DigiD 운영 현황
- 영국 NCSC: PHP 의 심각한 보안 취약점 대응

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

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

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