OneUptime 메모리 고갈(CVE-2026-69185)｜노출 범위와 대응

공개 실시간 경로가 제품 수준 위험으로 바뀌는 지점

CVE-2026-69185는 OneUptime의 공개 실시간 엔드포인트가 socket.io-parser의 메모리 고갈 문제를 인증 전에 노출하는 제품 수준 서비스 거부 취약점입니다. OneUptime 공식 권고는 12.0.14 미만을 영향 범위로, 12.0.14 이상을 수정 경계로 제시합니다. 문제의 중심은 단순히 취약한 전이 의존성이 잠금 파일에 있다는 사실이 아니라, 그 파서가 기본 공개 WebSocket 경로에서 사용자 인증보다 먼저 입력을 처리한다는 배치 구조입니다.

권고가 확인한 구성에서는 /realtime/socket 경로가 WebSocket 업그레이드를 받아들이고, 실시간 구성요소가 애플리케이션 시작 시 초기화되며, 연결 후 애플리케이션 이벤트 단계에서 사용자 권한을 확인합니다. 파서가 처리하는 프레임은 그보다 앞서 들어옵니다. 따라서 인증된 사용자만 기능을 쓴다는 애플리케이션 논리와 네트워크에서 파서가 실제로 노출되는 시점은 분리해서 봐야 합니다.

메모리가 해제되지 않은 흐름

OneUptime 12.0.9 잠금 파일은 socket.io-parser 4.2.6을 사용합니다. 해당 파서에서 첨부 개수가 0인 이진 이벤트가 들어오면 재구성 상태가 남을 수 있고, 이후 전달되는 이진 프레임이 계속 버퍼에 보관됩니다. 정상 흐름이라면 필요한 첨부 프레임을 모두 받은 뒤 재구성 상태를 정리해야 하지만, 0이라는 개수 때문에 완료 조건이 다시 충족되지 않은 예외 상태가 만들어집니다. 공격자는 계정·토큰·프로젝트 식별자 없이 공개 실시간 경로에 연결할 수 있으므로, 반복 입력은 공유 App/API/realtime 서비스의 메모리를 늘리고 결국 프로세스 재시작이나 중단으로 이어질 수 있습니다.

이 영향은 기밀성이나 데이터 변조가 아니라 가용성에 집중됩니다. 하지만 실시간 기능만 격리된 별도 프로세스가 아니라 공유 서비스로 묶여 있다면 모니터링 화면, API 처리, 알림·상태 갱신이 같은 장애 범위에 들어갈 수 있습니다. 운영 환경에서는 ‘WebSocket이 열려 있는가’보다 해당 경로가 어떤 프로세스와 메모리 한도를 공유하는지까지 확인해야 합니다.

영향 여부를 가르는 네 가지 조건

• 배포된 OneUptime 버전이 12.0.14 미만입니다.
• 실시간 기능과 /realtime 경로가 외부에서 접근 가능한 상태입니다.
• 배포 산출물의 socket.io-parser가 수정 전 계열로 잠겨 있습니다.
• 프록시·인그레스·서비스 계층에서 연결과 프레임 크기·속도 제한이 충분히 적용되지 않았습니다.

버전 표시만으로 끝내면 컨테이너 이미지 캐시나 잠금 파일 차가 때문에 실제 실행 의존성을 놓칠 수 있습니다. OneUptime 애플리케이션 버전, Common/package-lock.json의 해석 결과, 실행 이미지 안의 설치된 socket.io-parser 버전을 서로 대조해야 합니다. Helm이나 Compose 배포에서는 태그만 바꾸고 이미지 digest가 유지되는 상황도 함께 점검하는 편이 안전합니다.

업데이트와 방어 계층

공급사 조치의 우선순위는 OneUptime 12.0.14 이상으로 업데이트하는 것입니다. 권고는 socket.io-parser 4.2.7 이상을 잠그고 잠금 파일을 다시 만들며 App 이미지를 재빌드한 뒤, 첨부 개수가 0인 이진 패킷에 대한 회귀 시험을 수행하도록 안내합니다. 애플리케이션 코드만 바꾸고 기존 이미지나 node_modules 레이어를 재사용하면 수정된 의존성이 배포되지 않을 수 있으므로, 새 빌드의 의존성 트리와 이미지 digest를 남겨야 합니다.

인증 전 연결 차단과 인그레스의 연결·프레임 제한은 보조 방어입니다. 사전 인증을 적용하면 공개 파서 노출면을 줄일 수 있고, 연결 수·메시지 크기·전송 속도·연결 시간 제한은 한 클라이언트가 소비할 수 있은 자원을 제한합니다. 다만 이 설정만으로 취약한 파서 상태를 수정하는 것은 아니므로 업데이트를 대신하지 않습니다. 제한값은 정상 실시간 트래픽의 피크와 프록시·애플리케이션 양쪽의 적용 위치를 기준으로 조정해야 합니다.

배포 전 확인 순서

1. 외부 로드밸런서와 인그레스에서 /realtime 및 하위 WebSocket 경로의 공개 범위를 확인합니다.
2. 실행 중인 OneUptime 버전과 이미지 digest, 잠금 파일의 socket.io-parser 해석 버전을 기록합니다.
3. 12.0.14 이상으로 올린 새 이미지를 빌드하고 취약한 의존성 레이어가 남지 않았는지 확인합니다.
4. 스테이징에서 정상 실시간 연결, 재연결, 이진 이벤트, 연결 종료 시 메모리와 프로세스 상태를 관찰합니다.
5. 인증 전 연결 정책과 프레임·연결 제한을 적용하고 정상 알림·상태 갱신에 미치는 영향을 점검합니다.
6. 배포 후 App/API/realtime 프로세스의 RSS·힙·재시작 횟수·WebSocket 오류율에 별도 경보를 둡니다.

검증에서 놓치기 쉬운 부분

의존성 검사 도구가 socket.io-parser 취약점을 찾더라도 OneUptime 제품 수준 노출을 자동으로 판단하지는 못합니다. 반대로 애플리케이션이 로그인 기능을 갖췄다는 이유로 인증 전 프레임 파싱을 안전하다고 볼 수도 없습니다. 네트워크 경로, 파서 호출 순서, 의존성 버전, 프로세스 자원 경계를 한 장의 흐름으로 연결해야 우선순위가 분명해집니다.

업데이트 성공 기준은 패키지 버전 문자열이 바뀌는 것보다 넓습니다. 공개 경로가 필요한 범위로 제한되고, 수정된 파서가 실제 이미지에 들어가며, 비정상 연결이 이어져도 메모리가 지속적으로 증가하지 않고, 프로세스 재시작 없이 정상 트래픽을 처리해야 합니다. 롤백 시에도 수정 전 이미지를 다시 띄우지 않도록 이전 배포본의 위험을 변경 기록에 남기는 것이 좋습니다.

배포 구조별 추가 점검

Kubernetes 환경에서는 Ingress가 WebSocket 업그레이드를 허용하는 경로, Service가 연결하는 Pod 집합, Pod의 메모리 limit과 재시작 정책을 함께 봅니다. 한 Pod가 종료되더라도 같은 취약 입력이 다른 복제본으로 반복 전달되면 가용성 저하가 계속될 수 있습니다. 프록시의 연결 제한이 IP 단위인지 전체 경로 단위인지, 로드밸런서가 장시간 연결을 어떻게 분배하는지도 확인해야 합니다. Compose나 단일 호스트 배포에서는 App 컨테이너가 API·실시간 기능을 함께 맡는지와 컨테이너 재시작이 의존 서비스에 미치는 영향을 점검합니다.

관리형 클라우드 앞단에 WAF가 있어도 WebSocket 프레임 내부를 같은 방식으로 검사하거나 제한한다고 가정하면 안 됩니다. HTTP 요청 단계의 규칙, 업그레이드 이후 연결 제어, 애플리케이션의 parser 입력 제한은 서로 다른 계층입니다. 각 계층에서 실제 적용 가능한 통제를 문서화하고, 연결 수만 제한할지 프레임 크기와 속도까지 제한할지 결정해야 합니다.

장애 대응과 증거 보존

힙 사용량 급증과 실시간 서비스 재시작이 관찰되면 먼저 외부 연결 수와 프레임 처리량, 인그레스 로그, Pod·컨테이너 재시작 기록을 같은 시간축으로 맞춥니다. 서비스 복구를 위해 임시로 공개 실시간 경로를 제한할 때는 모니터링·상태 페이지·알림 기능에 미치는 영향을 명확히 알리고, 수정 버전 배포 뒤 정상 경로를 단계적으로 복원합니다. 입력 원문은 접근이 통제된 사고 기록에 필요한 범위만 보존하는 편이 안전합니다.

업데이트 전후 메모리 비교는 짧은 스냅샷 하나보다 일정한 정상 부하와 비정상 연결을 나눠 관찰해야 합니다. 정상 트래픽에서 힙이 상승했다가 GC 뒤 안정 범위로 돌아오는지, 비정상 연결 종료 뒤 retained buffer가 계속 남는지, 새 버전에서 같은 시험이 재현되지 않는지를 비교하면 수정 적용 여부를 더 분명하게 판단할 수 있습니다.

정보 확인 기준

2026년 8월 25일 14:00 KST 회차 기준으로 OneUptime 공식 GitHub 보안 권고를 확인했습니다. 영향 범위와 조치 기준은 제품 권고가 제시한 12.0.14 경계와 socket.io-parser 4.2.7 이상 조건을 따릅니다. 배포 판정에는 제품 버전, 잠금 파일, 실행 이미지, 공개 실시간 경로를 함께 대조합니다. 프록시 제한과 사전 인증은 업데이트 이후에도 보조 방어로 계속 유지합니다.