AI가 72시간 만에 워드프레스 플러그인 제로데이 300개를 찾아냈다 — 플러그인 개발자가 마주한 현실

AI found 300 WordPress plugin zero-days in 72 hours. I build plugins. Here's what changed for me.

Before I released my own AI chatbot plugin, I ran it through a security review. It came back with 35...

Rapls2026-06-22

개요 #

AI 정적 분석과 자동 검증을 묶은 파이프라인이 워드프레스 플러그인 생태계에서 치명적 제로데이 300여 개를 찾아냈다. 걸린 시간은 약 72시간. 모든 발견은 공개 전에 사람이 직접 검증했다. Help Net Security가 보안 연구자들의 이 결과를 전하면서, 한동안 잠잠하던 플러그인 보안 문제가 2026년 들어 한꺼번에 수면 위로 떠올랐다.

이 글을 쓴 개발자 본인도 AI 챗봇 플러그인을 출시하기 전 보안 점검에서 버그 35개를 마주했다. 그중 셋은 치명적 등급이었고, 가장 가슴을 철렁하게 한 건 모델 출력을 정화하지 않아 생긴 HTML 인젝션이었다. 당시엔 개발자로서 바닥을 친 기분이었다고 한다. 그런데 올해 생태계 전체 수치를 보고 나니 35라는 숫자가 차라리 귀엽게 느껴졌다.

2026년, 숫자가 커졌다 #

Patchstack의 2026년 보고서는 원인 하나에 이름을 붙였다. 바이브 코딩(vibe coding), 즉 개발자가 직접 감사할 수도 없는 LLM 생성 코드를 그대로 출시하는 관행이다. 한 에이전시는 바이브 코딩으로 만든 단일 플러그인 하나에서 서로 다른 보안 문제 100개를 찾아냈다고 보고했다.

AI는 공격과 방어 양쪽을 동시에 움직였다. 플러그인을 빠르게 짜면서, 짜는 동안 지루한 보안 작업은 건너뛴다. 이스케이프, 권한 검사, nonce 검증 같은 것들이다. 그리고 바로 그 구멍들을 다시 빠르게 찾아낸다. 공격자 쪽에서도 마찬가지다. 작은 플러그인을 지켜주던 두 가지, 무명성(obscurity)과 시간이 둘 다 사라졌다.

Patchstack이 측정한 공개 공시부터 대량 악용까지의 가중 중앙값은 약 다섯 시간이었다. "플러그인을 항상 최신으로 유지하라"는 표준 조언은 대응할 여유가 있다는 걸 전제로 한다. 다섯 시간은 여유가 아니다.

보안 취약점을 분석하는 작업 환경 Photo by Markus Winkler on Pexels

내 플러그인에 35개 버그가 있었던 이유 #

1인 개발자들이 과소평가하는 지점이 여기 있고, 글쓴이를 물었던 것도 같은 문제다. AI가 쓴 코드는 두 번 신뢰받는다. 한 번은 AI가 썼으니 "괜찮겠지" 하고, 또 한 번은 코드 안에서 모델 출력을 안전하다고 보고 검사 없이 처리하면서. 그의 코드베이스에서는 이 두 신뢰가 모두 틀렸다.

출력 쪽 HTML 인젝션이 바로 이 이중 신뢰가 현실이 된 사례였다. 모델이 생성한 응답이니 깨끗하겠거니 하고 그대로 HTML로 페이지에 렌더링했는데, 깨끗하지 않았다. 모델 출력에는 다른 사람의 콘텐츠가 섞여 있다. 사용자가 입력한 것, 검색 단계가 외부 페이지에서 긁어온 것. 이걸 안전하다고 여기면 입력 쪽을 아무리 막아도 소용없다. 나가는 길목에서 새어 나오기 때문이다.

1인 개발자로서 실제로 바꾼 것 #

"돌아간다"를 "안전하다"로 여기기를 그만뒀다. 이제 AI가 쓴 핸들러는 세 군데를 직접 손으로 읽는다. 입력, 출력, 권한이다.

출력에서는 모델 응답을 신뢰할 수 없는 입력으로 취급하고, 그게 향하는 곳에 맞게 무력화한다. HTML이면 이스케이프하고, 마크다운이면 허용 목록으로 거르고, URL은 가져오기 전에 검증한다. 워드프레스 용어로 옮기면 모델이 즐겨 건너뛰는 그 따분한 작업들이다.

esc_html로 출력 이스케이프
빡빡한 허용 목록을 적용한 wp_kses
모든 AJAX·REST 진입점에서 current_user_can과 nonce 검사
모든 쓰기 작업에 $wpdb->prepare

새로운 건 하나도 없다. 우리가 늘 해온 웹 보안을, 내가 직접 쓰지 않은 절반의 코드에 겨눴을 뿐이다.

공격 표면은 계속 넓어진다. 워드프레스 7.0의 Abilities API는 플러그인이 AI 에이전트에게 동작을 표준화된 방식으로 노출하도록 해준다. 유용하지만, 동시에 권한이 덜 좁혀진 채 새는 새로운 통로이기도 하다. 에이전트에게 필요 이상의 권한을 넘기는 플러그인은 같은 실수의 다음 버전이 될 수 있어서, 글쓴이는 이 부분을 특히 주시하고 있다.

정작 불편한 건 코드가 아니다 #

2026년의 논의가 실제로 가리키는 지점은 코드 문제가 아니다. Patchstack에 따르면 플러그인 개발자의 **52%**가 취약점이 공개되기 전에 패치를 내놓지 못했고, 공시된 취약점의 **46%**는 공개 시점에 아예 사용할 수 있는 수정본이 없었다.

버그를 찾는 일은 더 이상 병목이 아니다. AI가 몇 초 만에 해낸다. 병목은 그다음 전부다. 대부분의 플러그인은 무료이고, 생업 사이사이 한 사람이 유지보수한다. 수익이 0인 플러그인은 빠른 보안 패치 비용을 정당화할 수 없다. 2026년 생태계의 실패 양상은 버그를 찾기 어렵다는 게 아니다. 그걸 고칠 사람들이 그 대가를 받지 못한다는 것이다. AI가 이 간극을 만든 건 아니다. 다만 그것을 대규모로 드러냈고, 공격자에게 다섯 시간의 선점을 쥐여줬다.

1인 개발자가 마주한 유지보수 현실 Photo by Markus Winkler on Pexels

아무도 충분히 말하지 않는 마감일 #

여기엔 시계도 걸려 있다. 2026년 9월까지 EU 사용자에게 배포하는 플러그인·테마 개발자는 법적으로 취약점 공개 프로그램(vulnerability disclosure program)을 갖춰야 한다. 1인 개발자에겐 부담처럼 들리지만, 위협의 성격에 맞는 단 하나의 구조적 해법이기도 하다. AI가 찾아낸 버그를, 공개 CVE에 다섯 시간 타이머가 붙기 전에 누군가 조용히 신고할 수 있는 진짜 통로 말이다.

이걸 갖추는 게 거창할 필요는 없다. 1인 개발자라면 최소한의 형태로 충분하다.

플러그인 readme나 SECURITY 파일에 보안 연락처
공개 이슈 트래커가 아닌, 신고가 도착할 별도의 장소
신고자가 메시지가 방치되지 않는다는 걸 알 수 있도록 명시된 응답 기간

요점은 격식이 아니다. 버그를 찾은 사람이, 그것이 다섯 시간 타이머가 붙은 공개 CVE로 변하기 전에 보낼 곳이 있어야 한다는 것이다.

다음의 나에게 #

35개의 버그는 내가 쓰지 않은 코드를 의심하라고 가르쳤다. 올해는 나머지를 가르쳤다. 내가 놓친 걸 고칠 수 있는 시간은 그 어느 때보다 짧아졌고, 무명성은 애초에 나를 지켜준 적이 없었다.

플러그인을 출시한다면, AI를 썼든 안 썼든, 해야 할 일은 "더 조심해서 쓰고 잘되길 바라기"가 아니다. 구멍은 이미 몇 초면 찾을 수 있다고 가정하고, 그걸 먼저 잡아내는 부분을 만드는 것이다. 입력·출력·권한을 손으로 직접 읽는 검토, 출력 정화, 그리고 적대적인 누군가보다 우호적인 누군가가 먼저 닿을 수 있는 공개 통로 말이다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다. 원문에 따르면 수치(72시간 300여 건, 다섯 시간 대량 악용 중앙값, 52%·46% 패치 통계, EU 공개 프로그램 의무화 등)는 Patchstack 2026 보고서, Help Net Security 보도, hosting.com의 2026 플러그인 보안 글에 근거하며, 공개 전 1차 자료 확인이 권장됩니다.