AI 에이전트로 php2shell을 6분 만에 패치한 방법

에이전트가 실행한 명령어와 권한 명령어가 허용된 이유, 직접 따라 할 수 있는 플랫폼별 수정 버전·재시작 확인·오리진 접근 제한.

PHP는 10월 21일에 php2shell이라 불리는 심각한 취약점 두 건을 수정했습니다. 이 취약점을 악용하면 인증되지 않은 요청으로 PHP 웹 서버에서 코드를 실행할 수 있습니다. PHP가 웹 요청을 처리하는 모든 방식이 영향을 받습니다. php.net은 Apache의 mod_php 환경을 가장 위험하다고 평가합니다. 이 환경에서는 입증된 공격이 애플리케이션 코드가 실행되기 전에 시작될 수 있습니다.

운영 환경에서 PHP를 쓰고 있다면 패키지 업그레이드만으로는 막히지 않습니다. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 또는 배포판의 백포트를 적용한 뒤 PHP 요청을 처리하는 서비스를 재시작해야 합니다. 저희는 10월 21일에 Cloudflare 뒤에 있는 Ubuntu 22.04 mod_php 호스트를 패치했습니다. 아래에서 플랫폼별 수정 버전과 사이트 요청을 처리하는 프로세스에 패치가 적용됐는지 확인하는 방법을 설명합니다. 오리진 접근 제한과 그 한계도 다룹니다. 패치는 Alpacon을 거쳐 작업하는 Claude Code에 맡겼습니다. 사람이 세션을 승인하고 6분 뒤, Apache는 이미 패치된 PHP로 요청을 처리하고 있었고 에이전트에게 root 권한을 넘기지도 않았습니다. 어떻게 했는지는 실행 과정을 다룬 절에서 보여 드립니다.

php2shell의 정체와 영향 범위

요약: php2shell은 심각한 PHP 취약점 두 건(CVE-2026-109618, CVE-2026-109619)을 가리킵니다. PHP가 웹 요청을 처리할 때 쓰는 모든 서버 API(SAPI)에서 인증 없이 원격 코드를 실행할 수 있습니다. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 또는 배포판의 백포트로 업데이트한 뒤 PHP를 재시작하세요.

php.net: "PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35에서는 인증 없이 원격 코드를 실행할 수 있는 심각한 취약점 두 건을 수정했습니다."

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): 메모리 부족 오류로 PHP가 처리를 중단하면 요청 데이터가 부분적으로만 초기화된 채 남을 수 있고, 종료 과정에서 PHP가 이 데이터를 읽습니다.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): 요청에 속한 상태가 메모리 해제 후에도 남아, 같은 워커의 후속 요청에서 쓰입니다.

PHP 자체 CVE 번호 지정 기관(CNA)은 두 취약점 모두 CVSS 4.0 기준 9.2점, 심각으로 평가하고, Red Hat은 중요로 평가합니다. 영향 범위는 "PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed를 포함해 웹 요청을 처리하는 모든 PHP 설치 환경"입니다. PHP-FPM에서는 CVE-2026-109619의 세션 라이프사이클을 이용한 원격 코드 실행이 검증됐지만, CVE-2026-109618은 PHP-FPM에서 완전한 공격 사례가 입증되지 않았습니다.

PHP 8.1 및 이전 버전은 업스트림 릴리스가 없고 7.4, 8.0, 8.1용 최소한의 소스 백포트만 제공됩니다. Ubuntu 22.04의 php8.1 패키지 8.1.2-1ubuntu2.28에는 수정 사항이 포함돼 있습니다(USN-8948-1, CVE-2026-109618, CVE-2026-109619). CISA는 "즉시 업데이트할 수 없거나 지원이 종료된 PHP 8.1 또는 이전 버전을 계속 쓰는 조직은 패치 또는 업데이트가 가능해질 때까지 PHP 기반 시스템을 오프라인으로 전환해야 합니다"라고 권고합니다. Ubuntu 22.04에서는 Canonical이 배포한 패키지가 곧 패치입니다. 8.1.2-1ubuntu2.28을 설치하고 Apache를 재시작하기 전까지는 이 권고가 적용됩니다.

공격 관측 여부에 대해서는 1차 출처의 설명이 엇갈립니다. CISA는 "발표 시점까지 이 취약점을 악용한 사례를 관측하지 못했습니다"라고 밝혔고, 두 CVE 모두 알려진 악용 취약점(KEV) 목록에 없습니다. 반면 Cloudflare는 "고객을 겨냥한 공격 트래픽을 관측했습니다"라고 밝혔습니다.

실행 과정: root 권한 없이 프로덕션에서 일한 Claude Code

요약: Claude Code는 root 권한 없이 약 6분 만에 프로덕션 서버를 패치했습니다. 사람이 지정된 명령어 목록을 승인하기 전까지 sudo는 막혀 있었고, Alpacon 타임라인에는 sudo 명령어마다 허용된 이유가 남았습니다. 사람이 미리 승인한 목록이거나, Alpacon이 그 명령어의 위험도를 직접 평가해 승인한 경우입니다.

Claude Code는 Alpacon CLI로 작업했습니다. Alpacon은 승인된 작업 세션 안에서 서버 명령어를 실행하고 세션 타임라인에 기록합니다. 이 실행에서 확인하려는 질문은 에이전트가 root 권한을 넘겨받지 않고 프로덕션에서 권한이 필요한 작업을 할 수 있느냐는 것입니다.

패치

1. 명령어 범위만 있는 세션을 요청했습니다. Claude Code는 서버 한 대, 만료 시간 1시간, 작업 목적을 지정하고 command 범위만 있는 작업 세션을 먼저 요청했습니다. 기본적으로 AI 에이전트가 요청한 세션은 활성화되기 전에 사람의 승인이 필요하며, 이 세션은 Alpacon 콘솔에서 사람이 승인했습니다.

2. 지정한 sudo 명령어 목록을 승인받았습니다. 처음 실행한 sudo apt-get update는 세션에 sudo 범위가 없어 실행되기 전에 거부됐습니다(WORK_SESSION_SCOPE_NOT_ALLOWED). Claude Code는 같은 세션의 범위를 command와 sudo로 넓히고 짧은 sudo 명령어 패턴 목록을 적용해 달라고 요청했으며, 사람이 이 변경을 승인했습니다.

   복사

   apt-get update
   apt-get install --only-upgrade -y php8.1* libapache2-mod-php8.1
   apache2ctl configtest
   systemctl restart apache2
   ufw status verbose
   iptables -S
   ip6tables -S
   nft list ruleset
   ss -tlnpu
   

3. 업그레이드로 패키지 18개가 변경됐습니다. libapache2-mod-php8.1, php8.1-common부터 -phpdbg까지 변경됐습니다.

세션이 처음 승인된 시점부터 Apache가 패치된 PHP로 요청을 처리하기까지 약 6분이 걸렸으며, 여기에는 두 번째 승인도 포함됩니다. 그 대가로 세션 범위를 넓힐 때마다 승인을 받아야 했고, 승인할 사람이 자리에 있어야 했습니다.

방화벽

오리진 접근을 제한하기 위해(아래 절차 참고) Claude Code는 같은 세션에서 다음 패턴의 승인을 요청했고, 사람의 승인이 나기 전에 첫 번째 ufw allow를 실행했습니다. 요청한 패턴은 다음과 같습니다.

ufw allow proto tcp from * to any port 80
ufw allow proto tcp from * to any port 443
ufw delete allow 80/tcp
ufw delete allow 443/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw status numbered
certbot renew --dry-run

from *는 출발지를 가리지 않는 것으로 읽히므로, 승인된 목록은 Cloudflare의 15개 IP 대역보다 넓었습니다. IP 대역과 포트마다 패턴을 하나씩 지정해 15개 IP 대역을 나열했다면 승인된 허용 규칙을 모두 Cloudflare로 제한할 수 있었습니다. 롤백 명령은 의도적인 예외로, 두 포트를 누구에게나 다시 엽니다.

실행 기록에서 확인한 내용

에이전트의 작업을 사후에 감사할 수 있는 이유가 여기에 있습니다. 에이전트가 실행한 sudo 명령어는 모두 허용된 이유와 함께 Alpacon 세션 타임라인에 남아, 사람이 실행 전체를 나중에 확인할 수 있습니다. 이 명령어들이 실행되기 전에 Claude Code는 실행할 명령어를 나열하며 세션에 sudo를 추가해 달라고 요청했고, 사람이 그 목록을 승인했습니다. 이번 실행의 타임라인은 다음과 같습니다.

두 명령어는 목록과 일치해서가 아니라 Alpacon의 위험도 평가로 승인됐습니다. 설치 명령어는 와일드카드 패턴으로 미리 승인돼 있었지만 Claude Code가 글롭 php8.1*를 입력한 그대로 전달해, Alpacon이 그 명령어 자체를 평가했습니다. 첫 번째 방화벽 규칙은 패턴 승인을 기다리는 동안 실행됐고, Alpacon이 이 명령어도 평가해 승인했습니다.

• 정확한 패키지 이름을 지정하고 에이전트가 글롭 대신 그 이름을 사용하게 하세요.
• 새로 지정한 항목은 에이전트가 승인을 기다렸다가 실행하게 하세요.
• 실행 후 alpacon work-session timeline <session-id> 명령어로 같은 타임라인을 확인하세요.

그렇다면 에이전트가 root 권한을 넘겨받지 않고 프로덕션에서 권한이 필요한 작업을 할 수 있었을까요? root 권한 없이도 가능했습니다. 사람이 세션의 범위를 넓히기 전까지 sudo는 거부됐고, Alpacon이 허용한 sudo 명령어는 Alpacon이 위험도 평가로 직접 승인한 두 건까지 모두 허용된 이유와 함께 기록됐습니다.

플랫폼별 수정 버전

2026-10-22 03:00 UTC 기준 상태입니다. 당시 업체들이 아직 수정 버전을 내놓는 중이었으므로 조치 전에 다시 확인하세요.

Ubuntu 22.04 패치

버전은 저희 호스트가 쓰는 Ubuntu 아카이브 기준입니다. ondrej/php PPA를 쓴다면 그 변경 기록을 확인하세요.

sudo apt-get update
apt-cache policy php8.1 libapache2-mod-php8.1
sudo apt-get install --only-upgrade 'php8.1*' libapache2-mod-php8.1

• root로 패키지 목록을 새로 고쳐야 합니다. 저희 호스트에서는 오래된 목록으로 root가 아닌 계정에서 실행한 apt list --upgradable에 수정 버전이 보이지 않았습니다. root로 apt-get update를 실행한 뒤에야 나타났습니다.
• .27은 수정 버전이 아닙니다. jammy의 .27, noble의 .12, 26.10의 8.5.9-0ubuntu2는 다른 CVE를 수정하기 위해 10월 19일에 배포됐습니다. 10월 19일 이후 업데이트했더라도 아직 .27을 쓰는 호스트는 취약합니다.

즉시 패치할 수 없을 때

CISA는 즉시 업데이트할 수 없는 호스트를 오프라인으로 전환하라고 권고합니다. 오프라인 전환도 어렵다면 php.net이 제시한 완화 조치를 적용할 수 있습니다. php.net은 이 조치가 "특정 공격 경로에 노출될 가능성을 줄이지만 설치된 PHP를 안전하게 만들지는 못한다"고 설명합니다.

• CVE-2026-109619: php.ini, FPM 풀 또는 서버 설정에서 session.upload_progress.enabled=0으로 설정하세요. ini_set()이나 .user.ini에 설정하지 마세요. 모든 워커를 재시작해야 합니다.
• CVE-2026-109618: php_admin_value로 memory_limit=-1을 설정하고, post_max_size를 낮게 설정하며(업로드가 없으면 8M, 있으면 32M), cgroup 메모리 제한을 설정해야 합니다.

요청을 처리하는 프로세스의 패치 확인

요약: 패키지를 업그레이드해도 실행 중인 프로세스에는 패치가 적용되지 않습니다. PHP 요청을 처리하는 SAPI를 재시작하세요. mod_php는 Apache, FPM은 php-fpm을 재시작합니다. 그런 다음 패키지 빌드, 서비스 시작 시간, 각 사이트의 응답을 확인하세요.

1. 빌드를 확인합니다. 22.04에서는 새 8.1 릴리스가 아니라 -1ubuntu2.28 접미사로 패치 여부를 확인합니다(24.04에서는 0ubuntu0.24.04.13). php -v 결과로 판단하지 마세요. 이 명령은 CLI 바이너리를 보고하며, 웹을 처리하는 SAPI와 다를 수 있습니다.

   복사

   dpkg -l | grep php8.1    # look for 8.1.2-1ubuntu2.28
   

2. SAPI를 재시작합니다. mod_php는 Apache 안에서 실행되므로 Apache를 재시작해야 합니다. 먼저 설정을 테스트하세요.

   복사

   sudo apache2ctl configtest && sudo systemctl restart apache2
   

   FPM을 쓴다면 그 서비스를 재시작하고(sudo systemctl restart php8.3-fpm), 컨테이너를 쓴다면 재배포하세요. 저희 호스트에서는 needrestart 목록에 apache2가 없었습니다. needrestart 결과를 믿지 마세요.

3. 서비스 시작 시간이 업그레이드 이후인지 확인한 다음, 오리진의 모든 가상 호스트에 요청을 보내야 합니다.

   복사

   systemctl show -p ActiveEnterTimestamp apache2
   grep ' upgrade libapache2-mod-php8.1' /var/log/dpkg.log   # compare with the start time
   curl -sS -o /dev/null -w '%{http_code}\n' -H 'Host: www.example.com' http://127.0.0.1/
   

4. 확실히 확인하려면 SAPI에 직접 확인해야 합니다. 기본 사이트의 DocumentRoot(기본 Ubuntu에서는 /var/www/html)에 임의의 이름으로 phpinfo() 페이지를 만들고 localhost로 요청한 뒤 삭제하세요. 응답에 버전 정보가 없다면 요청이 파일에 도달하지 않은 것이며, PHP가 패치되지 않았다는 뜻은 아닙니다.

   복사

   f=$(openssl rand -hex 8).php
   echo '<?php phpinfo();' | sudo tee /var/www/html/$f >/dev/null
   curl -s http://127.0.0.1/$f | grep -m1 -o 'PHP Version [^<]*' || echo 'no phpinfo page: check the DocumentRoot'
   sudo rm /var/www/html/$f
   

Cloudflare를 통해서만 오리진에 접속하도록 제한

요약: 해결책은 패치이며, 이 설정은 노출 범위만 줄입니다. Cloudflare 뒤에 있다면 WAF 규칙은 Cloudflare를 거친 트래픽에만 적용됩니다. 80과 443 포트에는 Cloudflare IP 대역만 허용하고, 전체에 열려 있는 규칙을 삭제한 뒤 오리진으로 직접 보낸 요청이 시간 초과되는지 확인하세요.

Cloudflare는 Managed Ruleset과 Free Ruleset에 긴급 WAF 규칙 7개를 배포했습니다. 유료 플랜을 쓴다면 규칙이 차단 모드인지 확인하라고 Cloudflare 블로그에서 안내합니다. Cloudflare의 Authenticated Origin Pulls (AOP) 문서는 문제를 이렇게 설명합니다. "오리진 서버의 IP 주소를 알아낸 사람은 누구나 Cloudflare를 우회해 서버로 직접 요청을 보낼 수 있습니다." 변경 전에는 저희 오리진의 IP로 직접 보낸 요청에 200 응답이 돌아왔습니다.

먼저 확인할 사항

• sudo ufw status verbose에서 Status: active와 Default: deny (incoming)이 표시되는지 확인하세요. ufw가 비활성 상태라면 이 규칙들은 아무 효과가 없습니다. SSH 포트를 먼저 허용하고 sudo ufw enable을 실행한 뒤 Status: active를 확인하고 다음 단계로 넘어가세요.
• 오리진의 모든 호스트 이름이 프록시를 거치는지 확인하세요. DNS 전용 레코드인 호스트 이름은 이 변경 후 접속되지 않습니다.
• 80과 443 포트의 활성 연결이 Cloudflare IP 대역에서만 들어오는지 확인하세요. ss -tn state established '( sport = :80 or sport = :443 )' 명령어로 확인할 수 있습니다.

허용 규칙 추가 후 기존 규칙 삭제

사이트 연결이 끊기지 않도록 먼저 허용 규칙을 추가합니다.

반복문에 넣기 전에 받은 목록을 먼저 확인하세요. 2026-10-21 기준으로 IP 대역은 15개입니다.

curl -fsS https://www.cloudflare.com/ips-v4 -o cf-ips-v4.txt && cat cf-ips-v4.txt
for r in $(cat cf-ips-v4.txt); do sudo ufw allow proto tcp from "$r" to any port 80; sudo ufw allow proto tcp from "$r" to any port 443; done
sudo ufw status numbered   # expect 30 new allow rules

허용 규칙을 모두 추가한 뒤에만 진행하세요.

sudo ufw delete allow 80/tcp
sudo ufw delete allow 443/tcp

기존의 개방 규칙을 allow 80/tcp와 443/tcp로 추가한 것이 아니라면 sudo ufw show added에 표시되는 형식 그대로 80, 443 포트의 개방 규칙만 삭제하세요. 호스트에 공개 IPv6 주소가 있다면 삭제 전에 IPv6 대역 7개를 추가하세요. Docker가 외부에 공개한 포트는 ufw를 거치지 않으므로 DOCKER-USER 체인에서 필터링하세요.

검증

• 호스트 외부에서 두 포트에 직접 요청하면 모두 시간 초과되는지 확인하세요.

  복사

  curl -m 10 -sS -o /dev/null -H 'Host: www.example.com' http://<origin-ip>/
  curl -m 10 -sS -o /dev/null --resolve www.example.com:443:<origin-ip> https://www.example.com/
  

• 모든 사이트가 Cloudflare를 거쳐 응답하는지 확인하세요.

• sudo certbot renew --dry-run이 통과하는지 확인하세요.

롤백하려면 sudo ufw allow 80/tcp와 sudo ufw allow 443/tcp를 실행하세요.

이 방법으로 막을 수 없는 것

허용 목록으로 확인할 수 있는 것은 요청이 Cloudflare를 거쳤다는 사실뿐입니다. AOP 문서의 표현대로 요청이 "바로 내 계정에서" 왔다는 것까지 확인되지는 않습니다. 따라서 다른 Cloudflare 계정에서도 오리진에 접근할 수 있습니다. 자체 인증서를 사용하는 AOP나 Cloudflare Tunnel로 이 문제를 막습니다. 하지만 둘 다 Cloudflare를 거쳐 전달되는 공격까지 막지는 못합니다. Cloudflare는 블로그에서 "고객은 WAF 보호 기능을 쓰더라도 PHP 저장소에 패치를 적용해야 합니다"라고 말합니다.

티켓을 닫기 전 확인 사항

• PHP를 제공하는 모든 호스트에 수정된 빌드가 적용됐는지 확인하세요. 컨테이너 이미지도 포함하세요.
• 시작 시간을 기준으로 업그레이드 후 모든 SAPI가 재시작됐는지 확인하세요.
• 패치하지 못한 호스트는 오프라인 상태인지 확인하세요. 오프라인으로 전환할 수 없다면 서버 수준에서 php.net의 완화 조치를 적용하고 날짜를 적은 패치 계획을 마련하세요.
• 오리진이 직접 요청에 응답하지 않는지 확인하세요.
• 확인 당시 RHEL 9 php:8.4는 수정이 나오기 전이었고, Debian forky/sid는 여전히 취약했으며, AL2023 php8.1과 AL2 core php는 No Fix Planned였습니다. 다시 확인하세요.

서버 한 대에서 전체 서버로

전체 서버의 버전을 이미 관리하고 있지 않다면, 공격자가 먼저 움직이기 전에 노출된 호스트를 빠짐없이 찾아 패치하고 수정됐는지 검증하는 일은 수작업으로 사실상 불가능합니다. 이번에는 Cloudflare가 이미 공격 트래픽을 보고 있었습니다.

서버 전체를 Alpacon에 한 번 연결하면 에이전트가 모든 서버를 아우르는 하나의 Work Session에서 전 과정을 실행합니다. 취약한 빌드가 설치된 호스트를 각각 찾아 몇 분 안에 패치하고, 각 호스트가 정상적으로 동작하는지 확인합니다. 정해진 스크립트를 따르지 않고 각 단계의 결과를 검증하며 다음 작업을 결정합니다. 사람은 이 세션을 한 번 승인합니다. 모든 에이전트 세션은 Alpacon으로 승인되고 관리됩니다.

직접 서버에서 실행하려면 다음 순서를 따르세요.

1. 서버를 Alpacon에 연결합니다. Alpacon 콘솔에서 에이전트인 Alpamon을 설치하거나, AWS 계정을 연결해 전체 서버에 한 번에 설치할 수 있습니다.

2. Claude Code가 실행되는 곳에 Alpacon CLI를 설치하고 로그인합니다.

   복사

   brew install alpacax/alpacon/alpacon-cli
   alpacon login
   

3. Claude Code에 다음 프롬프트를 입력합니다.

   복사

   Alpacon으로 웹 서버들의 php2shell을 패치해 줘. 작업 세션을 열고 서버마다 PHP 빌드를 확인한 뒤 필요한 서버를 업그레이드하고, PHP 요청을 처리하는 서비스를 재시작해서 수정이 실제로 적용됐는지 확인해 줘.
   

4. 세션 승인 요청이 오면 승인하고, 타임라인에서 실행 과정을 따라가면 됩니다.

자주 묻는 질문

업스트림에서 8.1 지원이 끝났는데도 Ubuntu 22.04의 PHP 8.1에는 패치가 적용되나요? 네. 8.1.2-1ubuntu2.28을 설치하고 Apache 또는 php-fpm을 재시작하면 적용됩니다. Canonical은 USN-8948-1에서 수정 사항을 백포트했습니다.

AI 에이전트에게 패치를 맡겨도 되나요? 세 가지 습관을 지킨다면 맡길 수 있습니다.

• 사람이 권한을 부여하기 전까지 sudo를 막으세요.
• 에이전트가 정확한 패키지 이름과 방화벽 규칙을 나열하게 하고, 승인받을 때까지 실행하지 않게 하세요.
• 실행 후 모든 sudo 권한 부여 행에서 허용 근거를 확인하세요.

이번 실행에서는 입력된 형태가 승인 목록과 일치하지 않은 sudo 명령어 두 개를 Alpacon이 위험도 평가를 거쳐 승인했습니다. 이번 실행 기록에서 확인한 내용을 참고하세요.