jQuery UI 지원 종료 및 보안 유지 방법

주요 내용

• jQuery UI는 2021년 10월부터 유지보수 전용 모드로 전환되었으며, 가장 최신의 마이너 버전에만 수정 사항이 적용됩니다.
• jQuery UI 1.10.4에는 세 가지의 알려진 XSS 취약점이 포함되어 있으며, 이들 모두는 1.13.0 버전에서만 수정되었습니다.
• 3.5.0 미만의 jQuery 버전에는 CISA가 지정한 악용된 XSS 취약점이 포함되어 있으며, 2014년 버전의 jQuery UI로 인해 해당 업그레이드가 복잡해집니다.
• Realistic Paths의 해결책은 1.14.x 버전으로 업그레이드하거나, 위젯을 교체하거나, 확장 지원 서비스를 구매하는 것입니다.

2008년부터 2018년 사이에 웹 애플리케이션을 구축한 많은 기업들은 여전히 어딘가에 jQuery UI를 사용하고 있습니다. 경비 청구 양식의 날짜 선택기, 관리자 패널의 모달 대화 상자, 내부 검색 창에서 자동 완성 기능 등이 그 예입니다. 이러한 위젯들은 여전히 정상적으로 작동하기 때문에, 수년 동안 아무도 손을 대지 않은 것입니다. 문제는 이러한 애플리케이션이 계속 실행되는 동안 jQuery UI의 지원 종료가 조용히 이루어졌으며, 구버전의 경우 업스트림 보안 수정 사항이 더 이상 이전 버전으로 적용되지 않는다는 점입니다.

이 글에서는 jQuery UI의 현재 지원 현황, 아직 운영 중인 버전에 영향을 미치는 CVE는 무엇인지, jQuery에 대한 의존성이 라이브러리 자체보다 더 주목받아야 하는 이유, 그리고 앞으로 어떤 선택지가 있는지 살펴봅니다.

그림 1: 여러분이 익숙하게 볼 수 있는 위젯들.

jQuery UI는 정말로 지원이 종료된 것일까?

최신 버전을 제외한 모든 릴리스 라인의 경우, 그렇습니다. 2021년 10월, jQuery 유지보수 담당자들은 jQuery UI를 유지보수 전용 상태로 전환하고, 1.13.0을 프로젝트의 마지막 예정 릴리스로 발표했습니다. 이후 계획이 약간 변경되어 릴리스가 계속되고는 있지만, 이는 보안, 호환성 및 회귀 현상 수정 작업을 위한 것이며, 최신 마이너 버전에만 한정됩니다.

jQuery UI에 대해 공식적으로 발표된 지원 종료 일정은 없으므로, 아래 날짜들은 공식적으로 발표된 지원 종료 공지가 아닌 ‘최신 마이너 버전만 제공’ 정책에 근거한 것입니다.

문제는 맨 아래 행들에서 시작됩니다. 1.12.1은 5년 동안 최신 릴리스였으며, 많은 팀이 이 버전을 고정해 사용했지만, 상당수의 애플리케이션은 그 단계까지 도달하지 못했습니다. 1.10.4는 2014년 1월에 출시되었고 같은 해에 수정 패치 제공이 중단되었으므로, 여전히 이 버전을 실행 중인 시스템은 10년 넘게 업스트림 보안 패치를 받지 못한 상태입니다. 만약 여러분의 애플리케이션이 2014년 이전에 구축되었고, 아무도 프론트엔드를 의도적으로 업그레이드하지 않았다면, 이것이 가장 먼저 확인해야 할 사항입니다.

그림 2: 릴리스 라인 간 지원 격차.

jQuery UI의 지원 종료(EOL)가 애플리케이션에 미치는 영향

버려진 UI 라이브러리는 버려진 서버 런타임과는 다른 방식으로 취약점을 드러냅니다. 취약한 코드는 사용자의 브라우저에서, 사용자가 매일 상호작용하는 페이지에서 실행되며, 아래에서 다루는 jQuery UI 취약점들은 모두 서버 측 문제가 아닌 크로스사이트 스크립팅(XSS) 취약점입니다.

이미 등록된 CVE 목록

1.13 버전 계열에서 4건의 XSS 취약점이 수정되었습니다. 이 중 3건은 1.10.4 버전까지 거슬러 올라갑니다. 나머지 1건은 해당 취약점이 노리는 위젯이 그 이전 버전에는 존재하지 않았기 때문에 1.12.0 버전 및 그 이후 버전에만 영향을 미칩니다.

41182 그리고 41183 datepicker를 통해 스크립트 주입을 허용합니다. altField 옵션과 그 *Text 각각의 옵션입니다. 41184 다음과 같은 방식을 통해 동일한 기능을 수행합니다. of 의 .position() 툴팁이나 자동 완성 같은 위젯이 내부적으로 사용하는 유틸리티입니다. 이 세 가지 모두 1.13.0 버전에서 수정되었으므로, 1.10.4 배포본에는 이 세 가지가 모두 포함되어 있습니다. 네 번째는, 31160, 이는 HTML과 유사한 레이블이 포함된 체크박스 라디오 위젯을 새로 고침할 때 발생하는 XSS 취약점이며, 1.13.2 버전에서 수정되었습니다. 해당 위젯은 1.12.0 버전에서 처음 도입되었으므로, 1.10.4나 1.11.x 버전에는 이 취약점이 있는 코드 경로가 존재하지 않습니다. 하지만 다음 스캔 보고서가 나오기 전에 알아두면 좋은 점은, 공개된 권고문에서 1.13.2 미만의 모든 버전을 하한선 없이 취약한 것으로 표시하고 있기 때문에, 스캐너는 어쨌든 1.10.4에 대해서도 이 문제를 지적할 것이라는 점입니다.

시기를 살펴볼 필요가 있습니다. 네 가지 취약점 중 세 가지는 유지보수 모드 전환 발표와 함께 출시된 1.13.0 버전에서 바로 수정되었으며, 관련 보안 권고문은 몇 주 후에 공개되었습니다. 나머지 한 가지는 유지보수 모드로 전환된 지 9개월 만에 발견되었습니다. 활발한 개발이 중단된 후에도 취약점이 계속 발견되었습니다. 달라진 점은 수정 사항이 얼마나 과거 버전까지 소급 적용되는가 하는 점입니다.

그림 3: 인터페이스 내 CVE의 위치.

결코 역포트되지 않는 것들

유지보수 정책은 최신 마이너 버전에만 적용됩니다. 날짜 선택기나 대화 상자에서 다음 결함이 발견되면, 이를 1.14.x 버전을 기준으로 평가하여 패치가 필요한 경우 해당 버전에만 패치를 적용하고, 그 외 버전에는 아무런 조치를 취하지 않습니다.

jQuery UI 보안 공지에서는 영향을 받는 범위를 다음과 같이 명시하기 때문에, 해당 공지에서는 귀하의 지점이 영향을 받는다고 안내할 가능성이 높습니다. < 1.13.0 그리고 < 1.13.2. 백포트는 이루어지지 않을 것입니다. 버전이 고정된 팀들의 경우, 해당 브랜치에 전달되는 향후 모든 보안 권고 사항은 업스트림 측에서 결코 패치하지 않을 취약점을 다루게 될 것입니다.

규정 준수 체계가 실제로 효과를 발휘하는 곳

감사 논리는 유지보수가 이루어지지 않는 모든 구성 요소에 대해 동일하지만, 적용되는 방식은 귀사가 따르는 프레임워크에 따라 달라집니다. PCI DSS 4.x는 중대한 취약점에 대해서는 패치가 출시된 후 1개월 이내에 적용할 것을 요구하며, 그 외의 모든 취약점은 귀사가 정의한 위험 기반 일정에 따라 처리하도록 규정하고 있습니다. 지원되는 수정 프로그램이 없는 경우, 패치를 통해 이 두 가지 기한을 모두 충족하기는 쉽지 않습니다. SOC 2 통제 사항에 취약점 관리가 포함되어 있다면, 지원되지 않는 구성 요소로 인해 상류에서 수정 프로그램이 제공되지 않을 때 식별된 위험이 실제로 처리되고 있음을 입증하기가 더 어려워집니다. 바로 이 시점에서 감사관들은 귀사의 취약점 관리 프로세스가 실제로 어떤 역할을 하는지 묻기 시작합니다. HIPAA 보안 규칙은 규제 대상 기관이 ePHI에 대한 위험을 식별하고 이를 합리적이고 적절한 수준으로 낮출 것을 요구하므로, 환자용 포털에 알려진 수정 불가능한 XSS 취약점이 존재한다면, 귀사가 원하든 원하지 않든 그 분석의 일부가 될 수밖에 없습니다.

최근 연방 정부의 업무 방식이 변화함에 따라 기존의 약어는 더 이상 유효하지 않게 되었습니다. CISA는 2026년 6월에 BOD 22-01을 폐지하고 이를 BOD 26-04로 대체했는데, 이 규정은 연방 민간 기관의 시정 조치 기한을 자산 노출 정도, KEV 상태, 악용 자동화 및 기술적 영향에 따라 단계별로 구분하며, 최악의 경우 단 3일 이내에 조치를 완료해야 합니다. FedRAMP도 동일한 위험 기반 접근 방식을 채택하고 있으며, 2026년 12월 7일부터 클라우드 서비스 제공업체에 대해 ‘취약점 탐지 및 대응(Vulnerability Detection and Response)’ 규정이 의무화되어, 일률적인 30일 고위험 취약점 처리 기한이 위험 기반 평가로 대체됩니다. 제품 제조업체들은 EU의 ‘사이버 복원력 법(Cyber Resilience Act)’에 따라 이와 유사한 규정을 적용받게 되며, 이 법에 따라 실제로 악용되고 있는 취약점에 대한 보고 의무는 2026년 9월 11일부터 시행되고, 전체 취약점 처리 요건은 2027년 12월부터 적용됩니다.

범위, 노출 정도, 보완 통제 수단 등이 모두 중요한 요소이기 때문에, 이러한 프레임워크 중 어느 것도 “레거시 jQuery 감지”를 자동적인 발견 사항으로 간주하지 않습니다. 하지만 스캐너는 레거시 프론트엔드 스택을 신속하게 식별해 내며, 이러한 어떤 체계 하에서든 해당 경고는 정당화해야 할 작업이 됩니다.

EOL된 jQuery UI가 구버전 jQuery를 그대로 유지하는 방법

jQuery UI의 종속성 트리는 이보다 더 간단할 수 없을 정도입니다. 현재 npm 패키지에서는 jQuery가 유일하게 선언된 런타임 종속성이며, 다음과 같이 고정되어 있습니다. jquery >=1.12.0 <5.0.0. 이전 버전의 jQuery UI 코드에서는 스피너 위젯 내부에 jQuery Mousewheel 플러그인에 대한 컴포넌트 수준의 의존성이 포함되어 있었으나, 이는 2026년 1월 1.14.2 버전에서 제거되었으며, 애초에 두 번째로 명시된 의존성은 아니었습니다. 어쨌든, 이는 런타임 바이너리 내에 묻혀 있는 컴포넌트가 아닙니다. jQuery는 자체 스크립트 태그를 통해 로드되며, 대개 jQuery UI 코드 바로 위 줄에 위치합니다. 또한 대부분의 팀은 jQuery UI 버전보다 jQuery 버전을 더 빨리 확인할 수 있습니다. 여기서 문제가 되는 위험은 숨겨져 있는 것이 아니라, 결합되어 있다는 점입니다.

먼저, 해당 가시적 의존성에서 어떤 위험이 도사리고 있는지 살펴보겠습니다. jQuery 1.0.3부터 3.4.1까지 모든 버전에 영향을 미치는 XSS 취약점인 CVE-2020-11023은 실제 환경에서 악용된 증거가 확인된 후 2025년 1월에 CISA의 ‘악용된 것으로 알려진 취약점(Known Exploited Vulnerabilities)’ 목록에 등재되었으며, 연방 정부의 수정 기한은 2025년 2월 13일로 정해졌습니다. 이와 유사한 CVE-2020-11022는 동일한 DOM 조작 계열의 취약점을 다루며, CVE-2019-11358은 3.4.0 이전 버전에서 발생하는 프로토타입 오염(prototype pollution) 문제를 다룹니다. 프로토타입 오염 문제는 3.4.0에서, 두 가지 XSS 결함은 3.5.0에서 수정되었으므로, 여기에 언급된 모든 문제는 2020년 이후 업스트림에서 패치되었습니다.

그렇다면 6년이 지난 지금도 왜 여전히 많은 스택에서 jQuery 1.x나 2.x를 사용하고 있을까요? 일부의 경우, jQuery UI가 버전 업그레이드를 어렵게 만드는 요인 중 하나입니다. jQuery UI 1.10.4는 jQuery 3.0이 출시되기 2년 이상 전인 2014년 1월에 출시되었으며, 프로젝트 측은 이후 1.13.0 버전의 주요 목표를 “최신 jQuery 버전과의 호환성 개선”이라고 설명했습니다 . 그토록 오래된 릴리스는 당시 존재하지도 않았던 jQuery 버전으로 테스트될 수 없었기 때문에, 동결된 1.10 배포 환경 하에서 jQuery를 업그레이드하는 것은 단순한 버전 상승이 아니라 호환성 확보를 위한 작업에 가깝습니다. jQuery 업그레이드는 jQuery UI 업그레이드를 기다리게 되고, jQuery UI 업그레이드는 끝내 오지 않는 QA 기간을 기다리게 됩니다. 지원 종료(EOL)된 위젯 라이브러리는 jQuery의 위험을 감춰주지 않습니다. 오히려 그 위험을 고착시키는 데 일조할 수 있습니다.

그림 4: 지원 종료(EOL)된 위젯 라이브러리가 jQuery 업그레이드를 어떻게 복잡하게 만들 수 있는지.

확장 지원은 양쪽 모두에 먼저 업그레이드를 강요하지 않으면서도 이러한 교착 상태를 타개할 수 있는 한 가지 방법이며, TuxCare는 이미 1.8.2부터 3.4.1까지의 일부 EOL(지원 종료) jQuery 릴리스에 대한 보안 패치를 제공하고 있으므로, jQuery 계층은 현재 위치 그대로 패치된 상태를 유지할 수 있습니다.

jQuery UI 지원 종료(EOL) 이후의 선택지

어떤 방식을 선택할지는 현재 프론트엔드 작업을 어느 정도 감당할 수 있는지에 달려 있습니다. 정상적으로 작동하는 인터페이스를 건드리지 않고 패치만 적용해야 한다면, jQuery 레이어에 대한 지원 기간 연장을 통해 시간을 벌 수 있습니다. jQuery 마이그레이션과 본격적인 QA 테스트 일정을 잡을 수 있다면, 1.14.x 버전으로 업그레이드하는 것이 가장 깔끔한 해결책입니다. 그리고 어차피 프론트엔드를 재구축해야 한다면, 해당 프로젝트의 일환으로 jQuery UI를 분리해 내는 것이 작업을 두 번 하는 것보다 낫습니다.

연장 지원으로 시간을 벌기

TuxCare의 EOL(지원 종료) jQuery 릴리스에 대한 ‘Endless Lifecycle Support(ELS)’는 사용자가 이미 실행 중인 버전에 대한 패치를 지속적으로 제공하며, jQuery UI 1.10.4용 ELS 패키지도 마련되어 있습니다. 수정 사항은 해당 릴리스로 역포트되어 기존 동작과 호환성 테스트를 거친 후 서명 처리되며, SLA(서비스 수준 계약)의 보장을 받아 npm을 통해 제공되므로, 이를 적용하는 것은 프레임워크 마이그레이션이 아닌 단순한 의존성 구성 변경만으로 가능합니다. TuxCare는 선별된 EOL jQuery 코어 릴리스도 지원하므로, 지원 대상 jQuery 버전을 사용하는 jQuery UI 1.10.4 팀은 양쪽 모두에서 프레임워크 마이그레이션 없이 두 계층을 모두 처리할 수 있습니다. 공개 지원 매트릭스에는 전체 브랜치 대신 특정 릴리스가 나열되어 있으며, 1.10.4는 현재 문서화된 jQuery UI 릴리스이므로, 관련 계획을 세우기 전에 사용 중인 버전을 해당 매트릭스와 대조해 확인하시기 바랍니다.

TuxCare는 OpenJS 재단의 골드 회원으로서, 또한 재단이 더 이상 유지 관리하지 않는 버전에 대한 상업적 지원을 프로젝트와 연결하기 위해 운영하는 비독점적 프로그램인 ‘생태계 지속 가능성 프로그램(Ecosystem Sustainability Program)’의 전략적 파트너로서 이러한 활동을 수행하고 있습니다. 또한 TuxCare CVE 트래커에서 실시간으로 취약점 및 수정 사항을 확인할 수 있습니다.

연장 지원의 목적은 사용자를 오래된 버전에 영원히 묶어두기 위한 것이 아닙니다. 이는 기한에 대한 부담을 덜어줌으로써, 최종적인 업그레이드가 사용자의 일정에 맞춰 제대로 이루어지도록 하기 위함입니다.

1.14.x 버전으로 업데이트

지원되는 마이너 버전을 계속 사용하는 것이 가장 깔끔한 방법이지만, 1.10 시대의 앱에 있어서는 버전 번호가 시사하는 것보다 그 과정이 훨씬 더 길어집니다. 1.14 버전에서는 jQuery 1.7부터 1.11까지, 2.0부터 2.1까지, 그리고 3.0부터 3.5까지에 대한 지원이 중단되었는데, 이는 실질적으로 각 jQuery 메이저 버전의 최신 릴리스를 제외한 모든 버전을 의미합니다.

이는 주목할 만한 함정을 만들어 냅니다. jQuery UI 1.14.x는 여전히 jQuery 1.12.4 및 2.2.4를 기준으로 테스트되므로, 이미 해당 버전 중 하나를 사용 중인 환경에서는 1.14로 전환하기 위해 jQuery를 업그레이드할 필요가 없습니다. 또한 보안 측면에서도 아무런 이점이 없는데, 두 릴리스 모두 3.5.0보다 낮은 버전이며 여전히 KEV에 등재된 CVE를 포함하고 있기 때문입니다. 취약점이 있는 jQuery를 계속 사용하면서 지원되는 jQuery UI 마이너 버전을 적용하는 상황은 충분히 발생할 수 있습니다.

jQuery의 경우, 2026년 1월에 출시된 4.0.0 버전은 Internet Explorer 10 및 그 이전 버전을 지원에서 제외하는 한편, 당분간 IE 11은 계속 지원하며, jQuery UI 1.14.2는 이 버전과 호환성 테스트를 마쳤습니다. 3.x 계열을 계속 사용하실 경우, 오래된 CVE를 우연히 수정했을 뿐인 최소 지원 버전보다는 3.7.1과 같은 최신 릴리스를 대상으로 삼는 것이 더 좋습니다.

1.14 버전에서는 Internet Explorer 및 Edge Legacy에 대한 지원이 완전히 제거되었으며, 기본적으로 구형 1.11 API 호환성 레이어가 비활성화되지만, 설정을 jQuery.uiBackCompat 에 true 더 부드러운 전환이 필요하다면 1.13 버전의 동작 방식을 복원해 줍니다. 1.10.4 버전에서 바로 업그레이드할 경우, 버튼 API 변경 사항과 재설계된 효과 API를 포함하여 1.11 및 1.12 버전의 호환성 깨는 변경 사항들을 그 과정에서 수용해야 하며, 해당 호환성 레이어는 완전한 1.10 동작 방식이 아닌 1.11 API를 기반으로 구축되어 있습니다. 이 두 가지 모두 jQuery UI가 여전히 사용되고 있는 바로 그 종류의 내부 기업용 앱에 있어 중요한 문제입니다. 또한 1.14는 다음 마이너 버전이 출시될 때까지만 지원되므로, 버전 전환을 마친 후에도 유지보수의 악순환은 계속됩니다.

jQuery UI에서 마이그레이션하기

이 위젯들에는 현대적인 대응물이 있습니다. 다음과 같은 네이티브 컨트롤들처럼 <input type="date"> 간단한 사례들은 직접 처리하고, React나 Vue용으로 구축된 컴포넌트 라이브러리나 표준 기반 웹 컴포넌트가 나머지 부분을 담당합니다. 어차피 애플리케이션의 프론트엔드 재구축이 예정되어 있다면, jQuery UI 제거 작업을 해당 프로젝트에 포함시키는 것이 올바른 결정입니다. EOL에 대한 단독 대응책으로 볼 때, 이는 일반적으로 고려 가능한 옵션 중 가장 비용이 많이 드는 선택지입니다. 왜냐하면 현재 해당 위젯들이 구동하고 있는 모든 상호작용 영역을 재구축하고 재테스트해야 하기 때문입니다.

서둘러 업그레이드를 진행할 때의 위험성

jQuery UI 업그레이드는 사용자에게 직접적인 영향을 미치는 변경 사항이므로, 백엔드 업그레이드를 서두르는 것보다 그 영향이 더 두드러지게 나타납니다. jQuery 3.x로의 마이그레이션은 2010년대 코드가 은연중에 의존해 온 동작을 변경할 수 있습니다. 위젯 마크업과 테마 적용 방식이 버전별로 달라졌기 때문에, ThemeRoller 시대에 작성된 사용자 정의 CSS를 검토해야 합니다. 또한 검증은 단위 테스트 실행만으로 끝나서는 안 됩니다. 이는 사용자가 여전히 사용하는 모든 브라우저에서, 날짜 선택기, 대화 상자, 아코디언 또는 자동 완성 기능이 포함된 모든 페이지에 대해 시각적 및 기능적 회귀 테스트를 수행해야 함을 의미합니다.

이를 긴급 스프린트로 뭉뚱그려 진행하는 팀은 레이아웃 오류나 제대로 작동하지 않는 양식을 그대로 사용자에게 배포할 위험이 있으며, 그 결과 이후 몇 주 동안 지원 티켓 처리와 핫픽스 작업에 매달리게 됩니다. 서두르는 과정에서 추가된 임시 해결책은 아무도 감히 손대지 못하는 다음 과제가 되기 때문에, 기술적 부채는 조용히 쌓여만 갑니다. 사용자에게 노출되는 라이브러리의 업그레이드는 철저한 계획을 중시하고, 마감 기한에 쫓기는 방식은 오히려 역효과를 낳습니다.

TuxCare를 통해 EOL 이후에도 레거시 프론트엔드를 안전하게 유지 관리하세요

TuxCare는 자동화된 CVE 모니터링 및 백포팅과 테스트, 그리고 필수적인 전문가 검토를 결합한 패치 프로세스를 바탕으로, 지난 10년 이상 수천 개 조직의 엔터프라이즈 운영 환경에서 오픈소스 소프트웨어에 대한 패치를 지속적으로 제공해 왔습니다. 프론트엔드가 고정된 상태인 경우, 이는 귀사의 비즈니스가 여전히 의존하고 있는 코드가 프론트엔드 재작성을 긴급한 상황으로 만들지 않으면서도 지속적으로 보안 수정 사항을 적용받을 수 있음을 의미합니다.

jQuery용 ELS를 살펴보거나, CVE 트래커에서 이미 수정된 취약점이 무엇인지 확인해 보세요.

요약

기사 이름

jQuery UI 지원 종료 및 보안 유지 방법

설명

jQuery UI 1.10.4는 10년 넘게 지원이 중단된 상태이며, 알려진 XSS 취약점이 포함되어 있습니다. 관련 위험 사항과 해결 방법을 확인하십시오.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고