bit-pi(Bit Flows) 1.31.0 코드에서 확인되는 웹훅 콜백 라우트와 imageHelper 기본값, 어디까지 확인됐는가

이번 사안에서 실제로 확보된 자료는 bit-pi 1.31.0 태그의 코드 인용 두 건과 WordPress.org 플러그인 디렉터리 정보 한 건입니다. 아래 본문은 이 자료로 확인할 수 있는 문장과, 자료 사이에 여전히 비어 있는 구간을 의도적으로 나눠 서술합니다.

개요

- bit-pi 1.31.0 태그의 backend/hooks/api.php 인용에는 webhook/callback/{trigger_id} 경로를 post, get, head 요청에 매칭해 WebhookDispatchController의 handleWebhook으로 넘기는 라우트 등록이 담겨 있습니다. (라우트 등록 코드)
- 같은 태그의 ImageHelperTool.php 인용에는 nodeInfoProvider에서 imageHelper 노드 데이터를 읽고, conversionType 값이 없으면 기본값을 imageToBase64로 두는 처리가 담겨 있습니다. (ImageHelperTool 코드)
- WordPress.org 플러그인 디렉터리 정보 기준 slug는 bit-pi, 현재 게시 버전은 1.32.0입니다. (bit-pi 플러그인 정보)
- 따라서 이번 근거로 확인되는 지점은 라우트 등록과 HTTP 메서드 매칭, 이미지 변환 방식의 기본값, 그리고 디렉터리의 현재 게시 버전입니다.
- 확인되지 않은 지점도 또렷합니다. 위 코드들이 하나의 요청 안에서 서로 연결된다는 사실, 파일 경로로 쓰일 값이 어디서 오는지와 그 검증 여부, 변환 결과가 응답으로 밖으로 나가는지는 이번 인용에 나타나지 않습니다.

영향 범위

확보된 자료는 버전 태그 단위로 특정되어 있습니다.

• 코드 인용이 확인되는 버전: bit-pi 1.31.0 태그
• 디렉터리의 현재 게시 버전: 1.32.0. 다만 이 버전과 이번 사안의 관계, 즉 수정본인지 여부를 보여주는 근거는 없습니다.
• 플러그인 정체: WordPress 플러그인 bit-pi, 표시 이름은 Bit Flows: AI Agent Automation & Integrations for Forms, CRM, eCommerce, Google Sheets, and More
• 인용된 코드가 지나는 두 경로: webhook/callback/{trigger_id} 라우트 등록부, 그리고 imageHelper 노드 데이터에서 conversionType을 읽는 이미지 변환 도구부

제공된 근거는 두 버전 정보를 각각 따로 보여줍니다. 코드 인용은 1.31.0 태그라는 특정 지점에서 가져왔고, 디렉터리 정보는 현재 게시 버전 1.32.0을 보여줍니다. 이 글은 두 사실 사이에 수정본·미수정본 같은 관계를 추정하는 문장을 놓지 않습니다. 어느 설치자가 어떤 코드 경로에 해당하는지는 각 사이트의 설치 버전과 수정 이력 자료를 함께 확인해야 알 수 있다는 표현이 지금 근거에 맞습니다.

여기서 범위를 좁혀 둘 것이 있습니다. 이번 근거에는 webhook/callback/{trigger_id} 라우트 등록문의 HTTP 메서드 허용 범위만 담겨 있고, 이 경로가 인증을 요구하는지, 웹 외부에서 실제로 도달 가능한지는 포함되어 있지 않습니다. 그래서 이 글은 해당 경로를 공개된 진입점이라고 쓰지 않습니다. 또한 imageHelper 도구를 쓰는 플로우를 운영 중인지 여부는 사이트별 설정 사항이라 이번 근거로 확인할 수 없습니다.

기술적 분석

웹훅 콜백 라우트: 확인되는 범위는 등록문까지

Route::match(['post', 'get', 'head'], 'webhook/callback/{trigger_id}', [WebhookDispatchController::class, 'handleWebhook']);

인용에서 확인되는 사실은 등록문의 형태입니다. webhook/callback/{trigger_id}라는 경로가 등록되어 있고, post, get, head 메서드가 같은 핸들러에 매칭되며, 처리가 WebhookDispatchController의 handleWebhook으로 넘어간다는 점이 등록문에서 읽힙니다. trigger_id는 경로 파라미터 자리표시자로 등록문에 나타납니다.

여기서 한 걸음 더 나아간 해석은 이번 근거가 뒷받침하지 않습니다. 요청 본문 없이 URL만으로 핸들러에 도달할 수 있는지, 매칭된 메서드들이 실행 결과에서 어떤 차이를 만드는지는 이 등록문 한 줄로는 확인할 수 없습니다.

반대로 이 한 줄에 나타나지 않는 것도 분명합니다. 라우트 앞에 붙는 미들웨어, 시크릿 토큰이나 서명 검증 같은 계층, 경로 도달을 막는 다른 방어책은 이 인용에 없습니다. 따라서 이 인용은 인증이 없다는 증거가 아니라, 인증 여부를 보여주지 않는 자료입니다. 외부 노출과 공격 난이도는 그래서 확인 보류로 둡니다.

imageHelper 도구: 기본값 imageToBase64

GlobalNodeVariables::getInstance($this->flowHistoryId, $flowId);

$imageHelperData = $this->nodeInfoProvider->getData()['imageHelper'] ?? [];

$conversionType = $imageHelperData['conversionType'] ?? 'imageToBase64';

인용은 노드 데이터를 읽는 흐름을 보여줍니다. nodeInfoProvider의 getData()에서 imageHelper 키를 꺼내고, 그 값이 없으면 빈 배열로 처리합니다. 이어서 conversionType 키가 없으면 기본값을 imageToBase64로 둡니다. 인용 앞부분에는 getInstance($this->flowHistoryId, $flowId) 호출이 함께 나타납니다.

독해의 초점은 기본값의 존재입니다. 변환 모드를 명시하지 않은 설정에서도 도구는 변환 방식을 잃지 않고 imageToBase64로 정합니다. base64 인코딩은 파일 내용을 텍스트 형태로 표현하는 방식이므로, 변환할 대상을 정하는 입력과 결과를 실어 나르는 응답 경로가 무엇으로 맺히는지가 이 사안의 핵심이 됩니다.

그런데 인용은 바로 다음 구문에서 끊깁니다. 원문은 $params = $this->extractIn으로 이어지다 잘려 있고, 사라진 코드가 파라미터 추출부입니다. 즉 변환 대상 경로가 플로우 설정에서 오는지, 실행 중 들어오는 데이터에서 오는지, 그 값에 어떤 검증이 적용되는지가 인용 밖에 있습니다. conversionType 기본값은 확인되지만, 그 변환이 무엇을 대상으로 일어나고 결과가 어디로 가는지는 확인되지 않습니다.

조건이 갖춰질 때만 성립하는 해석

공급된 기술 분석의 문제 제기는 이 빈 구간 위에 있습니다. 웹훅 콜백은 본래 외부 시스템의 호출을 받아 플로우를 실행하는 통로라는 점에서, 인증 계층이 확인되지 않은 콜백 경로가 실행의 출발점이 될 수 있다는 전제가 먼저 놓입니다. 여기에 이미지 변환 도구가 기본값으로 base64 변환을 정한다는 사실이 더해집니다.

그래서 로컬 파일 포함(LFI) 유형의 원격 읽기가 성립하려면 확인이 필요한 고리가 세 개 남습니다. 라우트가 웹 외부에서 도달 가능한지, 변환 대상 경로가 실행 중 들어오는 값에서 오는지 그 검증 없이, 변환 결과가 응답으로 반환되는지입니다. 이 조건들이 실제로 확인되는 시점에 두 코드 지점은 하나의 읽기 경로로 이어질 수 있습니다. 반대로 어느 한 고리라도 검증이나 응답 비포함으로 확인되면 같은 조합은 읽기 경로가 되지 못합니다. 이번 인용은 세 고리 어디도 결론내리지 못하므로, 이 해석은 확인 전 시나리오로만 다뤄야 합니다.

점검의 순서는 이 조건 구조에서 나옵니다. 가장 먼저 정해야 할 것은 콜백 경로의 인증 요구 여부와 외부 도달 가능성이고, 그다음은 ImageHelperTool의 경로 입력 지점과 변환 결과 반환 동작, 마지막이 버전 경계와 공식 자료 확인입니다. 코드가 확인된 순서와 자료의 형태가 그대로 우선순위가 되는 구조입니다.

확인된 것과 확인되지 않은 것

표의 위쪽은 지금 확인할 수 있는 사실이고, 아래쪽은 아직 판단을 유보한 항목입니다. 유보는 안전하다는 뜻이 아닙니다. 확인이 끝날 때까지 판단을 미룬다는 뜻이고, 그래서 어떤 환경을 위험하다고도 안전하다고도 이 글은 쓰지 않습니다.

악용 상태

공개 PoC, 실제 야생 공격 사례, CISA KEV 등재 여부 중 이번 근거로 확인할 수 있는 것은 하나도 없습니다. 따라서 이 글은 악용 상태를 미확인 그대로 둡니다. 확인된 코드 사실과 악용 가능성은 별개의 문장으로 다뤄야 하며, PoC가 없다는 정황도 이번 근거에 없어 위험을 낮출 근거로도 쓰지 않습니다.

대응 방안

확보된 자료가 코드 인용과 버전 정보에 한정되어 있어, 이 글이 근거와 함께 권할 수 있는 조치는 무엇을 확인해야 하는가입니다. 차단 규칙, 로그 경보, 기능 해제, 인증 계층 추가 같은 구성 지침은 이번 근거가 뒷받침하지 않으므로 제시하지 않습니다.

지금 확인해야 할 것

• 설치한 bit-pi 버전을 확인합니다. 1.31.0이면 이번 코드 인용이 확인되는 태그이고, 1.32.0이면 디렉터리의 현재 게시 버전과 같은 번호입니다.
• 1.32.0이라는 숫자만으로 수정본이라고 읽지 않습니다. 두 버전과 이번 사안의 관계를 보여주는 자료가 없기 때문입니다.
• 벤더(Bit Apps)의 공식 보안 권고문과 수정·패치 정보가 공개되어 있는지 확인합니다. 제공된 근거에는 해당 정보가 없어, 버전 경계와 공식 업그레이드 지침은 별도 확인이 필요합니다.
• 공식 취약점 레코드와 심각도 평가가 발표되었는지도 함께 확인합니다. 이번 근거에는 식별자·CVSS 점수가 없어 이 글은 심각도를 표현하지 않습니다.

확인 결과에 따른 해석

• 공식 권고와 수정 버전이 확인되면 — 그 지침에 따른 업그레이드가 판단의 기준이 됩니다. 이 글의 조건부 서술은 그때 확정되거나 기각됩니다.
• 1.31.0을 사용 중이라면 — 제공된 코드 인용이 확인되는 버전이므로, 이번 분석의 전제와 같은 지점에 있습니다.
• 공식 권고·레코드가 아직 확인되지 않는 상태라면 — 위험이 없다고 결론 내리는 쪽도 성립하지 않습니다. 확인되지 않은 상태로 남아 있다는 것이 정확한 표현입니다.

참고자료

• backend/hooks/api.php - webhook callback 라우트 등록 (bit-pi tags/1.31.0)
• ImageHelperTool.php - imageHelper 도구 execute/imageToBase64 기본 경로 (bit-pi tags/1.31.0)
• bit-pi 플러그인 디렉터리 정보 - 현재 버전 1.32.0

함께 읽으면 좋은 글

• CVE-2026-109385: UiChemy AI 빌드 플러그인의 저장형 XSS
• CVE-2026-119025: open 패키지의 PowerShell 이스케이프 결함, MCP OAuth URL로 명령 주입이 되다
• CVE-2026-96652: Plex Media Server 인증 없는 SSRF와 CISA KEV 등재

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