[8월 24일 보안브리핑] justhtml·StackGres·Tenda

8월 24일 브리핑의 세 이슈는 모두 새 CVE 기록으로 공개됐지만, 위험이 나타나는 위치는 서로 다릅니다. justhtml은 애플리케이션이 비신뢰 HTML과 Markdown을 변환하는 코드 경로가 관건이고, StackGres는 다중 테넌트 PostgreSQL 운영 환경에서 데이터베이스 소유자와 메트릭 수집 구성 사이의 권한 경계가 핵심입니다. Tenda CH22는 무선 장비의 웹 관리면에 접근할 수 있는지가 첫 번째 판단 기준입니다. 같은 점수나 ‘원격’이라는 표현만 보고 우선순위를 정하기보다 실제 배포 형태와 입력 경로를 먼저 대조해야 합니다.

오늘의 공통 점검 기준은 제품 보유 여부가 아니라 비신뢰 입력, 테넌트 권한, 관리면 노출이 실제 환경에서 만나는 지점입니다.

이번 justhtml 항목은 보안 권고 자체의 최초 공개와 CVE 식별자 배정 시점이 다르다는 점도 함께 봐야 합니다. 프로젝트는 각 문제와 수정 버전을 앞서 공개했고, 8월 23일 CVE 기록이 새로 등록되면서 자산관리·취약점 스캐너·SBOM에서 추적할 공통 식별자가 생겼습니다. 새 식별자가 곧 새로운 공격 발생을 뜻하는 것은 아니지만, 과거 권고를 놓친 조직에는 다시 점검할 명확한 계기가 됩니다. StackGres와 Tenda 항목은 공개된 CVE 기록과 기술 참조를 기준으로 배포 조건을 대조했습니다.

justhtml 신규 CVE 묶음

Python 패키지 justhtml에는 기존 GitHub 보안 권고와 연결되는 CVE가 새로 배정됐습니다. 대표적으로 CVE-2026-8445는 파싱한 문서를 Markdown으로 바꿀 때 텍스트 노드의 꺾쇠 문자를 충분히 이스케이프하지 않아, HTML로 출력할 때는 텍스트였던 내용이 Markdown 렌더링 단계에서 원시 HTML로 다시 해석될 수 있은 문제입니다. 영향 범위는 1.11.0 이하이며 1.12.0에서 수정됐습니다. 사용자 입력을 HTML로 정화한 뒤 Markdown으로 변환하고, 그 결과를 다시 HTML 렌더러에 전달하는 서비스라면 단순히 최초 정화 성공만으로 안전을 판단하기 어렵습니다.

CVE-2026-5388은 1.15.0 미만에서 URL 정화 보조 함수, HTML 직렬화, Markdown의 html_passthrough 옵션, 사용자 정의 정화 정책의 경계 사례를 묶어 다룹니다. 인코딩된 javascript 스킴, 브라우저가 외부 호스트로 해석할 수 있은 역슬래시 기반 URL, 마크업 경계를 깨는 프로그램 방식 요소·속성 이름, 원시 textarea 종료 시퀀스 같은 입력이 서로 다른 처리 단계에서 의미를 바꿀 수 있습니다. 프로젝트 권고는 1.15.0으로 올리고, 즉시 올리기 어려운 동안 비신뢰 콘텐츠에 html_passthrough를 사용하지 않으며 style·meta refresh·base 같은 요소를 보존하는 사용자 정책을 피하라고 안내합니다.

CVE-2026-7808은 1.15.0 이하의 고급 사용 경로를 중심으로 다룹니다. 프로그램 방식 DOM을 sanitize 또는 sanitize_dom에 넘길 때 대소문자가 섞인 script·style 노드가 누락될 수 있고, 재사용하거나 내부 상태를 변경한 정책 객체가 이후 정화를 약화할 수 있습니다. SVG나 MathML을 보존하는 사용자 정책에서는 애니메이션 요소와 외부 URL 참조가 살아남은 경우도 포함됩니다. 보통의 JustHTML(..., sanitize=True) 경로 전체가 같은 조건으로 영향을 받는다는 뜻은 아니며, 프로젝트는 1.16.0 업그레이드를 권고합니다.

같은 날 배정된 CVE-2026-77088과 CVE-2026-74793도 변환·재구성 경계에 놓여 있습니다. 전자는 Markdown 인라인 코드 구간의 빈 줄 처리로 정화된 내용이 다시 활성 마크업으로 해석될 수 있은 문제이며 1.22.0에서 수정됐습니다. 후자는 selectedcontent 투영 과정에서 SVG·MathML 이벤트 처리기가 재삽입될 수 있은 XSS 문제로 3.11.0에서 수정됐습니다. 한 버전만 보고 전체 위험이 해소됐다고 가정하지 말고, 프로젝트가 사용하는 justhtml 버전과 호출 API를 함께 확인해야 합니다.

• 의존성 목록과 잠금 파일에서 실제 배포된 justhtml 버전을 확인합니다.
• to_markdown, html_passthrough, programmatic DOM, 사용자 정의 SanitizationPolicy 사용 지점을 코드 검색으로 분리합니다.
• 정화 결과가 Markdown 또는 다른 HTML 파서를 거쳐 다시 렌더링되는 경로를 테스트 범위에 넣습니다.
• 업데이트 후 기존 정상 콘텐츠와 보안 회귀 테스트를 함께 실행해 변환 호환성을 확인합니다.

StackGres 테넌트 권한 상승 경로

CVE-2026-78155는 Kubernetes에서 PostgreSQL을 운영하는 StackGres의 권한 경계를 다룹니다. 공개된 StackGres 작업 항목은 데이터베이스를 소유한 낮은 권한의 테넌트가 metrics-exporter의 검색 경로와 슈퍼유저 dblink 연결을 악용해 관리 권한으로 이어질 수 있은 경로를 설명합니다. 데이터베이스 내부 권한이 컨테이너와 Pod의 명령 실행 경계로 확장될 수 있다는 점이 중요합니다. 보고서가 지목한 범위는 StackGres 1.x부터 1.18.8과 1.19 개발 스냅샷까지입니다.

이 문제는 인터넷에 공개된 관리 화면만 찾은 식의 자산 점검으로는 충분하지 않습니다. 먼저 StackGres가 조직 안에서 공유 PostgreSQL 플랫폼으로 쓰이는지, 서로 다른 팀이나 고객에게 데이터베이스 소유권을 주는지, 해당 클러스터에 metrics-exporter가 어떤 권한으로 연결되는지 확인해야 합니다. 단일 신뢰 팀이 운영하는 전용 클러스터와 여러 테넌트가 데이터베이스 단위로 분리된 공유 클러스터는 우선순위가 다릅니다. 특히 테넌트가 데이터베이스 객체와 검색 경로를 변경할 수 있은 환경이라면 공개 작업 항목의 전제와 가까워집니다.

운영팀은 데이터베이스 계정의 이름만 확인하기보다 연결이 만들어지는 순서를 재구성하는 편이 좋습니다. 어떤 컨트롤러가 exporter 구성을 생성하는지, 연결 문자열이 어느 Secret에서 주입되는지, exporter 세션에 적용되는 기본 검색 경로가 무엇인지, 테넌트가 같은 스키마 이름의 객체를 만들 수 있는지를 차례로 확인하면 경계가 선명해집니다. 이 과정은 실제 명령을 실행하는 시험 없이도 구성과 권한 메타데이터를 읽은 방식으로 진행할 수 있습니다.

대응은 데이터베이스 권한만 좁히는 한 단계로 끝내지 않은 편이 좋습니다. 테넌트별 데이터베이스 소유권과 확장 기능 사용 권한을 목록화하고, metrics-exporter가 사용하는 계정·검색 경로·연결 대상과 Pod 보안 컨텍스트를 함께 검토해야 합니다. Kubernetes에서는 해당 네임스페이스의 서비스 계정 권한, 컨테이너 실행 사용자, 쓰기 가능한 파일시스템, 네트워크 정책도 권한 상승 뒤의 영향을 결정합니다. 공유 환경은 신뢰 경계가 명확해질 때까지 신규 테넌트 권한 부여와 고권한 연결 사용을 보수적으로 운영하는 것이 안전합니다.

• StackGres 버전과 metrics-exporter 활성 여부를 자산 기준으로 묶어 확인합니다.
• 데이터베이스 소유자 권한을 가진 테넌트와 공유 클러스터를 우선 검토합니다.
• Exporter 연결 계정의 검색 경로와 dblink 사용 권한을 점검합니다.
• Pod 보안 컨텍스트·서비스 계정·네트워크 정책으로 후속 영향 범위를 줄입니다.

Tenda CH22 웹 관리면 명령 삽입

CVE-2026-78063은 Tenda CH22 1.0.0.1의 웹 관리 기능에서 파일 이름 입력을 처리하는 formeditFileName 함수와 /goform/editFileName 경로를 지목합니다. editNameMit 인수 조작이 명령 삽입으로 이어질 수 있고, 네트워크를 통해 시도할 수 있으며 공개된 재현 정보가 참조에 포함됐습니다. 장비가 무선 구간을 연결하는 역할을 하더라도 취약 지점은 무선 암호화 자체가 아니라 관리용 HTTP 요청과 장비 운영체제 명령의 경계입니다.

첫 점검은 CH22 모델과 1.0.0.1 펌웨어 사용 여부를 확인하는 것입니다. 그다음 웹 관리 포트가 인터넷, 사내 사용자 VLAN, 게스트 무선망처럼 신뢰 수준이 낮은 네트워크에서 접근 가능한지 살펴봐야 합니다. 관리 페이지가 기본 LAN에 그대로 열려 있으면 공격 표면이 넓어집니다. 반대로 별도 관리 VLAN, 방화벽 허용 목록, VPN 기반 운영 경로로 제한돼 있다면 접근 조건을 줄일 수 있습니다. 장비 검색 결과만으로 취약하다고 단정하지 말고 모델·펌웨어·관리 경로를 한 묶음으로 기록하는 것이 중요합니다.

현장 장비는 자산대장에 모델명이 축약되거나 OEM 표기로 남은 경우가 있으므로, 웹 관리 화면의 모델 정보와 장비 라벨, 구성 백업 파일을 교차 확인하는 것이 좋습니다. 같은 무선 구간에 여러 브리지 장비가 설치돼 있다면 중앙 관리 도구의 장비 목록과 스위치 MAC 주소 테이블을 연결해 누락을 줄일 수 있습니다. 점검 중에는 설정 변경이나 재부팅을 먼저 수행하지 말고, 읽기 전용 정보와 접근 제어 상태를 기록한 뒤 유지보수 창을 정해야 서비스 중단 위험을 줄일 수 있습니다.

공급사 조치가 적용되기 전 운영 측 완화는 관리면 격리에 초점을 맞춰야 합니다. WAN과 일반 사용자망에서 웹 관리 접근을 차단하고, 필요한 관리자 주소와 점프 호스트만 허용하며, 관리 계정 비밀번호를 고유하게 바꿉니다. 리버스 프록시나 중앙 방화벽 로그에서 /goform/editFileName 요청과 비정상적으로 긴 파일 이름 인수를 탐색하면 노출 점검에 도움이 됩니다. 장비 구성 백업을 확보하고 재부팅·초기화 절차를 확인해 두면 장애 대응 시간을 줄일 수 있습니다.

• Tenda CH22 모델과 1.0.0.1 펌웨어를 자산 목록에서 식별합니다.
• 인터넷·게스트망·일반 사용자망에서 웹 관리 포트 접근을 차단합니다.
• 관리 VLAN과 허용 목록을 적용하고 고유한 관리자 자격증명을 사용합니다.
• 웹 요청 로그와 구성 변경 기록에서 관련 경로와 비정상 입력을 확인합니다.

오늘의 우선순위

세 이슈의 조치 순서는 자산 노출과 데이터 흐름으로 정하면 됩니다. 외부 입력을 Markdown으로 재출력하는 서비스는 justhtml 호출 경로와 버전을 먼저 확인하고, 여러 팀이 공유하는 StackGres는 테넌트 DB 소유권과 exporter 권한 조합을 우선 검토합니다. Tenda CH22는 웹 관리면이 넓은 네트워크에 노출된 장비부터 격리해야 합니다. 이 세 가지를 동일한 ‘패치 목록’으로 취급하기보다 애플리케이션 변환 경계, 클라우드 데이터베이스 권한 경계, 네트워크 장비 관리 경계로 나눠 담당자를 지정하면 점검 누락을 줄일 수 있습니다.