2026년 6월 27일 주말, Defused Cyber의 Oracle E-Business Suite 허니팟에 이례적인 HTTP 요청 6건이 기록됐다. 목적지 엔드포인트는 /OA_HTML/ibytransmit — Oracle Payments의 파일 전송 컴포넌트다. 요청에는 인증 토큰이 없었다. 서버는 응답했고, 공격자는 서버의 /etc/passwd를 읽어냈다.
당시 공개된 공격 코드는 존재하지 않았다. Oracle이 패치를 배포한 것은 6주 전인 5월 28일이었다. 패치 차이를 분석해 취약 코드 경로를 독자적으로 재현한 것으로 Defused Cyber는 결론 내렸다.
왜 Oracle Payments인가
Oracle E-Business Suite(EBS)는 전 세계 1만 4,000여 개 기업이 운용하는 ERP 플랫폼이다. 금융·제조·의료·정부 조달 분야에 집중 배포돼 있다.
Oracle Payments는 그 EBS 안에서 모든 입출금 흐름이 통과하는 단일 결제 허브 역할을 한다. 이 모듈이 보관하는 자산은 다음과 같다.
신용카드·직불카드 번호와 결제 승인 데이터
EFT(전자 자금 이체)를 위한 은행 계좌 정보
외부 금융 기관과의 통신에 쓰이는 결제 프로세서 API 키
카드 데이터를 보호하는 Oracle Wallet의 시스템 키 및 서브키 (3DES 체인 암호화)
취약한 컴포넌트는 이 모듈의 File Transmission 하위 기능이다. 결제 파일을 은행과 결제 기관에 전송하는 경로로, 인증 없이 여기에 접근할 수 있다면 파일 읽기를 통해 설정 파일과 암호화 키 자료까지 사슬처럼 연결된다.
결함 메커니즘
세 가지 CWE가 중첩돼 CVSS 9.8을 만들었다.
CWE-306: 핵심 기능에 대한 인증 누락
CWE-287: 인증 구현 불충분
CWE-269: 권한 관리 불충분
이 중 CWE-306이 결함의 뿌리다. ibytransmit 엔드포인트는 결제 파일 전송을 위한 외부 호출 경로로 노출돼 있는데, 세션 유효성 검사 로직이 이 경로 자체에 포함되지 않았다. 인증은 상위 계층에서 처리해야 한다는 설계 가정이 있었으나, 직접 HTTP POST로 접근하면 그 가정이 우회된다.
공격자는 /OA_HTML/ibytransmit 엔드포인트에 XML 형식의 DeliveryRequest 구조를 HTTP POST로 전송한다. 이 요청은 세션 검사 없이 내부 Oracle Java 파일 전송 함수를 직접 호출하며, 공격자가 지정한 경로의 파일을 읽어 응답으로 반환한다.
Defused Cyber의 허니팟 관측에 따르면, 공격자는 이 경로로 /etc/passwd 읽기에 성공했다. 이것은 파일 경로를 지정해 서버가 그 내용을 반환하게 만드는 파일 읽기 능력(primitive)이 실증된 것이다. Oracle Wallet 파일(ewallet.p12)이나 DB 접속 정보가 담긴 설정 파일에 동일한 방법이 적용되면, 결제 암호화 키까지 도달할 수 있는 연쇄 경로가 된다.
악용 전개
패치 발행(5월 28일)부터 야생 익스플로잇 포착(6월 27일)까지의 간격은 약 30일이다. Oracle CPU 발행 주기와 기업 패치 적용 주기 사이의 이 공백이 공격 창이 된다.
이 공백은 만의 문제가 아니다. Oracle EBS는 패치가 존재해도 기업 내부 변경 관리 프로세스와 테스트·롤아웃 일정 때문에 수주~수개월 지연 적용되는 경향이 있다. 공격자는 그 지연을 정확히 노린다.
직전 선례가 이를 뒷받침한다. 2025년 9월, CL0P 랜섬웨어 그룹은 (Oracle EBS BI Publisher RCE)를 패치 이전 제로데이 상태로 악용했다. 대학·항공사·미디어 등 30개 조직의 ERP 데이터를 탈취해 공개 협박했다. AhnLab ASEC도 당시 국내 기업을 대상으로 한 Oracle EBS 위협 인텔을 발행했다 — Oracle EBS 침해가 한국 환경과 무관하지 않음을 보여주는 전례다.
은 제로데이는 아니다. 그러나 공개 PoC가 없는 상태에서 패치 차이 분석으로 개발된 익스플로잇이라는 점은, 기업이 Oracle CPU 발행 즉시 패치를 적용하지 않으면 공개 PoC 공개 이전에도 표적이 될 수 있다는 현실을 보여준다. CL0P 사례가 제로데이 공백을 이용했다면, 이번 사례는 패치 이후 적용 지연 공백을 이용했다 — 공격 창의 형태만 달랐을 뿐 구조는 같다.
Shadowserver가 추적한 인터넷 노출 Oracle EBS 인스턴스는 약 950개다.
탐지 관점
이 공격은 다른 EBS 정상 트래픽과 구별되는 흔적 두 가지를 반드시 남긴다.
첫째, 인증 세션 없는 /OA_HTML/ibytransmit POST 요청. 정상 운영 환경에서 이 엔드포인트는 인증된 세션에서만 호출된다. 세션 토큰 없이 이 경로로 POST 요청이 수신되면 익스플로잇 시도의 직접 신호다. Defused Cyber 관측에서 사용된 User-Agent는 ibytransmit-lab-poc/1.0이었다. 비정상 User-Agent와 결합될 경우 더욱 명확하게 식별된다.
둘째, XML 페이로드 내 시스템 경로./etc/passwd, /etc/shadow, Oracle Wallet 경로 등이 FULL_FILE_PATH 파라미터에 포함된 요청은 파일 읽기 시도의 지표다. Oracle Payments의 정상 전송 요청은 이 파라미터에 서버 로컬 시스템 경로를 사용하지 않는다.
최초 관측된 공격 소스 IP는 45.84.137.125(AS136787 PacketHub S.A., EU 소재)다. 단일 소스 6건은 광범위 스캔이 아닌 표적 검증 성격으로 보인다. The Register는 이 공격이 "체계적 검증"에 가깝다고 평가했다.
한국 관점
Oracle EBS는 국내 대기업·공공기업에서도 광범위하게 운용되고 있다. 보안뉴스는 2025년 CL0P 캠페인 당시 "우리나라 대기업·공공기업에서도 많이 사용하고 있으며, 즉시 패치하고 보안 강화해야 한다"고 보도했다. KISA는 Oracle CPU 주요 취약점 발표 시마다 보안 업데이트 권고를 발행해 왔다(2026년 4월 Oracle WebLogic 권고 포함).
관련 국내 피해 조직은 현재까지 보고되지 않았다. 국내 금융·제조·공공 분야에서 Oracle Payments를 운용하는 조직이 2026년 5월 Oracle CPU를 미적용 상태로 유지하고 있다면, 6월 27일 허니팟에서 포착된 것과 동일한 방식의 익스플로잇에 노출될 수 있다. EBS 웹 인터페이스가 인터넷에 직접 노출돼 있다면 의 야생 익스플로잇 범위에 이미 포함돼 있다.