WordPress RCE를 GPT5.6과 25달러로 발견 — AI 에이전트로 풀스택 보안 감사를 시작하는 법

WordPress RCE를 GPT5.6과 25달러로 발견 — AI 에이전트로 풀스택 보안 감사를 시작하는 법

25달러, 한 사람, 한 모델로 발견한 취약점. 최근 한 보안 연구원이 GPT-5.6과 OpenAI API 비용 25달러만으로 WordPress의 원격 코드 실행(RCE) 취약점을 발견해 화제가 됐습니다. 직접 손으로 fuzzing 툴을 돌리거나 상용 취약점 스캐너를 빌릴 필요 없이, LLM 에이전트에게 공개 코드와 changelog를 통째로 읽게 한 뒤 의심 지점을 꼽히게 한 것이 핵심이죠. 이 글은 그 사건을 분해해서 왜 AI가 보안 감사의 첫 번째 도구가 될 수 있는지, 그리고 일반 개발자 팀이 어떻게 같은 패턴을 안전하게 재현할 수 있는지 정리합니다.

핵심 요지를 먼저 말씀드리면 — "LLM이 취약점을 '만든' 게 아니라, '찾아달라'고 시켰을 뿐이다"입니다. 기존에 사람이 1주일 걸리던 패턴 매칭 작업을 GPT-5.6이 2시간 동안 연속적으로 수행했고, 연구원은 그 결과를 다시 사람이 검증·재현해서 책임 영역을 분리했습니다. AI는 속도, 사람은 판단이라는 협업 모델이죠.

1. 사건의 실제 흐름 — 어떻게 25달러로 RCE를 찾았나

긱뉴스 원문 토픽(https://news.hada.io/topic?id=31640)을 요약하면, 진행 과정은 크게 4단계였습니다.

1. 대상 선정 — WordPress 핵심 파일과 최근 1년치 공개 changelog, 그리고 잘 알려지지 않은 30개 플러그인 소스코드를 입력 컨텍스트로 준비합니다. GPT-5.6의 컨텍스트가 충분하기 때문에 코드 전체를 그대로 넣을 수 있다는 게 기존 fuzzing과 다른 출발점입니다.
2. 패턴 프롬프트 — "다음 코드에서 sanitization/escape 누락, 권한 체크 우회, deserialize 후 임의 호출 패턴을 모두 찾아라. 의심되는 함수와 라인 번호를 표로 정리하라." 형태로, 모델이 정적 분석 도구처럼 작동하도록 지시합니다.
3. 반복 검증 루프 — 모델이 1차로 뽑은 후보 17개 중 진짜 양성을 사람이 검증해서 다시 모델에게 "이건 FP, 이 패턴은 왜 의심했는지 반박해라"를 시킵니다. 3 라운드 정도면 양성이 1~2개로 좁혀집니다.
4. 재현 및 신고 — 로컬 docker 환경에서 PoC를 만들어 재현성을 확인하고, WordPress 보안팀에 책임 공개(responsible disclosure) 절차로 제보합니다. 신고 시점에는 이미 패치 패치 PR 초안까지 함께 제출했다고 합니다.

비용 측면에서 API 호출 1회당 입력·출력 합쳐 약 2~3만 토큰이고, 전체 라운드에 9~11회 정도 호출했다고 보면 토큰 비용이 25달러 내외로 들어맞습니다. 사람이 fuzzing 인프라를 셋업해서 1주일 돌렸을 때의 전기세·엔지니어링 시간 비용과 비교하면 압도적으로 싼 것이죠.

2. 왜 AI 에이전트가 보안 감사에 잘 맞는가

보안 감사는 본질적으로 "넓은 후보군을 빠르게 좁히는 일"입니다. 우리가 fuzzing·정적 분석 도구를 쓰는 이유도 결국 같은 맥락이고요. LLM은 이 "넓은 후보군 압축" 작업을 사람보다 훨씬 빠르고, 무엇보다 컨텍스트 길이가 길다는 강점이 있습니다.

• 컨텍스트 단일 처리 — 코드베이스 전체를 한 번에 입력으로 넣을 수 있어, 여러 파일에 걸친 호출 흐름을 놓치지 않습니다. 전통 SAST 도구는 보통 파일 단위로 분석하기 때문에 인-파일 sanitizer 우회 패턴은 잘 잡지만, "File A에서 escape → File B에서 다시 decode → File C에서 eval" 같은 체인은 놓치기 쉽습니다.
• 언어 의존성 낮음 — PHP, Python, Go, Rust 어느 코드든 같은 프롬프트로 던질 수 있어서, 다국어 스택을 쓰는 팀에서 도구 통합 비용이 줄어듭니다.
• 사람이 놓치는 표면 — 잘 알려진 패턴은 도구가 잘 잡지만, "이 함수 이름은 안전해 보이는데 인자 검증이 빠졌다" 같은 의미 기반 의심은 모델이 더 잘 잡는 경우가 많습니다.
• 낮은 진입 비용 — 25달러의 API 키 한 개면 시작할 수 있어, 보안 인력이 부족한 소규모 팀도 첫 번째 보안 감사 라인을 만들 수 있습니다.

3. 일반 팀이 따라 할 수 있는 5단계 워크플로우

연구원의 사고방식을 그대로 따라하면, 1~2인 개발팀도 다음 한 달 안에 첫 AI 보안 감사 라인을 만들 수 있습니다.

3-1. 감사 대상과 입력 범위 정의

처음부터 전체 코드베이스를 넣지 말고, 위험도가 높은 변경 영역(인증, 권한, 입력 sanitization, 직렬화/역직렬화)부터 시작합니다. 한 번에 5~10만 라인 안팎이 모델 컨텍스트 한도 안에서 가장 효율적인 sweet spot입니다.

3-2. 패턴 프롬프트 템플릿 만들기

"다음 코드에서 다음 항목을 표로 정리하라" 식의 구조화된 프롬프트를 만들어두면 매번 새로 작성할 필요가 없습니다. 출력 포맷을 강제하는 것이 핵심이고, 모델이 자연어로 답변하게 두면 후처리가 어렵습니다.

Find security issues in the following code. For each finding, output a table with:


file_path, line_number, issue_type, severity (low/med/high/crit),
description (1-2 sentences), suggested_fix (1 line diff).


Look for: missing sanitization, broken access control, unsafe deserialization,
SSRF, SQLi, XSS, command injection, race conditions, insecure randomness.

Do NOT modify code. Only report findings.

3-3. 1차 후보 → 사람 검증 → 2차 프롬프트

모델이 뽑은 후보를 사람이 30분 안에 빠르게 검토하고, 오탐(FP)이라고 판단한 건 다시 모델에게 던져 "이 패턴은 왜 의심했는지 반박하라"고 시킵니다. 이 한 라운드가 끝나면 양성 비율이 보통 2배 이상 올라갑니다.

3-4. 재현과 패치 작성

모델에게 "위 양성에 대한 PoC sketch와 패치 diff를 작성하라"고 시킵니다. 단, PoC는 격리된 docker 환경에서만 돌려야 하고, 패치는 사람이 직접 merge 전에 다시 검증해야 합니다. 이 부분에서 사람을 빼면 사고 위험이 급격히 올라갑니다.

3-5. 책임 공개와 사후 점검

외부 프로젝트라면 책임 공개 절차를 따르고, 내부 프로젝트라면 발견 후 평균 수정 시간(MTTR)을 추적해서 다음 분기 우선순위에 반영합니다. AI가 발견했다는 사실 자체보다 사람이 받아들여 패치한 속도가 진짜 보안 지표입니다.

4. 운영상 주의사항 — AI는 속도, 사람은 판단

이 패턴이 강력하지만 한 가지 함정을 분명히 짚어야 합니다. AI가 제안한 패치를 그대로 merge하면 안 됩니다. 모델은 자주 "동작은 하지만 보안 컨텍스트가 빠진" 패치를 제안합니다 — 예: sanitization을 추가했지만 그 함수의 다른 호출 경로에서 여전히 우회 가능한 경우. 이런 부분은 결국 사람이 코드 리뷰로 잡아야 하죠.

또 하나, AI는 과잉 보고(false positive)가 매우 많습니다. 1차 후보 17개 중 진짜 양성은 1~2개였다고 했는데, 만약 그 비율을 모르고 17개 모두 패치했다면 절반 이상은 의미 없는 변경이 됐을 겁니다. 사람 검증 라운드를 빼면 시간은 줄지만 신뢰도가 떨어집니다.

마지막으로, 비밀키·사용자 데이터가 포함된 코드는 절대 모델 입력으로 넣으면 안 됩니다. 오픈 소스 라이브러리·자체 작성 코드의 sanitize된 부분만 사용하고, 운영 환경 코드에는 AI 감사를 적용하지 마세요.

5. 전망 — AI 에이전트가 만드는 "1인 보안팀"

이번 사건은 상징적입니다. 1인 + 25달러 + GPT-5.6이 WordPress급 오픈소스 프로젝트의 RCE를 찾았다면, 앞으로 5인 이하 스타트업도 비슷한 패턴으로 첫 번째 보안 감사 라인을 만들 수 있다는 뜻이거든요. 풀타임 보안 인력을 뽑기 어려운 초기 팀일수록 이 워크플로우의 임팩트가 큽니다.

다만, 이 사건을 "AI가 취약점을 발견했다"는 헤드라인처럼 보기보다는 "AI가 넓은 후보군을 빠르게 좁혔고, 사람이 검증했다"는 협업 사례로 보는 게 정확합니다. 다음 분기에는 이런 1차 후보 압축이 표준 보안 워크플로우의 일부가 될 가능성이 높고, 보안 감사 도구 시장도 재편될 가능성이 있습니다.

요약

• GPT-5.6과 25달러의 API 비용으로 WordPress RCE 취약점이 발견됐다 — 핵심은 AI가 양성을 좁힌 것이지, 취약점을 '만든' 게 아니다.
• 보안 감사는 "넓은 후보군 압축"이 핵심이고, LLM은 컨텍스트 길이와 패턴 매칭에서 이 작업을 매우 잘한다.
• 일반 팀은 (1) 대상 정의 → (2) 구조화 프롬프트 → (3) 사람 검증 루프 → (4) 재현·패치 → (5) 책임 공개의 5단계로 시작할 수 있다.
• AI는 속도, 사람은 판단 — 모델이 뽑은 패치는 반드시 사람이 직접 리뷰하고, 비밀키·운영 코드는 입력으로 넣지 않는다.
• 1인 + AI 에이전트 조합이 만드는 "1인 보안팀"은 향후 5인 이하 스타트업의 첫 번째 보안 라인으로 자리잡을 가능성이 높다.

---

원문 출처: 긱뉴스 토픽 #31640 · 작성 시각: 2026-07-21 · 키워드: WordPress, RCE, GPT-5.6, AI 보안 감사, 책임 공개

---

📰 원본 출처 · https://news.hada.io/topic?id=31640 (#N=31640)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.