Oracle EBS TCF 서블릿 미인증 SQL 인젝션 취약점 (CVE-2026-101767)

NOW Briefing

Brief 1 Oracle E-Business Suite의 미인증 SQL 인젝션 취약점(CVE-2026-101767)을 악용하는 PoC 코드가 GitHub에 공개됐습니다.

Brief 2 연구자 분석에 따르면 인증 없이 HTTP 요청만으로 임의 SQL이 실행되고, 원격 코드 실행(RCE)까지 이어질 수 있습니다.

Brief 3 EBS 12.2.3~12.2.15 운영 조직은 2026년 10월 분기 보안 패치를 적용하고, 적용이 지연되면 웹 티어의 외부 접근을 제한해야 합니다.

‍

Oracle EBS TCF 서블릿 미인증 SQL 인젝션 취약점 (CVE-2026-101767)

‍

■ 개요

‍

Oracle E-Business Suite(EBS)는 재무·구매·인사·공급망 업무를 하나로 묶은 오라클의 기업용 통합 업무 시스템(ERP)입니다. CVE-2026-101767은 이 제품의 Application Object Library(Core) 구성요소에 있는 취약점으로, 지원 버전 12.2.3부터 12.2.15까지가 영향을 받습니다. 공식 레코드 기준으로 인증과 사용자 상호작용이 모두 필요하지 않아, HTTP로 네트워크에 접근할 수 있으면 악용이 가능합니다.

연구자 분석에 따르면 공격자는 EBS 업무 데이터를 소유하는 데이터베이스 계정(APPS) 권한으로 임의 SQL을 실행할 수 있고, 여기서 EBS 애플리케이션 계정 권한의 운영체제 명령 실행까지 이어질 수 있습니다. 인증 단계를 거치지 않는 경로이므로 계정 탈취나 내부 접근 없이도 ERP의 업무 데이터와 애플리케이션 서버 양쪽이 영향권에 들어갈 수 있습니다. Oracle이 CNA로 산정한 CVSS v3.1 점수는 9.8이며, NVD 레코드는 아직 분석 대기(Awaiting Analysis) 상태입니다.

Horizon3.ai는 2026년 7월 24일 Oracle에 제보했고, Oracle은 2026년 10월 20일 분기 보안 패치로 수정했습니다. 이후 2026년 10월 26일 GitHub에 PoC 저장소가 공개됐습니다. Defused는 2026년 10월 27일 자사 미끼 시스템(디코이)에서 이 취약점을 겨냥한 탐색적 익스플로잇 시도를 관측했다고 밝혔습니다. Shadowserver 집계 기준으로 인터넷에 노출된 EBS 인스턴스는 670대 이상입니다. 현재 CISA의 악용된 취약점 목록(KEV)에는 등재되지 않았고, 공격 성공 사례도 공개 확인되지 않았습니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-101767 (EBS 자바 클라이언트 통신 서블릿의 미인증 SQL 인젝션)
CVSS 점수	CVSS v3.1 9.8
취약점 유형	• CWE-306 핵심 기능의 인증 누락, CWE-287 부적절한 인증(CISA-ADP 지정) • 미인증 SQL 인젝션 후 OS 명령 실행 연계(연구자 분석)
영향/위험	• 미인증 HTTP 요청으로 APPS 데이터베이스 사용자 권한의 임의 SQL 실행 가능 • SQL 실행에서 EBS 애플리케이션 계정 권한의 OS 명령 실행으로 연계 가능(연구자 분석) • 공개된 PoC 저장소가 SQL 인젝션 입력 지점과 자체 랩 환경 재현 절차를 함께 제공(운영 인스턴스 대상 검증 결과는 미공개) • Defused 디코이에서 탐색적 익스플로잇 시도 관측(2026년 10월 27일)
취약 버전	Oracle E-Business Suite 12.2.3 ~ 12.2.15 (Application Object Library, Core)
패치 버전	Oracle 2026년 10월 분기 보안 패치(2026-10-20 공개) 적용분

‍

■ 기술 분석

‍

취약 경로는 EBS 웹 티어의 /OA_HTML/AppsTCFServer 서블릿(oracle.apps.fnd.tcf.SocketServer)입니다. 이 서블릿은 자바 클라이언트와 서버를 잇는 통신 계층(TCF) 요청을 처리하면서, 요청에 지정된 서버 클래스를 인스턴스화합니다. Horizon3.ai 분석 기준으로 이 경로는 허용된 경로만 통과시키는 EBS 내장 접근 제어(URL 방화벽)의 기본 허용 목록에 포함돼 있어, 웹 티어가 외부에 열려 있으면 추가 설정 없이 도달합니다. 요청 처리 과정에는 인증·인가 검사가 없으며, CISA도 이 취약점에 CWE-306을 부여했습니다.

악용에 사용되는 대상은 일정 차트(간트) 데이터를 제공하는 서버 클래스(oracle.apps.jtf.gantt.server.GanttDataServer)입니다. 이 클래스는 자원 조회 질의를 설정하는 명령을 처리할 때 요청으로 전달된 문자열을 질의문 자체로 보관하고, 데이터 조회 단계에서 그 문자열을 그대로 JDBC 호출에 넘깁니다. PoC 저장소에는 EBS 12.2.15 바이트코드를 디컴파일한 소스 debug-src/oracle/apps/jtf/gantt/server/DataRetrieval.java가 포함돼 있는데, 이 파일의 executeQuery()는 해당 문자열을 prepareStatement(queryInfo.getResourceQueryString()) 형태로 호출합니다. 값만 따로 전달하는 바인드 변수가 아니라 질의문 전체가 외부 입력이므로, APPS 계정 권한으로 임의 SQL이 실행됩니다.

공개 범위에는 한계가 있습니다. Oracle의 패치 diff는 공개되지 않아 패치 전후 코드 비교는 제시할 수 없습니다. 같은 저장소의 debug-src/oracle/apps/jtf/gantt/QueryInfo.java는 import 구문과 디컴파일 실패 주석만 남은 껍데기여서 질의 조립 로직 자체는 공개 소스에서 확인되지 않습니다. SQL 실행에서 운영체제 명령 실행으로 넘어가는 구체적 수단도 Horizon3.ai가 공개하지 않고 IoC 수준의 설명만 제시했습니다. PoC 저장소 역시 UTL_FILE을 이용한 APPLPTMP 파일 쓰기까지만 구성했고, Concurrent Manager로 OS 명령을 실행하는 마지막 단계는 구현하지 않았다고 밝히고 있습니다.

‍

■ PoC

‍

GitHub 저장소 seck19/CVE-2026-101767-POC(커밋 70369ec)의 poc/tcf_poc.py는 TCF 통신 프레임을 직접 조립해 서블릿에 전송하는 파이썬 클라이언트입니다. 이 가운데 자원 조회 질의를 설정하는 부분이 SQL 인젝션 입력 지점입니다.

아래 코드는 공개 PoC 원문인 tcf_poc.py의 set_resource_query() 일부입니다. 코드는 수정하지 않고 그대로 옮겼습니다. 파일 전체는 참고 자료의 해당 파일 원문 링크에서 확인할 수 있습니다.

    def set_resource_query(self, sql):
        item = Item()
        item.add_int(CMD_SET_RESOURCE_QUERY)
        # QueryInfo.setResourceQuery(Item):
        #   int nTokens, nTokens * String, int nSelectCols,
        #   nSelectCols * dataType, boolean showShifts
        item.add_int(1)
        item.add_string(sql)
        item.add_int(0)        # 0 extra columns -> response = id,type,name
        item.add_bool(False)   # skip jtf_calendar_pub_24hr shifts
        return item

호출자가 전달한 sql 인자가 가공 없이 질의 토큰으로 실리고, 서버는 이를 질의문으로 받아 실행합니다. 저장소에는 데이터베이스 버전·현재 사용자·디렉터리 객체를 조회하는 정찰 모드와 결과를 나눠 받는 기능도 포함돼 있어, 랩 환경에서는 질의 결과가 응답으로 되돌아옵니다. 다만 저장소가 제시하는 재현 절차는 EBS 12.2.15 바이트코드로 구성한 자체 랩 환경(Docker, 로컬 주소)을 대상으로 하고, 이 랩은 세션 검증 수준을 달리 설정하는 모드를 함께 제공합니다. 실제 운영 인스턴스를 대상으로 한 검증 결과는 공개되지 않았습니다.

⚠️ WARN

패치 이전에 웹 티어가 인터넷에 노출돼 있었다면 침해 여부를 우선 점검해야 합니다.
디코이 기준으로 탐색적 익스플로잇 시도가 이미 관측된 만큼 패치 적용과 로그 소급 점검을 함께 진행해야 합니다.

‍

■ 탐지 및 점검

‍

• 웹 티어 접근 로그에서 인증 세션 없이 /OA_HTML/AppsTCFServer로 들어온 POST 요청을 식별해야 합니다. 요청 본문에서 간트 데이터 서버 클래스 지정 여부까지 확인하려면 프록시 본문 로깅이나 전체 패킷 캡처 같은 수집 설정이 미리 켜져 있어야 합니다.

• 해당 요청 직후 APPS 계정으로 데이터베이스 버전·현재 사용자·디렉터리 객체를 조회한 SQL이 있는지 데이터베이스 감사 로그에서 확인해야 합니다.

• $APPLPTMP 디렉터리에 업무 일정과 무관한 파일이 생성됐는지 점검하고, 단독 파일 발견만으로 침해를 확정하지 말고 웹 요청 기록과 함께 상관 분석해야 합니다.

• oracle 계정이 Concurrent Manager로 /bin/sh를 실행한 흔적이 있는지 프로세스 실행 로그에서 확인해야 합니다.

• 자사 EBS 웹 티어가 인터넷에서 직접 접근 가능한 상태인지 외부 관점에서 점검해야 합니다.

✅ CHECK

점검 기간은 패치 적용일이 아니라 2026년 10월 20일 이전까지 소급해야 합니다.
제보 시점부터 패치 공개까지의 기간에도 노출이 있었다면 같은 지표로 확인해야 합니다.

‍