flawopen.com/Teardowns/cve-2026-61500-rejetto-hfs-predictable-session-key
CVE-2026-61500: Rejetto HFS의 예측 가능한 세션 서명 키
Rejetto HFS 3.0.0–3.2.0은 세션 서명과 로그인에 Math.random() 기반 값을 사용했습니다. Horizon3에 따르면 값이 노출되어 세션 위조가 가능했습니다. VulnCheck는 10월 1일부터 악용 활동을 관찰했다고 밝혔습니다. 3.2.1 이상으로 업그레이드하세요. 특정 피해자의 침해는 확인되지 않았습니다.[1], [4], [5]
쿠키 서명은 관리자 출입증의 밀랍 봉인과 같습니다. HFS는 예측 가능한 숫자열로 봉인의 비밀을 만들었고, 로그인 과정에서 같은 숫자열의 다른 값도 드러났습니다. 비밀을 알아내면 봉인을 위조할 수 있습니다. 패치는 Node.js의 암호학적 난수를 사용합니다.[1], [3]
핵심 개념 및 용어
PRNG 상태- 다음 의사 난수 출력을 결정하는 내부 상태입니다. 같은 생성기를 비밀과 관찰 가능한 값에 함께 쓰면 둘 사이의 관계가 노출될 수 있습니다.[4]
발견 배경- Horizon3는 Mythos 지원 멀티에이전트 연구 시스템이 이 HFS 취약점 체인을 찾아 검증했다고 설명합니다. 이는 연구자들이 취약점을 발견한 경위이며, Mythos의 취약점이나 실제 HFS 배포를 AI가 자율 공격했다는 증거가 아닙니다.[4]
프레임워크 매핑
- 이 가이드에서 설명하는 약점의 CWE 참조: CWE-338
근본 원인 분석 (Root Cause)
CVE 기록은 HFS 3.0.0~3.2.0을 영향 버전으로 지정하고 CWE-338로 분류합니다. 업스트림 커밋 59472e5에서 취약한 코드는 Koa에 [randomId(30)]을 전달했고, randomId()는 Math.random()을 사용했습니다. 수정은 이를 node:crypto에서 가져온 [randomBytes(32).toString('base64url')]로 바꿉니다. 같은 커밋은 공개 로그인 핸드셰이크 식별자도 Math.random()에서 randomUUID()로 변경했습니다. Horizon3는 인증 없이 접근 가능한 로그인 응답에서 관련 출력이 충분히 노출되어 V8 PRNG 상태와 쿠키 서명 키를 추론할 수 있었다고 보고합니다. 위조된 관리자 세션은 HFS의 내장 관리 기능을 거쳐 서버 코드 실행으로 이어질 수 있었습니다. 이 문서는 체인을 높은 수준으로만 설명하며 복구 도구, 요청, 페이로드는 제공하지 않습니다. VulnCheck에 따르면 Canary Intelligence는 2026년 10월 1일부터 취약점 악용 활동을 관찰했으며, 10월 2일 보고서에 이를 공개했습니다. 이 텔레메트리는 침해된 특정 HFS 인스턴스를 밝히지 않습니다.[1], [3], [4], [5]
단계별 공격 실행 흐름
취약점이 세션 신뢰 경계를 넘음
Horizon3에 따르면 출력으로 PRNG 상태를 복구해 세션 서명을 위조하고 관리자 권한을 얻을 수 있었습니다. 구체적인 복구 절차는 생략했습니다.[4]
소스 코드 비교: 취약한 구현 vs 보안 패치
이 코드 조각은 실제 업스트림 커밋을 반영합니다. randomBytes(32)는 Node.js 암호화 모듈에서 256비트 키 재료를 제공하고, randomUUID()는 공개 로그인 식별자의 생성원을 바꿉니다. 세션 인증에 쓰는 비밀은 암호학적 난수원에서 만들고 애플리케이션 PRNG의 관찰 가능한 출력과 분리해야 합니다. HFS 3.2.1 이상 지원 버전으로 업데이트하세요. 이 조각은 수정 사항을 설명하며 단독 패치가 아닙니다. 이는 자동 생성되는 기본 대체값만 보호합니다. COOKIE_SIGN_KEYS를 설정했다면 제공한 각 키도 별도로 암호학적 난수로 생성하고 비밀로 관리하며 노출 시 교체해야 합니다.[3], [1]
소스 코드 발췌: src/index.ts (쿠키 서명 키) 및 src/api.auth.ts (로그인 핸드셰이크 ID, 업스트림 커밋 59472e5)
import { httpStream, randomId } from './misc'
const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
|| [randomId(30)]
export const app = new Koa({ keys })
const sid = Math.random()
import { randomBytes, randomUUID } from 'node:crypto'
const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
|| [randomBytes(32).toString('base64url')]
export const app = new Koa({ keys })
const sid = randomUUID()
엔지니어링 및 시스템 보안 강화 체크리스트
- ✓HFS 3.0.0~3.2.0을 3.2.1 이상으로 업데이트하고, 지원되는 최신 안정 버전을 우선 사용하세요.[2], [1]
- ✓Windows 호스트, 컨테이너, 테스트 서버, 인터넷에 노출된 파일 공유를 포함한 모든 HFS 인스턴스와 버전/노출 상태를 파악하세요.[4]
- ✓즉시 업데이트할 수 없다면 업데이트를 준비하는 동안 신뢰할 수 있는 네트워크로 접근을 제한하고 공용 접근을 차단하세요. 이는 노출을 줄일 뿐 약한 키 생성을 고치지는 않습니다.[4]
- ✓취약한 상태에서 인터넷에 공개되어 있던 인스턴스를 업데이트한 뒤 기존 세션을 모두 무효화하고 설정된
COOKIE_SIGN_KEYS를 교체하세요. 조사 결과 무단 관리자 활동이 확인되면 관리자 인증 정보도 교체하세요. 검토를 위해 로그를 보존하세요.[1], [4] - ✓관찰된 탐색은 조사 사유이지 침해 증거가 아닙니다. 로그를 보존하고 무단 설정 변경이나 코드 실행 흔적을 확인하세요.[5], [4]
- ✓Node.js 애플리케이션에서 설정된
COOKIE_SIGN_KEYS의 각 값이 별도로 암호학적 난수로 생성되고 비밀로 관리되며 노출 시 교체되는지 확인하세요. 안전한 기본 대체값은 재정의된 값을 검증하지 않습니다. 다른 비밀에는randomBytes()같은node:cryptoAPI를 사용하세요. 서명 키, 재설정 토큰, 권한 값을Math.random()에서 만들지 마세요.[3], [6]