전 세계 사이트 열에 넷이 굴리는 엔진, 그 밑바닥 쿼리에서 샌 CVE-2026-60137

이미지 출처: CISA KEV

워드프레스는 지금 이 순간에도 전 세계 웹사이트의 대략 40% 넘게를 떠받치고 있음. 그만큼 코어(core) 자체에서 SQL 인젝션 결함이 나왔다는 소식은, 특정 플러그인 하나가 삐끗한 것과는 무게가 다름. CVE-2026-60137은 바로 그 코어 계층에서 사용자 입력이 데이터베이스 쿼리로 흘러 들어가는 경로가 제대로 걸러지지 않아 생긴 SQL Injection 취약점임. 개인적으로 이런 코어 결함은 "우리 사이트는 플러그인 별로 안 깔았으니 괜찮겠지" 하는 방심을 정면으로 배신하는 종류라 더 눈여겨보게 됨.

핵심 요약

• CVE-2026-60137은 워드프레스 코어의 SQL 인젝션으로, 플러그인이 아니라 엔진 자체가 영향권임.
• 공격자는 조작된 입력으로 DB 쿼리를 비틀어 데이터 열람·유출을 노릴 수 있음.
• 방어는 즉시 패치가 1순위, 그 다음 WAF 룰과 DB 계정 권한 최소화·로그 모니터링으로 층을 쌓는 것.

SQL 인젝션이 코어에서 났다는 게 왜 무거운가

SQL 인젝션은 개념 자체는 오래됐음. 사용자가 넣은 값이 따옴표나 논리 연산자 같은 쿼리 구문의 일부로 해석되면서, 원래 개발자가 의도한 질의문의 뼈대를 공격자가 갈아끼우는 방식임. 워드프레스는 내부적으로 $wpdb라는 데이터베이스 추상화 계층을 두고, prepare()로 파라미터를 안전하게 바인딩하도록 설계돼 있음. 그런데 코어 어딘가에서 이 바인딩을 거치지 않거나, 값을 문자열로 이어붙이는 경로가 남아 있으면 그 틈으로 인젝션이 뚫림. 코어 결함이 무거운 이유는 단순함 — 거의 모든 사이트가 같은 코드를 공유하기 때문에, 하나의 페이로드 패턴이 수백만 대상에 그대로 통할 수 있음.

방어자 관점에서 먼저 볼 것

공격 재현은 개념 수준으로만 짚음. 핵심은 "신뢰할 수 없는 입력이 쿼리에 닿는 지점"을 찾아 막는 것이지, 남의 사이트에 쏴보는 게 아님. 우선순위는 이렇게 잡는 걸 추천함.

• 패치 우선. 워드프레스는 보안 릴리스가 나오면 관리자 화면에서 바로 업데이트가 뜸. 자동 업데이트를 꺼둔 사이트라면 이번 기회에 코어 마이너 자동 업데이트만이라도 다시 켜두는 걸 권함.
• WAF로 시간을 벎. 당장 패치 창을 못 잡는 운영 환경이라면, 웹방화벽에서 전형적인 SQLi 문자열 패턴(따옴표·UNION·주석 기호의 비정상 조합)을 차단하는 룰로 임시 방어막을 침. 완전한 해결은 아니지만 노출 시간을 줄여줌.
• DB 계정 권한 최소화. 워드프레스가 쓰는 DB 계정에 굳이 필요 없는 FILE·DROP 같은 권한이 붙어 있으면 회수함. 인젝션이 성공해도 피해 범위를 좁히는 마지막 방벽이 됨.

탐지: 로그에서 무엇을 봐야 하나

탐지는 결국 로그 싸움임. 웹 서버 접근 로그에서 요청 파라미터에 인코딩된 따옴표(%27)나 논리식(OR 1=1류)이 반복적으로 들어오는지 살핌. DB 계층에서는 평소보다 유난히 긴 쿼리, 예상치 못한 테이블 조인, information_schema를 훑는 질의가 늘어나면 신호로 봄. 짧은 시간에 동일 IP가 파라미터만 조금씩 바꿔가며 두드리는 패턴은 자동화된 스캐닝일 가능성이 큼. 이런 지표를 SIEM이나 단순 로그 알림에라도 걸어두면, 뚫리기 전에 낌새를 잡을 여지가 생김.

마무리

코어 취약점은 겁줄 소식이 아니라 점검 신호로 받아들이는 게 건강함. 오늘 할 일은 세 가지 — 코어 버전 확인하고, 자동 업데이트 상태 점검하고, DB 계정 권한 한 번 훑어보는 것. 나도 내 테스트 사이트부터 이 순서대로 다시 돌려볼 생각임. 각자 운영하는 사이트 버전은 어떤지, 어떤 WAF 룰로 막고 있는지 댓글로 공유해주면 서로 배우는 게 많을 듯. 같이 촘촘하게 막아봐요.