Oracle Identity Manager(OIM)는 고장 나기 전까지는 알아차리지 못하는 시스템입니다. ID를 프로비저닝하고, 자격을 관리하고, 액세스를 발급하거나 중개하며, 모든 중요한 엔터프라이즈 애플리케이션의 업스트림에 위치하는 경우가 많습니다. OIM에 취약점이 발견되면 "그냥 또 하나의 CVE"로 끝나는 경우는 거의 없습니다. CVE-2025-61757이 중요한 예입니다. 인증되지 않고 네트워크에 연결할 수 있는 RCE 의 REST 웹서비스 구성 요소에서 ID 계층을 완전히 장악할 수 있습니다. NVD에서 간단히 요약하면, 영향을 받는 지원 버전은 다음과 같습니다. 12.2.1.4.0 및 14.1.2.1.0악용하려면 다음이 필요합니다. 인증 없음이상 발생 HTTP및 수익률 영향력이 큰 타협 기밀성, 무결성 및 가용성 전반에서 CVSS 3.1 점수 9.8점(중요). (NVD)
이 CVE를 엔지니어급으로 깊이 있게 읽어볼 가치가 있는 이유는 점수뿐만 아니라 다음과 같은 점에서도 찾을 수 있습니다. 어디 살아 있습니다. ID 플랫폼은 현대 기업의 신뢰 기반입니다. OIM에서 코드를 실행하는 원격 공격자는 ID를 위조하거나 역할 할당을 변조하거나 인접 미들웨어 및 애플리케이션 계층으로 피벗하는 데 한 걸음 더 다가갈 수 있습니다. 다시 말해 CVE-2025-61757은 ID 탈취 프리미티브입니다.좁은 의미의 앱 버그가 아닙니다.
가장 많이 인용된 공개 분석: 이 체인이 작동하는 이유
공개된 글 중 Searchlight Cyber의 연구 게시물("Breaking Oracle's Identity Manager: Pre-Auth RCE")은 현재 CVE-2025-61757에 대해 가장 많이 참조되는 상세 분석이며, SANS 및 기타 추적자들에 의해 반영되고 있습니다. (서치라이트 사이버) 이들의 핵심 주장은 이 취약점이 2단계 체인:
- a 중앙 집중식 Java 보안 필터의 사전 인증 바이패스 REST 관리 표면을 보호하고
- 남용 해당 REST API가 노출하는 높은 권한의 관리/스크립트 관리 기능원격 코드 실행으로 정점을 찍습니다. (서치라이트 사이버)
정확한 페이로드 메커니즘은 방어자에게 중요한 것이 아닙니다(공인된 실험실 밖에서 반복해서는 안 됩니다). 중요한 것은 패턴입니다. "중앙 필터 + 부서지기 쉬운 허용 목록" 디자인에서 요청 URI를 허용 화이트리스트와 일치시켜 인증을 적용합니다. 구식 엔터프라이즈 Java 앱에서는 이러한 방식이 일반적이지만 보안 측면에서는 반복되는 문제입니다. 액세스 제어가 복잡한 URI 구문 분석 규칙에서 문자열 또는 정규식 일치에 의존하는 경우, 다음과 같은 문제가 발생할 수 있습니다. 모든 업스트림 컴포넌트는 동일한 방식으로 경로를 정규화합니다. 이 내기는 지는 경향이 있습니다.
근본 원인 형태를 파악하는 안전한 방법은 로직의 추상화된 버전을 살펴보는 것입니다:
// 안티 패턴을 설명하는 의사 코드(제품 코드가 아님)
if (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) {
chain.doFilter(요청, 응답); // 인증 건너뛰기
} else {
enforceAuthentication();
}
공격자가 인증 게이트를 우회할 수 있게 되면 강력한 관리자 엔드포인트는 잠재적인 실행 트램펄린으로 변합니다. Searchlight의 주요 시사점은 "이 특정 엔드포인트는 위험하다"가 아니라 다음과 같습니다. "IAM 제품 내의 REST 관리 표면에는 스크립트 컴파일, 커넥터 관리 또는 암묵적 신뢰가 있는 워크플로 후크가 포함되어 있는 경우가 많습니다." 인증 없이 노출되면 우연이 아니라 의도적으로 RCE를 얻게 됩니다. (서치라이트 사이버)
광범위한 엔지니어링 교훈은 이 단일 CVE 외에도 유용합니다: 허용 목록이 있는 중앙 집중식 필터는 구조적 취약성 클래스입니다.. 자체 Java 서비스에서 코드 검토를 수행하거나 공급업체 미들웨어를 감사하는 경우, "중앙 허용 목록 인증"을 적대적 테스트가 필요한 냄새로 취급하세요.

영향을 받는 버전 및 패치 컨텍스트
오라클은 CVE-2025-61757을 수정했습니다. 2025년 10월 중요 패치 업데이트(CPU)에 출시되었습니다. 2025-10-21. (Oracle) 여러 트래커에서 호출되는 지원되는 영향을 받는 버전은 다음과 같습니다:
| 제품 | 구성 요소 | 지원되는 버전 | 패치 라인 |
|---|---|---|---|
| 오라클 신원 관리자(퓨전 미들웨어) | REST 웹서비스 | 12.2.1.4.0, 14.1.2.1.0 | 2025년 10월 CPU에 패치 적용 |
이는 NVD, Wiz의 취약성 DB, RunZero의 노출 기록에 걸쳐 일치합니다. (NVD)
미묘하지만 중요한 운영 포인트입니다: 오라클 CPU는 분기별로 제공됩니다. CPU 도입 및 롤아웃에 여유가 없는 기업은 안정적이고 변화가 적은 시스템으로 인식되기 때문에 ID 및 미들웨어 스택에 '패치 부채'를 쌓아두는 경향이 있습니다. CVE-2025-61757은 이러한 가정을 깨뜨립니다. 신뢰할 수 없는 네트워크에서 REST 관리 플레인에 액세스할 수 있는 경우, 이는 '다음 분기'로 미룰 수 있는 버그가 아닙니다.
공격 표면의 현실: 이 CVE를 빠르게 스캔하는 이유
익스플로잇의 세부 사항을 설명하지 않더라도 CVSS 벡터의 형태를 보면 자동화된 위협 공격자들이 왜 관심을 갖는지 알 수 있습니다. NVD와 Wiz는 이를 다음과 같이 나열합니다:
- AV:N (네트워크 연결 가능),
- AC:L (낮은 복잡성),
- PR:N/UI:N (권한 없음, 사용자 상호 작용 없음),
- C:H/I:H/A:H (완전한 영향). (NVD)
이러한 조합은 상품 스캐너에 대한 '청신호'입니다. PoC가 공개 채널에 출시되는 순간, 이 제품은 원-리퀘스트 지문 + 팔로우온 체인 봇넷에서. 잘못 구성된 부하 분산 장치, 레거시 NAT 규칙 또는 공급업체의 원격 지원 허점을 통해 조용히 노출된 ID 서버는 이러한 스캔에서 빠르게 나타나는 경향이 있습니다.
더 큰 맥락의 문제도 있습니다: 오라클 미들웨어는 2025년에 인접 제품(웹로직, EBS, 마케팅 모듈)에서 인증되지 않은 여러 가지 중요한 버그가 발견되어 적극적인 캠페인의 대상이 되었습니다. Qualys의 10월 CPU 리뷰에서는 Fusion 미들웨어 크리티컬을 고위험 클러스터로 명시적으로 강조하고 있습니다. (Qualys) 이렇게 하면 공격자가 OIM 손상을 더 광범위한 오라클 자산 운영으로 연결할 가능성이 높아집니다.
탐지를 악용으로 전환하지 않는 방어적 검증
대부분의 팀에게 첫 번째 작업은 간단합니다: 노출 식별공격자를 모방하지 않습니다. 안전하고 승인된 워크플로우는 다음과 같습니다:
- 인벤토리 OIM 버전 환경 전반에서 영향을 받는 회선과 비교합니다.
- 관리 액세스 제한 패치 기간 전이라도 즉시(네트워크 ACL, VPN 게이트, ZTNA) 적용합니다.
- REST 관리자 이상 징후 추적 액세스 로그에서 엔트로피가 높은 요청 URI, 낯선 IP에서 발생한 버스트, 변경이 없는 시간에 호출된 관리자급 엔드포인트 등을 확인할 수 있습니다.
이를 구체적으로 설명하기 위해 에셋 인벤토리 작업에 혼합할 수 있는 방어 전용 버전 매처를 소개합니다:
# 방어 전용: 검색된 OIM 버전을 영향을 받는 세트와 일치시킵니다.
패키징 가져오기 버전에서
AFFECTED = [
("12.2.1.4.0", "12.2.1.4.0"),
("14.1.2.1.0", "14.1.2.1.0"),
]
def is_affected(v: str) -> bool:
v = version.parse(v)
return any(version.parse(lo) <= v <= version.parse(hi) for lo, hi in AFFECTED)
for v in ["12.2.1.4.0", "14.1.2.1.0", "14.1.2.2.0"]:
print(v, "affected?" , is_affected(v))
배너에서 버전을 안정적으로 추출할 수 없는 경우에는 내부 CMDB 데이터, 호스트 패키지 매니페스트 또는 Oracle 홈 메타데이터를 우선순위로 삼으세요. 핵심은 운영 위험을 증가시키는 방식으로 ID 계층을 '프로빙'하는 것을 피하는 것입니다.
패치 후 사냥: 타협은 어떤 모습일까요?
서치라이트의 체인은 업그레이드 후에도 주의해야 할 특정 종류의 행동을 의미합니다:
- 알 수 없는 소스로부터 공격을 받는 REST 관리 엔드포인트특히 공인 IP 범위의 경우 더욱 그렇습니다.
- 변경 창 외부에서 사용되는 관리 동사특히 워크플로/커넥터를 컴파일, 업로드 또는 변경하는 모든 작업을 수행합니다.
- 새 서비스 계정 또는 역할 변경 발권된 작업과 일치하지 않습니다.
RunZero와 Wiz는 모두 개선뿐만 아니라 강화의 일환으로 비정상적인 REST 활동에 대한 로그를 검토하고 관리 접근성을 좁힐 것을 권장합니다. (RunZero)
패치 후 이 문제를 심각하게 고려해야 하는 이유는 인증 전 RCE 버그가 종종 악용되기 때문입니다. 전에 공개. REST 계층이 노출된 경우 해당 계층이 건드려졌을 수 있다고 가정합니다.

실제로 위험을 줄이는 완화 조치
오라클의 공식 지침은 이 수정 사항이 포함된 2025년 10월 CPU 업데이트를 적용하는 것입니다. (Oracle) 엔지니어링 관점에서 보면 위험 감소 조치는 다음과 같이 중첩됩니다:
- 즉시 패치 영향을 받는 모든 지원 버전에서
- 공개 접근성 제거 의 REST 관리 플레인입니다. ID 관리자 API는 인터넷에 연결되지 않아야 합니다.
- 권한 있는 자격 증명 회전 운영상 가능한 경우 MFA를 요구합니다.
- 기준선 및 모니터 OIM 구성 드리프트(역할, 커넥터, 워크플로).
- IAM 계층 세분화 를 사용하여 OIM이 손상되더라도 측면 이동이 느려집니다.
이 모든 것이 새로운 것은 아니지만, CVE-2025-61757은 IAM 강화를 "설정하고 잊어버리는" 것으로 취급할 수 없는 이유를 보여주는 사례 연구입니다. 이제 ID 미들웨어는 엣지 VPN 및 웹 게이트웨이와 동일한 위협 우선순위 버킷에 속하게 되었습니다.
이 CVE가 AI 보안 엔지니어에게 중요한 이유
AI 시스템과 보안의 교차점에서 작업하는 경우, OIM은 점점 더 관련성이 높아지는 업스트림 종속성입니다. 모델을 제공하는 클러스터, 데이터 플랫폼, CI/CD, 심지어 내부 LLM 도구까지 기업 IAM에서 액세스 결정을 상속하는 경우가 많습니다. ID 인프라의 사전 인증 탈취는 공격자가 나중에 AI 스택 침해를 '합법화'하는 방법입니다. 변경이 허용된 ID를 만들 수 있다면 모델 서버를 손상시킬 필요가 없습니다.
방어적인 AI 관점에서 볼 때, CVE-2025-61757은 ID 원격 분석을 탐지 파이프라인에서 1급 신호로 취급해야 한다는 점을 상기시켜 줍니다. 에이전트 보안 도구를 구축하는 경우 가장 현실적인 '영향력이 큰 자동화'는 추측성 익스플로잇 생성이 아니라 고충실도 인벤토리, 폭발 반경 모델링, ID 및 미들웨어 자산에 대한 패치 오케스트레이션입니다.
자동화에 대한 조용한 메모(적합한 경우)
대규모 오라클 환경에서는 개발, QA, DR 및 레거시 테넌트가 분기별로 지연되는 등 버전 스프롤이 실제로 발생합니다. Penligent와 같은 휴먼 인 더 루프 자동화 플랫폼은 다음을 지원할 수 있습니다. 차량 전체에 걸친 OIM 버전 인벤토리, 노출 유효성 검사 및 수정 추적팀을 위험한 익스플로잇으로 내몰지 않고도 취약점을 찾을 수 있습니다. 취약점이 ID 계층에 중요한 영향을 미치는 경우, '발견 → 우선순위 지정 → 수정' 루프에서 속도와 정확성이 무엇보다 중요합니다.
닫기
CVE-2025-61757은 단순한 버그가 아니라 알려진 엔터프라이즈 Java 안티 패턴에서 비롯된 고도의 영향력 있는 ID 계층 침해 경로입니다. 즉각적인 조치는 영향을 받는 OIM 버전을 패치하고 REST 관리 액세스를 잠그는 것입니다. 장기적으로는 더 큰 문제가 있습니다: IAM 컨트롤 플레인에 도달할 수 있는 경우 공격을 받게 되며 중앙 집중식 허용 목록 필터를 우회하게 됩니다. 이 CVE를 강제 기능으로 취급하여 ID 시스템이 노출, 인증 및 모니터링되는 방식을 감사하세요.
