2026년 10월 22일 · @martin

한 줄 요약: PHP 5.4부터 숨어 있던 원격 코드 실행(RCE) 취약점 두 개가 공개됐고, 이걸 처음 찾아낸 건 사람이 아니라 AI였다. 지금 운영 중인 PHP 서버가 있다면 이 글을 다 읽기 전에 버전부터 확인하자. 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 미만이면 바로 패치 대상이다.

어제 하루, PHP 판이 뒤집혔다

10월 21일, PHP 프로젝트가 긴급 보안 릴리스를 내놨다. 전날인 20일에 "내일 보안 릴리스 나갑니다"라는 사전 공지가 먼저 돌았고, 21일 오후(한국 시간 밤 10시 반 무렵) 패치가 풀렸다.

취약점은 두 개다. 업계에서는 둘을 묶어 PHP2Shell이라고 부른다.

CVE

요약

심각도

CVE-2026-109618

메모리 부족(OOM) 처리 중 요청 데이터가 반쯤 초기화된 상태로 끊기고, 이후 정리(cleanup) 단계에서 그 깨진 데이터를 정상으로 믿고 사용 → RCE

CVSS v4.0 9.2

CVE-2026-109619

요청 사이에 남아 있는 오염된 전역 상태(stale global state)를 다음 처리에서 재사용 → RCE

CVSS v4.0 9.2

핵심은 로그인 없이, 원격에서, 서버 코드를 실행할 수 있다는 점이다. 애플리케이션 코드를 아무리 잘 짰어도 소용이 없다. 구멍이 우리 코드가 아니라 PHP 엔진(Zend) 쪽에 있기 때문이다. CodeIgniter든 Laravel이든 WordPress든, 그 아래에서 PHP가 돌고 있다면 전부 해당된다.

미국 NSA는 "업데이트할 수 없으면 차라리 내려라"는 수준의 권고를 냈고, Cloudflare는 모든 요금제 고객에게 WAF 룰을 일괄 배포했다. PHP가 전 세계 웹의 약 70%를 떠받치고 있다는 걸 생각하면 과한 반응이 아니다.

그런데 이걸 찾은 게 AI라고?

이번 사건이 다른 보안 이슈와 결정적으로 다른 지점이 여기다. 이 취약점들은 정기 보안 감사나 사람 연구자의 끈질긴 리버싱에서 나온 게 아니라, AI를 붙여 돌린 연구 과정에서 발견됐다.

공개된 내용을 정리하면 이렇다.

  • Calif — 미국의 AI 레드팀 전문 보안업체. OpenAI의 "Patch the Planet" 프로그램 안에서 GPT-5.6 Sol 모델을 활용해 두 취약점 중 하나를 찾아냈다. 발견 시점은 올여름(7~8월)으로 알려져 있다.
  • Wiz — 구글 소유의 클라우드 보안업체. 독자적으로 두 취약점을 모두 찾아내 보고했다. 연구 과정에서 Google의 Gemini 4 Argon, 자사 도구 Wiz Atlas, OpenAI의 GPT-5.6 Sol을 함께 썼다고 밝혔다.
  • OpenAI — 약 두 달 동안 PHP 메인테이너, 연구자, Cloudflare 같은 보안 사업자, 미국 정부 기관까지 묶어 공개 일정을 조율했다고 설명했다.
  • Cloudflare는 공개 주체로 위 세 곳에 더해 프랑스 보안업체 Quarkslab도 함께 언급했다.

Wiz 연구진은 블로그에서 이 정도 작업이면 원래 세계 최고 수준의 팀이 몇 달은 매달려야 했을 일이라고 적었다. 그 몇 달짜리 일을 AI가 크게 앞당겼다는 얘기다.

재미있는 대목이 하나 더 있다. 이 문제의 축소판은 이미 2024년에 한 번 발견된 적이 있다. 그때는 대수롭지 않게 여겨져 그냥 넘어갔다. 사람 눈에는 "그냥 엣지 케이스 버그"로 보였던 것을, AI는 실제로 쉘까지 따낼 수 있는 공격 경로로 이어 붙인 셈이다.

왜 AI가 이런 버그에 강한가

두 취약점의 공통점을 보면 이해가 된다.

  • 메모리가 바닥나는 아주 드문 순간에
  • 요청 처리 도중 어중간한 상태로 끊긴 데이터가
  • 한참 뒤 정리 단계나 다음 요청에서 다시 쓰인다

이런 버그는 코드 한 줄만 봐서는 절대 안 보인다. 수십만 줄짜리 C 코드에서 "이 함수가 여기서 중단되면, 저쪽 전역 변수는 어떤 상태로 남고, 그게 다음에 어디서 읽히는가"를 끝까지 추적해야 한다. 사람은 지치고, 퍼저(fuzzer)는 맥락을 모른다. 반면 요즘 프론티어 모델은 코드 전체를 읽으면서 상태 흐름을 추론하고, 가설을 세우고, 직접 재현 코드를 돌려보는 일을 쉬지 않고 반복할 수 있다.

올해 들어 이런 흐름은 이미 여러 번 나왔다. Mozilla는 Anthropic의 Claude Mythos Preview를 붙인 하네스로 Firefox에서 271개 버그를 찾아 고쳤고, Google의 CodeMender 에이전트는 반년 동안 오픈소스 프로젝트에 72건의 보안 수정을 올렸다. PHP2Shell은 그 흐름이 "전 세계 웹 70%" 규모의 사건으로 터진 첫 사례라고 보면 된다.

문제는 칼이 양날이라는 것

OpenAI는 이번 건을 두고 "공격자보다 AI가 먼저 찾아서, 방어자가 준비할 시간(Defender's Window)을 벌었다"고 설명한다. 반은 맞는 말이다.

그런데 같은 날 Cloudflare 쪽 설명은 결이 좀 다르다.

  • 공식 공개 전에 익스플로잇이 유출됐고
  • 실제로 고객을 노린 공격 트래픽이 관측됐으며
  • 공격자들이 WAF 룰을 피하려고 페이로드를 계속 변형하고 있었다고 한다.

Cloudflare가 WAF 룰을 켠 게 21일 새벽 3시 2분(UTC)이니, 패치보다 약 9시간 먼저 방어막부터 친 셈이다. CERT-EU도 PoC가 돌기 시작했다고 경고했고, 유출된 공격 도구는 PHP 5.4까지 먹힌다고 주장한다는 보도도 있다.

즉 이번 사건은 "AI가 먼저 찾았다"와 "그래도 공개 전에 새어 나갔다"가 동시에 참인 케이스다. OpenAI 스스로도 이런 능력이 공격자의 익스플로잇 개발 속도도 같이 끌어올린다고 인정했고, 앞으로 이런 발견이 몇 달 안에 급증할 거라고 내다봤다.

개발자 입장에서 이게 의미하는 바는 단순하다. 취약점 공개부터 실제 공격까지의 시간이 점점 0에 수렴한다. "다음 정기 점검 때 패치하자"는 운영 방식은 이제 진짜로 위험하다.

그래서 지금 뭘 해야 하나 (Ubuntu + CI4 기준)

1) 버전부터 확인

php -v
php-fpm8.3 -v   # 사용 중인 FPM 버전에 맞게

브랜치

패치 버전

비고

8.5

8.5.12

 

8.4

8.4.27

 

8.3

8.3.36

 

8.2

8.2.35

보안 지원 올해 말 종료

8.1 이하

php.net 공식 패치 없음

소스 백포트만 제공 (7.4 / 8.0 / 8.1)

주의: Ubuntu 기본 저장소 패키지는 버전 번호는 그대로 두고 보안 패치만 백포트하는 경우가 많다. php -v에 8.3.36이 안 찍혀도 패치가 들어갔을 수 있으니 changelog에서 CVE 번호를 직접 확인하자.

apt changelog php8.3-fpm | grep -i -E "CVE-2026-10961[89]"

2) 업데이트

sudo apt update
sudo apt install --only-upgrade 'php8.3*'   # ondrej/php PPA 사용자도 동일

3) 워커 재시작 — 이거 빼먹으면 말짱 꽝

패키지만 올리고 FPM을 안 내리면 메모리에 올라가 있는 옛날 바이너리가 계속 요청을 받는다.

sudo systemctl restart php8.3-fpm
# mod_php라면
sudo systemctl restart apache2

4) 놓치기 쉬운 곳들

  • Docker 이미지: php:8.x-fpm 베이스 이미지를 다시 pull 해서 리빌드해야 한다. 컨테이너 재시작만으로는 안 바뀐다.
  • CLI·큐 워커·크론: php spark 로 도는 CI4 커맨드, 큐 컨슈머, 스케줄러 같은 상주 프로세스도 재시작 대상이다.
  • CI/CD 파이프라인: GitHub Actions setup-php에서 버전을 고정해 뒀다면 패치 버전으로 올려두자.
  • EOL 서버(7.x, 8.0, 8.1): 인터넷에 노출된 구버전 PHP 호스트가 약 88만 대로 집계됐다는 분석도 있다. 클라이언트 레거시 서버가 있다면 이번이 진짜 업그레이드 명분이다. 당장 못 올리면 배포판·LTS 벤더의 백포트 패키지를 쓰거나, 최소한 WAF 뒤로 숨겨야 한다.
  • CodeIgniter 업데이트로는 해결 안 된다: 프레임워크가 아니라 엔진 문제다. composer update가 아니라 PHP 자체를 올려야 한다.

WAF는 시간을 벌어줄 뿐 해결책이 아니다. 앞서 봤듯 공격자들은 이미 룰 우회를 시도하고 있다. 업데이트가 유일한 완전한 대응이라는 게 PHP 측 공식 입장이다.

26년 PHP 개발자로서 드는 생각

PHP로 26년을 먹고살면서 보안 이슈는 숱하게 봤다. 그런데 이번 건은 느낌이 다르다. 구멍 자체보다 누가, 어떻게 찾았느냐가 더 큰 뉴스이기 때문이다.

몇 가지 정리해 보면,

  1. "오래돼서 검증된 코드"라는 말은 이제 안심의 근거가 못 된다. 14년 동안 수많은 눈이 지나간 코드에서 AI가 새 공격 경로를 찾아냈다. 사람이 리뷰했다는 사실과, 기계가 끝까지 추적했다는 사실은 다른 얘기다.
  2. 패치 주기는 "정기"에서 "즉시"로 바뀌어야 한다. 발견→공개→공격 사이의 간격이 계속 짧아진다. 서버 자동 보안 업데이트(unattended-upgrades), 배포 파이프라인에서 베이스 이미지 자동 리빌드 같은 체계를 지금 갖춰두는 게 맞다.
  3. 같은 무기를 우리도 쓸 수 있다. 공격자가 AI로 익스플로잇을 만든다면, 방어하는 쪽도 AI로 내 코드를 먼저 털어봐야 한다. 나는 요즘 Claude Code로 개발하면서 커밋 전에 "이 컨트롤러에서 인증 우회나 입력 검증 누락 가능성 찾아줘" 같은 요청을 습관처럼 던진다. 엔진 레벨 버그까지는 못 잡더라도, 우리 손에 있는 애플리케이션 코드만큼은 AI 점검을 기본 루틴으로 넣을 때가 됐다.
  4. 메모리 안전성 얘기가 다시 나올 것이다. 이번 두 버그 모두 결국 C 레벨의 메모리·상태 관리 문제다. PHP 코어의 일부를 더 안전한 언어로 옮기자는 논의가 앞으로 꽤 진지하게 나올 것 같다.

솔직히 조금 무섭기도 하고, 동시에 흥미롭기도 하다. AI가 코드를 "짜주는" 단계를 넘어 "세상의 코드를 털어보는" 단계로 넘어온 걸 눈으로 확인한 날이니까.

일단 오늘 할 일은 하나다. 서버 들어가서 php -v 치고, 패치하고, FPM 재시작. 생각은 그다음에 해도 늦지 않다.

참고 자료