본문으로 건너뛰기

전제조건이 복잡한 취약점은 더 이상 안전하지 않다 — PHP2Shell 단상

Inseok Jeon
Inseok Jeon
Security Manager

PHP 코어 RCE 2건을 보며 든 생각을 적는다. 전제조건이 많아 "실제로는 공격이 어렵다"는 평가는 맞지만, 그 전제가 AI 시대에도 방어선이 될 수 있는지는 다른 문제다.

사건 자체는 News에 정리해 뒀다. → PHP 코어 원격 코드 실행 취약점 2건

왜 Critical인가​

CVE-2026-109618·109619는 둘 다 CVSS v4.0 기준 9.2, Critical이다. 109618의 벡터를 뜯어보면 이유가 보인다.

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H

  • AV:N — 네트워크로 원격 공격 가능
  • PR:N / UI:N — 권한도, 사용자 조작도 필요 없음 (인증 없는 공격)
  • VC:H / VI:H / VA:H — 성공 시 기밀성·무결성·가용성 피해가 모두 최고 등급. 코드 실행이니 사실상 시스템 완전 장악이다.
  • AC:H / AT:P — 공격 복잡도가 높고, 성립하려면 전제조건이 필요하다

즉 "원격 + 비인증 + 완전 장악"이라는 피해의 천장이 최고 수준이라 Critical이다. CVSS는 점수를 매길 때 피해 영향에 큰 비중을 둔다.

전제조건은 무엇을 낮추는가​

점수가 10.0이 아니라 9.2인 이유가 바로 AC:H와 AT:P다. 공식 권고도 재현 신뢰도가 PHP 빌드, 확장 모듈, 프런트엔드 동작, 메모리 할당자 배치에 따라 달라진다고 밝혔고, 기본 설정·prefork의 mod_php 환경에서 검증했을 뿐 FPM에 대한 완전한 익스플로잇은 시연하지 못했다.

여기서 구분이 중요하다. 전제조건은 "공격이 성공할 가능성·난도"를 낮출 뿐, "성공했을 때의 피해"를 낮추지 않는다. 그래서 "어렵다"와 "Critical"이 동시에 성립한다. 사용자님이 보신 대로, 조건이 다 맞아야만 공격이 가능하고 실제 성공은 쉽지 않은 상태라는 평가는 정확하다. 실제로 공개 시점 기준 야생의 악용도 관측되지 않았다.

그런데 — AI 시대에도 "어려움"이 방어선인가​

여기서부터는 내 의견이다.

과거에는 전제조건이 복잡하면 그 자체가 사실상의 방어선이었다. 공격자가 대상의 정확한 버전과 확장 모듈을 알아내고, 환경마다 익스플로잇을 맞춰 조정하고, 할당자 동작까지 신뢰성 있게 맞추는 일은 사람의 수작업 비용이 컸다. 조건이 많을수록 그 비용이 커졌고, 그래서 Critical이어도 "어차피 실제로 당하긴 어렵다"는 판단이 어느 정도 통했다.

AI 에이전트가 공격에 쓰이는 지금은 그 전제가 흔들린다. 에이전트는 대상의 버전·구성·프런트엔드 동작을 빠르게 식별하고, 조건이 맞는 대상만 골라내며, 환경에 맞춰 공격 코드를 반복 조정할 수 있다. 사람 한 명이 대상 하나에 쏟던 노력이, 수많은 대상에 동시에 적용되는 자동화된 작업으로 바뀐다. "복잡해서 분석과 조정에 시간이 많이 든다"는 장벽이 바로 AI가 가장 잘 깎아내는 종류의 비용이다.

이건 어제 정리한 ARTEX 동작 분석에서 본 흐름과 같다. AI는 새로운 공격 기법을 만들기보다, 기존 공격의 처리량과 정밀도를 끌어올린다. 전제조건 식별과 환경별 맞춤이야말로 그 처리량·정밀도가 직접 작용하는 지점이다.

그래서 방어하는 입장에서는​

"공격이 복잡해서 실제로는 어렵다"를 위험 완화 근거로 삼던 과거의 가정을 버려야 한다. 공격 복잡도가 높다는 사실은 여전히 참이지만, 그 복잡함이 공격자에게 주던 장애물 효과는 줄고 있다.

  • 위험 평가의 기준을 "성공 난도"가 아니라 "성공 시 피해(impact)" 로 옮긴다. Critical이면 "어차피 성공 어렵다"에 기대지 말고 패치 우선순위를 그에 맞춘다.
  • 전제조건을 실제로 없애는 방향으로 간다. 복잡하니 안전하다가 아니라, 패치·설정 강화로 전제조건 자체를 성립하지 않게 만든다.
  • 단종 버전처럼 "조건만 맞으면 바로 뚫리는" 자산을 먼저 식별한다. AI 공격자가 가장 먼저 골라내는 대상이 바로 그런 곳이다.

오해는 없어야겠다. AI가 모든 전제조건을 마법처럼 무력화한다는 뜻은 아니고, 지금 당장 이 PHP 취약점이 대량으로 악용되고 있다는 뜻도 아니다. 다만 방향은 분명하다. "어려워서 안 당한다"는 더 이상 보안 계획의 전제가 될 수 없다.