요약
보안 회사 위즈가 AI 모델을 써서 지난 10년간의 PHP 버전에 걸친 원격 코드 실행 취약점을 찾아냈습니다.
클라우드 보안 회사 위즈 연구팀이 PHP 엔진 핵심부에서 메모리 안전성 버그 네 개를 찾아 PHP2Shell이라는 이름으로 공개했습니다. PHP는 10월 21일 패치를 내놓았고, 위즈는 Gemini 4 Argon과 GPT-5.6 Sol의 도움으로 연구자 한 명이 일주일 만에 공격 코드까지 만들었다고 밝혔습니다.
왜 중요한가
- 애플리케이션이 아니라 PHP 자체의 결함이라서 간단한 "Hello World" 서버도 영향을 받습니다.
- 전 세계 웹사이트의 약 70%가 PHP를 쓰고, 최근 10년 사이 나온 모든 버전이 하나 이상의 취약점에 노출됩니다.
- 위즈는 최상급 팀이 몇 달 걸리던 공격 개발을 AI가 크게 앞당겨 공격의 문턱이 낮아졌다고 봤습니다.
핵심 내용
- 메모리 부족 같은 치명적 오류로 요청이 비정상 종료될 때, 망가진 내부 상태가 다음 요청에 남는 것이 원인입니다.
- 네 버그를 엮은 스크립트로 최신 WordPress, Drupal, Joomla에서 인증 없이 원격 코드 실행에 성공했습니다.
- 그중 하나는 하트블리드처럼 다른 요청의 비밀번호나 API 키가 담긴 메모리를 쿠키로 흘려보냅니다.
- 두 CVE로 묶였고, 심각도는 CVSS(취약점 위험도 점수, 10점 만점) 9.2까지 올라갑니다.
- 8월 24일 신고 뒤 PHP가 확인하기까지 한 달이 걸렸고, 업데이트만이 완전한 해결책이라고 했습니다.
HN 반응
- 캘리프와 오픈AI가 같은 날 같은 원인을 독립적으로 신고했다는 PHP 재단 설명에 지나친 우연이라는 의문이 이어졌습니다.
- 결국 C의 메모리 안전성 문제이니 새 코드를 C로 쓰지 말자는 주장과, 규율 있게 쓰면 된다는 반론이 맞섰습니다.
제가 파악한 바로는 이렇습니다. OpenAI가 (어떤 모델인지는 밝히지 않은 채) 찾아냈고, Wiz도 (Gemini Argon으로) 독자적으로 찾아냈습니다. 그런데 그 전에 Calif가 (역시 모델은 밝히지 않았지만 일반인이 쓸 수 있는 모델로) 찾았고, Calif는 최초 발견과 공개, 수정 작업을 한 쪽이 LCFR_HAX라고 밝히고 있습니다.
LCFR이나 Calif 중 한쪽이 (발견이나 수정 과정에서 일반인이 쓸 수 있는 최신 모델을 써서) 학습 데이터에 이 내용을 넣었고, OpenAI가 그 학습 데이터에서 그대로 재현해 낸 건가 싶습니다. 나비에-스토크스 선점 사건 같은 식으로요. 다만 이번엔 아마 본인들도 몰랐을 가능성이 크고, 게다가 늦기까지 했죠. 이미 진행 중인 수정 작업을 몰랐으니 자기들이 새로 발견했다고 생각했을 겁니다. 전부 너무 헷갈리는데, 여기에 유출과 홍보전까지 더해지니 도저히 갈피를 잡을 수 없게 됐습니다.
수정: PHP 재단 덕분에 이제 앞뒤가 맞네요. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
저는 타임라인상 학습 데이터에 들어갔을 가능성은 없다고 봅니다. LLM 학습은 외톨이 사례 하나에서 이런 걸 배울 만큼 효율적이지 않은 것 같고, 이전의 작업이 OpenAI와 Gemini의 데이터에 둘 다 들어갔다는 것도 말이 안 됩니다. 나비에-스토크스는 이런 일이 벌어질 수 있다는 강한 증거가 못 됩니다. OpenAI는 버크마스터의 작업이 자기들이 쓴 모델의 학습 데이터에 없었다고 부인하고, 버크마스터에게는 훔칠 만한 돌파구가 없었으며, Scientific American[1]에 따르면 두 접근법의 유사성은 피상적이었으니까요. 게다가 모델이 새로운 취약점을 찾아낼 수 있다는 건 이제 충분히 입증된 사실입니다.
[1] https://www.scientificamerican.com/article/openais-blockbuster-navier-stokes-proof-isnt-what-we-thought-it-was/
제가 그 글을 쓸 때 이해한 바는 "다른 누군가가 채팅 기록이 남는 OAI 모델을 씀: 9월???, OAI는 모델 불명: 10월???"이었고, "나비에-스토크스식 선점"이라고 한 건 그 논란 때 제가 남긴 댓글과 같은 맥락입니다. https://news.ycombinator.com/item?id=49639648 저는 그쪽의 공식 입장이 "기술적으로는 맞지만 내부 사정을 모르면 오해하기 쉬운" 말이 아니라는 데는 동의하지 못합니다.
물론 PHP 재단 링크에서 나온 새 정보(특히 OAI가 Calif와 같은 날 보고했고, Calif가 OAI 프로그램의 후원 아래 활동했다는 점)로 제 첫인상의 타임라인은 무너졌습니다!
"인터넷을 훔쳤다" 타령, 이게 요즘 새로 나온 현실 외면이죠.
(PHP 재단은 PHP 프로젝트를 Patch the Planet 프로그램에 참여시켰고, 그 일환으로 보안 업체 Calif가 2026년 7월 30일 PHP 감사에 착수했습니다. 8월 11일 Calif의 연구원 Ryan A가 2024년에 우리가 찾아낸 OOM 문제와 근본 원인이 같은 무조건적 원격 코드 실행 취약점을 보고했습니다. OpenAI도 같은 날 같은 근본 원인을 독자적으로 보고했습니다)
이게 어떻게 가능한 겁니까? Calif는 Patch the Planet 프로그램으로 OAI와 협력합니다. Calif가 PHP에 발견 내용을 보고합니다. 그런데 OAI도 같은 날 '독자적으로' 보고합니다. Calif가 발견 내용을 OAI와 공유했을 것 같은데, 아니면 Patch the Planet은 원래 그렇게 돌아가지 않는 건가요? 너무 우연처럼 보입니다.
(8월 11일 Calif의 연구원 Ryan A가 2024년에 우리가 찾아낸 OOM 문제와 근본 원인이 같은 무조건적 원격 코드 실행 취약점을 보고했습니다. OpenAI도 같은 날 같은 근본 원인을 독자적으로 보고했습니다)
참 우연도 이런 우연이 없네요.
보고에서 공개까지 두 달이나 걸린 이유를 설명해 주실 분 있나요? 책임 있는 공개(Responsible Disclosure)가 어떤 개념인지는 압니다만, 타임라인과 심각도를 보면 그 시점이 이해가 안 됩니다. 특히 확인 응답까지 한 달이 걸렸다는 게요.
수정: 알고 보니 이미 5년도 더 전에 보고된 적이 있다고 하네요 [0]. 알아볼수록 더 헷갈립니다. 지난 10년 동안 일부러 PHP를 피해 오지 않은 사람이 잘 쓴, 사실에 기반한 사후 분석을 기대합니다.
[0] https://news.ycombinator.com/item?id=50181395
6년 전에 패치된 버그가 어떻게 오늘 RCE를 일으킨다는 거죠? 링크가 맞는지 모르겠네요.
6년 전에는 악용하기에 너무 복잡하다고 판단해서 우선순위를 높게 두지 않았던 겁니다.
'책임 있는' 공개 타임라인에 무책임한 공개가 빠져 있는 건 누가 설명해 주실 수 있나요? 조율된 배포 직전에 벌어진 그 일 말입니다.
PHP 공지에 따르면 빠진 부분은 이렇습니다.
(10월 21일 UTC 07:41, 조율된 배포보다 여섯 시간도 더 전에 Chainguard가 일방적으로 엠바고를 깨고 수정이 담긴 빌드 이미지를 공개했습니다. 다른 배포 업체들처럼 Chainguard도 취약점이 공개되는 즉시 사용자가 업데이트할 수 있도록 패치를 미리 받았습니다. 이제 다른 모든 PHP 사용자가 배포를 기다리는 동안 공격자는 누구든 바이너리 형태의 수정본을 분석할 수 있게 됐습니다. 이는 조율된 공개를 위해 여러 관계자가 수주 동안 들인 노력을 무시한 행위였습니다)
X나 다른 소셜 미디어에 올라오는 AI 쓰레기 글은 좀 그만 읽어야 합니다. 이 익스플로잇은 고난도였고 고치는 데도 상당한 노력이 들었습니다. 누구나 쓸 수 있는 RCE가 정말로 PHP에 열려 있었다면 파급력이 엄청났을 겁니다.
죄송한데 무슨 말씀이시죠? PHP에 열려 있는 RCE가 있었고(지금도 있고) 파급력도 엄청났습니다(지금도 그렇고요). 특히 구버전을 쓰는 팀들은 안됐습니다.
그럼 이 익스플로잇 때문에 "해킹당했다"고 확인된 사이트는 어디죠? Log4J는 마인크래프트를 비롯해 다른 서비스도 많이 망가뜨렸잖아요.
방금 공개된 거잖아요. 좀 기다리세요. PHP RCE는 농담이 아닙니다.
국가 지원 해커들 같은 쪽은 익스플로잇이 공개되기 한참 전부터 어떻게 쓸지 준비해 둡니다. 알려진 RCE가 PHP에 열려 있었다면 즉시 난리를 쳤을 겁니다. 그런 일은 분명히 없었고요.
여기가 HN 맞나요, 아니면 꼰대들 페이스북인가요? 이제 모르겠네요.
아직은 모릅니다. 그게 있든 없든 뭐가 달라지는지도 모르겠고요. 영향은 실제로 악용되는 것만으로 끝나지 않습니다. 유출도 그 면에서 좋지 않았고요.
Wiz와 Calif의 분석 글을 읽어 보니, 이슈 5~6개가 CVE 2개에 대응됩니다.
Wiz (GPT 5.6 Sol + Gemini 4 Argon 사용): 원격 프로세스 메모리 노출, OPcache 타입 혼동, 치명적 오류 백트레이스 UAF. WordPress, Drupal, Joomla에서 개념 증명(POC)을 보였습니다.
Calif (LLM 사용, 특정 모델은 밝히지 않았지만 누구나 쓸 수 있는 모델): Zend HashTable OOM. PHP-FPM과 mod_php가 대상입니다.
둘 다 업로드 진행률 unserializer의 UAF를 발견했습니다.
POC에 나오는 춤추는 애니메이션 소녀를 정말 Calif 연구원들이 올렸다니 놀랍네요.
참고로 구버전에 대한 백포트 수정은 신버전처럼 문제를 고치는 게 아니라 세션 업로드 자체를 통째로 꺼 버리는 것 같습니다.
https://github.com/php/php-src/commit/712e60f9edfd03f0960fc4fc3c2c375f42b90aa2#comments
둘 다 메모리 안전성 문제네요. 이번 10년에 C는 더는 쓸 만한 도구가 아닙니다.
프로그래머가 C의 기능을 현명하지 못하게 쓰고 그 결과 버그 있는 코드를 짜는 것은 C의 잘못이 아닙니다. 안전한 C 코드를 쓰려면 규율이 필요하고, 대개는 언어의 일부 하위 집합으로 스스로를 제한해야 합니다.
그래서 Rust 같은 언어가 존재 의의가 있는 겁니다. 컴파일러가 C에는 없는 규율과 절제를 강제하니까요. Rust에서 메모리 안전성 문제가 있는 코드를 쓰는 게 불가능한 것은 아니고, 훨씬 어려울 뿐입니다. Java에 대해서도 같은 말을 했던 기억이 납니다. 프로그램을 쓰는 게 쉬워지지는 않지만, 몇몇 버그를 쓰기 어렵게 만들어 줍니다.
(프로그래머가 C의 기능을 현명하지 못하게 쓰고 그 결과 버그 있는 코드를 짜는 것은 C의 잘못이 아닙니다. 안전한 C 코드를 쓰려면 규율이 필요하고, 대개는 언어의 일부 하위 집합으로 스스로를 제한해야 합니다.)
분명히 C 탓도 있습니다. 증거가 말해 주는 바로는, 지혜와 규율, C의 모든 기능과 흔히 쓰이는 모든 libc를 합친 것에 대한 불가능에 가까운 백과사전급 지식, 오타 한 번 내지 않는 비인간적인 완벽함, 그리고 그래도 빠져나온 버그 일부를 찾아내 줄 방대한 분석 도구가 필요합니다.
제가 꼽을 수 있는 가장 훌륭하고 가장 신뢰받고 가장 업적이 큰 C 프로그래머들도, 어떤 언어로 짜든 생길 수 있는 평범한 로직 버그뿐 아니라 C의 함정(footgun)이 일으킨 취약점을 만든 전적이 있습니다. 제가 OpenBSD 팀보다, 리눅스 개발자들보다, "뭐든 다 만든" 파브리스 벨라르보다 꼼꼼한 C 코드를 쓸 수 있을까요? 어림없습니다. 그런데 C는 그분들 모두를 물었습니다. 우리 같은 범인에게 승산은 없습니다.
(우리 같은 범인에게 승산은 없습니다.)
저는 그저 더 작은 걸음으로 나아가고, 점진적으로 테스트하고, 방대한 도구로 코드의 허점을 찔러 보면서, 리눅스/BSD 개발자나 벨라르 같은 실력을 키우는 문제라고 봅니다. 그분들만큼 많은 일을 해내진 못할 수도 있지만, 그것도 괜찮습니다. 세상에는 여전히 더 단순한 프로그램이 필요하니까요.
그래도 굳이 왜 그렇게 합니까? 저는 하루에 8시간 안팎으로 코드를 짭니다. 7시간 30분은 비즈니스 로직을 짜고 30분은 컴파일을 통과시키는 데 쓰거나(Rust/Python/Java/C#/뭐든), 아니면 30분은 비즈니스 로직을 짜고 7시간 30분은 RCE를 심지 않았다고 스스로를 납득시키는 데 쓰거나, 둘 중 하나입니다. 지금 시대에 사소하지 않은 C 프로그램을 새로 짜야 할 정당한 사례가 저는 보이지 않습니다. 기존 프로그램을 유지보수하는 건 물론 해야죠. 그런 건 사라지지 않을 테니까요. 하지만 지금 새로 뭔가를 C로 짠다면 엔지니어링 직무유기로 보입니다.
"안전한 C 코드를 쓰려면 규율이 필요하다"
아, 그 흔한 "도구를 잘못 쓰고 계신 겁니다" 말이군요.
그럴 수도 있겠죠. 하지만 아무도 제대로 쓰지 못하는 것 같은 도구라면요. 커널 버그, 곳곳의 제로데이, 아주 엄격하고 철저해 보이는 사람들이 만든 cURL의 버그, 구글과 마이크로소프트 제품의 버그 등을 보세요. 이 문제에서 그 도구가 무죄인지 잘 모르겠습니다. 세계에서 가장 비싼 몸값을 받는 C 개발자들도 못 쓴다면, 누가 쓸 수 있습니까?
맞기도 하고 아니기도 합니다. C에 잘못된 점은 없고 악한 것도 아니지만, C가 제공하지 않는 것들을 우리가 요구해야 하니 이제는 쓰지 않는 게 낫다고 봅니다. 어셈블리 코드에도 잘못된 건 없지만 요즘은 거의 안 쓰잖아요.
C는 그 시대에는 충분히 쓸 만했지만, 처음부터 큰 문제들이 있었습니다. 배열의 포인터 붕괴(decay), 길이를 가진 문자열의 부재, 사실상 어디서나 일어나는 에일리어싱, 그리고 Forth 정도로만 타입이 있던 BCPL에서 물려받은 흐물흐물한 타입 같은 것들이요. 그럼에도 제 몫의 힘든 일을 해냈지만, 이제는 유통기한이 한참 지났습니다.
저는 여전히 C가 불에 타 버렸으면 하지만, 그래도 명예로운 바이킹식 장례 정도는 치를 자격이 있겠죠(역사적으로 틀린 말이라는 건 압니다만 무슨 뜻인지는 아시죠).
POC 영상에 무슨 문제가 있죠? 그게 왜 놀라운 일인지 모르겠어요.
영상 스타일이 좀 비전문적으로 보이지 않나요? 차기 아이폰을 애플 CEO가 브이튜버 아바타로 발표하는데 배경에는 서브웨이 서퍼 플레이 화면이 깔려 있는 격이잖아요.
어떤 동네에서는 그게 신뢰도의 표시예요. 미리 유출한 건 정말 비전문적이지만요.
어쨌든 인터넷을 돌리는 건 퍼리들이잖아요.