HAgent MCP 도구의 OS 명령 삽입(CVE-2026-117573): hagent_arduino·hagent_esp32 점검 포인트

도구를 호출할 수 있는 클라이언트가 서버의 셸에 들어가는 입력을 결정하는 구조라면, 그 클라이언트의 입력은 사실상 서버의 셸 입력이 됩니다. HAgent의 Arduino·ESP32 MCP 도구에서 보고된 CVE-2026-117573은 바로 그 지점을 겨냥하는 OS 명령 삽입 취약점입니다.

개요

CVE Project / VulnCheck CNA가 등록한 CVE-2026-117573은 취약 대상의 범위를 hagent through commit 761eec6으로 지정한 OS 명령 삽입 취약점입니다. MCP 클라이언트가 hagent_arduino 또는 hagent_esp32 도구의 args 파라미터에 셸 메타문자를 주입하면 셸 명령을 실행할 수 있다는 것이 골자입니다.

GitHub 보안 이슈 #98은 원인을 CWE-78, 즉 사용자가 제공한 args가 셸 명령 문자열에 그대로 삽입된 뒤 shell=True로 실행되는 구조로 기술합니다. 두 근거는 서로 다른 층위, 곧 취약점 식별자와 코드 수준 원인에서 같은 문제를 가리키므로, 이번 사례는 코드 경로 자체가 확인된 유형으로 보는 것이 타당합니다.

영향 범위

제공된 근거가 지지하는 영향 범위는 다음입니다.

• CVE 레코드가 취약 대상으로 지정한 hagent through commit 761eec6
• hagent_arduino MCP 도구
• hagent_esp32 MCP 도구
• 취약한 도구를 호출할 수 있는 MCP 클라이언트(잠재적 공격 주체)

여기서 범위는 근거가 사용한 표현 그대로 옮겼습니다. 제공된 근거는 hagent through commit 761eec6이라는 표현 자체만 사용하고, 커밋 순서상 특정 구간 전체가 취약하다는 추가 설명은 담고 있지 않으므로 이 문서는 원문 표현 이상의 범위 해석을 덧붙이지 않습니다.

영향의 크기는 도구 자체가 아니라 hagent 서버가 어떤 권한으로 동작하는가에서 갈립니다. MCP 클라이언트 측의 입력이 hagent 서버 프로세스 권한의 셸 명령 실행으로 이어지기 때문에, 결과적으로 서버가 동작하는 호스트가 접근할 수 있는 자격증명·파일·개발 도구가 침해 반경에 들어갑니다.

여기서는 조건부 해석과 근거 범위를 구분할 필요가 있습니다. 에이전트가 신뢰할 수 없는 콘텐츠에 노출되어 프롬프트 주입 등으로 도구 호출을 유도받을 수 있는 환경이라면, hagent_arduino·hagent_esp32를 호출할 수 있는지는 곧 간접 명령 실행 통로의 유무가 됩니다. 반대로 취약한 도구에 도달하는 호출 경로가 없으면 args를 통한 명령 실행은 성립하지 않습니다. 다만 제공된 근거는 환경 간 위험의 크기를 정량적이나 비교 가능한 방식으로 평가하지 않으므로, 어느 환경에서 위험이 얼마나 줄어든다는 식의 결론은 이 문서의 범위에서 제외합니다. 근거로 확인할 수 있는 조건은 공격 성립의 전제인 취약 도구 호출 가능 여부 그 자체입니다.

기술적 분석

동작 순서로 추적하면 공격 경로는 MCP 클라이언트의 도구 호출, 도구의 args 파라미터, 셸 명령 실행으로 이어집니다.

핵심은 args 전달과 셸 실행 사이입니다. 사용자가 제공한 args가 셸 명령 문자열에 검증, 즉 살균 없이 문자열 보간으로 이어 붙여지고, 그 문자열이 subprocess.run(..., shell=True) 또는 subprocess.Popen(..., shell=True)로 전달됩니다. shell=True는 문자열을 셸 구문으로 해석하라는 지시이므로, 인자 안에 세미콜론·백틱·$()·파이프 같은 메타문자가 포함되면 이들은 데이터가 아니라 제어 문자로 처리되고, 개발자가 의도한 명령에 공격자가 의도한 추가 명령이 덧붙여집니다.

근거가 확인하는 코드 구조는 여기까지입니다. GitHub 보안 이슈 #98는 hagent_arduino와 hagent_esp32 MCP 도구에서 복수의 명령 삽입 취약점이 존재하며, 사용자가 제공한 args가 셸 명령 문자열에 직접 삽입된 뒤 shell=True로 실행된다고 보고합니다. 즉 원인은 값이 셸로 전달되는 경로 그 자체이며, 여기가 이번 취약점을 이해하고 점검할 때 출발점으로 삼을 수 있는 확인된 사실입니다.

심각도의 경우 출처마다 전제가 다릅니다. CVE-2026-117573 공식 레코드는 이 취약점을 CVSS 3.1 7.8(AV:L/PR:L) 및 CVSS 4.0 8.5(LOCAL, PR:LOW)로 산정합니다. 한편 GitHub 보안 이슈 #98 쪽의 주장으로 제시된 값은 CVSS 3.1 9.8(AV:N/PR:N)으로, 두 출처의 산정이 서로 일치하지 않습니다. 차이가 갈리는 지점은 점수가 아니라 벡터입니다. 공식 산정은 로컬 접근과 낮은 권한을 전제로 하는 반면, 이슈 측 주장은 네트워크 원격 접근과 권한 불요를 상정합니다. 다시 말해 원격 무권한 침입으로 볼 것인지, 도구 호출 자격을 이미 가진 상태에서 추가 명령을 붙이는 문제로 볼 것인지에 대해 출처가 갈립니다.

이 어긋남은 점검 순서를 정할 때 의미가 있습니다. 공식 레코드 기준으로 AV:L/PR:L 전제가 성립한다고 보면, 공격 성립의 관문은 취약한 args 코드 경로에만 있지 않고 그 경로에 도달할 수 있는 클라이언트 자격과 접근 범위에 있습니다. 반대로 네트워크 벡터를 전제한 더 높은 산정을 그대로 받아들이면 접근 통제만으로는 부족하고 코드 수정 전까지 노출 중단이 최우선이 됩니다. 이 문서는 확인 가능한 공식 산정인 CVE 레코드의 로컬·저권한 전제를 기준으로 삼되, 도달 자격의 폭을 좁히는 조치를 공통의 첫 단계로 봅니다. 이는 점수를 재해석하는 결론이 아니라, 두 산정이 공통으로 요구하는 전제 조건을 따라간 조건부 판단입니다.

공개 PoC·익스플로잇 분석

• 출처: 이번 판단에 쓸 수 있는 공개 근거는 두 건입니다. CVE-2026-117573 레코드는 MCP 클라이언트가 hagent_arduino 도구의 args 파라미터에 셸 메타문자를 주입해 셸 명령을 실행할 수 있다고 기록하고, 위 CVSS 3.1 및 CVSS 4.0 공식 산정과 벡터를 함께 담고 있습니다. GitHub 보안 이슈 #98은 같은 문제를 CWE-78로 특정하고, hagent_arduino와 hagent_esp32 양쪽에서 사용자가 제공한 args가 셸 명령 문자열에 직접 보간된 뒤 subprocess.run(..., shell=True) 또는 subprocess.Popen(..., shell=True)로 실행된다고 코드 수준에서 기술합니다. 공개되어 검증 가능한 것은 취약점 식별자와 원인 코드의 위치·형태, 그리고 출처별로 다른 심각도 산정입니다.
• 전제조건: 성립 조건은 근거에서 도출되는 범위 안에서 명확합니다. 대상이 CVE 레코드가 지정한 hagent through commit 761eec6에 해당해야 하고, 호출자가 hagent_arduino 또는 hagent_esp32 도구에 실제로 접근할 수 있어야 하며, args 값이 살균 없이 셸 문자열에 합쳐진 뒤 shell=True로 실행되는 코드 경로를 지나야 합니다. 다시 말해 성립의 관문은 코드 결함만으로 정해지지 않고, 취약한 도구를 호출할 수 있는 클라이언트 자리가 확보되는지에 달려 있습니다. 이 자리가 없으면 같은 코드라도 명령 실행으로 연결되지 않습니다. 공식 산정의 AV:L/PR:L 벡터도 이 접근·권한 전제와 같은 축에 있습니다.
• 입증 범위: 공개 근거가 입증하는 것은 메타문자를 포함한 입력이 셸 구문으로 해석되어 추가 명령이 실행된다는 메커니즘과, CVE 레코드가 담은 공식 심각도 산정(CVSS 3.1 7.8, CVSS 4.0 8.5)까지입니다. 반면 실제 야생 공격 관측 증거는 제공된 근거에 없고, CISA KEV 등 정부 취약점 카탈로그 등재 여부도 확인하지 못했습니다. 별도 PoC 저장소나 완전 동작하는 익스플로잇 코드의 존재 여부, 그리고 hagent through commit 761eec6으로 표시된 범위를 다루는 수정본의 존재 여부와 수정 커밋 또는 릴리스 식별자 역시 이번 근거 범위에서는 확인하지 못했습니다. GitHub 이슈의 CVSS 3.1 9.8 주장과 공식 레코드 산정 중 어느 쪽이 실환경에 맞는지에 대한 판정도 이번 근거로는 불가능합니다. 이 영역은 단정하지 않고 한계로 남깁니다.
• 운영상 의미: 원인이 된 코드의 위치와 형태, 메타문자 주입 경로가 문서로 공개되어 있어 재현 방법을 유추하기 쉬운 상태라는 것이 근거가 말하는 범위이고, 실제 악용 사례는 미확인입니다. 따라서 이 취약점에서 시급함을 가르는 판단 근거는 공격 관측 뉴스가 아니라 내 환경에 취약한 도구를 호출할 수 있는 클라이언트가 있는지, 그리고 호출이 성공했을 때 서버 프로세스 권한으로 도달 가능한 범위가 어디까지인지입니다. 두 도구를 사용하는 MCP 서버에 신뢰되지 않거나 자동화된 클라이언트가 접속할 수 있다면, 도구 노출과 호출 접근 범위를 먼저 좁히는 것이 확인된 사실에 맞는 대응입니다.

한계를 정리하면 다음입니다. hagent through commit 761eec6으로 표시된 범위를 다루는 수정본이 존재하는지, 그리고 그 수정 커밋 번호나 릴리스 버전·정확한 패치 방식은 제공된 근거에서 확인하지 못했고, CISA KEV 등 정부 취약점 카탈로그 등재 여부나 실제 야생 공격 관측 증거도 근거에 없습니다. 심각도는 CVE 레코드의 공식 산정과 GitHub 이슈의 주장이 벡터 전제에서 갈려 하나의 수치로 정리할 수 없습니다. 그래서 이 문서의 우선순위 설명은 공격 관측 여부나 단일 점수가 아니라, 취약한 도구를 호출할 수 있는 클라이언트 접근 조건과 명령 실행 성공 시 서버 프로세스 권한으로 미치는 영향 범위라는 두 가지 확인 가능한 축으로 좁힙니다. 구체적인 로그 포맷·탐지 시그니처·IOC도 제공된 근거에 포함되어 있지 않아, 이 문서는 로그 점검이나 프로세스 계보 추적 같은 탐지·조사 절차는 제시하지 않습니다.

대응 방안

즉시 적용

수정 버전 식별자가 확인되지 않은 상태에서는 업그레이드 확인만 기다리기보다, 도구에 도달 가능한 호출 경로 자체를 먼저 좁혀 보는 것이 검토할 만한 순서입니다.

• hagent_arduino, hagent_esp32를 사용 중이라면 해당 MCP 도구의 노출을 중단하거나, 접근 가능한 MCP 클라이언트를 신뢰된 대상으로 제한합니다.
• 두 도구가 MCP 서버에 실제로 등록·노출되어 있는지, 어떤 클라이언트가 이 도구를 호출할 수 있는 상태로 남아 있는지부터 확인합니다. 명령 실행은 취약한 도구를 호출할 수 있다는 전제 위에서 성립하므로, 이 확인이 후속 판단의 출발점이 됩니다.
• 실행 중인 hagent가 CVE 레코드가 지정한 hagent through commit 761eec6으로 식별되는 배포인지 확인합니다. 제공된 근거가 다루는 범위는 이 표현까지이므로, 이를 벗어나는 배포에 대한 결론은 이 문서에서는 내리지 않습니다.
• hagent 실행 계정의 권한을 최소화해, 명령 실행이 성사되더라도 도달 가능한 자격증명·파일 범위를 줄입니다. 이 권고는 명령이 hagent 서버 프로세스 권한으로 실행된다는 확인된 영향에서 도출된 조건부 조치입니다.

구조적 대응

• hagent through commit 761eec6으로 표시된 범위를 다루는 수정본이 제공되었는지 벤더 정보를 통해 확인하고, 식별자가 확인되면 업그레이드를 검토합니다. 현재 근거로는 해당 커밋 또는 릴리스 식별자를 확인하지 못했습니다.
• 코드 수준의 방향은 원인 기술의 반대편에 있습니다. args를 문자열 보간 없이 배열 인자로 subprocess에 전달하고 shell=True를 제거하는 형태로, 저장소에 보고된 원인을 그대로 되돌리는 수정입니다.
• MCP 서버 접근 통제를 상시화합니다. 클라이언트 신원·권한 검증과 도구별 호출 승인 정책은 이 취약점 하나에 국한된 조치가 아니라, 도구 호출이 명령 실행 표면이 되는 자리 자체를 줄이는 일반 방어선입니다. 공식 CVE 레코드의 산정이 로컬 접근·저권한을 전제로 한다는 점에서, 호출 자격과 범위에 대한 통제는 점수 해석과 무관하게 유효한 대응선입니다.

우선순위를 판단하는 기준

실용적인 점검은 다음 질문에서 출발합니다.

• 두 도구를 실제로 등록해 사용하는 MCP 서버가 동작 중인가.
• 그 서버에 신뢰되지 않거나 에이전트가 대리 호출하는 형태의 클라이언트가 접속할 수 있는가.
• hagent 실행 계정이 호스트에서 넓은 권한을 갖고 있는가.
• 공식 산정이 전제하는 로컬 접근·낮은 권한 조건이 내 환경에서는 어떤 자격과 일치하는가.

이 답변에 따라 검토의 초점이 달라질 수 있습니다. 다만 제공된 근거는 특정 배포 환경에서 코드 개정 추적만으로도 충분하다는 판단을 뒷받침하지 않습니다. 실제 대응 수준은 접근 가능 클라이언트 범위, hagent 실행 계정의 권한, 조직의 위험 허용도를 함께 보고 개별적으로 결정해야 합니다.

참고자료

• CVE-2026-117573: hagent through commit 761eec6 OS Command Injection via Arduino and ESP32 MCP Tools
• [Security] CWE-78: OS Command Injection in Arduino and ESP32 MCP Tools via Unsanitized args + shell=True

함께 읽으면 좋은 글

• Kali-GPT MCP 서버의 OS 명령 삽입(CVE-2026-117569): execute_tool() 경로의 입력 검증 공백과 점검 포인트
• Z.ai Zcode Sed Command Filter OS 명령 주입(CVE-2026-116118) 점검
• Continue 2.0.0 MCP Server Transport 명령 주입(CVE-2026-116109): CVE 기록으로 확인되는 범위와 점검 순서

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