Executive Summary

PHP2Shell은 두 취약점에 연구자들이 붙인 이름이다. 번호로는 CVE-2026-109618과 CVE-2026-109619이고, PHP 공식 평가로 둘 다 CVSS v4.0 기준 9.2점이다. 영향 범위는 웹 요청을 처리하는 모든 PHP 설치다. 패치 판본은 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12 넷이고, 8.1 이하는 PHP 프로젝트에서 더 이상 갱신을 받지 않는다.

두 결함의 성격은 php.net 공지문이 짧게 적는다. 앞엣것은 메모리가 바닥났을 때의 처리 과정이 요청 내부 자료가 절반만 준비된 상태에서 PHP를 끊어 버릴 수 있고, 그 뒤 요청 정리 절차가 그 망가진 자료를 멀쩡한 것으로 다루는 결함이다. 뒤엣것은 요청에 딸린 내부 상태가 그 상태를 담고 있던 메모리가 반납된 뒤에도 살아남아, 같은 작업 프로세스가 처리하는 다음 요청이 초기화 전에 그 낡은 상태를 쓰는 결함이다. 재현 방법은 이 글에서 다루지 않는다. 완화 설정이 필요한 쪽은 php.net 공지문의 권고를 그대로 따르면 된다. 앞엣것은 memory_limit과 post_max_size를 운영 환경에서 고정하는 쪽이고, 뒤엣것은 session.upload_progress.enabled를 끄고 작업 프로세스를 전부 재시작하는 쪽이다. 어느 쪽이든 답은 패치다.

이 사건이 이 글의 주제가 된 것은 결함 자체가 아니라 그 앞뒤에 일어난 일 때문이다. 발견부터 공개까지 두 달 반이 걸렸고, 공개 하루 전에 상세가 샜고, 공개 예정일이 하루 앞당겨졌고, 그런데도 첫 공격이 패치보다 먼저 왔다. 아래 표는 그 순서를 시각과 함께 적은 것이다. 시각은 협정 세계시(UTC)를 적고 한국 시간을 괄호로 붙였다.

출처: PHP 재단 공식 블로그(2026-10-21), php.net 공지 아카이브, 두 CVE 레코드(2026-10-22 조회), daubois.dev, watchTowr, Sansec, 클라우드플레어 경유 보도. 발견일이 갈리는 행은 두 값을 모두 적었다.

이 표에서 먼저 눈에 걸리는 줄은 07:43과 14:00이다. 공격이 패치보다 여섯 시간쯤 빨랐다. 공격이 빨랐던 것 자체는 새로운 이야기가 아니다. 우리는 공개와 무기화 사이의 간격이 하루 아래로 내려왔다는 집계를 올해 한 번 다뤘다. 이번 건은 그 집계의 실물이다.

그런데 같은 표의 마지막 줄이 더 오래 남는다. 첫 공격이 관측되고 거의 일곱 시간이 지난 14:34에, 레코드에 붙은 악용 여부 판정은 '없음'이었다. 미국 사이버보안·인프라보안국을 비난할 일이 아니다. 그 판정은 조회 시점의 스냅숏이고 나중에 갱신된다. 다만 이 글이 세려는 것이 바로 "기록이 언제 무엇을 담았는가"이고, 이 한 줄은 그 물음의 교과서 같은 사례다. 바깥에서는 이미 공격이 오고 있었는데, 기계가 읽는 칸에는 아직 오지 않았다고 적혀 있었다.

공개 시각도 한 가지로 모이지 않는다. php.net 공지 아카이브와 PHP 재단 블로그는 둘 다 10월 21일 14:00 UTC를 적는다. 그런데 두 CVE 레코드에 박힌 발행 시각은 13:48:34와 13:54:43으로, 공지된 시각보다 각각 11분과 5분 이르다. 원래 공개 예정 시각도 마찬가지다. PHP 재단 자신은 "10월 22일 14:00 UTC"라 적고, watchTowr 공식 FAQ는 "2026년 10월 22일 18:00 CEST"라 적는다. 둘의 차이는 두 시간이다. 같은 사건의 같은 일정조차 기록하는 곳마다 다르다는 사실을, 이 글은 2절부터 본격적으로 세게 된다.

10월 20일에 샌 것도 한 갈래가 아니었다. PHP 재단은 자사 블로그에서 셋을 따로 적는다. CVE 번호를 포함한 익명 게시물, Calif가 실수로 공개했다가 지운 개념 증명 영상, 그리고 공식 패치보다 약 여섯 시간 앞서 패치 반영 이미지를 올린 Chainguard다. 재단이 마지막 건에 붙인 문장은 이렇다.

이제 어떤 공격자든 수정 내용을 바이너리 형태로 들여다볼 수 있게 됐다. 다른 모든 PHP 사용자는 아직 릴리스를 기다리고 있는데 말이다. 원문: "Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." — PHP Foundation 공식 블로그(2026-10-21)

AI가 오래된 코드에서 결함을 찾아내고 그 사실이 사건이 되는 흐름은 이번이 처음이 아니다. 같은 구조의 앞선 사건을 기록해 둔 글이 이 블로그에 있다. 그 글은 사건을 다뤘다. 이 글은 다른 것을 본다. 그 사건이 끝난 뒤, 누가 무엇을 했다는 이야기가 어디에 어떤 꼴로 남는가다.

취약점 하나에는 공로 기록이 붙는다. 권고문에 누가 무엇을 했는지 적는 칸이다. 이 사건에는 그 칸이 두 군데 있다. 하나는 사람이 보는 화면인 깃허브 보안 권고이고, 다른 하나는 기계가 읽는 정본인 CVE 레코드다. 뒤엣것은 JSON 파일이고, 보안 도구와 취약점 관리 시스템이 실제로 긁어 가는 것은 이쪽이다. 우리는 2026년 10월 22일에 둘을 다 열어 공로 기록을 전수로 옮겨 적었다. 아래가 그 대조다.

출처: GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp 화면, 그리고 MITRE CVE Services API로 받은 두 레코드 원본(스키마 판 5.2). 둘 다 2026년 10월 22일 조회분이다. 대괄호 안은 레코드의 type 값을 한국어로 옮긴 것이다.

이 표에서 사실 셋이 나온다. 하나씩 본다.

2.1같은 회사가 한쪽에서는 발견자, 다른 쪽에서는 신고자다

CVE 레코드 규격은 발견자와 신고자를 다른 역할로 가른다. 발견자는 "취약점을 식별한 쪽"이고, 신고자는 "그 취약점을 벤더나 CVE 번호 발급 기관에 알린 쪽"이다. 같은 사람이 둘 다 할 수도 있지만, 규격이 칸을 나눠 둔 이상 어느 쪽을 적느냐는 뜻이 다른 선택이다.

두 레코드가 그 선택을 다르게 했다. CVE-2026-109618에서 오픈AI는 발견자다. CVE-2026-109619에서 오픈AI는 신고자다. 나머지 둘(Calif의 Ryan Austin과 Wiz)은 양쪽 모두에서 신고자다. 같은 주에 같은 네 당사자가 얽힌 한 사건이고, 두 레코드를 같은 기관이 같은 날 몇 분 간격으로 발행했는데, 한 주체의 역할만 둘로 갈렸다.

왜 갈렸는지 PHP 쪽은 설명하지 않았고, 이 글도 추측하지 않는다. 실수일 수도 있고, 두 결함의 발견 경위가 실제로 달랐다는 뜻일 수도 있다. 다만 한 가지는 분명하다. 깃허브 화면은 이 차이를 보여 주지 않는다. 거기서는 넷이 전부 'Reporter'이고, 발견자라는 말은 나오지 않는다. 사람이 열어 보는 쪽이 기계가 읽는 쪽보다 적게 적는다.

2.2한 사람은 정본에 아예 없다

깃허브 화면의 신고자 넷 가운데 셋은 소속이 비교적 쉽게 잡힌다. lcfr-hax는 프로필에 calif.io를 걸어 뒀고, sagitzadik-wiz와 amyb-oai는 계정 이름 끝에 소속이 붙어 있다. 넷째인 tomash-areion은 저장소도 소개도 링크도 비어 있어 바깥에서 소속을 확인할 수 없다.

그런데 CVE 레코드를 열면 이 계정은 확인할 수 없는 정도가 아니다. 아예 없다. 두 레코드 모두 신고자 쪽 항목이 셋뿐이고, 네 번째 자리에 해당하는 이름이 없다. 깃허브가 공로 대상을 계정으로 찾아 붙이게 돼 있고 CVE 레코드의 같은 칸은 자유 문자열이라, 두 기록이 같은 사건의 같은 사람들을 다른 식별 체계로 적은 결과다. 그 과정에서 한 사람이 한쪽에서 떨어져 나갔다.

같은 칸 안에서도 해상도가 갈린다. CVE 레코드의 신고자 셋을 적힌 그대로 옮기면 Ryan at Calif.io와 Wiz와 OpenAI다. 첫째는 사람과 회사를 같이 담았고 나머지 둘은 회사만 담았다. 이 칸이 자유 문자열이라 가능한 일이고, 그래서 무엇을 어느 해상도로 적을지는 적는 쪽의 선택으로 남는다. 이 자유로움은 뒤에서 한 번 더 나온다. 3절에서 볼 선행 사례는 같은 칸에 사람과 도구의 이름을 함께 담았다.

비슷한 어긋남이 수정 쪽에도 있다. 패치 커밋에는 공저자로 Nicolas Grekas의 이름이 들어 있는데, 두 기록의 수정 개발자 넷에는 그 이름이 없다. 어느 쪽이 틀렸다는 말이 아니다. 공로 기록은 커밋 로그의 사본이 아니고, 양쪽이 담는 범위가 원래 다르다. 다만 "누가 이 일을 했는가"를 알고 싶은 사람이 어느 칸을 열어 보느냐에 따라 다른 명단을 받는다는 것은 사실이다.

2.3가장 자세히 적은 곳은 공식 기록이 아니라 감사 인사말이었다

같은 사람들을 적은 자리가 하나 더 있다. PHP 재단이 패치 당일 올린 블로그 글의 감사 인사말이다. 세 기록의 신원 해상도를 나란히 놓으면 이렇다. 기계가 읽고 영구 보존되는 CVE 레코드는 회사명만 적는다. 사람이 보는 깃허브 화면은 계정명만 적는다. 그리고 재단의 인사말은 팀 이름과 사람 이름까지 적었다.

Calif, 그중에서도 특히 Ryan A, 그리고 Wiz, OpenAI Codex Security, 그중에서도 특히 Amy Burnett, OSTIF, Quarkslab에 연구와 책임 있는 공개에 대해 감사드린다. 원문: "Thank you to Calif, especially Ryan A, Wiz, OpenAI Codex Security, especially Amy Burnett, OSTIF, and Quarkslab for their research and responsible disclosure." — PHP Foundation 공식 블로그(2026-10-21)

이 문장에만 있는 것이 셋이다. 오픈AI 쪽 담당이 Codex Security 팀이라는 것, 그 팀의 Amy Burnett이라는 사람 이름, 그리고 공로 기록 어느 쪽에도 나오지 않는 OSTIF와 Quarkslab이다. 반대로 이 문장에 없는 것도 둘이다. 구글과 앤트로픽이다.

이것이 2절을 닫는 자리다. 적을 의지가 없었던 것이 아니다. 재단은 알고 있었고, 적고 싶어 했고, 실제로 적었다. 다만 적은 자리가 구조화된 칸이 아니라 산문이었다. 산문은 기계가 못 읽고, 집계되지 않고, 다음 사건에서 다시 쓰이지 않는다. 블로그 글은 언젠가 주소가 바뀌거나 사라지지만, CVE 레코드는 남는다. 그리고 남는 쪽에는 회사 이름 셋과 사람 이름 넷이 있을 뿐이다. 모델 이름은 양쪽 어디에도 없다.

"모델 이름이 없다"는 관찰은 그 자체로는 약하다. 적을 자리가 없었다면 없는 게 당연하기 때문이다. 그래서 규격을 열어 봤다. CVE 레코드 형식을 정의하는 스키마 파일에서 공로 기록의 역할 칸은 열 가지 값 중 하나를 받는다. 아래가 그 전부이고, 가운데 열은 스키마 안에 적힌 정의를 그대로 옮긴 것이다.

출처: CVEProject/cve-schema 저장소의 CVE_Record_Format.json(2026-10-22 조회). 정의는 스키마 본문의 영어 설명을 옮긴 것이다. 이 칸에는 기본값도 박혀 있다. 역할을 생략하면 발견자로 간주된다.

여덟 번째 줄이 이 절의 못이다. 발견에 쓰인 도구의 이름을 적는 칸이 규격 안에 따로 있다. 아홉 번째 줄에는 그 발견을 지원한 주체를 적는 칸이 있다. 둘 다 PHP2Shell의 두 레코드에서는 비어 있다.

규격만 그런 것도 아니다. 깃허브에서 보안 권고를 작성할 때 공로 대상에게 붙이는 역할도 드롭다운으로 고르게 돼 있고, 그 목록에 'Tool — 취약점 발견이나 식별에 쓰인 도구의 이름'이 그대로 들어 있다. PHP 쪽은 그 드롭다운을 보면서 Reporter와 Remediation developer 둘만 골랐다.

3.1그 칸이 실제로 얼마나 쓰이는지 세어 봤다

칸이 있다는 것과 쓰인다는 것은 다른 이야기다. 그래서 공개된 CVE 레코드 전체가 들어 있는 저장소에서 각 역할 값이 몇 건에 나타나는지 세었다. 2026년 10월 22일 기준이고, 공로 기록을 가진 레코드는 92,928건이다.

2026년 10월 22일 집계. 한 레코드가 여러 역할을 담으므로 합은 92,928을 넘고 비율 합도 100%를 넘는다.

센 방법과 그 한계를 같이 적는다. 이 글이 비판하는 것이 바로 방법 없는 수치라서, 우리 수치에 같은 흠을 남길 수는 없다. 방법은 이렇다. 깃허브 코드 검색으로 CVE 레코드 저장소에서 각 역할 값이 든 파일 수를 셌다. 한계는 셋이다. 첫째, 한 파일에 같은 값이 여러 번 나와도 1로 센다. 둘째, 우리가 쓴 문자열 꼴과 다르게 저장된 레코드는 빠질 수 있다. 셋째, 대형 저장소를 코드 검색 색인이 전부 덮는다는 보장이 없다. 그래서 이 수치는 실제보다 작을 가능성이 크고, 하한에 가깝다고 보는 편이 맞다.

그래도 자릿수는 분명하다. 발견자가 6만 건대인 자리에서 도구는 세 자릿수다. 백 건 중 한 건에도 못 미친다. 후원자는 그보다 다섯 배 더 드물다. 칸은 있고, 거의 안 쓰인다.

3.2그런데 AI 이름을 적은 레코드가 이미 열여덟 건 있다

거의 안 쓰인다는 것이 아무도 안 쓴다는 뜻은 아니다. 구글의 취약점 발견 AI인 Google Big Sleep의 이름이 든 레코드를 찾아보니 열여덟 건이 나왔다. 그중 여섯을 열어 공로 기록을 그대로 옮겨 적었다.

2026년 10월 22일 조회. 'Google Big Sleep'이 든 레코드는 모두 열여덟 건이고, 위 여섯 건은 그중 공로 기록을 직접 확인한 것이다.

이 표가 3절을 닫는다. 서로 다른 발급 기관 셋이, 일 년 넘게, AI 발견 도구의 이름을 공식 레코드에 적어 왔다. 특히 맨 윗줄은 이 글이 6절에서 제안할 기재 방식의 완성형이다. 사람 이름과 소속을 적고, "Google Big Sleep의 도움을 받아"를 그 뒤에 붙여, 한 문자열 안에 사람과 도구를 같이 담았다. 역할은 발견자로 줬다. 새 칸을 만들 필요도, 새 규격을 기다릴 필요도 없었다.

PHP 쪽이 이렇게 적을 의무는 없다. 공로 기록을 어떻게 쓸지는 발급 기관의 재량이고, 그 재량을 비난하는 것이 이 글의 목적이 아니다. 이 절이 적는 것은 여기까지다. 이미 쓰이는 방법이 있었는데, 이 건에는 안 쓰였다.

한 가지가 더 붙는다. curl은 2025년 5월부터 제보 접수 양식에 "문제를 찾거나 이 제보를 작성하는 데 AI를 썼습니까"라는 질문을 넣어 두고 있다. 그런데 그 답은 어디에도 공개되지 않는다. 같은 curl이 CVE-2025-9086에서는 Google Big Sleep을 발견자로 레코드에 적었으니, 적을 능력이 없는 것도 아니다. 고지는 접수 창구에서 받고, 공개 기록으로는 흐르지 않는다. 이 끊긴 자리가 3절과 6절을 잇는다. 기구를 새로 만들기 전에 기록 보존 규칙이 먼저라는 이야기는 금융 감독 쪽을 다룰 때 이미 적었다.

공식 기록 바깥에서는 말이 많았다. 같은 주에 네 주체가 각자 AI 성과를 발표했고, 보도는 대개 그중 하나만 호명했다. 그런데 이 넷을 한 표에 놓기 전에 먼저 치워야 할 전제가 하나 있다. 네 회사가 아니다.

구글은 2026년 3월 11일에 Wiz 인수를 마무리했다. 320억 달러짜리 거래였고, Wiz는 Google Cloud 산하에서 브랜드를 유지한 채 운영된다. 그러니 "구글이 Gemini 4 Argon으로 독립 발견했다"와 "Wiz가 Gemini 4 Argon을 썼다고 블로그에 적었다"는 서로 다른 두 회사의 겹치는 주장이 아니다. 한 회사 안에서 Wiz 브랜드의 글과 구글 공식 계정의 글이 같은 모델의 공을 두 자리에 따로 적은 것이다. 오픈AI 자신도 이 사실을 알고 있어서, 자사 발표문에서 Wiz를 "3월에 구글이 인수한 AI 보안 회사"라고 소개하며 자기 쪽 발견과 구분했다. 오픈AI 발표문 원문 페이지는 접근이 막혀 있어, 이 문장은 전재본으로 확인한 것이다.

그리고 공식 기록 쪽에서 보면 구도는 한 번 더 단순해진다. 신고자 명단에 구글 소속 계정은 없다. 구글 모델은 이 사건에서 신고자가 아니라 Wiz의 발표문 안에 등장하는 도구다. 아래 표는 그 구분까지 넣어 네 주체가 무엇을 주장하고 무엇을 근거로 댔는지를 같은 항목으로 재 본 것이다.

각 주체의 발표문과 두 공로 기록을 같은 항목으로 재 본 것이다. 앤트로픽 행은 다른 과제이므로 다른 주체들과 성적을 비교하는 용도가 아니다. 왜 한 표에 넣었는지는 아래에 적었다.

표의 마지막 줄에는 단서를 하나 붙여야 한다. 공식 기록 쪽 모델 이름 칸은 '없음'인데, 엄밀히 하자면 한 칸 건너까지는 닿는다. 두 CVE 레코드를 열어 참조 목록을 보면, PHP가 자기 레코드에 붙인 링크는 자사 깃허브 권고 하나뿐이다. 모델 셋의 이름이 적힌 Wiz 블로그 글은 거기 없다. 그 글은 미국 사이버보안·인프라보안국이 뒤에 덧붙인 칸에 '제3자 권고'라는 꼬리표를 달고 들어가 있고, 두 레코드 모두 같다.

그러니까 이 사건에서 모델 이름에 가장 가까이 닿은 공식 경로는 공로 기록이 아니라 참조 링크였고, 그 링크를 붙인 쪽은 번호를 발급한 PHP가 아니라 제3의 기관이었다. 참조 링크 칸에는 누가 무엇을 했는지를 적는 자리가 없다. 링크는 읽을거리를 가리킬 뿐 공을 적지 않는다. 기계가 레코드를 긁어 가며 "이 취약점은 누가 찾았나"를 뽑을 때, 그 링크 너머까지 따라가 주는 도구는 없다.

4.1분모가 없는 배수

표에서 가장 비어 있는 줄은 구글 행이다. 구글 공식 계정은 Gemini 4 Argon이 "베이스라인 모델보다 두 배 넘게" 취약점을 찾았고 "이전 최전선 모델들이 놓친 치명적 위험"을 잡았다고 적었다. 구글 딥마인드의 Gemini 보안 책임자 Raluca Ada Popa는 "Gemini 4 Argon을 써서 Wiz 팀은 최전선 AI가 사이버 방어의 판을 바꾸는 이유를 보여 줬다"고 말했다.

두 배가 무엇의 두 배인지는 어디에도 없다. 베이스라인 모델이 어느 모델인지, 비교 대상이 몇 건이었는지, 어떤 코드베이스에서 쟀는지, 무엇을 취약점으로 셌는지가 전부 빠져 있다. 우리는 이 주장의 근거가 될 공개 측정 문서를 찾으려 했고, 찾지 못했다. 찾지 못했다는 것 자체가 이 절의 결과다. 9월 30일 Gemini 4 Argon 공개 때 제시된 벤치마크 점수와 같은 측정인지 다른 측정인지도 가를 수 없었다.

같은 모델을 놓고 같은 구멍을 본 적이 있다. Gemini 4 Argon의 선별 접근 프로그램을 다룬 글에서 우리는 자격 요건은 공개돼 있는데 누가 왜 통과했는지의 판정 기록이 없다는 점을 적었다. 이번에는 숫자가 공개돼 있고 그 숫자를 어떻게 냈는지가 없다. 수치를 내걸고 측정 방법은 안 적는 패턴 자체는 AI를 내세운 회사들의 주장을 감사한 기록에서 이미 본 것이다.

4.2분모와 측정 방법을 둘 다 적은 쪽은 공을 주장하지 않았다

표에서 그 두 칸이 모두 채워진 행은 앤트로픽 하나다. 그런데 앤트로픽은 이 사건의 공을 주장하지 않았다. 같은 주에 전혀 다른 과제로 숫자를 냈을 뿐이다. 그 과제는 취약점 발견이 아니라 공격 표면 축소, 그러니까 공격자가 닿을 수 있는 코드와 설정의 범위를 줄이는 일이다. 493은 그렇게 짚어 낸 지적 사항의 건수이고, 앤트로픽 자신도 이것을 취약점이라 부르지 않는다. CVE 번호가 배정된 것도 아니다.

분모 쪽은 이렇게 적혀 있다. 25개 프로젝트, 500만 줄이 넘는 코드, 목록화한 설정 옵션 17,000개 중 보안 관련이 3,842개. 설정 조합 162개가 경고 없이 허용됐고 그중 94개는 조용히 보안 기능을 껐다. OpenSSH 사례에서는 새 코드 약 4,500줄이 인증 전 클라이언트에 닿을 수 있었고 그것이 데몬 사전 인증 코드의 약 16%였으며, 수정 뒤 닿을 수 있는 코드가 약 5분의 1 줄었다고 적었다. 상류가 받아들인 것은 OpenSSH 한 건이다.

그리고 앤트로픽은 자기 측정의 한계를 스스로 적었다. 네 발표문 가운데 그렇게 한 곳은 여기뿐이다.

어떤 코드베이스에든 알려지지 않은 취약점이 몇 개나 있는지를 재는 일은 아마 불가능할 것이다. 원문: "It is perhaps impossible to measure how many unknown vulnerabilities are in any given codebase." — Anthropic, 공격 표면 축소 연구 글(2026-10-20)

이 문장이 표 전체를 다시 읽게 만든다. 공을 주장하지 않은 쪽이 분모와 측정 방법과 한계를 다 적었다. 공을 주장한 쪽들은 셋 중 어느 것도 온전히 적지 않았다. 어느 쪽이 더 많이 찾았는지를 이 표로는 알 수 없고, 알 수 없다는 것이 이 표가 주는 정보다.

4.3모델을 만든 쪽과 모델을 쓴 쪽이 같은 발견을 다르게 적는다

"AI가 먼저 찾았다"가 실제로 무엇을 뜻하는지도 한 가지로 모이지 않는다. 오픈AI는 발표문에서 이 발견을 방어 측이 얻은 시간으로 적는다.

우리가 아는 한 최전선 AI가 공격자보다 먼저 이 취약점들을 찾아냈고, 그 덕에 메인테이너와 보안 업체가 공개에 앞서 수정과 보호 조치를 준비할 수 있는 '방어자의 창'이 열렸다. 원문: "To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender's Window for maintainers and security providers to prepare fixes and protections ahead of disclosure." — OpenAI 발표문. ⚠️ 원문 페이지는 접근이 막혀 있어 전재본으로 확인했다.

반면 그 모델을 직접 쓴 Calif의 Ryan Austin은 자기 쪽 기록에서 범위를 좁혀 적었다. 특별한 실험 장치도, 일반에 공개되지 않은 모델 접근도 쓰지 않았고, 사람이 과거 취약점 패턴 쪽으로 모델을 겨눠 줘야 했다는 서술이다. 같은 취지로 Calif는 "어떤 모델도 단순한 프롬프트만으로 '모든 버그'를 캐낼 수는 없다"고 적었다. 두 서술은 모순이 아니다. 하나는 결과를 말하고 하나는 과정을 말한다. 다만 독자가 둘 중 하나만 보면 전혀 다른 그림을 들고 가게 된다. 그리고 어느 쪽도 공식 기록에는 없다.

4.4영향 범위에도 숫자가 여럿 돈다

같은 잣대로 재지 않는 버릇은 공로 기록에만 있는 것이 아니다. 이 사건이 얼마나 많은 웹을 건드리는지에 대해서도 숫자가 셋 돌았다. 여러 보도가 "전 세계 웹사이트의 최대 70%"라 적었고, 다른 보도는 "75~80%"라 적었다. 측정 주체로 지목되는 W3Techs의 사건 당일 수치를 직접 확인하니 69.3%였다. 서버 쪽 언어가 파악된 웹사이트 가운데 PHP의 비중이고, 2026년 10월 21일 기준이다. 같은 집계의 내역은 PHP 8이 65.2%, PHP 7이 27.0%, PHP 5가 7.7%다.

셋 중 기준 시점과 분모를 둘 다 밝힌 것은 하나뿐이다. 나머지 둘은 반올림이거나 출처를 거슬러 갈 수 없는 값이다. 세 숫자의 차이가 실무에 큰 영향을 주지는 않는다. 어느 값이든 "거의 모든 웹"이라는 결론은 같다. 다만 이 사건에 대해 말해진 거의 모든 수치가 같은 흠을 공유한다는 사실은 기록해 둘 만하다.

발표문은 발견 쪽에서 나온다. 발견이 끝난 자리에서 일하는 쪽은 발표문을 내지 않는다. 이 절은 그쪽을 본다.

PHP 쪽이 이 결함의 징후를 처음 본 것은 2026년이 아니다. 2024년 Quarkslab의 외부 감사에서 코어 개발자가 메모리 고갈 처리에 문제가 있다는 신호를 봤다. 그때는 공격이 이론 단계였고 코드 실행까지 가는 경로를 찾지 못했다. 수정안은 나왔지만 저마다 비용이 달랐다. 하위 호환이 깨지거나, 서비스 거부 위험이 새로 생기거나, 수천 개 확장을 고쳐야 하거나 했다. 합의에 이르지 못한 채 시간이 갔다. 재단은 그 지연을 자기 말로 이렇게 적었다.

지연은 구조적 실패였다. 보안팀의 의사결정 절차와 자원 부족이 함께 만든 결과다. 원문: "a structural failure, caused by both the security team's decision process and its lack of resources" — PHP Foundation 공식 블로그(2026-10-21)

2026년에 Calif와 Wiz가 실제로 작동하는 익스플로잇을 들고 오면서 영향이 확정됐고, 수정이 최우선으로 올라갔다. 그다음에 일어난 일을 숫자로 보면 이렇다. 수정 커밋은 지원 브랜치마다 따로 들어갔고, 브랜치별로 대략 390~420개 파일, 1만~1만 2천 줄 규모다. 그 커밋에 이름이 붙은 수정 개발자는 넷이다. 이 글의 비판 대상은 이 넷이 아니다. 반대다. 발표문이 넷이 나오는 동안, 고치는 일을 한 사람은 넷이었다.

2차 보도 몇 곳은 재단이 이 사건 뒤에 생태계 보안팀을 신설했다고 전했는데, 재단 자신의 글은 그 팀을 2026년 5월에 만들었다고 적는다. 사건보다 다섯 달 앞선다. 이번 일로 바뀐 것은 팀의 존재가 아니라 의사결정 방식이다. 조직이 아예 없었다는 그림은 사실과 다르다.

재단은 같은 글에서 돈 이야기도 꺼냈다. "PHP 위에 제품과 서비스를 만드는 회사들은, 자기들이 PHP에 얼마나 기대고 있는지에 걸맞은 수준으로 PHP 재단을 후원해 달라"는 문장이다. 검증과 수정을 할 사람을 늘리는 데 드는 비용이 어디서도 자동으로 나오지는 않는다는 뜻이다.

5.1curl은 품질에 한 번, 물량에 한 번 막히고 세 번째 답을 냈다

제보가 늘면 받는 쪽에서 무슨 일이 생기는지는 curl이 먼저 겪었다. 이야기는 중단과 복귀로 끝나지 않고 한 단계 더 간다.

첫 단계는 품질이었다. 수년간 15%를 넘던 유효 제보 비율이 2025년에 5% 아래로 떨어졌다. 스무 건에 한 건도 안 된다는 뜻이다. 그래서 2026년 1월 31일에 버그바운티를 접었다. 2019년 4월부터 운영하며 취약점 87건을 확인하고 10만 달러 넘게 지급한 창구였다. Daniel Stenberg가 밝힌 이유는 지어낸 거짓말을 보낼 유인을 없애겠다는 것이었다. 2026년 3월에 보상 없이 접수만 재개했고, 4월에는 유효율이 15~16%로 돌아왔다. 품질 문제는 이렇게 풀렸다.

두 번째 단계는 물량이었다. 품질이 좋아진 뒤에도 들어오는 양은 줄지 않았고, 2026년 7월 1일부터 8월 3일까지 신규 접수를 아예 멈춰야 했다. Stenberg는 그 결정을 "오랜만에 내린 최선의 선택이었을지 모른다"고 적었다. 그리고 세 번째 단계가 PHP 패치 전날이다. 10월 20일, curl은 낮음·보통 등급 취약점을 더 이상 비공개로 받지 않고 깃허브에 공개로 올리겠다고 발표했다. 10월 26일부터다.

프로젝트로서 우리는 버거운 상태다. 핵심 메인테이너 전원이 긴장하고, 과부하를 느끼고, 감당할 수 있는 한계의 끝까지 밀려와 있다고 느낀다. 원문: "We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster." — Daniel Stenberg(2026-10-20)

같은 글에서 Stenberg는 AI가 만들어 내는 제보의 성격을 짚는다. 새로 들어오는 취약점 상당수가 모델이 만들어 낸 기이한 순서나 옵션 조합으로, 뭔가 예상 밖의 일이 일어나기는 하지만 현실에서 쓰일 법하지 않은 것들이라는 서술이다. 사용자에게 가는 실제 위험은 거의 없는데, CVE 절차를 타면서 프로젝트 자원은 그대로 먹는다. 지난 몇 해 동안 전체 제보의 90% 넘는 수가 높음 등급 아래로 빠르게 판정됐다고도 적었다.

여기서 "AI 제보는 쓰레기다"로 미끄러지면 곤란하다. curl 자신이 2026년 4월에 이제 거의 모든 보안 제보가 어떤 식으로든 AI를 쓰는데 품질은 매우 높다고 적었고, 같은 프로젝트가 Google Big Sleep을 발견자로 레코드에 적었다. 문제는 누가 썼느냐가 아니라 무엇이 따라오느냐다.

5.2창구를 좁힌 곳이 curl만은 아니다

2026년 한 해에 같은 결정을 내린 곳이 줄을 이었다. 해커원의 인터넷 버그 바운티는 3월 27일에 신규 접수를 멈추면서, AI를 쓴 연구가 취약점 발견의 범위와 속도를 넓히고 있어 구조와 보상을 다시 보겠다고 적었다. 구글은 오픈소스 취약점 포상 프로그램을 두 번에 걸쳐 좁혔다. 3월 19일에 상위 등급 메모리 손상 제보에 재현 절차나 이미 병합된 패치를 요구했고, 10월 1일에는 제품 취약점 접수를 아예 닫았다. 닫으면서 밝힌 사유는 자동 제출이 크게 늘었고 그 대다수가 유효하지 않다는 것이었다.

앞의 결정들이 공유하는 배경은 양이다. 해커원이 2026년 3월에 내놓은 플랫폼 전체 집계로는 제보 건수가 전년 대비 76% 늘었고, 그중 실제 취약점으로 확인된 비율은 25%였다. 이 두 수치는 1차 공지문을 직접 열지 못하고 보도 경유로 옮긴 것이다. 분모가 플랫폼 전체 제보이고 기준 시점이 2026년 3월이라는 것까지만 밝혀져 있어, 무엇을 유효로 셌는지는 확인할 수 없었다.

그 연쇄를 구글 쪽 공지와 규칙 원문으로 따로 정리한 글이 앞서 있다. 그 글의 결론은 닫힌 쪽과 열린 쪽을 가른 기준이 제보자가 누구냐가 아니라 기계가 돌려 볼 수 있는 증거가 따라오느냐였다는 것이다. 이번 글은 그 결론을 반대편에서 본다. 그 글은 들어오는 제보에 증거를 요구하는 쪽 이야기였고, 이 글은 다 끝난 뒤 공식 기록에 무엇이 남는가의 이야기다. 둘은 같은 요구의 앞뒤다. 입구에서 증거를 받아 놓고 출구에서 적지 않으면, 받아 둔 증거는 그 사건 한 번에만 쓰이고 사라진다.

여기까지가 센 것이다. 이 절은 그 결과에서 끌어낸 제안이고, 독자가 자기 조직에서 오늘 할 수 있는 일로 범위를 좁힌다. 외부 규격이 바뀌기를 기다릴 필요는 없다. 3절에서 봤듯 항목들은 이미 표준 규격 안에 자리가 있고, 그 자리를 쓰는 기관도 이미 있다.

AI가 거든 발견을 기록으로 남길 때 적을 것은 여섯이다. 제보를 받는 쪽이라면 이 여섯을 같이 달라고 요구하면 되고, 제보를 내는 쪽이라면 이 여섯을 적어 보내면 된다. 사내 보안 제보 양식과 보안 권고 템플릿에 칸을 여섯 줄 늘리는 일이다.

이 여섯을 한 줄로 쓰는 방법은 이미 나와 있다. 3절의 맨 윗줄이 그 꼴이었다. 사람 이름과 소속을 적고 그 뒤에 "Google Big Sleep의 도움을 받아"를 붙여 발견자 역할로 준 그 레코드다. 칸을 새로 만들지도, 규격을 고치지도 않았다. 기존 칸 안에서 문자열을 한 번 더 자세히 쓴 것뿐이다.

반대로 적지 말아야 할 것도 분명하다. 분모 없는 배수다. "베이스라인 대비 두 배"처럼 비교 대상과 측정 조건이 빠진 수치는, 읽는 쪽에서 검증할 수도 반박할 수도 없어서 결국 아무 정보도 전하지 않는다. 숫자를 못 적겠으면 숫자를 빼고 적는 편이 낫다.

마지막으로 범위를 분명히 해 둔다. 이 여섯 항목은 "AI가 찾았다"는 주장을 참으로 만들어 주지 않는다. 그 주장을 나중에 확인할 수 있게 만들어 줄 뿐이다. 이 글이 PHP2Shell을 누가 먼저 찾았는지 판정하지 못한 이유도 같다. 판정할 근거가 기록에 없다. 다음 사건에서도 없을지는 이번에 무엇을 적어 두느냐에 달려 있다.

1절부터 6절까지는 공로 기록과 규격 원문, 당사자 발표문에서 확인한 것이다. 이 절은 그 문서들이 하지 않은 이야기이고, 페블러스가 왜 이 사건을 오래 들여다봤는지에 관한 것이다.

7.1진단이 아니라 진단에 붙는 성적서가 우리 일이다

페블러스가 데이터클리닉에서 하는 일의 핵심은 진단 자체가 아니다. 진단에 성적서를 붙이는 일이다. 무엇을 무슨 기준으로 쟀고, 몇 건 중 몇 건이 걸렸고, 그 판정을 누가 어떻게 다시 돌려 볼 수 있는지를 구조화된 칸에 남기는 일. 이번 사건은 그 일의 정확한 반대 사례다. 세 주체가 공개적으로 모델 이름을 말했는데 기계가 읽는 정본에는 한 줄도 없고, 그나마 남은 두 기록은 서로 다르다. "AI가 N건을 찾았다"가 성적서 없는 수치일 때 무슨 일이 생기는지를, 검증이 가장 엄격해야 할 분야에서 보여 주는 실물이다.

7.2스키마는 멀쩡한데 칸이 비어 있다

이 글이 다루는 결함은 보안 결함이 아니라 기록 결함이다. 그리고 기록 결함은 우리가 데이터에서 늘 보는 것과 구조가 같다. 값은 있는데 그 값이 어떻게 만들어졌는지가 없는 상태. 라벨은 있는데 누가 언제 무슨 기준으로 붙였는지가 없고, 수치는 있는데 분모가 없는 상태다.

더 날카로운 것은 적을 칸이 이미 있었다는 사실이다. 규격에 도구와 후원자 칸이 따로 있고 발견자와 신고자가 갈려 있는데, 92,928건 중 774건만 도구 칸을 쓴다. 스키마가 없어서가 아니라 채우지 않아서 비어 있다. 데이터 품질 현장에서 가장 자주 보는 실패가 정확히 이것이다. 규격은 멀쩡한데 칸이 비어 있고, 몇 달 뒤 아무도 그 값을 다시 설명하지 못한다.

이번 건은 한 걸음 더 간다. 같은 사건이 두 시스템에 다르게 적혔고, 사람이 보는 화면과 기계가 읽는 정본이 어긋난다. 데이터 품질에서 정합성 결함이라 부르는 바로 그것이다. 결측보다 고약한 이유는 간단하다. 비어 있는 칸은 비어 있다는 게 보이는데, 어긋난 칸은 양쪽 다 채워져 있어서 열어 보기 전까지는 멀쩡해 보인다.

7.3받는 쪽과 내는 쪽, 두 질문이 곧 온다

오픈소스를 쓰지 않는 조직은 없고, 제보 경로에 AI가 들어오는 것은 이미 시작됐다. 고객사가 곧 마주할 질문은 둘이다. 받는 쪽에서는, 사내 보안 제보나 벤더가 가져온 "AI가 찾았다"는 보고를 받을 때 무엇을 같이 요구할 것인가. 내는 쪽에서는, 우리 팀이 AI를 써서 찾은 것을 상대에게 알릴 때 무엇을 적어 보낼 것인가.

6절의 여섯 항목은 그 두 질문에 대한 최소 답이다. 외부 규격이 바뀌기를 기다리지 않고 오늘 사내 양식에 넣을 수 있고, 3절이 보였듯 항목마다 표준 규격 안에 이미 자리가 있다. 새 필드를 발명할 필요가 없다는 것이 이 제안의 유일한 장점이자 가장 큰 장점이다.

7.4판정하지 않고 기록을 여는 자리

이 사건은 앞으로 몇 주간 두 가지 틀로 소비될 것이다. "AI가 드디어 사람을 넘었다"와 "AI 발견은 과장이다". 둘 다 판정이고, 둘 다 근거를 공식 기록에서 가져오지 않는다. 페블러스는 셋째 자리에 선다. 판정하지 않고 기록을 연다. 두 레코드를 다 열어 대조하고, 규격의 빈 칸을 9만 건 단위로 세고, 앞선 사례를 전수로 찾는 쪽이다.

이미 몇 번 선 자리이기도 하다. 수치는 내걸고 측정 방법은 안 적는 회사들, 감독 기구보다 기록 보존 규칙이 먼저라는 쪽, 자격은 공개돼 있는데 판정 기록이 없는 프로그램이 그랬다. 이번 글은 그 축의 네 번째다. 달라진 것은 무대뿐이다. 가장 검증이 엄격해야 할 분야에서도 같은 구멍이 난다.

출처의 등급이 갈리므로 묶어서 적는다. 첫 묶음은 공로 기록과 규격 원문이고, 본문 2절과 3절의 대조는 전부 여기서 나왔다. 둘째 묶음은 PHP 쪽 1차 문서다. 셋째 묶음은 벤더 발표문인데, 1차 출처이되 "그 회사가 그렇게 말했다"는 사실의 1차 출처이지 사건의 사실에 대한 1차 출처는 아니다. 본문에서 이 구분을 문장마다 지켰다. 넷째 묶음은 메인테이너 쪽 1차이고, 다섯째 묶음은 보도와 분석으로 쓸 때마다 귀속을 문장 안에 밝혔다.

공로 기록·규격 (1차)

• 1.CVE Record CVE-2026-109618("RCE via OOM corruption"). MITRE CVE Services API, 2026년 10월 22일 조회 — 2절 대조표의 공로 기록, 발행 시각 13:48:34 UTC, CVSS v4.0 9.2, 그리고 CISA 판정 컨테이너의 악용 여부 값이 여기서 나왔다. 4절의 참조 목록 대조도 같은 원본에서 했다. PHP가 붙인 참조는 자사 깃허브 권고 하나뿐이고, Wiz 블로그는 CISA 쪽 컨테이너에 제3자 권고로 들어가 있다. 두 레코드가 같다. cveawg.mitre.org
• 2.CVE Record CVE-2026-109619("RCE via stale global state"). 같은 API, 같은 날 조회 — 발행 시각 13:54:43 UTC. 오픈AI의 역할이 앞 레코드와 다르다. cveawg.mitre.org
• 3.GitHub Security Advisory GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp(php/php-src) — 2절 대조표의 왼쪽 열. 신고자 계정 넷과 그 역할 표기가 여기서 나왔다. github.com
• 4.CVE Project. CVE Record Format 스키마(CVE_Record_Format.json) — 3절 역할 표의 열 가지 값과 정의, 그리고 생략 시 기본값이 발견자라는 사실. cveproject.github.io
• 5.CVEProject/cvelistV5 저장소 — 3.1절의 역할별 집계(2026년 10월 22일, 공로 기록 보유 92,928건 기준)와 3.2절의 Google Big Sleep 레코드 열여덟 건. 센 방법과 한계는 3.1절 본문에 적었다. github.com
• 6.GitHub Docs. 저장소 보안 권고 작성 — 공로 대상의 역할 드롭다운에 'Tool'이 들어 있다는 3절 서술의 근거다.
• 7.CVE-2025-6965(구글, 2025-07-15) · CVE-2025-59730 · CVE-2025-62490(구글) · CVE-2025-9086(curl) · CVE-2025-11731 · CVE-2026-83596(레드햇) — 3.2절 표. 첫 번째 것의 공로 기록 문자열은 본문에 그대로 옮겼다.

PHP 쪽 1차

• 8.PHP Foundation. Today's PHP security release and how we're strengthening PHP security(2026-10-21) — 2.3절의 감사 인사말, 5절의 "구조적 실패", Chainguard 관련 문장, 생태계 보안팀 설립 시점(2026년 5월), 후원 요청 문장, 그리고 공개가 하루 앞당겨졌다는 서술이 전부 여기서 나왔다. thephp.foundation
• 9.php.net. Security advisory: Critical remote code execution vulnerabilities, update now(2026-10-21 14:00 UTC) — 1절의 두 결함 설명, 패치 판본 넷, 영향 범위, 그리고 완화 설정 권고. 본문의 완화 설정은 이 문서에 실린 것만 옮겼다. php.net
• 10.php/php-src 수정 커밋(지원 브랜치별) — 5절의 패치 규모 범위. 같은 변경이 브랜치마다 다른 해시로 들어가 있어 특정 해시 하나로 단정하지 않았다.
• 11.Daubois. CVE-2026-109618 PHP2Shell rumors(2026-10-21, PHP 보안팀 소속임을 밝힌 글) — 1절의 유출 경위, 그리고 CVSS 10.0이 유출 게시물 자신의 근거 없는 주장이었다는 교정. 공식 점수는 두 건 다 9.2다.

벤더 발표문 (1차이되 '주장'으로 인용)

• 12.Wiz. PHP2Shell: PHP RCE — 1절 타임라인의 8월 19일·24일, 4절의 모델 셋(Wiz Atlas · Gemini 4 Argon · GPT-5.6 Sol) 사용 서술. 이 글은 CISA가 두 CVE 레코드에 제3자 권고 참조로 붙여 뒀다. wiz.io
• 13.OpenAI. Patch the Planet: global response coordination as agents uncover critical vulnerabilities(2026-10-21) — 4.3절의 '방어자의 창' 인용과 Wiz를 구글 소속으로 밝힌 문장. ⚠️ 원문 페이지는 접근이 막혀 있어 전재본으로 확인했고, 본문에서도 그렇게 적었다.
• 14.Anthropic. 공격 표면 축소 연구 글(2026-10-20, Chris Rohlf, Frontier Red Team) — 4.2절의 분모 수치 전부와 측정 한계 문장. 이 과제는 취약점 발견이 아니고 PHP2Shell과 직접 관련이 없다.
• 15.구글 공식 계정의 Gemini 4 Argon 관련 게시물, Raluca Ada Popa(Google DeepMind) 발언 — 4.1절. "베이스라인 모델보다 두 배 넘게"의 근거가 될 측정 문서는 찾지 못했다.
• 16.Calif Research 자체 기록(Ryan Austin) — 4.3절의 "특별한 실험 장치도, 일반에 공개되지 않은 모델 접근도 쓰지 않았다"는 서술. ⚠️ 원문 주소를 확인하지 못해 전재본 경유로 인용했다.
• 17.Trail of Bits. Patch the Planet 프로그램 페이지 — 4절 Calif·오픈AI 행의 프로그램 단위 집계. 라이브 집계판이라 조회 시점에 따라 값이 달라진다.

메인테이너 부하 (1차)

• 18.Daniel Stenberg. Do minor curl vulnerabilities in the open(2026-10-20) — 5.1절의 10월 26일 전환, 과부하 인용, AI가 만든 제보의 성격, 90% 넘는 제보가 높음 등급 아래라는 서술. daniel.haxx.se
• 19.curl 취약점 공개 정책과 제보 접수 양식 — 3.2절의 AI 사용 고지 질문(2025년 5월 추가)과 5.1절의 버그바운티 중단·복귀 경위. curl.se
• 20.구글 OSS VRP 공지 — 2026년 3월 19일 규칙 강화와 10월 1일 제품 취약점 접수 중단. 5.2절. HackerOne 인터넷 버그 바운티의 2026년 3월 27일 신규 접수 중단 공지도 같은 절에 썼다. ⚠️ 같은 절의 플랫폼 전체 수치(제보 전년 대비 76% 증가, 유효 확인 25%)는 해커원 1차 공지문을 직접 열지 못해 보도 경유로 옮겼고, 본문에도 그렇게 적었다.

보도·분석 (귀속 명시해 사용)

• 21.BleepingComputer. PHP ships emergency patches for critical PHP2Shell flaws(2026-10-21) · Sansec. PHP2Shell 연구 글 · watchTowr. PHP CVE-2026-109618 FAQ · CrowdStrike 분석 — 1절 타임라인의 일부와 4.4절의 영향 범위 수치. ⚠️ 노출 조건에 대해 CrowdStrike와 Sansec의 평가가 갈리고, 둘이 서로 다른 CVE를 가리킬 가능성이 있어 본문에서 어느 쪽으로도 단정하지 않았다.
• 22.W3Techs. Usage statistics of PHP(2026-10-21 기준 69.3%) — 4.4절. 보도가 쓴 70%·75~80%와 나란히 놓았다. 구글의 Wiz 인수 종결(2026-03-11, 320억 달러)은 복수 매체와 알파벳 분기 공시로 교차 확인했다.

페블러스 블로그 인접 글

• 23.AI가 오래된 코드에서 결함을 찾은 앞선 사건(1절) · 공개와 무기화 사이가 하루 아래로 내려온 집계(1절) · 기구보다 기록 보존 규칙이 먼저다(3절·7절) · 자격은 공개돼 있는데 판정 기록이 없다(4절·7절) · 수치는 내걸고 측정 방법은 안 적는다(4절·7절) · 제보가 늘자 창구를 닫은 쪽(5절)