PHP2Shell은 AI가 널리 쓰이는 소프트웨어의 심각한 취약점을 찾아낼 수 있음을 보여줬다. 하지만 취약점 발견만으로 이용자를 지킬 수 있는 것은 아니다. 수정 사항을 만들고, 관련 업체와 운영자가 배포·적용할 수 있도록 조율하는 과정이 뒤따라야 한다. OpenAI는 2026년 10월 21일 발표에서 이번 대응이 AI의 단독 발견 사례가 아니라, 공개 전 두 달 동안 유지관리자와 연구자, 보안 업체들이 함께 준비한 작업이었다고 설명했다.
18
AI가 찾은 것은 무엇이었나
PHP2Shell은 PHP 핵심 코드에서 발견된 두 취약점, CVE-2026-109618과 CVE-2026-109619를 가리킨다. 두 건 모두 CVSS 9.2로 평가됐으며, 연구진은 로그인하지 않은 상태에서 WordPress, Drupal, Joomla 설치 환경에 원격으로 코드를 실행하는 상황과 메모리 정보 노출을 시연했다.
3
4 보고된 영향 범위는 PHP 5.4부터 PHP 8.5까지다.
1
문제는 PHP의 메모리 처리 과정에 있었다. 한 취약점은 메모리 부족 상황의 처리와 관련됐고, 다른 하나는 요청 사이에 오래된 내부 상태가 남아 해제된 메모리를 다시 참조하는 문제와 연관된 것으로 보고됐다.
3
9 다시 말해 특정 웹사이트 응용프로그램에 국한된 결함이 아니라, 그 아래에서 동작하는 PHP 자체의 취약점이었다.
3
4
OpenAI에 따르면 Calif는 자사의 Patch the Planet 프로그램에서 GPT-5.6 Sol을 활용해 중대한 취약점을 발견했고, Wiz도 두 취약점을 독립적으로 찾아 보고했다.
18 Wiz의 보고와 관련 보도는 Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol을 연구 도구로 언급한다.
4
33 다만 제공된 자료만으로는 각 모델이 맡은 작업을 명확히 나누기 어렵다. 따라서 어떤 모델이 공격 시험이나 패치 검증에 구체적으로 기여했는지 단정하기는 어렵다.
PHP Foundation의 발표를 인용한 2차 타임라인에는 Calif가 8월 11일, Wiz가 8월 24일, OpenAI가 9월 18일 PHP 측에 취약점을 보고한 것으로 나온다.
6 이는 보고가 이뤄진 날짜이며, 각 팀이 취약점을 처음 발견한 날과 반드시 같지는 않다.
공개 전 조율이 필요했던 이유
OpenAI는 취약점 공개에 앞서 수정 사항과 방어책을 준비하기 위해 유지관리자, 연구자, 보안 업체들과 두 달 동안 협력했다고 밝혔다.
18 PHP 유지관리자들이 수정과 버전 배포를 주도했고, 연구·보안 파트너들은 조사와 기술 지원, 조율을 뒷받침했다.
18
패치는 당초 예정된 10월 22일보다 하루 앞선 10월 21일 공개됐다.
14 보도에 따르면 정보 유출과 패치가 포함된 컨테이너 이미지의 조기 공개가 일정 변경과 맞물렸다. PHP Foundation은 Chainguard가 공개 유예 합의를 어겼다고 비판했다. 다만 이는 당사자의 주장이며, 제공된 보도만으로 독립적으로 결론이 난 사안은 아니다.
6
35
38
이번 일은 ‘조정된 취약점 공개’가 안고 있는 고민을 드러낸다. 세부 정보를 비공개로 유지하면 유지관리자와 배포 업체가 업데이트를 준비할 시간을 벌 수 있다. 반면 실제 공격이 진행 중이라면 공개와 패치가 늦어지는 동안 이용자가 위험에 노출될 수도 있다. 보도에 소개된 OpenAI의 대응 구상은 취약점 확인과 수정, 배포 업체의 사전 준비, 정부 파트너와의 협력, 더 넓은 대상에 대한 통지, 공개 안내 순으로 진행되는 단계적 절차다. 공격이나 정보 유출이 확인되면 일정을 앞당길 수 있다는 취지도 담겼다.
37
41
공격 시도 보고와 확인되지 않은 부분
Amazon은 자사의 MadPot 시스템이 PHP2Shell 악용 시도를 10월 17일 탐지했다고 밝혔다. 공개 나흘 전이다. 패치 공개 이후에는 더 광범위한 악용 시도가 있었다는 보도도 나왔다.
5 그러나 공격 시도가 관측됐다는 사실이 실제 서버 장악의 성공을 뜻하지는 않는다. 현재 제공된 보도는 공격자가 공개 전에 취약점 정보를 어떻게 알게 됐는지, 실제로 침해된 서버가 몇 대인지는 확인해주지 않는다.
Palo Alto Networks는 PHP2Shell에 취약할 가능성이 있는 인터넷 연결 인스턴스가 2,260만 개 이상이라고 추산한 것으로 보도됐다.
53 여기서 ‘취약할 가능성이 있다’는 수치는 노출 규모 추정치이지, 실제 악용이 가능하거나 침해가 확인된 시스템의 수가 아니다.
당국은 조직에 신속한 조치를 촉구했고, 한 보도는 빠르게 보안 조치를 할 수 없다면 시스템을 오프라인으로 전환하라는 권고가 있었다고 전했다.
56 Cloudflare는 자사 웹 애플리케이션 방화벽(WAF)을 이용하는 고객을 위해 공개 전 방어 규칙을 배포했다고 밝혔다.
12 이런 보호 조치는 패치와 함께 적용할 수 있는 보완책이지, 영향을 받는 PHP 설치를 확인하고 업데이트할 필요를 없애지는 않는다.
취약점을 수정한 것으로 보고된 PHP 버전은 8.2.35, 8.3.36, 8.4.27, 8.5.12다.
8 운영자는 사용 중인 PHP 배포판과 버전을 확인해야 한다. 리눅스 배포판이나 서비스 제공업체에 따라 패키지 버전 표기가 다를 수 있기 때문이다.
8
발견의 속도만큼 중요한 대응 역량
OpenAI는 보안 방어자를 위한 Daybreak 이용권을 보조하는 데 10억 달러를 약속했다고 밝혔다. 보안 자원이 부족하면서 핵심 서비스를 보호하는 조직을 우선 지원 대상으로 꼽았다.
25 이는 방어자가 보안 도구에 접근하도록 돕는 한 축이다. PHP2Shell은 여기에 더해, 수정 사항을 준비하고 알리고 실제로 배포하는 역량이 소프트웨어 생태계 전반에 필요하다는 점을 보여준다.
AI를 활용한 연구는 취약점 발견에 힘을 보탤 수 있다. 그러나 무엇이 발견됐는지, 어떤 도구가 기여했는지, 공격이 실제로 성공했는지는 출처를 구분해 신중하게 설명해야 한다. PHP2Shell에서 얻을 수 있는 결론은 분명하다. 취약점을 일찍 발견하면 방어자에게 귀중한 시간을 벌어줄 수 있지만, 그 시간을 패치 준비와 전달, 적용에 쓰지 못한다면 방어의 기회도 제한된다.