jQuery 취약점: CVE, 보안 위험 및 해결 방안

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

jQuery의 위험 요소 대부분은 새로 발견된 문제에서 비롯된 것이 아니라, 여전히 운영 환경에 남아 있는 구버전에서 비롯됩니다.
XSS는 CVE-2020-11022, CVE-2020-11023, CVE-2015-9251을 통해 목록에서 압도적인 비중을 차지하고 있으며, 프로토타입 오염이 그 뒤를 바짝 쫓고 있습니다.
jQuery 1.x 및 2.x는 지원되지 않으며, 3.x는 중대한 문제만 수정되며, 4.x가 현재 지원되는 버전입니다.
아직 업그레이드가 현실적으로 어렵다면, 공급업체가 지원하는 패치 적용을 통해 구버전이 보안상의 취약점으로 전락하는 것을 막을 수 있습니다.

보안 스캐너가 3년 동안 아무도 손대지 않은 앱에서 jQuery 3.4.1을 탐지하고, 어느새 자신도 모르게 CVE를 안게 됩니다. 이것이 바로 2026년 jQuery 취약점 사태의 전모입니다. 결함은 오래된 것이고, 수정 패치도 이미 존재하지만, 위험은 아무도 여전히 운영 중이라는 사실조차 잊고 있던 버전 속에 숨어 있습니다.

이 가이드에서는 실제 CVE 사례, 이를 통해 공격자가 어떤 행동을 할 수 있는지, 왜 이러한 취약점이 감사를 통과해 버리는지, 그리고 시스템 업그레이드 여부와 관계없이 이를 해결하는 방법을 단계별로 설명합니다.

jQuery 취약점 개요

jQuery 취약점은 특정 라이브러리 버전에 존재하는 보안 결함으로, 공격자가 이를 악용하여 브라우저에서 신뢰할 수 없는 자바스크립트를 실행하거나, 공유 객체 프로토타입을 훼손하거나, 페이지를 다운시킬 수 있습니다. 이러한 취약점은 CVE로 추적됩니다.

문제는 jQuery가 팀 차원에서 적극적으로 유지보수되는 경우가 거의 없다는 점입니다. jQuery는 번들로 묶여 제대로 작동하는 버전에 고정된 채로 방치되기 일쑤입니다. “패치가 존재한다”는 사실과 “패치가 적용된다”는 사실 사이의 그 간극이야말로 진정한 보안 취약점이 도사리고 있는 곳입니다.

jQuery 취약점의 유형

아래의 5개 CVE에 포함된 취약점은 크게 세 가지 범주로 나뉩니다. XSS 가 가장 큰 비중을 차지하지만, 프로토타입 오염 및 서비스 거부 도 스캔 결과에 실제로 나타나는 취약점들을 구성하고 있습니다.

CVE	유형	영향을 받는 버전	수정됨
11022	XSS (htmlPrefilter)	1.2 – 3.4.x	3.5.0
11023	XSS (select/option)	1.0.3 – 3.4.x	3.5.0
11358	시제품으로 인한 오염	1.1.4 – 3.3.x	3.4.0
9251	XSS (크로스 도메인 AJAX)	3.0.0 이전	3.0.0

크로스 사이트 스크립팅(XSS)

XSS는 jQuery의 가장 큰 문제점입니다. CVE-2020-11022 는 jQuery의 DOM 조작 메서드에 전달된 일반적인 신뢰할 수 없는 HTML을 다루며, 이 문제는 jQuery.htmlPrefilter 가 마크업을 정규화하는 방식에서 비롯됩니다. CVE-2020-11023 는 option 요소를 포함하는 HTML을 다룹니다. 이 두 취약점은 1.0.3부터 3.5.0 이전의 모든 릴리스에 영향을 미치며, 여기에는 여전히 현장에서 활발히 사용되고 있는 jQuery 3.4.1도 포함됩니다. 취약한 조건 하에서, 공격자가 제어하는 마크업이 해당 메서드 중 하나에 전달되면, 마크업이 정제된 후에도 페이지 내에서 스크립트가 실행될 수 있습니다. 3.0.0보다 오래된 버전에서는 CVE-2015-9251, 즉 크로스 도메인 Ajax XSS 취약점도 존재하며, 해당 범위 내에서 1.12.2 버전만이 패치된 예외입니다.

프로토타입 오염

CVE-2019-11358 1.1.4부터 3.4.0 미만(3.4.0 제외)까지의 릴리스에 영향을 미칩니다. jQuery.extend(true, {}, …) 를 통해 전달된 조작된 객체는 Object.prototype에 쓰기를 시도할 수 있으므로, 공격자가 제어하는 속성이 해당 프로토타입 체인을 사용하는 다른 객체들에 상속됩니다. 이 자체만으로도 기본적인 조작 기법입니다. 오염된 속성이 하위 단계에서 어떻게 사용되는지에 따라, XSS나 기타 애플리케이션 특유의 영향으로 이어질 수 있습니다. 이 취약점은 Drupal과 Backdrop CMS에서 두드러지게 나타났으며, 이것이 바로 수동으로 작성된 jQuery 코드 외부에서도 이 취약점을 자주 접하게 되는 이유 중 하나입니다.

서비스 거부(DoS)

더 조용한 범주. CVE-2016-10707 은 jQuery 3.0.0-rc.1에만 영향을 미치며, 그 외에는 아무런 영향도 주지 않습니다. 해당 릴리스 후보 버전은 대소문자가 섞인 부울 속성 이름을 잘못 처리하여, 영향을 받는 게터가 무한 재귀에 빠지고 호출 스택을 소진시켰습니다. 이는 XSS 취약점 쌍과는 다른 유형의 영향이며, 해당 코드 경로에 도달하면 여전히 해당 페이지가 멈추게 됩니다. 3.0.0 정식 릴리스에서 이 문제가 수정되었습니다.

알고 계셨나요? 2026년 2026년 OSSRA 보고서(Black Duck) 에 따르면, 가장 널리 퍼진 취약점 상위 10개 중 4개가 jQuery CVE로 확인되었으며, 이는 감사 대상 코드베이스의 25%에서 28%에 영향을 미치는 것으로 나타났습니다. 수년 전부터 존재해 왔고 패치도 오래전부터 제공된 결함임에도 불구하고, 상용 소프트웨어의 4분의 1 이상에서 여전히 발견되고 있습니다.

jQuery 취약점을 해결하지 않을 경우의 위험

jQuery의 CVE는 추상적인 위험이 아닙니다. 이 라이브러리는 방대한 웹 환경의 프론트엔드에서 사용되고 있으며, 어떤 CVE가 존재하는지, 그리고 애플리케이션이 이를 어떻게 활용하느냐에 따라 그 여파는 사용자의 브라우저에서 코드가 실행되는 것부터 감사 보고서에 지적되는 사항이나 페이지 응답 중단에 이르기까지 다양합니다.

계정 탈취 및 세션 도용

XSS는 가장 흔한 jQuery CVE의 주요 영향이며, XSS란 공격자가 사용자의 브라우저에서 자바스크립트를 실행할 수 있게 되는 것을 의미합니다. 실제로 이는 로그인 양식에서 인증 정보를 탈취하거나, 자바스크립트가 접근할 수 있는 세션 데이터를 도용하거나, 로그인된 사용자로 위장하여 눈에 띄지 않게 작업을 수행하는 것을 의미합니다.

HttpOnly 쿠키는 쿠키 자체에 대한 접근을 차단하여 어느 정도 도움이 되지만, 해당 세션 내에서 활동하는 공격자를 막는 데는 아무런 효과가 없습니다. 관리자 대시보드가 여전히 jQuery 3.4.1에서 실행되는 소규모 SaaS 앱의 경우, 단 한 번의 저장형 페이로드만으로도 관리자의 세션에 접근할 수 있습니다.

규정 준수 및 감사 실패

PCI DSS 평가, 취약점 스캔 및 기업 보안 검토 과정에서 운영 환경의 종속성에 존재하는 알려진 취약점이 끊임없이 드러나며, “그저 프론트엔드 라이브러리일 뿐”이라는 변명만으로는 보고서를 무마할 수 없습니다. 해당 구성 요소에 패치를 적용했거나 다른 방법으로 조치를 취했음을 반드시 입증해야 합니다. 여기서 언급된 CVE는 오탐가 아니라 실제 CVE이지만, 개별 스캐너의 탐지 결과는 여전히 실제 코드와 패치 상태를 대조하여 확인해야 합니다. 검토자가 요청하기 전에 이러한 구분을 미리 준비해 두는 것이 좋습니다.

생각보다 더 넓은 폭발 반경

jQuery는 거의 단일 인스턴스로 사용되는 경우가 없습니다. 테마, 플러그인, CMS 코어 등이 모두 jQuery를 불러오기 때문에, 하나의 EOL 버전이 수십 개의 페이지나 하위 시스템에 걸쳐 반복적으로 사용될 수 있습니다. 이러한 확산을 추적하려면 의도적인 노력이 필요하며, CVSS 점수를 을 올바르게 파악하는 것은 작업 순위를 정하기 시작할 때 매우 중요합니다.

주의: 많은 취약점 및 규정 준수 스캐너는 탐지한 jQuery 버전 문자열을 바탕으로 노출 여부를 판단합니다. 업스트림 버전 번호를 유지하는 백포트된 수정 사항이라도 여전히 오탐을 유발할 수 있으므로, 패치 내용을 명확하게 문서화하십시오.

jQuery 취약점은 어떻게 발생하나요?

거의 모든 문제는 세 가지 패턴에서 비롯됩니다. 바로 구버전을 사용하는 것, 본인이 선택하지도 않은 jQuery를 상속받는 것, 그리고 신뢰할 수 없는 입력을 전달하는 것입니다.

구버전 jQuery

이것이 대부분의 팀에게 있어 근본적인 원인입니다. jQuery 1.x와 2.x는 2016년 5월 20일에 각각 1.12.4와 2.2.4라는 최종 버전을 출시한 이후로 더 이상 업스트림 릴리스가 없었습니다. 현재 3.x 브랜치에는 중대한 보안 패치와 버그 수정만 제공되며, 2023년 8월에 출시된 3.7.1이 여전히 최신 버전입니다. 프로젝트 측은 모든 사용자에게 4.x로 전환할 것을 권고하고 있습니다.

한 번 릴리스가 업스트림 지원에서 제외되면, 해당 버전에서 새로 발견된 결함은 사용자가 업그레이드하거나 다른 지원되는 출처에서 패치를 적용하지 않는 한 jQuery 프로젝트 측에서 수정해 주지 않습니다. 이는 수명이 다한 다른 소프트웨어와 마찬가지입니다. 업스트림 유지보수 담당자들은 더 이상 해당 버전을 관리하지 않지만, 사용자의 운영 시스템은 여전히 그대로 가동됩니다.

상속 및 전이성 jQuery

의도적으로 위험을 감수하는 경우는 거의 없습니다. 워드프레스, 드루팔(Drupal), 그리고 수많은 테마와 UI 플러그인들이 jQuery를 자동으로 불러옵니다. 이는 누구도 결정하지 않은 채로 스택에 포함되며, 대개 플러그인 제작자가 테스트한 버전에 고정되어 있습니다. 이러한 복사본들을 찾으려면 단순히 자신의 package.json만 살펴보는 것만으로는 충분하지 않습니다. 이는 PHP 취약점 관리 및 수많은 다른 생태계에서 나타나는 바로 그 숨겨진 의존성 문제입니다.

안전하지 않은 DOM 패턴

현재 릴리스에서도 신뢰할 수 없는 HTML을 .html() 또는 .append()를 통해 신뢰할 수 없는 HTML을 전달하더라도 를 통해 신뢰할 수 없는 HTML을 전달하면 여전히 애플리케이션 수준 XSS가 발생할 수 있습니다. 이 라이브러리는 사용자가 요청한 대로 정확히 동작합니다. 문제는 사용자가 신뢰한 입력에 있습니다.

신뢰할 수 없는 객체에 대한 심층 병합도 동일한 수준의 면밀한 검토가 필요하지만, 패치된 릴리스가 CVE-2019-11358 자체를 해결하고 있으므로 $.extend 의 위험은 함수 자체가 아니라 전달하는 값에 있습니다. 해당 버전에 패치를 적용하면 라이브러리 측의 결함은 해결됩니다. 하지만 코드 검토를 통해 이러한 패턴을 반드시 잡아내야 합니다.

현실 점검: “우리는 jQuery 3을 사용하고 있으니 문제없다”는 것이 가장 흔한 잘못된 가정입니다. CVE-2020-11022와 CVE-2020-11023은 3.5.0 버전에서야 패치되었으므로, 3.4.1 및 그 이전의 모든 3.x 릴리스는 여전히 취약점에 노출되어 있습니다.

jQuery 취약점을 해결하는 방법

명확한 조치 순서가 있습니다. 가능하다면 업그레이드를 진행하고, 불가능하다면 공급업체에서 제공하는 패치를 적용하며, 어느 쪽이든 그 기반 위에 방어 체계를 구축해야 합니다.

1. 지원되는 버전으로 업그레이드하십시오

가장 깔끔한 해결책입니다. jQuery 3.5.0 이상으로 업그레이드하면 XSS 관련 두 가지 문제가 모두 해결되며, 최신 4.x 릴리스로 전환하면 업스트림의 완전한 지원을 받는 최신 브랜치를 사용할 수 있습니다. 단, 4.0 버전부터 jQuery.trim 및 jQuery.isArray와 같은 더 이상 사용되지 않는 API가 제거되었기 때문에 호환성 문제가 발생할 수 있다는 점에 유의해야 합니다.

먼저 현황 파악부터 시작하세요:

npm ls jquery

코드베이스가 깨끗하다면, jQuery Migrate 플러그인의 개발용 빌드를 업그레이드하여 실행함으로써, 프로덕션 환경에 적용된 후가 아니라 그 전에 호환성 경고가 표시되도록 하세요. 만약 레거시 앱이 버전 업그레이드 시 오류가 발생한다면, 아래의 두 번째 방법이 더 현실적인 해결책입니다.

2. 업그레이드가 불가능할 때의 공급업체 지원 패치

많은 팀이 진정으로 난관에 봉착해 있습니다. jQuery 1.x에 묶여 있는 구형 기업용 대시보드나, 주요 버전 업데이트 시 오류가 발생하는 CMS 테마는 단기간 내에 4.x로 전환하기 어렵습니다. 바로 이것이 그 격차입니다. TuxCare의 jQuery용 ‘무한 라이프사이클 지원(ELS)’이 가 메우는 바로 그 공백입니다.

ELS는 CVE 수정 사항을 사용자가 현재 실행 중인 버전으로 역포트하여 npm을 통해 제공합니다. 지원 범위는 jQuery 1.8.2부터 3.4.1까지 총 10개 릴리스에 이르며, 이들 모두는 업스트림 지원 종료 시점을 훨씬 지난 버전입니다. 실질적인 장점은 프론트엔드를 즉시 마이그레이션하거나 재작성할 필요 없이 보안 패치를 적용할 수 있다는 점으로, jQuery에 깊이 의존하는 애플리케이션도 개발팀이 이전 계획을 제대로 수립하는 동안 패치를 계속 적용받을 수 있습니다.

이 지원 범위는 jQuery를 넘어 Java, JavaScript, Python, PHP 및 .NET 생태계 전반에 걸쳐 있습니다.

3. 다층 방어

취약점 패치 이 해결책입니다. 이러한 계층들은 어쩔 수 없이 보안이 뚫렸을 때 피해를 최소화해 줍니다. 공격자가 제어하는 HTML은 안전하지 않은 것으로 간주하고, 가능한 한 텍스트 기반의 안전한 DOM API를 우선적으로 사용하며, 애플리케이션이 신뢰할 수 없는 마크업을 반드시 렌더링해야 할 때는 검증된 HTML 세정 도구를 활용하십시오. 그 위에 엄격한 콘텐츠 보안 정책(CSP)을 적용하십시오. 그리고 SBOM을 생성하십시오 하여, 의존성 메타데이터에 등록된 모든 jQuery 사본이 기록되도록 하십시오.

전문가 팁: 버전 문자열을 기반으로 한 grep 검색은 압축되거나 번들화된 파일을 놓칠 수 있으며, 매니페스트와 락파일을 기반으로 생성된 SBOM은 애초에 npm 메타데이터를 포함하지 않았던 파일들을 놓칠 수 있습니다. retire.js와 같은 콘텐츠 기반 스캐너를 빌드된 자산 전체에 적용해 보세요. 이 도구는 설치된 것이 아니라 다운로드되어 커밋된 라이브러리를 탐지하기 위해 특별히 개발되었기 때문입니다.

EOL jQuery로 인한 비즈니스 위험 최소화

jQuery의 문제는 이 라이브러리가 생소해서가 아닙니다. 문제는 이 라이브러리가 어디에나 널려 있고, 대부분 구식이며, 누구도 적극적으로 관리하지 않는다는 점입니다. 그래서 2015년에서 2020년 사이에 어딘가에서 공개된 CVE가 다음 감사에서 문제가 되는 것입니다. W3Techs에 따르면 현재 전체 웹사이트의 약 66%에서 jQuery를 사용하고 있다고 집계하고 있으며로 집계하고 있으며, 이 중 5개 중 1개 조금 넘는 사이트가 여전히 2016년에 최종 업스트림 릴리스가 이루어진 1.x 또는 2.x 버전을 사용하고 있습니다.

모든 사용 사례를 찾아보세요. 가능한 부분은 업그레이드하세요. 업그레이드할 수 없는 부분은 보안 취약점에 노출된 채로 두지 말고, 공급업체가 지원하는 보안 조치를 마련하세요. 지원 종료(EOL) 버전을 계속 사용해야 하는 경우, TuxCare의 jQuery용 ‘Endless Lifecycle Support’ 를 이용하면, 준비가 될 때까지 강제로 재작성할 필요 없이 마이그레이션을 계획하는 동안에도 지속적으로 패치를 적용받을 수 있습니다.

요약