이번 PHP 취약점은 쉽게 악용할 방법이 없습니다

There isn't an easy exploit for this PHP vulnerability

eliastaylor.com ▲ 611 댓글 439 zkldi

요약

이번 PHP 취약점은 실재하지만 Log4Shell처럼 쉽게 악용할 길은 없다는 주장입니다.

일라이어스 테일러가 취약점 공개 약 10시간 뒤에 쓴 글입니다. GitHub에 쏟아진 개념 증명(PoC) 코드가 대부분 작동하지 않는데도 사람들이 공황에 빠졌다고 봤습니다.

왜 중요한가

  • 취약점이 얼마나 심각한지와 실제로 악용하기 쉬운지는 따로 따져야 한다는 문제 제기입니다.
  • LLM이 만든 엉터리 PoC가 사람들의 위험 판단을 흐리고 있다고 지적합니다.

핵심 내용

  • 취약점은 진짜이고 서버는 패치해야 하지만, 악용은 알려진 것보다 훨씬 어렵다고 했습니다.
  • GitHub의 PoC 수천 개는 기본 설정 PHP에서 작동하지 않으니 LLM 말고 직접 돌려 보라고 권했습니다.
  • 인기 PoC들은 로컬 파일 포함(LFI, 서버가 지정된 파일을 불러오게 하는 별도 결함)을 전제하거나 실습 환경에 그런 결함을 일부러 심었다고 했습니다.
  • Log4Shell, Heartbleed 때는 LLM 없이도 봇넷이 금방 나왔지만 이번에는 작동하는 익스플로잇(실제 공격 코드)이 없다고 비교했습니다.
  • 공황의 원인으로 PHP 코어 팀원의 "패치 15분 뒤 익스플로잇" 예고와 PHP에 대한 불신 등을 꼽았습니다.

HN 반응

  • 위즈, 캘리프 등 보안 업체가 수정하지 않은 PHP 앱을 뚫는 익스플로잇을 확보했다고 밝혀, 글이 금세 빗나갔다는 비판이 많았습니다.
  • 반면 실제 악용에는 정확한 PHP 설정과 ASLR(메모리 주소를 무작위로 배치하는 방어 기법) 우회가 필요해 공황이 과했다는 반론도 맞섰습니다.

댓글

30개 표시 · 전체 439개
  1. tptacek HN

    그러니까, 이 글은 우유처럼 상해 버렸네요. 지금은 취약점 연구팀 여러 곳이 수정하지 않은 PHP 애플리케이션을 상대로 동작하는 RCE PoC를 갖고 있다는 글을 올렸습니다.

    이런 글을 쓴 의도를 잘 모르겠어요. 물론 Log4Shell보다는 익스플로잇하기 어려운 취약점이죠. 그런데 Log4Shell보다 쉬운 건 세상에 없습니다. 그게 사람들의 판단에 대체 어떤 영향을 줘야 한다는 건가요?

    제 경력을 통틀어 처음으로, 어제 패치도 안 되는 치명적 취약점을 완화하려고 애쓰는 대신 아예 서비스를 내려 버리는 사이트들을 봤습니다. 사용자를 위험에 빠뜨리느니 가용성 손실을 감수한 거죠. 드디어요. 그런데 우려를 누그러뜨려서 얻는 게 뭡니까?

    익스플로잇 가능성을 파고드는 길고 덕후스러운 글이었다면 이해했을 겁니다. 하지만 아니잖아요. 사실상 논리 취약점과 메모리 손상 취약점을 고수준에서 비교한 글일 뿐입니다. 이 주장은 대체 뭘 위한 거죠?

  2. qudat HN

    지금은 취약점 연구팀 여러 곳이 수정하지 않은 PHP 애플리케이션을 상대로 동작하는 RCE PoC를 갖고 있다는 글을 올렸습니다.

    증거 없으면 없던 일이죠.

  3. likpok HN

    Wiz(구글 자회사)가 동작하는 익스플로잇을 갖고 있다고 주장합니다: https://www.wiz.io/blog/php2shell-php-rce . Calif도 마찬가지고요: https://calif.io/php2shell/ . Calif는 익스플로잇 시연 영상까지 올렸습니다(이후 삭제됨).

  4. tptacek HN

    이게 바로 이 글의 문제예요. 지금 같은 상황에서, 직접 만져 볼 수 있는 공개 익스플로잇도 없다 보니 상황을 냉정하게 평가하는 것보다 이 취약점을 두고 음모론자식 논쟁을 벌이는 게 더 재미있거든요. 그래서 게시판의 제1법칙에 따라 토론은 음모론자식 논쟁이 장악하게 됩니다.

  5. JeremyNT HN

    직접 만져 볼 수 있는 공개 익스플로잇도 없다 보니 이 취약점을 두고 음모론자식 논쟁을 벌이는 게 더 재미있거든요

    코드를 달라는 사람은 아무도 없다고 생각해요. 말씀하신 동작하는 익스플로잇에 대한 주장을 볼 수 있으면 좋겠다는 거죠.

    주장이라도 누가, 어떤 맥락에서 하느냐에 따라 값어치가 상당할 수 있으니까요.

  6. apple4ever HN

    요점을 놓치고 계십니다. 글쓴이는 이 취약점이 그다지 쉽게 익스플로잇되지 않는다고 주장하고 있고, PHP 취약점이 동작한다는 예시는 전부 서로 무관한 취약점 여러 개를 엮은 체인에 의존합니다.

    당신은 증거도 없이 동작하는 예시가 있다고 단언했습니다.

    누군가 그 예시를 보여 달라고 했는데, 보여 주는 대신 모두를 모욕했고요.

  7. tptacek HN

    저는 증거를 내놓을 생각이 없습니다.

  8. cookiengineer HN

    트롤한테 말 걸지 마세요. 댓글 기록을 보면 어디서나 이런 쓸데없는 댓글만 달고 다닙니다.

  9. Onavo HN

    그럼 ASLR이 기본으로 켜진 최신 리눅스 서버에서 이게 어떻게 통하는지 보여 주세요. DoS식으로 무차별 대입하는 건 빼고요.

    구형 LAMP 서버만 취약하다는 거라면, "당신의 여든 살 할머니가 사고를 더 당하기 쉽다"고 말하는 것과 다를 바 없습니다.

  10. Onavo HN

    Wiz 글을 인용했다가 어째선지 비추천 폭탄을 맞은 RagingCactus의 형제 댓글에도 답하자면(HN 사용자들은 정말 변하지 않네요), PHP 취약점 두 개만으로는 여전히 ASLR을 우회할 수 없습니다.

    CVE-2026-109619가 메모리 관련 핵심 취약점이지만, 이것 하나로는 도배하듯 무차별 대입(브루트포스)하지 않는 한 OS 수준의 ASLR을 깰 수 없습니다.

  11. decisionSniper HN

    그 글들 링크 좀 공유해 주실 수 있나요?

  12. tptacek HN

    제가 아는 한 아직 실제로 통하는 익스플로잇을 공유한 사람도, 공유하겠다는 사람도 없습니다.

  13. ebcode HN

    그런데 "지금은 취약점 연구팀 여러 곳이 수정하지 않은 PHP 애플리케이션을 상대로 동작하는 RCE PoC를 갖고 있다는 글을 올렸습니다"라고 쓰셨잖아요? 그 "여러 글"은 일급 기밀인가요?

  14. apple4ever HN

    맞아요, 완전한 예시가 공개되지 않았더라도 그런 말을 하는 글들이 있다고 단언하셨으니 적어도 그 글들은 볼 수 있어야죠.

    그렇다 해도 원래 글이 틀렸다는 게 증명되는 건 아닙니다. 순정 PHP 서버를 상대로 어떻게 익스플로잇할 수 있는지는 우리가 직접 볼 수 없으니까요.

  15. RagingCactus HN

    이런 글에서 늘 이성적인 목소리를 내 주셔서 감사합니다. 저는 소프트웨어 업계 전반이 보안을 어떻게 생각하는지, 그리고 소프트웨어 보안 상황이 얼마나 심각한지 사람들이 이해하는지 보려고 여기 자주 들릅니다.

    보통은 기분 나쁜 의외의 모습을 보게 되지만 견딜 수는 있어요. 대부분의 개발자는 어떤 문제가 정말 심각한 건지 사소한 건지 깊이 판단할 지식이 없다는 걸 아니까요. 그런데 이제는 사람들이 과연 언젠가 이해하긴 할지 의문이 드는 지경에 이르렀습니다. 널리 쓰이는 소프트웨어에서 치명적인 취약점이 이틀이 멀다 하고 나오고, 기술적으로 익스플로잇하기 매우 어려운 취약점의 익스플로잇도 기록적인 속도로 나오는데, 보안 전문가가 아닌 사람들은 아직도 1999년인 양 "완전히 무기화된 PoC가 없으면 진짜가 아니다"라고 떠들어 댑니다(제가 그 시절을 알 만큼 나이가 들었던 건 아니지만요).

    보안 하는 사람들이 뭔가 좀 알 수도 있다는 걸 왜 아무도 믿지 않는지 모르겠어요. 그냥 눈을 감고 아무 문제 없는 척하는 게 훨씬 편해서일까요? 우리 삶의 모든 부분을 돌리는 소프트웨어를 어떻게 하면 더 안전하게 만들 수 있을지, 마침내 다 같이 이야기하려면 무슨 일이 있어야 하는지 궁금합니다.

  16. rico735 HN

    이번 경우의 문제는 보안 쪽 사람들이 OpenAI와 연결돼 있다는 점 같아요. OpenAI는 이 사태가 최대한 크게 보이는 데 금전적 이해관계가 있으니까요.

    PHP가 경고를 그렇게 엄격하게 낸 건 옳았고, 사람들이 예방 차원에서 사이트를 내린 것도 옳았습니다. 정말 끔찍한 일이 될 수도 있었어요.

    하지만 OpenAI 때문에 양치기 소년 상황이 돼 버렸어요. "패치가 나오고 15분 뒤면 익스플로잇이 나올 것으로 예상한다"는 말이 다행히 현실이 되지 않은 진짜 우려였는지, 아니면 자기네 모델의 능력을 부풀리려던 건지 저는 알 수 없습니다.

    이런 문제에 더 신경 써야 한다는 말씀은 맞지만, AI 하는 사람들이 이걸 자랑거리로 써먹는 건 안 봤으면 좋겠어요. 패치 공개 파티에 맞춰 공식 php2shell 웹사이트까지 준비해 놨던데, 그러면 홍보 행사처럼 보이지 않을 수가 없죠.

  17. tptacek HN

    Dan Guido는 바로 어제 저녁 HN에 나와서 자기 팀의 완전한 익스플로잇 PoC에 대해 이야기했습니다. 제가 알기로 Dan Guido는 OpenAI와 아무 관련이 없어요. PoC를 당신에게 공유할 리는 없겠지만, 이 분야에서 중요한 사람들은 모두 그 팀이 이런 걸 지어내는 팀이 아니라는 데 동의합니다.

  18. rico735 HN

    지어냈다고 말한 적 없습니다(그래서 그 잠재력에 대한 반응은 옳았다고 쓴 거고요). 제 말은 OpenAI가 이걸 마케팅 기회로 삼아서 물을 흐렸다는 거예요. 과거에도 신뢰하기 어려웠고 공포 조장을 마케팅 기법으로 쓰는 회사니까요.

    양치기 소년 이야기에도 늑대는 있잖아요.

  19. tptacek HN

    그게 무슨 도움이 됩니까? 중요한 건 늑대가 있느냐 없느냐입니다.

  20. rico735 HN

    제가 답한 글이 왜 사람들이 여기서 의심을 보이는지 묻고 있었고, 저는 이 특정 사례에 대한 제 가설을 말한 것뿐입니다. 도움이 되려는 것도, 시비를 걸려는 것도 아니고 그냥 생각을 말한 거예요. 사실 그 글이 하는 말에 대부분 동의하고요.

    보안과 홍보를 섞는 건 좋은 생각 같지 않고, 걱정스러운 선례가 된다고 봅니다.

    PHP는 제대로 대처했고 저는 PHP를 신뢰합니다. OpenAI에 대해서는 같은 마음이 들지 않고요.

    한 스레드에서 대화가 여러 갈래로 흘러갈 수도 있는 거고, 모든 게 흑백일 필요는 없잖아요!

  21. RagingCactus HN

    우선, 기술적 문제의 심각성을 의심하는 것과 커뮤니케이션에 대한 비판을 뒤섞지 않고 차분히 의견을 밝혀 주셔서 감사합니다.

    저도 이 정도 규모의 극도로 심각한 취약점을 두고 일부 사이트에서 마케팅 소음이 그렇게 심했던 건 거슬렸습니다. 보안 지식이 없는 독자들에게는 신뢰도 면에서 도움이 되지 않았을 거라는 데 동의해요.

    그렇긴 해도, 그 사이트들에 올라온 분석과 시연을 보면 UAF 같은 것이 어떻게 익스플로잇되는지 기초 지식만 있는 사람(정말 기초입니다. 저도 이런 건 동작하는 익스플로잇을 직접 못 짜요!)이라면 이게 아주 심각한 문제라는 걸 분명히 알 수 있었습니다. 공개 전에 쏟아져 나온 환각투성이 쓰레기 저장소들과 달리, 제시된 사실들이 주장된 영향과 맞아떨어졌고요. 제 불만은 이런 경우에 보안 쪽 사람들 말을 보안 비전문가들이 왜 자주 믿지 않느냐는 건데, 이게 왜 이렇게 한결같은 문제인지 잘 모르겠어요. 게다가 말씀하신 대로 이게 심각하다고 한 건 OpenAI, Wiz, Calif만이 아니라 PHP 쪽 사람들도 똑같이 말했습니다. 그들은 문제를 부풀릴 이유가 전혀 없었고요.

    저는 15분 만에 익스플로잇이 나올 수 있다는 우려도 진심이었고 타당했다고 생각합니다. 가능성이 압도적이진 않았을지 몰라도 분명히 있었다고 봐요. 하지만 더 큰 문제는 익스플로잇이 하나 나오고 나면 그걸 다른 빌드에 맞게 고치는 능력에서 옵니다. 이 글의 다른 댓글은 이 취약점이 "모든 환경에 통하는 PWN 버튼"은 절대 되지 못할 거라고 주장하는데요. 바이너리 익스플로잇에서는 (위협 모델에 따라) 역사적으로 어느 정도 맞는 말이었습니다. 하지만 공개된 LLM이 15분 안에 완전한 pwn 익스플로잇을 한 번에 안정적으로 짜내지는 못한다 해도, 기존 익스플로잇을 다른 대상 버전과 빌드에 맞게 바꾸는 건 아주 쉽게 해낼 수 있습니다.

  22. hn773746483 HN

    소셜 미디어와 "사이버 보안 전문가"들이 이 사태에 큰 역할을 했습니다. "EU, 긴급 취약점이라고 밝혀" 같은 말이 돌았고 일본 총리가 야간에 공익 방송까지 했죠. 이들은 초기 권고문에 대한 "전문가"들의 소셜 미디어 글을 인용하는데, 정작 그 소위 전문가라는 사람들은 구글 검색 AI가 내놓은 완화책을 그대로 공유하고 있었습니다. 어느 기관이나 단체도 권고문과 소셜 미디어에 있던 것 말고는 세부 내용을 몰랐어요(예: "CVSS 10이면 심각한 거잖아!!").

    제가 보기에는 브로드pwn과 더 비슷합니다. 기술적으로 심각하고 범위도 넓지만(수백만 대의 아이폰) 결코 모든 환경에 통하는 PWN 버튼은 되지 못한다는 점에서요.

    AI 시대에도 이터널블루처럼 나중에 무기화될 것 같지는 않습니다... 하지만 저는 팔로워 15000명짜리 소셜 미디어 보안 인플루언서가 아니니, 제 말을 곧이곧대로 믿지는 마세요 ;)

  23. iaaan HN

    사이버 보안 업계에서 일하는 건 절반이 소셜 미디어 페르소나 가꾸기인 것 같아요. 기이합니다. 저는 그것 때문에 한창 뜨던 스타트업을 떠났어요. 전통적인 소셜 미디어를 쓰지 않는 사람으로서, 회사에서 모두의 페르소나가 이상하고 불편하게 뒤섞이더라고요.

  24. renehsz HN

    네, 사이버 보안 업계가 찾을 수 있는 모든 (소셜 미디어) 채널에서 스스로를 과대 포장하는 건 분명합니다. 하지만 공평하게 말하면 어느 정도는 그래야만 해요. 많은 사람과 회사가 뭔가 터지기 전까지는 보안과 패치에 지독하게 게으르니까요. 그러니 소동을 일으키고, 위험을 부풀리고, 긴박감을 만들어야 움직이게 할 수 있습니다.

    물론 더 큰 선의 때문이 아니라 오로지 자기 경력을 위해 부풀리는 사람들도 있어요... 그리고 정직하게 그렇게 자기 홍보를 하고 싶지 않은 사람들조차 사실상 그럴 수밖에 없습니다. 사이버 보안 분야에서 일자리를 구할 때는 가시성이 전문성만큼 (혹은 그 이상으로) 중요할 수 있고, 다들 하는 만큼 스스로를 부풀리지 않으면 성과가 별로 없는 사람처럼 보일 테니까요.

  25. n0on3 HN

    그렇지 않습니다. 눈에 띄는 대부분이 소셜 미디어 페르소나이다 보니 그렇게 결론 내리시는 건 이해가 가요. 하지만 그런 건 신경도 안 쓰고 묵묵히 일만 하는 사람들은 대부분 눈에 보이지 않습니다.

  26. sam_lowry_ HN

    그리고 그 일에 대한 대가는 푼돈이고, 소셜 미디어 페르소나들은 수백만 달러를 쓸어 담죠.

  27. micoti HN

    안타깝게도 일부 사이버 보안 직무는 말 그대로 영업이 업무의 일부입니다. 제가 커리어 초반에 사이버 보안 일자리를 제안받았는데, 채용 담당자가 업무에 더해 영업도 하고 사람들에게 연락도 돌려야 할 거라고 하더군요. 저는 그냥 거절했어요.

  28. Ohmec HN

    문제는 대체로, AI가 취약점 익스플로잇까지 걸리는 시간을 극적으로 줄여서 요즘 CVE들이 종종 실제 심각도보다 낮게 평가된다는 점입니다. 올해 보안 쪽에서 일해 보셨다면 취약점이 줄줄이 이어지는 행군이었고, 다들 시스템을 노출시킬 다음 대형 취약점을 기다리고 있다는 걸 아실 거예요.

    이 CVE에 쉽게 익스플로잇할 경로가 없다는 사실은 현대의 위협 환경에서 역사적으로 거의 의미가 없었습니다. AI는 아주 어렵거나 힘든 익스플로잇 여러 개를 엮어 내는 능력을 입증했고, 기계는 "쉬움"이나 "어려움"을 신경 쓰지 않으니까요.

    요컨대 보안 업계는 지금 약간 겁을 먹은 상태지만, 그럴 만한 이유가 있습니다.

  29. ishouldnotbutk8 HN

    "사이버 보안 전문가"들이 이 사태에 큰 역할을 했습니다

    전문가 말을 듣는 사람은 없어요. 사이버 보안 인플루언서를 말씀하신 거 아닌가요? 진짜 전문가는 대부분의 업계에서 그렇듯 가장 눈에 띄는 사람들이 아닙니다.

    심각도에 대한 추정은 기본적으로 맞습니다. 적어도 지금은 익스플로잇하려면 정확한 PHP 설정을 알아야 하고 손볼 것도 많아요.

    인터넷과 모든 HN 스레드에서 완전한 패닉이 일었고, 사람들은 "이미 실제 환경 곳곳에서 익스플로잇되고 있다"(아니었습니다), "공개된 정보만으로 10분 만에 이 취약점을 재현했다"(그래요, 그러시겠죠), "분석이 담긴 공개 블로그 글이 있다"(AI가 환각으로 지어낸 쓰레기였습니다) 같은 터무니없는 주장을 했습니다. 더 많이 아는 사람들의 목소리도 있었지만 가짜 뉴스에 묻혔어요. 첫 스레드들에서는 더 많이 알고 (조율된 공개에 진지했던) 사람들이 많은 말을 할 수 없었던 것도 도움이 안 됐습니다. 그래서 가장 많이 떠든 사람들이 가장 모르는 사람들이었죠.

    도움이 되고 싶지만, 솔직히 틀린 정보를 앵무새처럼 되풀이하는 사람이 너무 많아서 불가능합니다. 이 취약점이 공개되기 전에 정보를 받아 대응 작업을 했던 사람이 씁니다.

  30. apple4ever HN

    이런 글을 전부 읽다 보니 정말 이만큼 보안이 심각했나 하는 의문이 들었어요. 거의 도덕적 공황 같았습니다. 물론 저도 나오자마자 패치했지만, 웹사이트를 내리는 건 좀 과하다 싶었어요.

Hacker News에서 보기 ↗