이 글 공유하기

PHP 코어 구조를 형상화한 이미지, 두 줄의 균열과 빛의 빔 PHP2Shell 사건의 핵심을 형상화했습니다. 레거시 웹 구조의 코어를 관통하는 두 균열과, 그 균열을 비추는 한 줄기 탐지광입니다.

왜 읽어야 하나

웹 서비스 인프라를 돌보거나, 에이전트 플랫폼의 보안 정책을 설계하는 개발자라면 이 글을 읽어야 합니다. 이유는 하나입니다. 이번 사건은 “AI가 취약점을 찾는다”를 실제 프로덕션 코어에서 확인한 첫 대규모 사례이기 때문입니다. 핵심 결론을 먼저 씁니다. 플랫폼 팀의 질문은 이제 “우리 코드에 AI가 취약점을 찾을 것인가”에서 “발견되는 순간, 공격자보다 빠르게 대응할 수 있는가”로 옮겨갔습니다.

개요

10월 21일, 25년 이상의 역사를 가진 스크립트 언어 PHP의 코어에서 두 개의 치명적 취약점이 동시에 공개되고 패치가 나왔습니다. 이름은 PHP2Shell입니다. CVE-2026-109618과 CVE-2026-109619, 이 두 개의 식별자가 가리키는 것은 원격 코드 실행(RCE)과 Heartbleed식의 메모리 정보 유출입니다. 영향 범위는 PHP 5.4에서 8.5, 사실상 현재 유지되는 모든 버전입니다.

이번 사건에서 눈여겨볼 점은 발견 주체입니다. OpenAI는 두 취약점 중 하나를 보안 테스트 협력사 Calif가 GPT-5.6 Sol로 찾아냈다고 발표했습니다. 구글 산하 보안 기업 Wiz는 두 취약점을 모두 독립적으로 발견해 신고했다고 밝혔습니다. OpenAI에 따르면 PHP는 인터넷 웹의 약 70%를 뒷받침하는 언어입니다. 이번에 취약점이 나온 곳은 웹 상당 부분이 의존하는 PHP 코어입니다.

PHP는 1995년에 나온 언어로, 30년 가까이 웹의 동적 콘텐츠를 처리해 왔습니다. 그 생태계는 안정성보다 빠른 구현을 우선하는 실용주의가 중심이었습니다. 코어의 결함은 프레임워크 수준의 결함보다 영향 범위가 넓습니다. 이번 사건의 무게는 취약점이 언어 엔진 자체에 있다는 점에 있습니다.

웹의 70%를 지탱하는 25년 된 PHP 코어를 형상화한 슬라이드 PHP는 인터넷 웹 생태계의 약 70%를 지탱하며 “안정성보다 실용성”을 바탕으로 누적된 런타임의 역사입니다.

무슨 일이 있었나, 두 개의 구멍

기술적으로 이번 취약점은 두 축으로 구성됩니다. 첫 번째인 CVE-2026-109618은 원격 코드 실행입니다. Wiz의 설명에 따르면 공격자는 조작한 HTTP 요청 하나만으로 서버의 권한으로 코드를 실행시킬 수 있었습니다. PHP로 동작하는 웹 서버라면 추가 인증이나 특별한 설정 없이 공격할 수 있다는 뜻입니다. 두 번째인 CVE-2026-109619는 메모리 정보 유출입니다. Wiz는 이를 Heartbleed식이라 표현했는데 2014년 OpenSSL을 흔든 Heartbleed가 프로세스 메모리를 새어나가게 만들었던 것처럼, 메모리에 머물던 기밀 데이터가 공격자에게 노출되는 유형입니다.

두 취약점이 동시에 PHP 코어에서 발견된 것은 이례적입니다. RCE로 진입한 뒤 메모리 유출로 기밀을 수집하는 결합 공격도 생각해 볼 수 있습니다. 공시도 같은 날 나란히 나왔습니다.

PHP 코어의 두 취약점, RCE와 메모리 유출의 구조를 보여주는 슬라이드 CVE-2026-109618(RCE)은 외부의 단일 HTTP 요청만으로 서버 권한을 장악하고 CVE-2026-109619는 Heartbleed식으로 프로세스 메모리의 기밀 데이터를 노출합니다.

사건의 이름 PHP2Shell이 “누출된 익스플로잇에서 유래했다”는 보고(Wikipedia PHP2Shell 항목)가 있는 점도 주목할 만합니다. 공시 전에 익스플로잇이 이미 외부에 돌아다녔거나 익스플로잇이 존재한다는 증거가 유출된 상태에서 사건 이름이 붙었다는 뜻일 수 있습니다. ellio.tech의 모니터링 보고는 실제 익스플로잇 시도가 관측되었다고 전합니다. 즉, 공개와 패치 시점에 이미 공격이 진행됐을 가능성이 있습니다.

PHP 생태계의 규모를 생각하면 파장이 큽니다. 콘텐츠 관리 시스템, 이커머스 플랫폼, 관리 콘솔. 레거시 웹의 상당 부분이 PHP 위에 올라가 있고 그 상당수가 5.4~8.5 구간 안에 있습니다. 개별 서비스의 위험도는 노출 면적과 설정에 따라 크게 다르지만 “PHP로 돌고 있다”는 사실 자체가 이번 주에는 점검 대상이 되었습니다.

발견의 과정, 2개월간의 연합

사건의 타임라인은 8월 말로 거슬러 올라갑니다. 보고에 따르면 취약점은 8월 말경에 이미 발견되었고 그 후 약 2개월 동안 조정된 대응이 진행되었습니다.

발견 주체에는 두 개의 독립된 경로가 겹쳐 있습니다. 첫 번째는 OpenAI 쪽입니다. OpenAI는 보안 테스트 기업 Calif가 자신의 “Patch the Planet” 이니셔티브 안에서 GPT-5.6 Sol을 사용해 두 취약점 중 하나를 식별했다고 발표했습니다. OpenAI 블로그의 제목이 “에이전트가 치명적 취약점을 파헤치며, 글로벌 대응 조정이 어떻게 작동하는가”인 것처럼, OpenAI는 이 사건을 모델의 발견 능력과 조정 프로세스라는 두 축으로 설명했습니다. 두 번째는 Wiz입니다. Wiz의 블로그는 AI가 발견한 RCE 취약점과 Heartbleed식 메모리 유출을 다루며 Wiz 역시 두 문제를 독립적으로 발견하고 신고했다고 밝힙니다.

서로 독립적인 두 경로가 같은 취약점에 도달했다는 점에서, 이번 발견은 우연이 아닌 구조적인 신호로 읽을 수 있습니다. 다른 팀이 다른 방식으로 같은 코어의 같은 취약점을 찾아냈습니다.

OpenAI·Calif와 Google Wiz의 독립적 동시 발견을 보여주는 슬라이드 OpenAI·Calif(GPT-5.6 Sol, Patch the Planet)과 Google Wiz(독립 보안 연구)가 동일한 코어의 같은 구멍을 각각 찾아냈습니다.

공시는 10월 21일 14시(UTC)에 조정된 형태로 나왔습니다. sansec.io의 보고에 따르면 PHP 프로젝트가 같은 시각에 두 취약점에 대한 수정을 공개했습니다. OpenAI는 개발자가 자신의 서비스가 영향받는지 확인하도록 도구를 함께 내놓았다고 The Verge가 전합니다. 개발자가 CVE 목록을 직접 읽고 자기 환경에 대조하는 대신, 도구로 영향 여부를 빠르게 판정할 수 있게 한 것입니다. 즉 이번 공시는 영향 확인 도구가 함께 제공된 패치 공지였습니다. 네덜란드 국가사이버보안센터 NCSC-NL은 운영 정보를 담은 저장소를 열었고 CERT-EU도 두 CVE를 추적하고 있습니다.

방어자와 공격자의 2개월 타임라인을 보여주는 슬라이드 8월 말 최초 발견부터 10월 21일 14시(UTC) 조정 공시까지의 2개월. 공시 전에 익스플로잇은 이미 외부에서 돌아다녔으며 ellio.tech의 실제 공격 시도 관측이 이를 뒷받침합니다.

그리고 OpenAI는 “이것은 아직 시작”이라고 말했습니다. Andrew Curran의 트윗에 따르면, OpenAI는 PHP 보안 결함(GPT-5.6 Sol로 발견)을 “빙산의 일각”에 비유하며 추가로 발표할 발견이 여러 개 더 있다고 전했습니다. 이번 PHP2Shell은 그 첫 사례로 볼 수 있습니다.

왜 이것이 보안 운용의 분기점인가

기술 뉴스의 틀에서 보면 “PHP에 버그가 발견됐고 패치가 나왔다”는 이벤트입니다. 하지만 플랫폼 보안의 관점에서 이 사건이 남기는 신호는 네 가지입니다. 모두 취약점을 발견하는 속도와 패치하는 속도가 벌어졌다는 구조적 변화와 관련됩니다. 발견과 패치 사이의 간극이 새로운 운용 변수가 되었다는 점을 하나씩 살펴봅니다.

첫째, 프론티어 모델이 실제 프로덕션 코어의 실제 취약점을 찾았다는 확인입니다. 대상은 CTF나 합성 벤치마크가 아닌, 인터넷 위에서 실제로 돌고 있는 25년 된 코어입니다. 이 사건은 AI가 코드를 이해하는 수준을 넘어 실제 결함을 찾는 단계에 왔음을 보여 줍니다.

둘째, 발견이 복제 가능하다는 점입니다. Calif와 Wiz, 두 팀이 같은 취약점을 각각 발견했습니다. 이는 같은 급 모델 전반의 능력으로 읽어야 하는 신호입니다. 공격자도 같은 모델을 쓸 수 있다면, 방어자가 먼저 취약점을 발견해 대응할 수 있는 시간이 구조적으로 줄어듭니다.

여기에 더해 발견 비용의 비대칭도 짚어야 합니다. 과거에는 어떤 코어에 어떤 종류의 결함이 숨어 있는지를 찾는 일이 인간 보안 연구원의 수개월 단위 노력이었습니다. 이번 사건에서는 그 노력의 상당 부분을 모델이 맡았다고 알려졌습니다. 발견에 드는 비용이 낮아지면 같은 코어를 살피는 주체가 늘어납니다. 주체가 늘면 누군가 언제든 발견할 확률이 높아지고, 방어자 측의 “발견되지 않겠지”라는 가정은 더 이상 성립하지 않습니다.

레거시 시대와 AI 시대의 비대칭을 비교하는 슬라이드 발견 주체가 “소수의 인간 전문가”에서 “상시 가동되는 AI 에이전트”로, 방어 전제가 “숨어 있으면 안전”에서 “언제든 발견된다”로 바뀐 비대칭 매트릭스.

셋째, 조정 자체가 체계를 갖추고 있다는 점입니다. 모델 벤더(OpenAI), 보안 기업(Wiz, Calif), 언어 프로젝트(PHP), 국가 CERT(NCSC-NL, CERT-EU), 미디어(TechCrunch 등)가 같은 2개월 안에 하나의 공시로 수렴했습니다. AI가 발견한 취약점에 대한 “공시 인프라”가 이 사건에서 처음 제대로 작동했습니다.

넷째, 공격이 공시 전에 이미 시작됐다는 점입니다. 익스플로잇 유출 보고와 실제 시도 관측은, 방어 쪽이 패치를 준비하는 동안 공격 쪽이 탐색을 마쳤을 가능성을 시사합니다. 이 상황에서 “패치는 언제 나오나”가 아니라 “패치 배포까지의 시간”이 방어 성과의 결정 변수가 됩니다.

이 네 가지가 겹치면, 플랫폼 팀의 보안 운용에 필요한 전제가 바뀝니다. 더 이상 “우리 코드는 외부 AI가 읽지 않는다”는 가정으로 안전을 설계할 수 없습니다. 공개되는 모든 코드와 의존성은, 상시 가동 중인 “취약점을 찾는 에이전트”의 입력으로 취급해야 합니다.

ThakiCloud 제품 적용 시사점

이번 사건은 ThakiCloud의 Paxis와 ai-platform 두 관점에서 시사점을 남깁니다.

Paxis 렌즈에서 보면, Paxis는 에이전트·스킬·정책·감사로그를 일급 리소스로 다루는 Agent-Native Cloud입니다. “에이전트가 취약점을 찾는다”는 시대가 시작되었는데 그 에이전트의 동작을 포착하는 감사로그와, 어떤 범위에서 어떤 코드를 읽을 수 있는지를 통제하는 정책 게이트는 이제 선택지가 아니라 플랫폼의 기본 안전장치입니다. Paxis가 고객 환경에서 보안 점검용 에이전트를 운용한다면, 이번 PHP2Shell이 보여주듯 “에이전트가 발견한 것”과 “그 발견이 어떻게 조정되었는가”가 동일하게 중요한 기록이 됩니다. 발견 능력만큼 조정 기록도 중요한 자산이 됩니다.

ai-platform 렌즈에서 보면, ThakiCloud의 ai-platform은 K8s 위에서 고객의 AI/ML 워크로드를 서빙하는 인프라입니다. ThakiCloud 자체 스택은 Go 기반이라 이번 PHP 취약점의 직접적 영향은 적습니다. 그러나 고객 워크로드의 상당수는 레거시 웹 서비스와 연동되고 그 레거시의 상당 부분이 PHP 위에 올라가 있습니다. 플랫폼 팀이 할 일은 두 가지입니다. 하나는 자신의 의존성과 연동 레이어에서 유사한 “코어 레벨 취약점”이 발생했을 때 탐지부터 고객까지의 전파 시간을 줄이는 것, 다른 하나는 고객이 자신의 PHP(혹은 유사한) 워크로드를 점검할 수 있도록 플랫폼 차원의 CVE 알림과 패치 가이드를 제공하는 것입니다.

구체적으로 이번 주에 점검할 것 세 가지를 꼽으면, (1) 플랫폼과 고객 워크로드가 의존하는 언어 런타임의 최신 패치 상태 확인, (2) CVE 공개 시 고객까지 알림이 도달하는 경로의 전파 시간 측정, (3) 에이전트 기반 보안 점검을 도입할 경우 정책 게이트와 감사로그가 어떤 범위의 코드를 읽는지 정의하는 것입니다.

ThakiCloud 환경의 세 가지 즉각적 실행 과제를 보여주는 슬라이드 런타임 패치 상태 검증, 전파 시간(TTN) 측정, 에이전트 권한 재정의. 이번 사건을 플랫폼 프로세스의 스트레스 테스트로 삼는 세 단계.

한 줄로 요약하면, 이번 사건은 ThakiCloud의 보안 운용 프로세스에 대한 “스트레스 테스트”로 읽을 수 있습니다. 직접적 피해는 없지만 우리의 프로세스가 이 속도를 버틸 수 있는지 점검할 계기입니다.

한계 및 반론

이 사건에 대한 설명을 그대로 받아들이기 전에, 몇 가지 반론도 함께 살펴야 합니다.

첫째, “AI가 발견했다”는 표현에는 홍보성 과장의 위험이 있습니다. 실제 발견은 인간 보안 기업(Calif)이 모델을 사용해 수행했고 조정 역시 인간 중심의 프로세스였습니다. “AI 보조 발견”에 가깝고 “AI 단독 발견”으로 부르기는 어렵다는 점을 분명히 해야 합니다. 그리고 모델이 실제로 어떤 역할을 했는지, 인간의 가설과 모델의 검색이 어떻게 배분되었는지는 아직 충분히 투명하게 공개되지 않았습니다.

둘째, PHP의 나이 문제입니다. 25년 이상의 생태계에서 구조적으로 누적된 결함이, AI의 등장으로 “새롭게” 발견된 것인지, 아니면 AI가 발견 속도를 높인 것인지는 구분해야 합니다. 후자에 가깝다면, 이번 사건의 의미는 “AI의 위협”이 아니라 “발견 속도의 비대칭”에 더 가깝습니다.

셋째, 익스플로잇 유출의 본질입니다. 공시 전에 익스플로잇이 돌아다녔다면, 사건의 실질적 피해는 “패치 전의 시간 창”에서 발생했을 가능성이 높습니다. 이 경우 언론과 모델 벤더가 주목하는 “AI 발견”보다, 운영자가 주목해야 하는 것은 “패치 배포 지연”입니다.

넷째, 영향 범위의 과대 해석입니다. 두 개의 취약점이 “웹 전체를 무너뜨린다”는 것은 아닙니다. 개별 서비스의 위험은 노출 면적, 입력 검증, WAF, 패치 상태에 따라 크게 달라집니다. “PHP를 쓴다”는 사실만으로 패닉할 필요는 없지만 “PHP를 쓰고 있다”는 사실만으로 점검 대상에 올릴 이유는 충분합니다.

사건 서사의 한계와 현실을 정리한 슬라이드 AI 마케팅의 이면(“AI 보조 발견”), 실질 피해가 발생하는 패치 전 시간 창, 그리고 과대 해석의 경계. 패닉 대신 점검이 필요합니다.

정리

이번 주, 웹의 70%를 돌리는 언어의 코어에서 두 개의 치명적 취약점이 공개되었고 그 발견의 한 축이 프론티어 모델이었다는 점이 확인되었습니다. PHP2Shell은 “AI가 코드를 읽는다”의 다음 문장, “AI가 코드의 결함을 찾는다”를 현실로 만든 사건입니다.

독자가 취할 조치는 다음과 같습니다. PHP 5.4~8.5를 돌리는 서비스가 있다면 오늘 패치 상태를 확인하고 OpenAI가 내놓은 확인 도구와 NCSC-NL의 운영 정보를 점검에 활용하시기 바랍니다. 플랫폼 팀이라면 이번 사건을 “우리 프로세스의 스트레스 테스트”로 삼아 탐지에서 고객 전파까지의 시간을 측정해 보시기 바랍니다.

결론의 한 문장을 담은 슬라이드 “AI가 우리 코드의 취약점을 찾을 것인가”는 더 이상 질문이 아닙니다. 질문은 “발견되는 순간, 공격자보다 빠르게 대응할 수 있는가”로 이동했습니다.

한 줄 결론. “AI가 우리 코드의 취약점을 찾을 것인가”가 더 이상 질문이 아닌 시대에, 질문은 “발견되는 순간, 공격자보다 빠르게 대응할 수 있는가”로 이동했습니다. 그 답이 플랫폼 팀의 보안 성숙도를 가르는 기준입니다.

출처

이 글 공유하기

태그: agentops, paxis, 보안

카테고리:

업데이트:

참고

The Twin Registry: 셀프에볼빙 2,200 스킬 레지스트리의 twin(근접 중복 스킬) 축적 법칙, 4채널 라우팅 오류 귀속, merge vs rewrite 중복 제거 dividend를 분석으로 세운 논문

 

레지스트리가 커지지 않아도 라우팅 top-1은 늙습니다. twin 축적 법칙, 4채널 오류 귀속, merge vs rewrite 중복 제거 dividend를 분석으로 세운 ThakiCloud의 논문 The Twin Registry를 소개합니다. 분석 논문이라 모든 값은 실측이 아닙...

궁금함은 계산 가능한 신호일까: Schmidhuber가 ICML 2026에서 interestingness를 ‘미래 압축 진전의 귀납적 휴리스틱’으로 형식화한 포지션 페이퍼

 

X에서 ‘왜 아름다운지, 왜 웃긴지’ 답한다는 논문이 돌았습니다. 그 논문은 Herrmann과 Schmidhuber의 ICML 2026 포지션 페이퍼이고, 실제 주장은 좀 더 좁습니다. interestingness, 즉 미래 압축 진전의 잠재가 과거 진전 기록에서 예측 가능한 신호...