DEEP DIVE REPORT

CVE-2026-118534: Directorist 결제 재시도 기능의 주문 소유권 누락과 IDOR

SecurityDesk
• 2026.11.08 • 조회 4

Directorist 워드프레스 플러그인의 결제 재시도 기능이 대상 주문의 소유권을 확인하지 않는다는 사실이 공개됐습니다. 확인된 문제는 결제 자체보다 권한 확인의 공백에 있습니다. 그래서 먼저 볼 것은 버전이고, 그다음은 결제 시도 기록입니다. 아래에서는 근거로 확인된 내용과 아직 확인되지 않은 범위를 나눠 정리합니다.

개요

개요 인포그래픽
Directorist: AI-Powered Business Directory, Listings & Classified Ads 워드프레스 플러그인 8.11 이전 버전에는 체크아웃 결제 재시도를 처리하는 REST 동작이 있습니다. 이 동작은 요청이 지정한 주문이 해당 사용자의 것인지 확인하지 않은 채 동작합니다. 그 결과 구독자처럼 권한이 낮은 계정이라도 다른 사용자의 주문을 겨냥해 결제 시도 기록을 생성할 수 있습니다.

이 유형은 객체 수준 권한 확인이 빠져 있다는 점에서 직접 객체 참조(IDOR)로 분류됩니다. WPScan이 공개한 취약점 정보에도 Directorist < 8.11 – Subscriber+ Payment Retry on Other Users' Orders via IDOR라는 제목으로 정리돼 있고, 수정 버전은 8.11로 기재돼 있습니다. 이 건은 CVE-2026-118534로 공개됐습니다.

영향 범위

영향 범위는 Directorist 8.11 이전 버전이고, 수정 버전은 8.11입니다. 설치된 버전이 8.11보다 낮으면 수정 적용 대상에 포함됩니다. 다만 개별 설치 환경에서 실제로 어떤 코드가 동작하는지까지는 제공된 자료로 확인되지 않으므로, 판단의 첫 단계는 버전 확인이 됩니다.

두 번째 조건은 인증입니다. 악용에는 인증된 사용자 계정이 필요하고, 구독자도 이 조건에 포함됩니다. 관리자만 위험한 취약점이 아니라, 회원가입이나 로그인 기능으로 일반 사용자 계정이 만들어질 수 있는 사이트가 점검 대상이 됩니다.

여기서 선을 그어야 할 부분도 있습니다. 실제 결제가 처리되는지, 금전 손실이나 주문 정보 노출로 이어지는지는 제공된 근거만으로 확인할 수 없습니다. 확인된 것은 다른 사용자의 주문에 결제 시도 기록을 생성할 수 있다는 점이고, 그 기록이 결제 흐름에서 어떤 결과를 만드는지는 별도 확인이 필요한 영역입니다.

기술적 분석

소유권 확인이 빠진 결제 재시도 경로

확인된 취약점은 체크아웃 결제 재시도를 처리하는 REST 동작이 대상 주문이 요청 사용자에게 속하는지 확인하지 않는다는 점입니다. 인증된 사용자라는 신원 확인은 통과하지만, 이 주문의 주인이 실제로 요청자인지를 묻는 단계가 빠져 있습니다. 제공된 근거가 확인한 범위는 이 소유권 검증의 누락까지이며, 인가 점검 전체의 유무나 주문 식별자가 서버 내부에서 어떻게 처리되는지는 근거에 담겨 있지 않습니다.

그만큼 근거로 확인되는 결과는 다른 사용자의 주문을 향한 결제 시도 기록의 생성입니다. 주문 데이터가 열람되는지, 결제 상태가 바뀌는지는 이 구조만으로는 단정할 수 없습니다. 기록 생성이 어디까지 이어지는지는 결제 처리 로직의 동작을 봐야 알지만, 제공된 근거에는 그 부분이 포함돼 있지 않습니다.

악용 현황

제공된 근거에는 실제 환경에서의 악용이나 공개된 개념증명(PoC)을 확인할 수 있는 내용이 없습니다. 다만 이는 실제 악용이 없다는 뜻이 아니라, 확인된 자료가 없다는 뜻으로 읽어야 합니다. 요청 형식과 주문 식별자 확보 방법도 확인되지 않았습니다. 이 부분은 근거가 없어 판단을 유보합니다.

대응 방안

버전 확인과 업데이트

가장 먼저 설치된 Directorist 버전을 확인합니다. 8.11 이전이면 수정 버전 적용을 우선 검토합니다. 업데이트가 어려운 환경에 적용할 검증된 우회책은 제공된 자료에서 확인되지 않았고, 그런 임시 조치가 존재하는지 여부도 근거로 뒷받침되지 않습니다. 즉 수정 전 노출을 줄이는 방법은 이 자료의 범위를 넘는 확인 사항으로 남아 있습니다.

결제 기능이 얽힌 변경인 만큼, 8.11 적용 시에는 스테이징이나 비혼잡 시간대처럼 사이트의 변경 절차에 따라 결제 동작의 호환성을 함께 확인하는 순서가 현실적입니다. 주문과 결제 흐름의 확인은 권장 범위로 다뤄야 합니다.

점검 대상을 넓히는 조건

관리자 계정만 위험하다고 보면 범위를 놓칩니다. 구독자도 악용 조건에 해당하므로, 회원가입과 로그인으로 일반 사용자 계정이 생성되는 환경이라면 그 계정들도 점검 대상에 포함됩니다.

결제 시도 기록 확인

가능한 탐지 접근은 확인 가능한 결제 시도 기록을 검토해, 다른 사용자의 주문과 관련된 비정상적인 시도가 있는지 살피는 방향입니다. 다만 제공된 근거에는 요청자와 주문 소유자의 불일치를 식별할 구체적인 로그 필드나 탐지 규칙이 없습니다. 어떤 필드를 봐야 하는지는 플러그인의 기록 구조를 알아야 하므로, 이 부분은 확정된 탐지 절차가 아니라 확인이 남은 한계로 두고 벤더 정보를 통해 채우는 편이 정확합니다.

참고자료

함께 읽으면 좋은 글

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9