먼저, 제가 바꾼 것부터 쓰겠습니다. 공격 측이 AI로 취약성을 양산할 수 있게 된 이상, "내 플러그인도 언젠가 똑같은 파이프라인에 걸릴 수 있다"는 전제로 만들기로 했습니다. 구체적으로는, phpcs:ignore로 침묵시켰던 행을 재검토합니다. 오래된 버전이 지금도 작동하고 있다는 전제로 수정합니다. AI의 출력도 입력도, 외부로부터의 공격 면(Attack Surface)으로 취급합니다.

계기는 지난 5월에 나온 한 연구였습니다.

72시간 만에 300건이라는 뉴스

TrendAI와 CHT Security의 연구자들이 3일 만에 구축한 파이프라인을 통해, WordPress 플러그인에서 300건이 넘는 중대한 제로데이(Zero-day)를 찾아냈습니다. 스캔에 걸린 시간은 72시간이었습니다. Ekoparty Miami에서 발표되었으며, 발견된 취약점은 모두 수동으로 검증한 후 책임 공개(Responsible Disclosure)되었습니다. 대시보드 로그에 따르면, 95개 태스크에서 약 2.2억 토큰을 소비했다고 합니다.

숫자라기보다 속도에 등골이 서늘해졌습니다. "3일 만에 만든 체계가 72시간 만에 300건". 이것은 이제 인간 연구자가 하나씩 찾아내는 세계의 이야기가 아닙니다. 발견된 취약점에는 인증 전 원격 코드 실행(RCE), SQL 인젝션(SQL Injection), WordPress의 훅(Hook) 메커니즘을 악용한 권한 상승, SSRF가 포함되어 있었으며, GitHub 스타 1,000개가 넘는 인기 플러그인에서도 인증 전 RCE가 있었다고 합니다. 인기가 곧 안전은 아닙니다.

저는 WordPress 플러그인을 만들어 배포하는 입장입니다. 남의 일이 아니었습니다.

무서웠던 것은 "수"보다 2가지 수법

뉴스의 숫자 이상으로 제 손이 멈춘 것은 두 가지 구체적인 사례였습니다.

첫 번째. SQL 인젝션이 PHPCS의 주석으로 "안전"하다고 표시된 행에 숨어 있었다는 이야기입니다. 정적 분석을 침묵시키기 위한 주석을 AI는 곧이곧대로 받아들이지 않았습니다. 이 점이 뼈아팠습니다. 제 코드에도 phpcs:ignore를 붙인 행이 여러 개 있습니다. 그것은 "확인 완료"의 표시라고 생각했지만, 관점을 바꾸면 "자동 체크의 눈을 가린 곳"이기도 합니다. 눈을 가린 그 지점에서, 저는 정말로 안전을 확인했었나요?

두 번째. AI가 인간의 지시 없이 다운그레이드 공격 체인(Downgrade Attack Chain)을 구성했다는 이야기입니다. 플러그인을 이전 버전으로 되돌리고, 그 구버전이 가진 허점을 찔러 두 개를 연결해 작동하는 공격을 만들었습니다. 아무도 "이렇게 해라"라고 가르쳐주지 않았는데 말입니다.

이 점이 가장 가슴에 와닿았습니다. 저는 "최신 버전에서 고쳤으니 괜찮다"라고 생각하기 쉽습니다. 하지만 과거에 배포한 버전은 지금도 어딘가의 서버에서 돌아가고 있습니다. 공격자 입장에서 보면 최신 버전을 뚫을 필요 없이, 사용자가 업데이트하지 않은 구버전으로 되돌리기만 하면 됩니다. "고쳤다"와 "세상에서 사라졌다"는 별개의 문제였습니다.

만드는 입장에서 바꾼 것

여기서부터가 본론입니다. 읽고 끝내고 싶지 않았기에 제 플러그인을 같은 시각으로 재검토했습니다. 원래 저는 출시 전에 몇 번이고 재검토하는 성격이라, 이전에 어떤 플러그인을 11번 리뷰하여 35건의 문제를 찾아낸 적이 있습니다. 그때 가장 무서웠던 1건도 입력이 아니라 출력 측, 즉 LLM의 답변을 그대로 화면에 삽입하던 부분이었습니다. "AI의 출력은 신뢰할 수 없는 외부 입력이다"라는 생각은 그때부터 제 중심 원칙이 되었습니다. 이번 사건을 통해 그 원칙을 조금 더 넓혔습니다.

바꾼 것은 세 가지입니다.

phpcs:ignore를 붙인 행을 전수 조사했습니다. 왜 무시하게 했는지 기억나지 않는 행이 솔직히 몇 개 있었습니다. 기억나지 않는 무시는 위험한 무시입니다. 이유를 주석으로 다시 쓰거나, 무시를 중단하고 정말로 수정하는 것 중 하나로 결정했습니다.

오래된 버전을 공격의 입구로 간주하기로 했습니다. 보안 수정은 변경 이력(Changelog)에 "이것은 보안 수정이다"라고 명확히 적습니다. 업데이트하지 않는 사용자에게 어떤 일이 일어나는지를 릴리스 노트(Release Note)에 한마디로 전달합니다. 버전을 되돌려 공격당할 것을 전제로, 구버전의 허점을 조용히 지우지 않고 보이는 형태로 없앱니다.

취약성 접수 창구를 마련했습니다. AI가 생성하는 저품질 보고(AI slop)로 인해 트리아지(Triage)가 무너지기 시작하면서, 공개 프로그램은 실적이 있는 연구자만 통과시키는 초대제로 움직이고 있습니다. 한편 EU의 사이버 복원력 법(Cyber Resilience Act) 흐름에 따라 상용 플러그인에는 취약성 공개 창구가 필요해질 것입니다. 개인 제작자라도 보고를 받을 입구(연락처와 방침) 정도는 미리 마련해 두는 것이 좋습니다. 보고가 온 뒤에 당황하기보다, 올 것을 전제로 대비해 두는 것입니다.

AI에게 감사를 맡긴다면, 맹신하지 말 것

한 가지 보충하겠습니다. 이번 사례는 "AI로 자신의 코드도 감사(Audit)할 수 있다"는 이야기로도 읽힐 수 있습니다. 실제로 유효한 방법입니다. 다만 동일한 연구가 보여준 것은, AI가 대량으로 쏟아내는 보고의 상당수가 노이즈(AI slop)이며, 이를 받는 쪽이 과부하 상태에 빠져 있다는 현실이기도 했습니다.

그래서 저는 AI에게 감사를 맡긴 후, 나온 지적 사항을 하나씩 수동으로 확인합니다. 재현이 되는지, 정말로 도달 가능한지 말입니다. 그대로 믿어버리면, 본인이 "AI slop을 자신에게 던지는 사람"이 되어버립니다. 공격 측의 AI에도, 내가 사용하는 AI에도 똑같은 태도로 대하는 것이 적절하다고 생각합니다.

다음의 나에게 남기는 메모

• 공격 측은 이미 AI로 양산하고 있다. "언젠가 내 플러그인도 공격당할 수 있다"는 전제로 개발할 것
• phpcs:ignore는 "안전의 표식"이 아니라 "눈을 가린 곳"이다. 기억나지 않는 무시(ignore)는 없애버릴 것 - "최신 버전에서 수정했다"와 "세상에서 사라졌다"는 다르다. 구버전은 지금도 작동하고 있으며, 롤백되어 공격받을 수 있다
• 취약점 제보 창구(연락처·방침)를 보고가 오기 전에 미리 마련해 둘 것
• AI에게 감사를 맡겨도 좋다. 단, 지적 사항은 하나씩 수동으로 확인할 것. AI slop을 자신에게 던지지 말 것

300건이라는 숫자는 타인의 플러그인 이야기입니다. 하지만 다음 72시간의 스캔 대상에 자신이 포함되지 않는다는 보장은 어디에도 없습니다. 겁을 먹기 위해서가 아니라, 대비 태세를 바꾸기 위해 이 숫자를 기억해 두려 합니다.

출처:

• Help Net Security 「AI에 의한 WordPress 플러그인의 제로데이 대량 발견」(2026년 5월 22일)
• Patchstack 「State of WordPress Security in 2026」 외

평소에는 raplsworks.com에서 WordPress 플러그인 개발 및 Claude Code 관련 글을 쓰고 있습니다.

Discussion