[8월 25일 보안브리핑] OneUptime·fast-uri·Micrometer

2026년 8월 24일 새로 공개되거나 CVE 레코드가 등록된 세 가지 소프트웨어 보안 이슈를 다룹니다. 이번 브리핑의 공통점은 단순히 ‘버전이 낮으면 위험하다’는 데 있지 않습니다. 인증된 화면과 공개 화면이 같은 출처를 공유하는지, URL을 검사한 결과와 실제 접속 목적지가 일치하는지, 실패한 비동기 요청의 추적 상태가 끝까지 정리되는지가 각각 보안 경계를 결정합니다. 따라서 설치 여부만 확인한 뒤 끝내기보다 해당 기능을 실제로 쓰는지와 데이터 흐름이 어디를 통과하는지를 함께 살펴보셔야 합니다.

우선순위는 노출 조건에 따라 달라집니다. 인터넷에서 접근할 수 있은 OneUptime 인스턴스는 공개 상태 페이지와 실시간 통신 경로를 먼저 확인하는 편이 좋습니다. 외부 입력이 URL 정규화·리디렉션 검사·서버 측 요청으로 이어지는 Node.js 서비스는 fast-uri 의존성과 호출 위치를 함께 점검해야 합니다. Micrometer와 Apache HttpAsyncClient를 결합한 Java 서비스는 응답이 오기 전 연결 실패가 반복될 수 있는지, 그 상황에서 힙 사용량이 계속 상승하는지를 운영 지표로 확인하시면 됩니다.

조사 범위와 선정 기준

조사 시간은 한국시간 8월 24일 오전 9시부터 8월 25일 오전 8시 59분까지로 고정했습니다. 공개·예약·비공개 기존 원고를 비교한 결과 OneUptime, fast-uri, Micrometer를 같은 검색 의도와 조치 목록으로 다룬 글은 없었습니다. 8월 24일 브리핑의 justhtml·StackGres·Tenda, 8월 23일 개별 CVE 글의 Fabrik·Mailgun·WS Form과도 제품·영향·운영 조치가 겹치지 않습니다.

OneUptime은 같은 제품에서 동시에 공개된 세 권고를 하나의 운영 경계 문제로 묶었습니다. fast-uri는 동일한 패치 버전으로 수렴하는 호스트 해석 취약점 두 건을 하나의 의존성 점검 항목으로 구성했습니다. Micrometer는 CVE 레코드가 조사창 안에서 공개된 점과 공식 Spring 권고가 구체적인 영향 조건·고정 버전·대체 계측 경로를 제시한다는 점을 근거로 채택했습니다. 세 항목 모두 공개된 공식 권고에서 확인할 수 있은 내용만 사용했습니다.

OneUptime 인증·상태 페이지 경계

OneUptime은 8월 24일 상태 페이지, 공개 실시간 엔드포인트, 알림 채널 검증과 관련한 권고를 공개했습니다. 가장 높은 심각도의 상태 페이지 문제는 테넌트가 넣은 사용자 정의 JavaScript와 원시 헤더·푸터 HTML이 대시보드·API·계정·관리자 화면과 같은 애플리케이션 출처에서 실행될 수 있다는 내용입니다. 인증 쿠키가 호스트 전체 경로에 적용되는 구조에서 로그인 사용자가 공격자가 만든 상태 페이지를 방문하면, 그 스크립트가 동일 출처 요청을 보내고 응답을 읽을 수 있습니다. 단순한 상태 페이지 꾸미기 권한이 다른 프로젝트의 데이터와 상태 변경으로 이어질 수 있은 경계 실패라는 설명입니다.

이 문제는 12.0.15 미만 버전에 영향을 주며 12.0.15 이상에서 수정됐습니다. 운영팀은 사용자 정의 스크립트 허용 여부만 볼 것이 아니라 공개 상태 페이지가 대시보드·API와 같은 호스트에서 제공되는지도 확인해야 합니다. 별도 사용자 정의 도메인을 쓰더라도 주 호스트의 대체 상태 페이지 경로가 남아 있으면 경계가 완전히 분리되지 않을 수 있습니다. 업데이트 전에는 상태 페이지 편집 권한을 최소화하고, 사용자 제어 HTML·JavaScript를 인증 애플리케이션과 분리된 출처에서 제공하는 구조가 우선입니다.

CVE-2026-69185와 연결된 두 번째 권고는 OneUptime의 기본 공개 실시간 경로가 취약한 socket.io-parser를 인증 전에 처리한다는 내용입니다. 특정 비정상 바이너리 이벤트 이후 후속 프레임이 메모리에 계속 보관되면 공유 App·API·실시간 서비스의 메모리가 소진돼 재시작이나 중단으로 이어질 수 있습니다. OneUptime 12.0.14 이상은 수정된 parser를 포함합니다. 공개 WebSocket 경로에 대한 연결·프레임 제한은 방어층을 보강하지만, 권고에서 제시한 업데이트를 대신하지는 않습니다.

세 번째 권고는 이메일·SMS·음성통화·WhatsApp 알림 채널 소유 확인에 사용되는 6자리 코드가 만료되지 않고, 실패 횟수·잠금·회전·경로별 속도 제한도 적용되지 않았던 문제입니다. 낮은 권한의 인증 사용자가 제3자의 연락처로 채널 행을 만든 뒤 작은 코드 공간을 반복 시도하면 소유 확인 상태를 잘못 만들 수 있습니다. 이 문제도 12.0.14 이상에서 수정됐습니다. 세 권고를 한 번에 해소하려면 최종적으로 12.0.15 이상을 기준으로 배포 이미지를 재구축하고, 실제 실행 중인 이미지 태그와 애플리케이션 내부 버전이 일치하는지 검증하는 편이 안전합니다.

• 인터넷 공개 인스턴스의 OneUptime 버전과 실행 중인 이미지 태그 확인
• 상태 페이지 대체 경로가 대시보드·API와 동일 출처인지 점검
• 사용자 정의 JavaScript·헤더·푸터 HTML 편집 권한 최소화
• 공개 /realtime WebSocket 경로의 인증 전 처리와 연결 제한 검토
• 12.0.15 이상 적용 후 상태 페이지·알림 채널·실시간 통신 회귀 시험

fast-uri 호스트 해석 취약점 2건

Node.js의 URI 파서 fast-uri에서는 CVE-2026-75899와 CVE-2026-75931이 8월 24일 CVE 레코드로 공개됐습니다. 두 문제는 입력 문자열을 검사할 때 보았던 호스트와 정규화·해결 이후 실제로 사용되는 호스트가 달라질 수 있다는 공통점을 가집니다. URL을 단순 표시용으로만 처리하는 애플리케이션보다, 사용자가 제공한 URL을 서버가 직접 요청하거나 리디렉션 허용 목록·호스트 정책·오리진 검사의 근거로 쓰는 애플리케이션에서 우선순위가 높습니다.

CVE-2026-75899는 호스트의 퍼센트 이스케이프가 파싱 중 한 번, authority 재구성 중 다시 한 번 디코딩될 수 있은 이중 해석 문제입니다. 중첩 인코딩된 호스트가 한 번의 normalize 또는 resolve 처리 뒤 내부·루프백 목적지를 나타내는 값으로 바뀌면, 원래 입력을 기준으로 통과시킨 정책과 실제 요청 목적지가 어긋날 수 있습니다. 공개 권고는 이를 서버 측 요청 위조와 호스트 정책 우회의 기반으로 설명합니다. 영향 버전은 2.4.1 이상 2.4.5 미만, 3.1.2 이상 3.1.6 미만, 4.0.0 이상 4.1.3 미만입니다.

CVE-2026-75931은 스킴이 명시된 URI에서는 호스트를 ASCII 형식으로 정규화하지만, //host/처럼 스킴 상대 참조를 resolve할 때는 유효 스킴을 알고도 호스트를 같은 방식으로 정규화하지 않았던 문제입니다. 그 결과 parse·resolve·normalize·equal 같은 진입점이 같은 호스트를 서로 다르게 해석할 수 있습니다. 정책 검사는 한 표현을 보고 통과시켰지만 후속 파싱과 요청은 다른 호스트를 향하는 상황이 생길 수 있으므로, IDN을 포함한 외부 입력을 허용 목록 검사와 결합하는 코드 경로를 우선 찾아야 합니다.

두 취약점의 고정 버전은 모두 2.4.5, 3.1.6, 4.1.3으로 수렴합니다. package-lock.json, pnpm-lock.yaml, yarn.lock 등 실제 잠금 파일에서 직접 의존성과 전이 의존성을 함께 확인하시고, 애플리케이션이 실행하는 번들이 고정 버전을 포함하는지 빌드 산출물에서도 재검증하는 것이 좋습니다. 업데이트 뒤에는 같은 입력이 정책 검사·정규화·resolve·실제 요청 직전 단계에서 동일한 정규화 호스트로 유지되는지 회귀 시험을 추가해야 합니다. 임시로는 외부 입력 URL을 해석한 뒤 최종 목적지를 다시 검증하고, 내부·루프백·링크 로컬 주소 접근을 네트워크 계층에서도 제한하는 방식이 방어층을 보강합니다.

• fast-uri 직접·전이 의존성 버전과 실제 잠금 파일 확인
• 사용자 입력 URL이 서버 측 요청·리디렉션·Webhook으로 이어지는 경로 식별
• 정책 검사 전후의 정규화 호스트가 같은지 테스트
• 2.4.5·3.1.6·4.1.3 이상으로 해당 메이저·마이너 계열 업데이트
• 내부·루프백·링크 로컬 목적지에 대한 네트워크 송신 정책 재확인

Micrometer 비동기 요청 메모리 누수

CVE-2026-59295는 Micrometer로 계측한 Apache HttpAsyncClient에서 응답을 받기 전에 비동기 요청이 실패할 때 추적 상태가 정리되지 않은 문제입니다. 연결 재설정, 연결 시간 초과, 소켓 오류처럼 응답 메시지가 오기 전 발생하는 실패가 반복되면 요청별 상태가 JVM 힙에 계속 남습니다. 장시간 누적되면 OutOfMemoryError와 애플리케이션 중단으로 이어질 수 있습니다. 모든 Micrometer 사용자가 같은 조건에 놓이는 것은 아니며, MicrometerHttpClientInterceptor로 Apache HttpAsyncClient 4.x 또는 5.x를 계측하는 구성이 핵심입니다.

공식 Spring 권고는 영향 버전으로 1.17.0, 1.16.0~1.16.6, 1.15.0~1.15.12, 1.14.0~1.14.16, 1.9.18 이하를 제시합니다. 공개 OSS 고정 버전은 1.17.1과 1.16.7이며, 1.15.13·1.14.17·1.9.19와 일부 세부 릴리스는 엔터프라이즈 지원 채널로 안내됩니다. 따라서 단순히 ‘최신 Micrometer’라고 기록하기보다 현재 사용 중인 지원 계열과 공급 경로를 먼저 확인한 뒤 공식 표에 맞은 고정 버전을 선택해야 합니다.

Apache HTTP Client 5.6 이상을 사용하는 환경은 Micrometer의 기존 interceptor 대신 httpclient5-observation 모듈을 사용할 수 있고, HTTP Client 5.x와 Micrometer 1.12 이상 조합에서는 terminal outcome을 정리하도록 설계된 ObservationExecChainHandler로 이동하는 경로도 공식 권고에 제시돼 있습니다. 이 전환은 계측 이름·태그·대시보드 쿼리에 영향을 줄 수 있으므로 운영 모니터링 회귀 시험과 함께 진행해야 합니다. 라이브러리 교체 뒤 요청 성공률만 볼 것이 아니라 연결 실패 시 힙 사용량, GC 이후 잔존 객체, 요청 추적 메트릭이 안정화되는지도 확인하셔야 합니다.

즉시 업데이트가 어려운 경우에는 신뢰할 수 없거나 불안정한 외부 엔드포인트로 나가는 요청을 식별하고, 연결·응답 시간 제한과 동시 요청 수를 보수적으로 조정해 누적 속도를 낮추는 방어층을 적용할 수 있습니다. 다만 문제의 원인은 실패한 요청 상태의 정리 누락이므로 트래픽 제한만으로 수정이 완료되지는 않습니다. 장애 대응에서는 재시작만 반복하기보다 힙 증가가 특정 외부 목적지의 사전 응답 실패와 함께 나타나는지 로그·메트릭·트레이스를 시간축으로 대조하는 편이 원인 분리에 도움이 됩니다.

• MicrometerHttpClientInterceptor와 Apache HttpAsyncClient 조합 사용 여부 확인
• 영향 계열별 공식 고정 버전과 지원 채널 확인
• 연결 reset·timeout 시 JVM 힙과 GC 후 잔존 상태 관찰
• 가능한 환경은 httpclient5-observation 또는 ObservationExecChainHandler 전환 검토
• 업데이트 뒤 실패 요청 부하에서 메모리 안정성과 관측 데이터 연속성 검증

운영팀 점검 순서

세 이슈를 같은 우선순위로 한꺼번에 처리하기보다 외부 노출과 기능 사용 여부를 기준으로 순서를 정하는 편이 효율적입니다. 첫째, 자산 목록에서 OneUptime, fast-uri, Micrometer의 실제 배포 버전을 확인합니다. 둘째, OneUptime 공개 경로, fast-uri를 통과하는 외부 URL, Micrometer가 계측하는 비동기 HTTP 요청처럼 취약 조건과 맞닿은 코드·통신 경로를 찾습니다. 셋째, 공식 고정 버전을 선택하고 스테이징에서 기능 회귀와 보안 경계 회귀를 함께 시험합니다. 넷째, 배포 뒤 실행 이미지·잠금 파일·애플리케이션 메트릭을 다시 확인해 계획한 수정이 실제 런타임에 반영됐는지 검증합니다.

1. 자산·SBOM·잠금 파일에서 세 제품과 정확한 버전 확인
2. 인터넷 노출·외부 입력·실패 요청 빈도로 실질 노출도 분류
3. OneUptime 12.0.15 이상, fast-uri 2.4.5·3.1.6·4.1.3 이상, Micrometer 계열별 고정 버전 준비
4. 상태 페이지 출처 분리·호스트 일치·실패 요청 메모리 안정성 회귀 시험
5. 운영 배포 후 버전·로그·메트릭을 재확인하고 변경 기록 보존

버전 확인은 시작점입니다. 실제 우선순위는 공개 경로, 외부 입력 URL, 응답 전 연결 실패가 각각 어떤 런타임 흐름에 연결되는지 확인할 때 정해집니다.