내일인 8월 4일은 미국 사이버보안청(CISA)이 연방기관들에게 워드프레스 코어의 SQL 인젝션 결함을 반드시 고치라고 못 박은 마감일이다. 대상 취약점 하나가 세계 웹사이트의 상당수를 차지하는 워드프레스 코어에서 발견됐고, 이미 실제 공격에 쓰이고 있다는 게 CISA의 판단이었다. 1998년 처음 세상에 알려진 SQL 인젝션이라는 공격 기법이, 30년 가까이 지난 2026년에도 이 정도 급한 불로 남아 있다는 뜻이다. 왜 아직도 안 사라졌을까.
SQL 인젝션이란, 식당 주문서에 빗대면
SQL 인젝션을 한 문장으로 정리하면 “사용자가 입력한 값을 애플리케이션이 데이터가 아니라 명령어로 착각해서 실행해버리는 구조적 결함”이다. 말로만 들으면 감이 잘 안 올 텐데, 식당에 비유하면 이해가 쉽다.
손님이 주문서에 “김치찌개 하나”라고 적으면 주방은 그걸 데이터로 받아들여 김치찌개를 만든다. 그런데 만약 주방 시스템이 주문서에 적힌 글자를 곧이곧대로 ‘지시문’으로도 읽어버린다면 어떨까. 손님이 메모란에 뭘 적든 주방이 그걸 요리 순서 자체로 착각해 실행해버리는 상황, 이게 SQL 인젝션의 본질에 가깝다. 웹사이트의 로그인창이나 검색창은 원래 사용자가 입력한 글자를 ‘데이터’로만 다뤄야 하는데, 입력값을 제대로 걸러내지 못하면 그 글자가 데이터베이스에 명령어로 그대로 전달돼버린다.
이 결함이 무서운 이유는 성공했을 때 피해 범위다. 단순히 화면 하나가 깨지는 수준이 아니라, 데이터베이스 전체에 접근 권한이 열릴 수 있다. 회원 개인정보, 결제 정보, 관리자 계정 정보까지 한 번에 노출되는 사고가 유독 SQL 인젝션에서 자주 나오는 이유다. OWASP(오픈 웹 애플리케이션 보안 프로젝트)가 오랫동안 이 유형을 웹 애플리케이션 보안 위험 목록 상위권에 올려놓고 있는 것도 같은 맥락이다.
SQL 인젝션은 왜 이렇게 오래돼도 안 막힐까
패턴 자체는 25년 넘게 알려져 있고, 막는 원리도 개발자 교육 자료에 빠짐없이 나온다. 그런데도 매년 사고가 반복되는 데는 몇 가지 구조적인 이유가 있다.
가장 큰 원인은 오래된 코드의 총량이다. 지금 운영 중인 웹사이트 중 상당수는 안전한 코딩 관행이 자리 잡기 전에 처음 만들어졌고, 그 뼈대가 아직도 살아있는 경우가 많다. 여기에 직접 짜지 않고 가져다 쓰는 플러그인이나 서드파티 라이브러리 문제가 더해진다. 개발자가 아무리 조심해도, 가져다 쓴 부품 하나에 결함이 있으면 그게 전체 시스템으로 퍼진다. 이번 워드프레스 사고도 코어 자체의 결함이 특정 플러그인·테마의 허술한 처리 방식과 맞물리면서 인증 없이도 서버를 장악할 수 있는 수준까지 커졌다.
속도와 검증 사이의 줄다리기도 빼놓을 수 없다. 서비스 출시 일정에 쫓기다 보면 입력값 검증처럼 눈에 안 보이는 작업은 우선순위에서 밀리기 쉽다. 그리고 공격 기법 자체도 가만있지 않는다. 탐지 규칙을 피해가는 새로운 우회 방식이 계속 나오다 보니, 한 번 막았다고 안심할 수 있는 성격의 위협이 아니다.
최근 실제 사례로 보는 SQL 인젝션
가장 최근 사례는 역시 워드프레스 코어 결함(CVE-2026-63030)이다. 지난달 이 블로그에서도 wp2shell이라는 이름으로 다룬 적이 있는데, 정리하면 이렇다. 이 결함이 또 다른 SQL 인젝션 취약점(CVE-2026-60137)과 함께 사용되면 로그인조차 하지 않은 공격자가 서버 권한을 완전히 가져갈 수 있다. CISA는 지난 7월 21일 이 취약점을 실제 공격에 쓰이고 있는 것으로 확인된 목록(KEV)에 올렸고, 연방기관에 8월 4일까지 고치라고 지시했다. 워드프레스가 전 세계 웹사이트에서 차지하는 비중을 생각하면 공격 대상 풀 자체가 어마어마하다.
국내에서도 비슷한 구조의 사고가 있었다. 아웃도어 의류 기업 비와이엔블랙야크는 2025년 3월 홈페이지에 SQL 인젝션 공격을 당해 이용자 34만 2,253명의 개인정보가 새어나갔다. 개인정보보호위원회 조사 결과, 이 회사는 홈페이지를 만든 2021년부터 취약점 점검을 소홀히 해왔던 것으로 드러났다. 결국 13억 9,100만 원이라는 적지 않은 과징금을 물었다. 두 사고는 발생 시점도, 규모도, 나라도 다르지만 원인은 똑같았다. 입력값을 제대로 걸러내지 않았다는 것.
SQL 인젝션 방어 체크리스트
사고 사례를 보면 답은 이미 나와 있다. 문제는 이걸 꾸준히 지키느냐다.
일반 이용자 입장에서 SQL 인젝션 자체를 직접 막을 방법은 사실 없다. 서버 안쪽에서 벌어지는 일이기 때문이다. 대신 사고가 터진 뒤의 대응은 이용자 몫으로 넘어온다. 이용 중인 서비스에서 유출 통지가 오면 무시하지 말고 바로 확인하고, 여러 사이트에서 같은 비밀번호를 재사용하지 않는 습관이 그나마 가장 효과적인 방어선이다. 오래전에 가입하고 잊어버린 계정도 주기적으로 정리해두는 편이 좋다.
서비스를 직접 운영하는 입장이라면 이야기가 다르다. 모든 입력값은 매개변수화된 쿼리(prepared statement) 방식으로 처리해서, 입력값이 명령어로 해석될 여지 자체를 없애는 게 기본이다. 관리자 페이지는 아이디·비밀번호만으로 접근하게 두지 말고 추가 인증 수단을 걸어야 한다. 그리고 웹 취약점 점검은 서비스를 처음 만들 때 한 번으로 끝낼 일이 아니라, 정기적으로 반복해야 한다는 걸 블랙야크 사례가 보여준다.
자주 묻는 질문
Q. SQL 인젝션은 아무 사이트에나 통하나요?
아니다. 입력값 검증과 매개변수화된 쿼리 처리가 제대로 돼 있는 사이트는 이 방식으로 뚫리지 않는다. 다만 검증이 허술한 오래된 시스템이나 검증되지 않은 플러그인을 쓰는 사이트는 여전히 위험에 노출돼 있다.
Q. 내가 가입한 사이트가 SQL 인젝션 사고를 당했는지 어떻게 아나요?
서비스 운영사가 개인정보보호위원회 등에 신고하면 이용자에게 개별 통지하는 것이 원칙이다. 다만 통지가 늦어지거나 누락되는 경우도 있으므로, 자주 이용하지 않는 계정은 비밀번호를 주기적으로 바꿔두는 편이 안전하다.
Q. 회사에서 쓰는 워드프레스도 지금 위험한 상태인가요?
CVE-2026-63030과 CVE-2026-60137이 함께 존재하는 구버전 워드프레스라면 그렇다. 최신 보안 패치가 적용됐는지부터 확인하는 게 우선이다.
Q. SQL 인젝션과 앞으로 다룰 크로스사이트 스크립팅(XSS)은 뭐가 다른가요?
둘 다 검증되지 않은 입력값이 문제의 시작이라는 점은 같다. 다만 SQL 인젝션은 서버 쪽 데이터베이스를 겨냥하고, XSS는 다른 이용자의 브라우저에서 악성 코드가 실행되게 만드는 쪽에 가깝다는 차이가 있다.
앞으로 이 시리즈에서
이번 편은 SQL 인젝션의 기본 개념과 왜 오래된 결함이 계속 반복되는지를 다뤘다. 앞으로 이 블로그는 크로스사이트 스크립팅(XSS), 크리덴셜 스터핑, 랜섬웨어 침투 경로 같은 다른 해킹 기법들도 같은 방식으로 하나씩 다룰 예정이다. 뉴스 하나를 요약하고 끝내기보다, 그 사고를 가능하게 한 구조 자체를 이해하는 게 결국 내 정보를 지키는 데 더 오래 남는 지식이라고 생각해서다.
출처
국내 기업 금융 보안 조직 8년차. 취약점 진단과 보안 기획 업무를 하며, 업계 밖에서는 잘 안 보이는 보안 이야기를 정리하고 있습니다. 개인 자격으로 쓰며 소속 조직과 무관합니다.