서론
지난 기사(허니팟에 오는 'AI 관련' 공격)에서는 'AI 크롤러'를 사칭하는 통신의 6할이 탐색 목적이며, 소수의 Google Cloud IP가 수십 가지 종류의 AI 크롤러 이름을 재사용하고 있다고 작성했습니다.
그 탐색 내용을 자세히 살펴보던 중, 생소한 경로가 있었습니다.
POST /api/designer/v1/file-content
{"file_path":"/proc/self/environ"}
조사해 보니, **TEN Framework라는 AI 에이전트(음성 대화 등)를 만들기 위한 프레임워크의 개발용 도구 취약점(CVE-2026-85688)**을 노린 것이었습니다. 이 취약점은 2026년 9월 4일에 CVE로 공개되었으며, 제가 조사했을 당시의 공개 정보에서는 '악용 보고 없음'으로 되어 있었습니다. 게다가 2026년 10월 30일 기준으로 수정 버전은 아직 나오지 않았습니다.
결론부터 말씀드리자면, 다음 세 가지입니다.
이 취약점에 대한 탐색 시도는 CVE 공개 후 13일 뒤(9월 17일)에 허니팟으로 들어왔습니다. 한 달 동안 707건, 발신지는 51개의 IP였으며, 모두 Google Cloud의 IP였습니다.
- 목표는 파일의 '읽기'였고, 읽으려고 시도한 것은 단 두 가지뿐이었습니다. 프로세스의 환경 변수(
/proc/self/environ)와 .env입니다. 즉, **비밀 정보(API 키 등)**를 노린 것입니다.
- 이는 단독 공격이 아니라, 지난번 'AI 크롤러를 사칭하는 탐색'에서 사용된 어휘 목록의 한 줄에 불과했습니다. 같은 IP들은 같은 기간 동안 약 11만 8천 건의 요청을 보냈으며, TEN을 노린 것은 그중 0.6%였습니다.
TEN Framework와 CVE-2026-85688
TEN Framework는 실시간 음성/영상 데이터를 다루는 AI 에이전트를 만들기 위한 오픈소스 프레임워크입니다. 이 안에는 TMAN Designer라는, 에이전트 구성을 브라우저에서 편집하는 개발용 도구가 있습니다.
공식 절차에 따르면 TMAN Designer는 시작할 때 다음과 같이 표시됩니다.
Starting server at http://0.0.0.0:49483
모든 네트워크 인터페이스(0.0.0.0)의 49483번에서 대기하는 것이 초기 설정입니다.
CVE-2026-85688은 이 TMAN Designer의 파일 내용을 읽고 쓰는 API(/api/designer/v1/file-content)에 인증이 없다는 취약점입니다(VulnCheck 공개 정보 기준).
| 항목 | 내용 |
|---|
| 대상 | TEN Framework 0.11.71 이전의 TMAN Designer (공개 정보 기재).⚠실제로는 최신 버전인 0.11.74에서도 동일 (아래) |
| ... | 없음 (2026-10-30 시점) |
수정 버전은 아직 나오지 않았다
공개 정보의 대상은 '0.11.71 이전'이지만, GitHub에서 확인해 보면 그 이후에 나온 0.11.72(9월 18일), 0.11.73(9월 22일), 0.11.74(10월 21일)에서도 개발 중인 main 브랜치에서도, 문제의 코드는 0.11.71과 완전히 동일했습니다. 파일 읽기 처리는 전송된 경로를 그대로 열어 사용합니다.
// core/src/ten_manager/src/designer/file_content/mod.rs (0.11.74・main과도 동일)
match fs::read_to_string(&file_path) { // 전송된 경로를 그대로 읽음
...
...
보고된 issue는 2026년 6월 12일에 생성된 채 open 상태이며, 댓글도 없습니다. 즉, 취약점의 내용(어떤 파일의 몇 번째 줄인지)은 6월부터 누구나 볼 수 있는 상태였고, CVE가 나온 것은 9월이고, 수정은 아직 이루어지지 않은 순서입니다.
개발용 도구이므로 본래는 인터넷에 공개할 것이 아닙니다. 다만, 초기 설정이 모든 인터페이스에서 대기하기 때문에 클라우드의 VM 등에서 구동하면 그대로 외부로부터 전달될 수 있습니다.
무엇이 오고 있었나
HTTPS를 수신하는 웹 하니팟(H0neytr4p) 기록을 집계했습니다. 기간은 8월 1일부터 10월 29일까지입니다.
| 항목 | 값 |
|---|
| 건수 | 707건 (모두 POST=읽기) |
| 최초 | 2026-09-17 10:47 (CVE 공개 13일 후) |
| 마지막 | 2026-10-15 |
| 송신원 | 51 IP, 모두 Google LLC의 AS |
| 표방한 User-Agent | 41종 (모두 AI 크롤러/어시스턴트 또는 검색 엔진 이름) |
| 본문 | {"file_path":"/proc/self/environ"}가 362건, {"file_path":".env"}가 345건. 이 두 가지만 |
일별 건수는 여러 개의 봉우리(피크)를 보였습니다.
처음 2건은 다음과 같은 형태였습니다 (1초 차이의 동일 IP).
09-17 10:47:10 136[.]109[.]234[.]57 UA: PanguBot/1.0 {"file_path":"/proc/self/environ"}
09-17 10:47:11 136[.]109[.]234[.]57 UA: DeepSeekBot/1.0 {"file_path":".env"}
1초 사이에 표방하는 이름이 Huawei Cloud의 크롤러에서 DeepSeek의 크롤러로 바뀌고 있습니다. 이는 이전 기사에서 언급했던 '이름 재활용' 그 자체입니다.
표방한 이름은 Claude-SearchBot, Claude-User, ClaudeBot, ChatGPT-User, GPTBot, OAI-SearchBot, GrokBot, PerplexityBot, Perplexity-User, DeepSeekBot, Qwenbot, KimiBot, MoonshotBot, MistralAI-User, Meta-ExternalAgent, Googlebot, Google-Extended, Bytespider, Amazonbot, CCBot 등 41종이었습니다. 대부분은 20~30건씩으로 특정 이름에 치우치지 않았습니다. 실제 크롤러가 타인의 서버의 /proc/self/environ을 POST 방식으로 읽으러 오는 일은 없습니다.
왜 '환경 변수'와 '.env'인가
AI 에이전트를 구동하는 서버에는 LLM이나 음성 인식 등 외부 서비스의 API 키가 많이 배치됩니다. 이러한 키들은 환경 변수(environment variable)나 .env 파일로 전달하는 방식이 일반적입니다.
/proc/self/environ은 해당 프로세스의 환경 변수가 그대로 들어있는 파일입니다. 만약 파일 읽기 취약점이 있다면, 단 한 번의 요청으로 API 키를 일괄적으로 탈취할 가능성이 있습니다. 쓰기(코드 실행)까지 시도하지 않고, 읽기 두 가지에만 국한하고 있는 것은 '열쇠를 획득하는 것'이 목적의 탐색이기 때문이라고 생각합니다 (추측입니다).
같은 IP들은 다른 무엇을 하고 있었나
TEN을 노린 51개 IP가 같은 기간(9월 15일~10월 16일)에 보낸 요청을 모두 합산하면 117,772건이었습니다. TEN을 노린 것은 707건으로, **0.6%**에 불과합니다.
상위 경로를 분류하면 다음과 같습니다.
| 유형 | 예시 |
|---|
| AI/ML 계열 앱의 파일 읽기 및 코드 실행 | /read-document ・/feast/read-document (Feast = ML 특성 저장소・CVE-2026-23536), /api/v1/node-load-method/customMCP (Flowise), /api/v1/validate/code (Langflow), /api/designer/v1/file-content (TEN) |
| 개발용 서버의 취약점 | /@fs/…/.env?raw?? (Vite), /_debugbar/open ・/telescope/requests (Laravel), /actuator/* (Spring Boot), /debug/vars (Go), /functionRouter |
| 비밀 파일 자체 | .env의 변종(예: .env.bak ・.env.prod), .npmrc, firebase-adminsdk.json, /@fs/home/ubuntu/.aws/credentials?raw?? |
| 오래된 알려진 취약점 | PHP-CGI 인자 주입(/php-cgi/php-cgi.exe?%AD… ) |
Feast의 /read-document
(1,344건) 중 본문은 TEN과 완전히 동일한 2가지 유형(/proc/self/environ와 .env)이었으며, 모두 Google Cloud의 IP에서 발생했습니다.
즉, TEN의 취약점은 'AI 앱이나 개발 도구에서 파일을 읽을 수 있는 구멍'을 모아놓은 어휘 목록에 공개된 지 2주도 되지 않아 추가되었다고 보는 것이 자연스럽습니다.
초기 포트는 노려지지 않았다
TMAN Designer의 초기 포트는 49483입니다. 만약 TEN만을 전문적으로 겨냥하는 공격자라면, 이 포트를 찾아올 것입니다.
하지만 하니팟에 도착한 49483번으로의 연결은 8월 이후로 465건・27개 IP였으며, 월별로는 8월 294 → 9월 113 → 10월 58로, 공개된 후에 오히려 줄어들었습니다. 평소 포트 스캔의 일부에 불과합니다.
TEN을 겨냥한 707건은 모두 HTTPS(443번)에서, 모두 도메인 이름 대상이었습니다. IP 주소를 직접 지정한 요청은 0건입니다.
이러한 탐색은 'TEN이 구동되는 서버'를 찾고 있는 것이 아니라, '도메인 이름의 웹 서버'에 가지고 있는 어휘 목록을 순차적으로 던지고 있다고 생각합니다. 리버스 프록시 뒤에 개발용 도구를 그대로 두고 있다면, 초기 포트를 닫아 놓았더라도 감지될 수 있습니다.
일반적인 보도와의 관계
'AI 크롤러를 사칭하여 인증 정보를 찾는' 움직임은 2026년 여름부터 가을에 걸쳐 여러 회사에서 보고되었습니다.
| 보고 | 시기 | 내용 |
|---|
| GreyNoise | 2026-07-28~08-23 | AI 관련 13개의 이름을 사칭하는 스캐너・824 IP・/.env ・/.aws/credentials |
| Fastly 'AI Bot Cosplay' | 2026-09-23 (1일분) | 약 630만 건・약 1만 IP. 약 1,600 IP가 94%를 차지하며 거의 전부가 하나의 퍼블릭 클라우드에서 발생했습니다. 대다수 IP는 약 12종의 AI 봇 이름을 순환시키고・96개의 공통 어휘・/@fs/.env (Vite) |
| Cequence (Hackread 기사) | 2026-09 하순~10 하순 | 몇 초 만에 다른 회사의 봇 이름으로 전환・하루 300을 넘는 클라우드 IP |
저의 관찰은 **하나의 클라우드에서 발생하는 IP, 이름 순환 방식, 어휘(.env ・Vite의 /@fs/)**가 자주 일치한다는 점입니다. Fastly 데이터의 날짜(9월 23일)는 이전 기사에서 언급한 '9월 하순부터 하나의 IP가 다수의 이름을 재사용하게 된' 시기와도 겹칩니다.
다만, 어떤 보고도 '어떤 취약점의 어휘가 포함되었는지'에 대한 세부 사항이나 IP 등의 흔적은 공개하지 않았습니다. TEN Framework의 취약점이 노려지고 있었다는 것은 제가 조사한 범위 내에서는 보도된 바가 없었습니다.
CVE-2026-85688 자체도 2026년 10월 30일 기준으로 미국 CISA의 '악용이 확인된 취약점' 목록(KEV, 10월 28일 버전)에 올라와 있지 않으며, 취약점 정보 사이트에서도 '악용 미확인'으로 되어 있습니다. 향후 30일간 악용될 확률 추정치(EPSS)는 2.6% (10월 29일 기준, 전체 CVE 상위 15% 수준)였습니다.
한편, 취약점 스캐너 Nuclei의 공식 템플릿 모음에는 이 취약점을 조사하는 템플릿이 10월 19일에 추가되었습니다. 내용을 살펴보면, 전송되는 것은 {"file_path":"/etc/passwd"}이며, 이는 단순히 '읽을 수 있는지'를 확인하는 용도입니다.
| Nuclei 공식 템플릿 | 허니팟으로 도착한 요청 | |
| :--- | :--- |
| 전송 본문: /etc/passwd (읽기 가능 여부 확인) | /proc/self/environ 및 .env (비밀 정보) | |
| 시기: 10월 19일 추가 | 9월 17일부터 |
즉, 허니팟에 도착한 것은 '공개된 검사 템플릿으로 조사한' 것이 아닙니다. 검사 템플릿이 공개되기 한 달 전부터, 처음부터 키를 탈취하는 본문으로 시도했던 것입니다.
귀속에 관하여: 말할 수 있는 것/말할 수 없는 것
말할 수 있는 것
- 2026년 9월 17일부터 10월 15일까지,
/api/designer/v1/file-content에 /proc/self/environ과 .env를 읽으려는 POST 요청이 707건 도착했습니다. - 전송원 IP 51개는 기록 시점 모두 Google LLC의 AS였습니다.
- 동일한 IP들은 AI/ML 계열 앱, 개발용 서버, 비밀 파일을 노리는 요청을 총 11만 8천 건 보냈습니다.
- 명시된 User-Agent는 41종류의 AI 크롤러 및 검색 엔진 이름이었으며, 1초 단위로 바뀌기도 했습니다.
말할 수 없는 것
- 공격이 성공했는지 여부. 허니팟은 TEN Framework를 구동하고 있지 않습니다. 도착한 것은 '시도'입니다. -
- 누가 수행했는지. 클라우드 IP는 빌리고 반납할 수 있기 때문에, 그 시점의 사용자가 누구인지는 알 수 없습니다. 'Google이 했다'는 의미가 아닙니다. -
- 명시된 이름이 진짜인지 여부. 각 사가 공개하는 IP 범위와 대조하지 않았습니다 (다만, 실제 크롤러가 타인의 환경 변수를 POST로 읽으러 오는 일은 없기 때문에, 이름 위장으로 간주합니다). -
- 보도된 활동과 같은 공격자인지 여부. 수법과 시기는 유사하지만, 흔적이 공개되지 않아 대조할 수 없습니다. -
- '세상에서 악용되고 있지 않은지' 여부. 공개 정보에 '악용 보고 없음'이라고 해도, 그것은 '보고되지 않았다'는 것일 뿐입니다. 이번 관측 역시 악용의 성공이 아니라 시도의 관측입니다.
방어자로서 할 수 있는 것
- TMAN Designer와 같은 개발용 도구를 인터넷에 노출하지 않습니다. 초기 설정은
0.0.0.0이므로, 시작할 때 대기하는 주소를 127.0.0.1로 제한하거나 방화벽으로 닫습니다. -
- 리버스 프록시 뒤에 두지 않습니다. 이번 탐색은 초기 포트가 아닌, 도메인 이름의 443번으로 왔습니다. '포트를 닫았으니 괜찮다'고 할 수 없습니다. -
- TEN Framework를 사용한다면, 버전을 올려도 해결되지 않을 수 있음에 주의합니다 (2026년 10월 30일 기준으로 수정 버전 없음). TMAN Designer는 사용할 때만 구동하고 대기하는 주소를 제한합니다.
--ip 옵션으로 지정할 수 있습니다 (초기값은 0.0.0.0). 떨어진 곳에서 사용할 경우, SSH의 포트 포워딩 등을 통해 127.0.0.1로 접속합니다. 수정 버전이 나왔는지 여부는 GitHub의 issue #2187과 릴리스를 통해 확인하십시오. tman designer --ip 127.0.0.1
- 비밀 정보가 유출된다는 전제하에 생각합니다. 파일을 읽을 수 있는 구멍이 하나만 있어도,
/proc/self/environ과 .env에서 API 키를 한 번에 가져갈 수 있습니다. 키의 권한은 필요 최소한으로 줄이고, 사용하지 않는 키는 삭제합니다. -
- 로그로 찾습니다.
POST /api/designer/v1/file-content, 본문에 file_path
/proc/self/environ을 포함하는 요청은 거의 확실하게 스캐닝(탐지 시도)입니다.
"AI 크롤러"라는 이름만으로 신뢰하지 마십시오. 이름은 쉽게 위장됩니다. 허용할 경우, 각 사가 공개한 IP 범위와 대조해야 합니다.
IoC
공격 출처 IP(모두 Google LLC의 AS 및 기록 시점 기준 상위 10개).
| IP | 건수 |
|---|
| 34[.]182[.]241[.]223 | 237 |
| ... | |
| 요청 형태. | |
POST /api/designer/v1/file-content
Content-Type: application/json
{"file_path":"/proc/self/environ"}
...
동일한 본문이 /read-document, 그리고 /feast/read-document (Feast)에도 전송되었습니다.
맺음말
'악용 보고 없음'이라고 쓰여 있고 수정 버전도 나오지 않은 취약점에, 허니팟에는 CVE 공개 후 2주가 채 지나지 않아 스캐닝이 들어왔습니다. 다만, 그것은 TEN Framework만을 전문적으로 노리는 누군가가 아니라, AI 크롤러를 사칭하는 대규모 스캐너가 어휘 목록에 한 줄 추가했을 뿐이었습니다.
AI 앱이나 AI 에이전트의 기반에는 새로운 취약점이 연이어 공개되고 있습니다. 그리고 그 기반에는 API 키가 모여 있습니다. 파일을 읽을 수 있는 구멍은 그대로 '열쇠를 모으는 구멍'이 되기 때문에, 찾는 쪽에서는 새로운 구멍을 즉시 어휘 목록에 추가한다고 생각합니다.
개발용 도구는 외부에 노출하지 말아야 합니다. 한번 내보내 버리면, '포트가 다르니까', '아무도 모르는 도구니까'라는 것은 안전의 이유가 될 수 없다는 것이 이번 관측을 통해 알 수 있는 점입니다.
출처
논의
