CISA는 10월 26일 PHP 취약점 CVE-2026-109618과 CVE-2026-109619을 알려진 악용 취약점(KEV) 목록에 추가했다. 미국 연방 민간 기관은 10월 29일까지 패치를 적용하고 침해 여부를 조사해야 한다. PHP 웹 서버를 운영하는 다른 조직도 먼저 증거를 보존한 뒤 업데이트와 재시작을 하고, 과거 침해 흔적을 확인해야 한다.

이 기사는 PHP2Shell 취약점에 관한 기존 글의 후속 글이다. 기존 글은 두 취약점의 작동 방식과 영향을 받는 SAPI, 설정 완화책을 다룬다. 이번 글은 KEV 등재의 의미와 패치 공개 5일 뒤 확인된 악용 증거를 정리한다. CVE-2026-109618 증거 자료에서 관련 기록을 확인할 수 있다.

CISA 등재 내용과 대응

  • CVE-2026-109618: PHP 메모리 손상 취약점(메모리 부족 상태에서 발생하는 손상, GHSA-w8hw-w9fx-j79w). 2026년 10월 26일 등재, 10월 29일 조치 기한. 포렌식 조사 필요, 랜섬웨어 사용 여부는 알 수 없음.
  • CVE-2026-109619: PHP 내부 요청 상태가 오래된 값으로 남는 취약점(GHSA-6wmf-4rv5-p3rp). 2026년 10월 26일 등재, 10월 29일 조치 기한. 포렌식 조사 필요, 랜섬웨어 사용 여부는 알 수 없음.

BOD 26-04에 따르면 ‘포렌식 조사 필요: 예’는 기관이 3일 안에 취약점을 해결하고 각 자산의 침해 여부도 평가해야 한다는 뜻이다. CISA는 같은 날 10월 21일 발표한 PHP 경보를 갱신했다. 업데이트할 수 없거나 PHP 8.1 이하를 계속 사용한다면 패치될 때까지 PHP 시스템을 오프라인으로 전환하라는 권고는 바뀌지 않았다. PHP가 다른 제품에 포함되는 경우가 많으므로, 직접 PHP를 설치한 서버만 목록화하면 일부 시스템을 놓칠 수 있다고 CISA는 경고했다.

PHP를 아래 수정 버전으로 올린 뒤 해당 PHP를 실행하는 모든 프로세스를 재시작해야 한다.

text
# Debian / Ubuntu sudo apt update && sudo apt install --only-upgrade 'php*' sudo systemctl restart apache2 'php*-fpm' # RHEL / Alma / Rocky / Fedora sudo dnf upgrade 'php*' && sudo systemctl restart httpd php-fpm # Containers: rebuild on the new base tag and redeploy docker build --pull -t my-app .

수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35다. 10월 17일 이후 패치되지 않은 빌드로 트래픽을 처리한 서버라면 조치 순서가 중요하다. 아마존이 보고한 가장 이른 공격 시도 시점은 10월 17일이다(SecurityHQ). CISA의 조사 지침은 패치 과정에서 휘발성 증거가 사라질 수 있으므로 업데이트 전에 수집하라고 권고한다. PHP 서버에서는 재시작으로 공격자가 실행한 셸과 자식 프로세스가 함께 종료될 수 있고, 재부팅하면 이번 공격에서 미라이(Mirai) 페이로드가 저장된 /tmp가 비워질 수 있다. 증거 수집에는 약 2분이 걸린다.

text
mkdir -p /root/p2s-triage && cd /root/p2s-triage ps -eo user,pid,ppid,lstart,cmd --forest > ps-forest.txt ss -tnp > sockets.txt ls -la --time-style=full-iso /tmp /var/tmp /dev/shm > tmp-listing.txt cp -a /var/log/apache2 /var/log/httpd /var/log/nginx /var/log/php* . 2>/dev/null php -v > php-version.txt

그런 다음 패치하고 재시작한 뒤, CLI뿐 아니라 웹 서버 자체가 수정된 버전을 보고하는지 확인해야 한다. 기존 글에는 작업자 프로세스가 구버전 바이너리를 계속 실행하는지 확인하는 PHP_VERSION 및 lsof 점검 방법이 있다.

패치 뒤 확인된 악용 증거

10월 24일 전까지 공개된 증거는 수백만 건의 공격 시도였고, 코드 실행이 확인된 사례는 없었다. 이후 퍼플렉시티 연구자 아델 카리미(Adel Karimi)는 10월 24일 허니팟 3대에서 아파치 작업자가 셸을 실행한 기록 35건을 확인했다. 해당 시스템은 mod_php를 사용하는 PHP 8.4.26을 실행했고, 두 IP 주소에서 메모리를 고갈시키고 유출한 다음 명령을 실행하는 4단계 요청이 들어왔다(SecurityWeek, BleepingComputer). 카리미는 이를 CVE-2026-109618과 연결했다. 다만 단일 작업자 구성은 공격자에게 유리하도록 의도적으로 설정했으므로, 사용량이 많은 작업자 풀에서 공격이 얼마나 안정적으로 성공하는지를 보여주는 결과는 아니다. 후속 명령은 id, curl, wget, php -r를 이용해 162.35.99[.]94에서 파일을 가져오려는 것이었으며, 2단계 페이로드는 내려받지 않았다.

봇넷도 공격을 시도하고 있다. 소포스는 미라이에서 파생된 디도스 봇 Potassium 설치 시도가 실패한 사례를 확인했다. 봇은 /tmp/nfs에 기록된 뒤 ./nfs php로 실행되려 했다(The Hacker News). SecurityHQ의 분석은 다운로드가 92.118.112[.]100에서 이뤄졌다고 추적했다.

CYFIRMA는 한국어를 사용하는 운영자들이 패치되지 않았거나 완화 조치가 일부만 적용된 호스트 216대를 대상으로 느리고 표적화된 스캔을 진행했다고 보고했다. 이들은 21개 노드를 번갈아 사용하며 스캔 속도를 제한 경보 기준 아래로 유지했다. CYFIRMA는 이 운영자들이 라자루스 생태계와 연관됐을 가능성을 중간 수준의 신뢰도로 평가했다(The Hacker News).

취약한 PHP가 포함된 제품도 공격 대상에 올라왔다. Defused Cyber는 Palo Alto GlobalProtect 허니팟에서 p2s-rider 표식이 담긴 업로드 진행률 요청을 확인했다. 요청은 204.76.203[.]7에서 왔다(같은 THN 보도). 이는 PHP가 다른 제품에 포함될 수 있다는 CISA의 경고와 맞닿아 있다.

공격 트래픽도 계속 늘고 있다. Delft Threat Intelligence Lab의 실시간 추적기는 10월 26일 23:25 UTC까지 IP 주소 627개에서 발생한 공격 요청 58,951건을 집계했다. 가장 바빴던 시간은 이날 14:00 UTC로, 요청 8,179건이 기록됐다.

10월 25일 업데이트를 정정한다. 당시 Unit 42의 보고를 인용해 유럽 정부 기관이 PHP2Shell을 통해 침해됐고 후속 작업에 AI 에이전트가 사용됐다고 전했다. 그러나 Unit 42는 10월 25일 해당 업데이트를 철회하면서 최초 접근이 이 CVE들과 관련 있다고 연결할 수 없다고 밝혔다. 기존 글에도 이 점을 표시했다.

서버 침해 여부 확인

접근 로그에는 요청 본문이 보통 저장되지 않으므로, 공격으로 생긴 부수 흔적을 찾아야 한다. ReliaQuest는 실험실에서 CVE-2026-109618을 재현했다. The Hacker News가 인용한 설명에 따르면, 확인할 흐름은 POST 요청의 500 응답, PHP의 메모리 고갈 및 힙 손상 기록, 이어지는 아파치 작업자 충돌이다. 각 호스트가 수정된 빌드로 재시작한 시점까지, 10월 17일부터의 기록을 검색한다.

text
# memory exhaustion and heap corruption from PHP grep -hE 'Allowed memory size|zend_mm_heap corrupted' /var/log/apache2/error.log* /var/log/php*fpm*.log* 2>/dev/null | head # Apache children dying mid-request grep -h 'Segmentation fault' /var/log/apache2/error.log* 2>/dev/null | head # clients sending POSTs that end in 500 (combined log format) awk '$6=="\"POST" && $9==500 {print $1}' /var/log/apache2/access.log* | sort | uniq -c | sort -rn | head # payload and callback addresses named in public reporting ls -la /tmp/nfs /var/tmp/nfs 2>/dev/null grep -rlE '162\.35\.99\.94|92\.118\.112\.100|204\.76\.203\.7' /var/log 2>/dev/null

처음 세 가지 검색 결과는 단서일 뿐 침해의 증거는 아니다. 작은 memory_limit 설정에서 큰 파일을 업로드해도 같은 기록이 남을 수 있다. 저장한 프로세스 목록에서 www-data 권한으로 실행된 셸이나 curl을 찾거나 /tmp/nfs 파일을 발견하면 침해로 봐야 한다. 업그레이드만으로는 침해가 되돌려지지 않는다. 웹 사용자 계정이 읽을 수 있었던 데이터베이스 비밀번호와 .env 및 환경 변수의 API 키를 모두 교체하고, 웹 루트에 새 .php 파일이 생겼는지 확인해야 한다. 해당 기간의 요청 로그나 프로세스 로그가 없다면 그 기간을 깨끗하다고 판단하지 말고, 확인되지 않은 기간으로 기록해야 한다.

적용 범위와 남은 불확실성

HTTP 요청을 처리하지 않는 PHP는 이번 취약점의 영향 범위에 들어가지 않는다. 두 보안 권고에서 다룬 요청 경로에는 크론 작업, 큐 작업자, CLI 스크립트가 포함되지 않으며, KEV 등재로 이 범위가 달라지지는 않는다.

패치되지 않은 빌드로 트래픽을 처리한 적이 없는 호스트도 과거 기록을 조사할 필요는 없다. 예를 들어 PHP 8.5.12, 8.4.27, 8.3.36 또는 8.2.35로 새로 구축한 서버는 업그레이드 여부를 확인하면 된다.

10월 29일 기한은 미국 연방 민간 기관에만 적용된다. 그 밖의 조직에 CISA가 제시한 법적 준수 기한은 아니지만, 실제 공격 증거가 충분하다는 판단을 보여주므로 대응을 서두를 이유가 된다.

KEV 등재는 공개된 피해자 명단이 아니다. CISA는 등재 근거를 공개하지 않으며 랜섬웨어 사용 여부도 ‘알 수 없음’으로 표시했다. 코드 실행을 보여주는 가장 강한 공개 증거는 여전히 연구용 허니팟에서 나온 것이다. 소포스도 성공적인 침해가 있었다는 초기 주장을 철회했다(Sophos). 다만 공격자들이 작동하는 공격 절차를 확보해 실제 호스트를 겨냥하고 있다는 점에서, 확인된 침해가 없다는 이유만으로 대응을 미룰 수는 없다.

참고 자료: