전자정부 표준프레임워크 치명적 취약점 990건: 공공 웹서비스 패치 점검 가이드

서론

전자정부 표준프레임워크(eGovFrame)는 공공 웹서비스 개발에서 오랫동안 재사용돼 온 기반이다. 공통 컴포넌트, 예제 코드, 업무 기능 템플릿은 개발 시간을 줄여주지만, 같은 코드가 여러 기관과 사업자 프로젝트로 복제·수정되는 구조에서는 패치 전파가 늦어질 수 있다. 이번 990건 취약점 발표를 운영 관점에서 봐야 하는 이유가 여기에 있다.

Project Canopy와 관련 보도에 따르면 eGovFrame 공통 컴포넌트와 MSA용 공통 컴포넌트 분석 과정에서 1차로 1,300여 건의 취약점 후보가 탐지됐고, 중복과 오탐을 정제해 구조적 결함 및 보안 취약점 990건이 최종 식별됐다. 보도에서는 이 중 약 10%가 Critical 또는 High 등급으로 분류됐으며, 인증 우회, 임의 SQL 실행, 고정 암호키 노출에 따른 파일 탈취, IDOR/BOLA 같은 유형이 예시로 언급됐다.

행정안전부는 티오리가 2026년 6월 30일 취약점을 전달했고, 분석 후 보안성 강화 패치를 공유 저장소와 누리집에 배포했으며 사용 기관에도 최신 버전 적용을 안내했다고 설명했다. 다만 이 설명은 "공식 저장소에 패치가 배포됐다"는 의미이지, 각 기관의 실제 운영 서비스에 자동으로 반영됐다는 뜻은 아니다. 공공 웹서비스 운영기관은 자신들의 코드가 어떤 시점의 공통 컴포넌트를 복제했는지, 어떤 부분을 커스터마이징했는지, 공식 패치와 동등한 보완이 실제 운영 코드에 들어갔는지를 확인해야 한다.

본론

990건과 300여 건 패치 수치를 어떻게 읽어야 하나

이번 사안에서 숫자는 서로 다른 층위를 가리킨다. 1,300여 건은 AI 기반 자동 분석에서 나온 1차 취약점 후보 수로 볼 수 있다. 990건은 정제 과정을 거쳐 최종 식별된 구조적 결함 및 보안 취약점 수로 보도됐다. 300여 건 패치 완료는 보도, Project Canopy, 행정안전부 설명에서 언급된 취약점 패치 수로 서술하는 것이 적절하다.

반면 GitHub 커밋이나 PR의 파일 변경 수를 300여 건 패치 수와 같은 의미로 쓰면 부정확하다. "egovframe-common-components"의 PR #1155는 GitHub API 기준 changed_files가 786개다. 해당 PR에 포함된 대표 커밋 "fb45f509f74b15239ebdb4b8bbc9f3985c4f1b85"는 additions 7,815 / deletions 3,606 규모로 확인된다. 따라서 PR #1155는 "300여 건 취약점 패치 완료"의 직접 파일 수 근거가 아니라, 대규모 보안점검 적용 정황과 대표 변경 내역을 보여주는 GitHub 근거로 분리해서 봐야 한다.

이 구분은 단순한 표현 문제가 아니다. 운영기관이 "파일 300개만 바뀌었는지"를 찾는 방식으로 대응하면 실제 패치 범위를 놓칠 수 있다. 반대로 "PR changed_files 786개"를 취약점 786건으로 읽어도 안 된다. 취약점 수, 패치 항목 수, 변경 파일 수, 코드 라인 증감은 서로 다른 지표다.

공개된 GitHub 변경에서 보이는 보안점검 정황

공통 컴포넌트 저장소의 PR #1155 제목은 "NCSC 보안점검 적용"이며, 대규모 파일 변경과 함께 여러 공통 보안 로직이 추가된 정황이 확인된다. 대표적으로 "pom.xml"에는 CKEditor 등 리치 텍스트 콘텐츠 조회 시 XSS 방지를 위한 "jsoup 1.18.3" 의존성이 추가됐다. "EgovHtmlSanitizer.java"는 스크립트, 이벤트 핸들러, 위험 프로토콜을 제거하는 HTML Sanitizer 역할로 볼 수 있다.

"EgovWebUtil.java"에는 XSS, SSRF, 세션 고정 대응에 필요한 유틸리티가 추가된 것으로 확인된다. 내부 IP, 루프백, 링크로컬 주소 차단을 위한 FTP 호스트 검증, 상대경로 URL 검증, XML·JavaScript escape 로직 등은 특정 화면 하나가 아니라 여러 공통 흐름에 영향을 주는 방어 코드다. CSRF 관련 보안 구성으로 "EgovCsrfSecurityConfig.java", "EgovCsrfControllerAdvice.java" 같은 파일도 포함된다.

변경 범위는 게시판, 댓글, 파일, 이미지, 메일, LDAP, OAuth, Captcha, WebSocket, Batch 등 다양한 Controller와 JSP로 이어진다. 이는 이번 보안점검이 단일 취약점 수정이라기보다 공통 컴포넌트 전반의 입력 검증, 출력 인코딩, 권한 확인, 요청 위조 방어, 파일 처리 방어를 넓게 보완하는 성격임을 시사한다.

MSA 공통 컴포넌트 쪽에서도 별도 변경이 확인된다. "egovframe-msa-common-components"의 2026년 7월 8일 커밋 "4e3d98e3633f1007a374a552dc134a7e2461b12e"는 "NCSC 보안점검 조치 적용"으로 표시되며, Gateway와 Downstream 서비스 사이의 내부 인증 신뢰 모델 보완이 핵심이다. "GatewayInternalAuthSupport", "GatewayInternalAuthVerifier", "AuthorizeFilter", "gateway.internalSecret" 관련 변경은 고정 헤더나 단순 코드 비교 방식 대신 내부 서명 검증과 Secret 분리로 전환하려는 방향을 보여준다.

운영기관이 특히 주의해야 할 패치 고립

eGovFrame 공통 컴포넌트는 일반 라이브러리처럼 의존성 한 줄을 올리면 모든 서비스에 자동 반영되는 구조만 있는 것이 아니다. 많은 공공 웹서비스는 예제와 공통 컴포넌트 코드를 프로젝트 내부로 복사한 뒤 업무 요구에 맞게 JSP, Controller, Service, Mapper를 수정한다. 외주 개발 산출물, 자체 수정본, 오래된 복제본, MSA 전환 과정의 분기 코드가 섞인 환경도 흔하다.

이 구조에서는 공식 저장소가 패치돼도 운영 서비스의 취약 코드가 그대로 남는 패치 고립이 발생할 수 있다. 버전 문자열이 최신처럼 보여도, 실제 파일은 과거 공통 컴포넌트를 바탕으로 수정돼 있을 수 있다. 반대로 파일명은 달라졌지만 동일한 기능 흐름이 운영 코드 어딘가에 남아 있을 수도 있다.

따라서 운영기관의 점검 기준은 "우리 서비스가 eGovFrame을 쓴다"에서 멈추면 안 된다. 어떤 공통 컴포넌트가 포함됐는지, 원본 복제 시점이 언제인지, 공식 패치의 보안 로직이 운영 코드에 반영됐는지, 자체 수정으로 인해 패치가 누락됐는지를 기능 단위로 확인해야 한다.

우선 점검해야 할 공격 표면

세부 취약점 목록과 PoC가 공개된 상태는 아니므로, 운영기관은 공개된 취약 유형과 패치 단서를 기반으로 우선순위를 정해야 한다. 가장 먼저 볼 영역은 인증 전 접근 가능한 파일 업로드, 파일 다운로드, 이미지 출력, 웹에디터, 게시판 첨부파일 기능이다. 이 영역은 웹셸 업로드, 경로 조작, MIME 우회, 내부 파일 노출, 이미지 프록시형 SSRF와 연결될 수 있다.

웹에디터와 게시글 HTML 렌더링도 우선순위가 높다. CKEditor 같은 리치 텍스트 입력값은 저장형 XSS의 대표 경로다. Sanitizer가 적용됐는지, 기존 게시글과 민원·공지·자료실 콘텐츠가 안전하게 렌더링되는지, 허용 태그와 속성 정책이 과도하게 느슨하지 않은지 확인해야 한다.

관리자, 권한관리, 회원 기능은 인증 우회와 권한 체크 누락, IDOR/BOLA, 세션 고정의 영향을 크게 받을 수 있다. URL 직접 접근, 파라미터 변조, 사용자·기관·부서 ID 변경 테스트를 통해 다른 사용자의 데이터에 접근할 수 없는지 확인해야 한다.

DB, 검색, 통계, 배치 기능은 임의 SQL 실행 보도와 맞닿는 영역이다. 동적 쿼리, 관리자 검색 조건, 엑셀 다운로드, 배치 실행 파라미터, Mapper ID를 우선 리뷰해야 한다. 특히 운영자 화면은 외부에 직접 노출되지 않더라도 계정 탈취 이후 피해를 키울 수 있으므로 별도 점검 대상이다.

MSA 환경에서는 Gateway와 내부 API의 신뢰 경계를 확인해야 한다. Gateway 내부 인증 서명 검증, 내부 Secret 분리, 신뢰 헤더 제거, Downstream 직접 접근 차단 여부가 핵심이다. 운영 로그에서는 Gateway를 통과하지 않은 내부 API 호출, 비정상 X-* 헤더, 반복되는 401·403 응답을 모니터링해야 한다.

운영기관용 패치 검증 절차

첫 단계는 자산 목록화다. eGovFrame 기반 서비스, 공통 컴포넌트 사용 여부, 단일형과 MSA형 구분, 원본 복제 시점, 커스터마이징 파일, 외부 노출 URL을 목록으로 만든다. Maven·Gradle 의존성만 보지 말고 소스에 직접 포함된 공통 컴포넌트 코드도 확인해야 한다.

두 번째는 패치 기준선 수립이다. 단일형 공통 컴포넌트는 "egovframe-common-components"의 2026년 7월 14일 "NCSC 보안점검 적용" 변경과 공식 배포 패치를 기준선으로 삼는다. MSA형은 "egovframe-msa-common-components"의 2026년 7월 8일 "NCSC 보안점검 조치 적용" 변경을 별도 기준선으로 삼는다. 300여 건 패치 완료 수치는 취약점 패치 수로 참고하되, 파일 단위 점검은 PR #1155의 changed_files 786개 및 대표 보안 로직을 기준으로 맵핑해야 한다.

세 번째는 코드 diff 검증이다. 원본 저장소의 패치 파일 목록과 운영 코드의 대응 파일을 매핑한다. 단순 문자열 검색보다 Controller, JSP, Util, SecurityConfig, Filter, Interceptor 단위로 기능 반영 여부를 확인해야 한다. 자체 수정으로 원본 파일명이 바뀐 경우 라우트, Bean 이름, Mapper ID, JSP include 경로까지 추적한다.

네 번째는 보안 회귀 테스트다. 인증·인가, CSRF, XSS, SSRF, 파일 업로드·다운로드, 이미지 렌더링, SQL 입력값 검증을 테스트 케이스로 만든다. Sanitizer 적용 후 기존 게시글과 민원·공지·자료실 콘텐츠가 깨지지 않는지 샘플링하고, 권한 변경이나 세션 만료 같은 정상 흐름도 함께 확인한다.

다섯 번째는 운영 모니터링이다. 패치 전후로 파일·이미지 처리 URL, 관리자 기능, Gateway 내부 호출, 권한 오류, 4xx·5xx 급증을 관찰한다. 공개 PoC가 없더라도 보도 이후 스캐닝이 늘 수 있으므로 WAF와 웹 로그에서 eGovFrame 특유 경로 접근을 별도 룰로 추적하는 편이 안전하다.

다음 표는 운영기관 점검 체크리스트로 활용할 수 있다.

과장과 축소를 모두 피해야 한다

이번 사안을 "모든 공공 웹서비스가 즉시 침해 가능하다"고 단정하면 부정확하다. 행정안전부 설명처럼 프레임워크 재료 코드의 취약점과 최종 운영 웹시스템 취약점은 구분해야 한다. 각 기관의 서비스 구조, 복제 시점, 커스터마이징 정도, 외부 노출 여부에 따라 실제 위험은 달라진다.

반대로 "행정안전부가 패치를 배포했으니 조치가 끝났다"고 보는 것도 위험하다. eGovFrame 공통 컴포넌트의 재사용 방식상 공식 저장소 패치와 운영 시스템 반영 사이에 간극이 생길 수 있다. 운영기관은 최신 버전 적용 안내를 받은 뒤 실제 운영 코드까지 패치가 들어갔는지 확인해야 한다.

2025년에 공개된 eGovFrame 관련 CVE 사례는 이번 990건 발표와 동일 사건은 아니다. 다만 파일 업로드, 웹에디터, 암호키, 공개 추적 체계가 반복적으로 문제가 될 수 있다는 배경 근거로는 참고할 수 있다. 이번 글에서는 공개되지 않은 세부 악용 절차를 재현하기보다, 공개된 범위의 취약 유형과 패치 검증 절차에 초점을 맞추는 것이 적절하다.

결론

전자정부 표준프레임워크 990건 취약점 발표는 공공 웹서비스 운영기관에 두 가지 과제를 남긴다. 하나는 공식 저장소와 누리집에 배포된 보안성 강화 패치를 확인하는 일이고, 다른 하나는 그 패치가 실제 운영 서비스의 복제·커스터마이징 코드까지 반영됐는지 검증하는 일이다.

300여 건 패치 완료는 취약점 패치 수로 이해해야 하며, GitHub PR #1155의 changed_files 786개나 커밋의 additions/deletions와 혼동해서는 안 된다. GitHub 변경은 대규모 보안점검 적용 정황과 대표 보안 로직을 확인하는 근거로 활용하고, 운영기관은 이 변경이 자기 코드에 어떻게 대응되는지 별도로 매핑해야 한다.

우선순위는 명확하다. eGovFrame 기반 서비스 목록을 만들고, 단일형과 MSA형을 나누며, 파일 처리·웹에디터·인증인가·SQL·Gateway 내부 인증 영역부터 점검한다. 버전 표기만 확인하는 방식에서 벗어나 diff, 회귀 테스트, 운영 로그 모니터링까지 이어져야 한다. 이번 사안의 핵심은 취약점 숫자보다 패치가 운영 코드에 도달했는지 확인하는 데 있다.

참고자료

1. 보안뉴스
   https://m.boannews.com/html/detail.html?idx=144687&skind=i

2. 행정안전부 설명자료
   https://www.korea.kr/briefing/actuallyView.do?newsId=148968153

3. 행정안전부 설명자료 PDF
   https://www.korea.kr/common/download.do?fileId=198508071

4. Byline Network
   https://byline.network/2026/07/14-602/

5. ZDNet Korea
   https://zdnet.co.kr/view/?no=20260714113340

6. 전자신문
   https://www.etnews.com/20260714000416

7. Project Canopy
   https://project-canopy.com/

8. eGovFrame GitHub Organization
   https://github.com/eGovFramework

9. egovframe-common-components PR #1155
   https://github.com/eGovFramework/egovframe-common-components/pull/1155

10. egovframe-common-components commit fb45f509
    https://github.com/eGovFramework/egovframe-common-components/commit/fb45f509f74b15239ebdb4b8bbc9f3985c4f1b85

11. egovframe-msa-common-components commit 4e3d98e
    https://github.com/eGovFramework/egovframe-msa-common-components/commit/4e3d98e3633f1007a374a552dc134a7e2461b12e

12. eGovFrame Security Policy
    https://github.com/eGovFramework/egovframe-runtime/blob/main/security.md

13. eGovFrame Code Inspection Guide
    https://www.egovframe.go.kr/wiki/doku.php?id=egovframework%3Adev4.3%3Aimp%3Ainspection

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.