MCP SSE 서버는 ToolsMCPServer.run_sse() / launch_tools_mcp_server(transport="sse")를 통해 시작되었습니다. 기본적으로 0.0.0.0에 바인딩하고 인증 미들웨어 없이 Starlette 애플리케이션을 구축합니다. Origin 헤더 검증은 없습니다. mcp/mcp_security.py 모듈은 필요한 제어 기능을 정확하게 제공합니다. (원본 검증, DNS 리바인딩 감지, 인증 헤더 적용, SecurityConfig), 그러나 다음 중 어느 것도 없습니다. 이러한 함수는 모든 전송에서 호출됩니다. 즉, 데드 코드입니다. 도달할 수 있는 모든 호스트 포트는 자격 증명 없이 등록된 모든 도구를 나열하고 호출할 수 있으며 피해자의 브라우저는 DNS 리바인딩을 통해 localhost 인스턴스에 대해 동일한 호출을 수행합니다.

영향을 받는 코드: src/praisonai-agents/praisonaiagents/mcp/mcp_server.py

• run_sse는 기본적으로 모든 인터페이스에 대한 호스트를 설정하고(라인 245) debug 및 routes만 사용하여 앱을 빌드합니다.
  • middleware= 및 경로별 인증/원본 게이트 없음(라인 ~271-289): 앱 = Starlette(debug=self._debug, 경로=[ 경로(sse_path, 끝점=handle_sse), # "/sse" 마운트(messages_path, app=sse_transport.handle_post_message), # "/messages/" ]) uvicorn.run(앱, 호스트=호스트, 포트=포트)
• launch_tools_mcp_server도 기본값은 host="0.0.0.0"입니다(라인 301).

src/praisonai-agents/praisonaiagents/mcp/mcp_security.py는 정의하지만 전송에서는 다음을 호출하지 않습니다.

• is_valid_origin(30행), is_potential_dns_rebind(110행), verify_auth_header(167행), SecurityConfig.is_origin_allowed(라인 236). 이러한 기호는 mcp_security.py 내에서만 참조됩니다. 그리고 init 다시 내보내기. (mcp_websocket.py의 인증 참조는 서버 유효성 검사가 아닌 클라이언트 측입니다.)

영향: launch_tools_mcp_server(transport="sse")는 MCP를 통해 도구를 노출하기 위한 문서화된 경로입니다. 와 함께 그 위의 기본값은 인증되지 않은 네트워크 연결 가능 도구 실행 엔드포인트입니다. 폭발 반경은 다음과 같습니다 등록된 도구의 기능 파일/셸/코드 실행 도구를 사용하면 이것이 RCE입니다. 원산지 없음 확인해 보면, 피해자가 단지 방문하는 악성 페이지는 호스트 이름을 127.0.0.1에 다시 바인딩하고 다음을 발행할 수 있습니다. JSON-RPC는 개발자의 로컬 서버에 대해 교차 출처를 호출합니다.

개념 증명: 정적 증명(수정되지 않은 소스의 AST 분석): 확인 1 - run_sse(host='0.0.0.0'); launch_tools_mcp_server(host='0.0.0.0') -> 노출됨 확인 2 - Starlette(...) kwargs: ['debug','routes'] -> 미들웨어 없음= (인증/원본 게이트 없음) 확인 3 - is_valid_origin / is_potential_dns_rebound / verify_auth_header / SecurityConfig 어떤 전송 수단으로도 호출되지 않음 -> DEAD CODE 실행 중인 서버에 대한 실시간 공격: 컬 -N http://VICTIM:8080/sse

이벤트: 엔드포인트 / 데이터: /messages/?session_id=

컬 -X POST "http://VICTIM:8080/messages/?session_id=" -H 'Content-Type: application/json'
-d '{"jsonrpc":"2.0","id":1,"method":"초기화","params":{"protocolVersion":"2024-11-05", "capability":{},"clientInfo":{"name":"x","version":"1"}}}' 컬 -X POST "http://VICTIM:8080/messages/?session_id=" -H 'Content-Type: application/json'
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"","arguments":{...}}}' 어디에도 Authorization 헤더가 없습니다. 브라우저 DNS 리바인딩 변형은 교차 출처에서 동일한 호출을 유도합니다.

해결: 기존 mcp_security.py 컨트롤을 연결하고 기본값을 수정합니다.

• 기본 run_sse(host="127.0.0.1"); 0.0.0.0을 바인딩하려면 명시적인 선택이 필요합니다.
• is_valid_origin / is_potential_dns_rebind를 호출하는 Starlette 미들웨어를 연결합니다. 나쁜 기원을 거부하십시오.
• SecurityConfig.require_auth일 때 verify_auth_header를 적용합니다. 기본 require_auth=True(및 루프백이 아닌 바인드의 경우 Allow_missing_origin=False).

이전 권고와 구별되는 점: 허용되는 MCP 권고는 도구 처리기 버그입니다. 도구/호출 경로 탐색 -> .pth RCE (GHSA-9mqq-jqxf-grvw) 및workflow.show/validate (GHSA-9cr9-25q5-8prj)를 통해 읽은 인증되지 않은 파일입니다. 이는 인증/노출이 누락된 전송 계층입니다. SSE 서버는 인증 또는 Origin 검증을 시행하지 않습니다. 코드베이스가 제공하는 보안 모듈을 무시합니다. 기본적으로 안전하지 않은 패턴에 정신적으로 가장 가깝습니다. (GHSA-8444 / 86qc) 그러나 다른 서버와 다른 근본 원인(설정되지 않은 환경 변수가 아닌 연결되지 않은 컨트롤)입니다.