LoopX의 serve-status 구성요소가 모든 응답에 Access-Control-Allow-Origin: * 헤더를 보내면서, 외부 웹 페이지가 제어면 상태와 비공개 Markdown 파일을 읽을 수 있는 조건이 공개되었습니다. GitHub Advisory Database의 자문서 GHSA-vx2m-gpq4-8j5q가 이를 다루고 있습니다. 이 글은 취약 구조가 어떤 원리로 동작하고, 현재 운영 환경의 점검 범위·우선순위·대응 순서에 어떤 의미를 주는지 확인합니다.
개요
serve-status는 인증되지 않은 JSON 응답을 포함한 모든 응답에 Access-Control-Allow-Origin: *(ACAO: *) 헤더를 함께 반환해 왔습니다. 와일드카드 CORS가 존재한다는 사실만으로 침해가 확정되는 것은 아니지만, 브라우저를 매개로 한 교차 출처 데이터 유출 경로가 개념 증명 수준에서 확인된 상태입니다. 자문서 GHSA-vx2m-gpq4-8j5q는 이 취약 조건을 CVE-2026-108372로 등록해 공개했습니다.
영향 범위
- pip 패키지
loopx중0.0.1이상0.4.5미만 버전 - 인증 없이 노출되는 serve-status 엔드포인트와 제어면 상태(status.json)·비공개 Markdown을 반환하는 경로
- 기본 포트 8765/8766에서 serve-status를 실행 중인 배포
- 브라우저로 LoopX에 접근할 수 있는 사용자가 있는 운영 환경
노출은 내부 사용자가 공격자가 제어하는 웹 페이지에 방문할 때 발생합니다. 즉, 악성 페이지 방문이라는 사용자 상호작용이 필요한 교차 출처 읽기 조건이며, 자문서에 포함된 재현 사례가 바로 이 조건이 실제로 재현됨을 보여 줍니다.
다만 자문서와 재현 사례만으로는 비공개 Markdown의 정확한 파일 경로와 민감도 수준을 확인할 수 없습니다. 피해 범위는 조직별로 직접 확인이 필요합니다.
기술적 분석
근본 원인은 출처 검증 없이 발급되는 와일드카드 CORS 헤더입니다. serve-status가 인증되지 않은 JSON 응답을 포함한 모든 응답에 Access-Control-Allow-Origin: *를 반환하기 때문에, 공격자가 제어하는 웹 페이지에 접속한 사용자의 브라우저가 LoopX 제어면에 교차 출처 요청을 보내도 브라우저의 동일출처 정책(Same-Origin Policy)이 완화되어 응답 본문을 그대로 읽을 수 있습니다.
자문서에 포함된 재현 사례는 다음과 같습니다.
GET /status.json Origin: https://evil.example
-> 200 ACAO: '*'
악의적 출처(https://evil.example)에서 /status.json을 요청했을 때 200 응답과 함께 ACAO: '*'가 반환되는 형태입니다.
기본 포트가 8765와 8766 두 가지로 고정되어 있다는 점도 공격 난이도를 낮춥니다. 공격자 페이지는 두 포트를 모두 시도하면 되므로, 서비스 탐색(discovery) 단계가 필요하지 않습니다.
자문서가 제시한 CVSS v4 벡터는 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N입니다. 이는 네트워크 경로(AV:N), 낮은 복잡도(AC:L), 권한 불필요(PR:N), 그러나 사용자 상호작용이 필요(UI:P), 그리고 기밀성에 높은 영향(VC:H)인 조합으로 평가한 것입니다.
공개 PoC·익스플로잇 분석
자문서에서 교차 출처 읽기 PoC가 개념 증명 수준으로 재현 가능함을 확인했습니다. 이는 위에서 본 /status.json 요청 재현 사례에 해당합니다.
실제 악용 사례(in-the-wild exploitation)는 조사 범위에서 발견되지 않았습니다. CISA KEV 등재 상태는 제공된 근거로 확인되지 않습니다. 따라서 이 취약점은 "실제 공격이 확인된 것"이 아니라 "재현 가능한 취약 조건이 확인된 것"으로 평가해야 합니다.
대응 방안
업그레이드라는 근본 대응
- 실행 중인 LoopX 버전을 확인하고,
0.0.1이상0.4.5미만이면 0.4.5로 업그레이드하는 계획을 수립합니다. - LoopX v0.4.5 릴리스 노트에 따르면, 이 버전부터 serve-status는 외부 출처에
Access-Control-Allow-Origin: *를 더 이상 전송하지 않고 reward/configure-goal 라우트는 안전하지 않은 goal id를 거부합니다.
이 취약점의 조건에는 악성 페이지 방문이라는 사용자 상호작용이 필요합니다(CVSS v4 벡터의 UI:P). 따라서 노출 경로를 근본적으로 없애는 대응은 serve-status의 와일드카드 CORS 동작을 제거하는 0.4.5 업그레이드입니다.
한계 및 확인 필요 사항
- 자문서와 재현 사례는 개념 증명 수준이며, 실제 악용 사례는 조사 범위에서 발견되지 않았습니다. CISA KEV 등재 상태는 제공된 근거로 확인되지 않습니다.
- 비공개 Markdown의 어떤 민감도 내용과 어떤 파일 경로가 노출되는지는 제공된 근거로 확인할 수 없으며, 조직별로 확인이 필요합니다.
- 조직 내 LoopX 사용 여부와 serve-status 노출 형태는 각 환경별 확인이 필요합니다. 일반적인 판단으로 적용할 수는 없습니다.
참고자료
- LoopX serve-status permissive CORS policy exposes control-plane state and private Markdown files · CVE-2026-108372
- GHSA-vx2m-gpq4-8j5q affected version range (pip: loopx)
- LoopX v0.4.5 release notes (serve-status CORS fix)
- PR #3137: stop sending ACAO * on unauthenticated read responses
함께 읽으면 좋은 글
- aiohttp 부분 헤더로 첫 요청 마감 시점 연장 문제(CVE-2026-111064): 3.14.4 수정과 공개 HTTP 서비스 점검
- Mercury /api/terminals 인증 우회 원격 코드 실행: 노출 서비스와 패치 범위 점검
- ProjectSend 권한 검증 결함 점검 — 제한된 API 토큰의 완전한 대화형 계정 승격
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!