CVE-2026-57853: DataGerry 서버 측 템플릿 인젝션 취약점 점검

CVE-2026-57853는 DataGerry 3.3.0 미만 버전의 DocAPI 템플릿 기능에서 확인된 서버 측 템플릿 인젝션(SSTI) 취약점입니다. 점검의 초점은 공격 기법의 복잡함이 아니라, 템플릿을 추가할 수 있는 권한이 서버에서의 명령 실행으로 연결되는 경로가 문서로 명확히 기술되어 있다는점에 있습니다.

개요

개요 인포그래픽
CVE 상세에 따르면 DataGerry 3.3.0 미만 버전에는 서버 측 템플릿 인젝션 취약점이 존재합니다. base.docapi.template.add 권한을 가진 인증된 공격자가 POST /rest/docapi/template 요청의 template_data 필드에 임의의 Jinja2 페이로드를 저장하고, 이후 사용자가 GET /rest/docapi/template/<id>/render/<object_id>를 호출하면 저장된 내용이 샌드박스가 적용되지 않은(non-sandboxed) Jinja2 환경에서 렌더링됩니다.

이 렌더링 과정에서 Jinja2의 표준 가젯 체인으로 기술된 cycler.__init__.__globals__.os 경로를 이용해 DataGerry 웹 프로세스 사용자 권한으로 임의의 운영체제 명령을 실행할 수 있으며, 원격 코드 실행(RCE)에 이릅니다. 이 실행 권한이 기본 Docker 배포에서는 root로 확인되었습니다.

VulnCheck advisory는 이 취약점에 대해 CWE-1336(템플릿 엔진에 사용되는 특수 요소의 부적절한 무해화)과 CWE-79(Cross-site Scripting)을 제시하고, 평점 8.7과 CVSS 4.0 벡터 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N을 안내합니다. 벡터상 요구 권한은 Low, 사용자 상호작용은 None으로 표기됩니다.

영향 범위

영향 대상은 DataGerry 3.3.0 미만 버전입니다. 여기에 악용의 사전 조건이 두 겹으로 붙습니다. 첫째, 공격에 사용할 계정으로 인증되어 있어야 합니다. 둘째, 그 계정이 base.docapi.template.add 권한을 보유하고 있어야 합니다. 이 두 조건은 환경마다 노출 정도를 다르게 만듭니다.

템플릿 추가 권한을 소수의 관리자 계정에 한정해 관리하는 환경에서는 이 경로에 도달할 수 있는 주체 자체가 제한됩니다. 반대로 여러 부서 계정이나 공용·서비스 계정이 같은 권한을 들고 있는 환경에서는, 이미 낮은 수준의 접근 권한을 확보한 공격자가 별도의 고난도 기술 없이 코드 실행 지점까지 도달할 가능성이 열립니다. CVSS 4.0 벡터가 요구 권한을 Low로 두는 것은 이 취약점이 높은 권한을 전제로 하지 않는다는 표시로 읽을 수 있습니다.

배포 구성도 조건에 따라 점검해야 합니다. 근거는 명령 실행이 DataGerry 웹 프로세스 사용자 권한으로 이루어진다고 명시하고, 기본 Docker 배포에서 그 사용자가 root임을 확인합니다. 따라서 기본 Docker 배포를 그대로 운영 중이라면 확인되는 영향은 웹 프로세스의 root 권한으로 임의 명령이 실행된다는 점입니다. root 권한이 컨테이너 경계 너머로 어디까지 확장되는지, root로 실행되지 않는 구성에서 어떻게 달라지는지에 대한 추가 근거는 현재 자료에 제시되지 않았습니다.

기술적 분석

공격 경로는 저장과 렌더링의 두 단계로 정리됩니다.

저장 단계: base.docapi.template.add 권한을 가진 인증 사용자가 POST /rest/docapi/template 요청의 template_data 필드에 임의의 Jinja2 코드를 저장합니다.
렌더링 단계: 사용자가 GET /rest/docapi/template/<id>/render/<object_id>를 호출하면, 저장된 내용이 샌드박스가 적용되지 않은 Jinja2 환경에서 렌더링됩니다.
실행 단계: 렌더링 중 Jinja2의 표준 가젯 체인으로 제시된 cycler.__init__.__globals__.os 경로를 통해 DataGerry 웹 프로세스 사용자 권한으로 임의의 운영체제 명령이 실행됩니다.

이 경로의 성립 조건은 렌더링 환경에 샌드박스 격리가 없다는 점입니다. CVE 상세는 저장된 페이로드가 non-sandboxed Jinja2 환경에서 렌더링된다고 명시하며, 같은 조건에서 위 가젯 체인을 통한 명령 실행을 기술합니다.

실행 시점은 렌더링입니다. 저장은 페이로드를 서버에 축적하는 단계이고, 코드가 실제로 평가되는 것은 렌더링 엔드포인트가 호출될 때입니다. CVE 상세는 이 시점을 렌더링 엔드포인트를 호출하는 사용자 행동으로 규정합니다. 저장과 실행이 한 시점에 끝나지 않는 이 구조 때문에, 대응 시 점검 대상도 템플릿을 저장하는 경로와 렌더링을 호출하는 경로, 그리고 그 사이에 저장된 template_data 내용으로 자연스럽게 나뉩니다.

현재 확인되지 않은 사항

실제 환경에서의 악용 사례, 공개 PoC의 존재 여부, CISA KEV 등재 여부는 전달된 근거에서 확인되지 않았습니다. DataGerry 3.3.0 릴리스가 존재한다는 사실은 확인되지만, 그 릴리스 노트에서 이 SSTI에 대한 구체적 수정 항목을 뒷받침하는 자료는 함께 제시되지 않았습니다. 따라서 이미 악용되었다는 전제의 조치가 아니라, 공격 경로가 문서로 명시된 취약점으로서의 조치로 우선순위를 잡는 것이 정확합니다.

대응 방안

정리하면 이 취약점의 실질은 권한 확인과 배포 확인입니다. 악용 상황이 확인된 취약점은 아니지만, 요구 조건이 충족된 환경에서는 원격 코드 실행에 이르는 절차가 근거에 명시되어 있습니다.

가장 우선순위가 높은 조치는 DataGerry를 3.3.0 이상으로 업그레이드하는 것입니다. 영향 범위가 3.3.0 미만으로 명시되어 있고 3.3.0 릴리스가 확인되기 때문입니다. 다만 해당 릴리스의 구체적 수정 항목이 별도 자료로 확인되지 않았다는 한계가 남아 있으므로, 업그레이드 이후에도 아래 권한·저장 상태 점검을 병행해 실제 노출이 줄었는지 확인하는 편이 안전합니다.

다음은 권한 점검입니다. 공격 경로가 인증된 계정과 base.docapi.template.add 권한을 요구하므로, 이 권한이 부여된 계정이 무엇이고 실제로 템플릿 추가가 필요한 계정인지 대조하는 것이 도달 가능한 공격 주체를 줄이는 방향이 됩니다.

그다음은 저장 상태 확인입니다. 실행이 렌더링 시점에 일어나므로, 이미 저장된 템플릿의 template_data 필드 내용과 POST /rest/docapi/template, GET /rest/docapi/template/<id>/render/<object_id> 두 경로로 들어온 요청 이력을 점검 대상으로 삼습니다. 어떤 문자열이나 신호를 악성으로 판정할지에 대한 기준은 현재 자료에 없으므로, 추측성 탐지 규칙보다 저장된 템플릿 자체와 관련 호출 이력의 검토에 먼저 우선순위를 두어야 합니다.

마지막으로 배포 구성 확인입니다. 기본 Docker 배포에서 DataGerry 웹 프로세스가 root로 실행된다는 점이 확인되었으므로, 자신의 배포가 그 기본 구성에 해당하는지, 웹 프로세스가 어떤 사용자 권한으로 실행 중인지를 대조해 확인합니다. 이 범위 밖의 배포 하드닝이나 기능 접근 차단, 권한 관리 절차에 대한 지침은 현재 자료에 포함되어 있지 않습니다.

참고자료

함께 읽으면 좋은 글

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

CVE-2026-57853: DataGerry 서버 측 템플릿 인젝션 취약점 점검

개요

영향 범위

기술적 분석

현재 확인되지 않은 사항

대응 방안

참고자료

함께 읽으면 좋은 글

댓글 (0)

IT 도구 서랍

CVE-2026-57853: DataGerry 서버 측 템플릿 인젝션 취약점 점검

개요

영향 범위

기술적 분석

현재 확인되지 않은 사항

대응 방안

참고자료

함께 읽으면 좋은 글

인사이트를 이메일로 받아보세요

약관

댓글 (0)

IT 도구 서랍