Gonnector 인사이트 - 2026년 10월 두 보안 이슈와 Gonnector AI 팀의 점검, 대응을 보안을 잘 몰라도 읽을 수 있게 풀어 쓴 해설입니다. ← gonnector.com 홈2026년 10월에 나온 두 가지 보안 소식이 무엇이고, Gonnector가 이를 어떻게 점검하고 대응했는지를 보안 비전문가도 읽을 수 있게 풀어 쓴 문서입니다.
Dylan (고영혁, Gonnector 대표)이 공유한 두 링크 중 "Python 관련 정보"는 Python 재단(PSF)이 eMudhra 인증서 사고를 Python 사용자에게 알린 공지였습니다. 즉 Python 이슈의 정체가 인증서 사고였고, PHP 사건과는 원인이 전혀 다릅니다.
무엇이 고장났나: PHP라는 웹 프로그래밍 언어의 엔진 자체에 구멍이 있어서, 로그인 없이도 서버를 장악할 수 있습니다.
누가 영향받나: PHP로 웹사이트를 운영하는 곳(WordPress 등).
취약점 번호: CVE-2026-109618, CVE-2026-109619
해결: 2026-10-21에 나온 수정 버전(8.2.35 / 8.3.36 / 8.4.27 / 8.5.12)으로 올리고 서버를 재시작합니다. 8.1 이하는 수정 버전이 없습니다.
무엇이 고장났나: 인증기관 eMudhra가 쓰는 인증서 도장 8개가 너무 약하게 만들어져서, 누구나 그 도장을 복제해 가짜 인증서를 만들 수 있게 됐습니다.
누가 영향받나: HTTPS로 "상대가 진짜인가"를 확인하는 모든 프로그램. 언어와 상관없습니다.
해결: 프로그램마다 자기가 쓰는 신뢰 명단을 고쳐야 합니다(4장).
HTTPS 사이트에 접속하면 사이트는 신분증(인증서)을 내밉니다. 프로그램은 그 신분증에 찍힌 도장을 따라 위로 올라가서, 맨 위의 본부(루트 인증기관)가 자기가 가진 "믿을 만한 본부 명단"에 있는지를 봅니다. 명단에 있으면 진짜로 인정합니다.
여기서 중요한 점은 명단이 프로그램마다 따로 있다는 것입니다. Windows가 쓰는 명단, Python이 쓰는 명단, Git이 쓰는 명단이 각각 존재합니다. 이번 일을 이해하는 열쇠가 바로 이것입니다.
eMudhra(인도의 인증기관)가 2025년 4월에 만든 발급소 8곳의 도장(비밀 키)이 너무 단순하게 만들어졌습니다. 금고 비밀번호가 세 자리 숫자인 것과 비슷해서, 누구나 계산으로 도장을 복원할 수 있습니다. 2026-10-17에 신고됐고, 복원한 도장으로는 github.com, api.anthropic.com처럼 아무 사이트의 가짜 신분증을 만들 수 있습니다.
가짜 신분증이 통과하려면, 위조 도장을 보증해 준 본부가 내 명단에 있어야 합니다. 이번 발급소 8곳을 보증해 준 본부가 네 곳이고, 그중 두 곳이 핵심입니다.
사고를 일으킨 곳이 아니라 Sectigo(옛 Comodo)의 오래된 본부입니다. 그런데 eMudhra 발급소 8곳을 모두 보증해 줬기 때문에, 이 본부 하나만 믿어도 가짜가 통과할 수 있습니다. Firefox와 Chrome은 이미 명단에서 뺐지만 Microsoft의 Windows 명단에는 아직 들어 있습니다.
eMudhra 자신의 본부입니다. 중간 다리를 보증해 주면서 웹용 위조 발급소 6곳까지 길을 이어 줍니다. Python의 certifi 명단은 2026.10.18판에서 이 본부를 뺐고(권장판은 2026.10.19), Mozilla(Firefox)도 사고 후 신뢰를 거둔 것으로 알려져 있습니다.
Microsoft만 인정하는 eMudhra 본부 두 곳입니다. Windows는 필요할 때 이런 본부를 스스로 내려받아 명단에 넣기도 해서, 점검 중에 이 경로를 일부러 건드리지 않았습니다(8장).
요즘 PC와 노트북에는 명단이 하나가 아닙니다. 개발자가 아니어도 그렇습니다. AI 에이전트가 일을 하면서 아래 도구들을 스스로 설치해 쓰기 때문입니다(6장). 그래서 "Microsoft가 막았다"는 소식만으로는 끝나지 않습니다. Microsoft의 차단이 걸리는 것은 Windows 검증 엔진을 쓰는 프로그램뿐이고, 나머지 명단은 각자 고쳐야 합니다.
| 명단 | 누가 쓰나 | Windows 차단이 적용되나 | 고치는 방법 |
|---|---|---|---|
| Windows 본체 명단 | 브라우저 외 일반 Windows 앱 | 적용됨 | Microsoft 자동 갱신(2026-10-20 배포) |
| Python 표준 기능 | urllib 등 Python 기본 통신. AI 에이전트가 돌리는 스크립트도 많이 씀 | 적용 안 됨 | Python 전용 필터, 또는 CPython 차단 패치(아직 미출시) |
| pip 내장 명단 | 패키지 설치 도구 | 일부 | pip 26.2.2 이상 |
| certifi 명단 | requests 같은 라이브러리 | 적용 안 됨 | certifi 2026.10.19 이상 |
| uv 내장 명단 | Python 도구 관리자 uv. AI 에이전트용 도구 서버(MCP 서버)를 띄울 때 자주 쓰임 | 적용 안 됨 | uv 0.13.4 이상 |
| Git (Git for Windows, GitHub Desktop 내장 Git 등) | git push/pull (GitHub 로그인 정보가 오가는 길) | 설정에 따라 | OpenSSL 방식이면 적용 안 됨, Windows 방식(schannel)이면 적용됨. 쓰는 Git이 어느 쪽인지 확인하고 필요하면 schannel로 전환 |
| Node.js 내장 명단 | npx로 실행하는 MCP 서버 등 Node.js 프로그램 | 적용 안 됨 | 2026-10-20~21 보안 릴리스(22.23.4 / 24.22.1 / 26.12.1) 이상으로 업데이트. 이 릴리스에서 문제 본부가 빠짐 |
| WSL 리눅스 명단 | WSL 안의 리눅스 프로그램 | 적용 안 됨 | 배포판 ca-certificates 업데이트 |
은행에 비유하면 이렇습니다. Microsoft(은행)는 "도난 도장 8개" 목록을 받아 창구에 붙였습니다. 그런데 Python 표준 기능은 은행에서 "공인 본부 명단" 원본만 복사해 가고, "도난 도장 목록"은 가져가지 않습니다. 그래서 Windows 창구는 가짜를 거절하지만, Python 창구는 AAA와 ECC G3를 그대로 믿고 가짜를 통과시킵니다. 추측이 아니라 Python 소스 코드에서 직접 확인한 동작입니다.
Python 3.10 이상에서 돌아가는 pip 24.2 이상은 Windows 명단과 자기가 들고 다니는 명단을 합쳐서 믿습니다. 그래서 Windows 쪽이 막혀 있어도 자기 명단이 낡았으면 뚫립니다. 반대로 말하면, Windows 쪽은 이미 막혀 있으니 pip 자체만 업그레이드하면 pip 경로는 닫힙니다. 이 점은 TARS가 pip 소스를 읽어서 짚어 냈습니다.
| PHP2Shell | eMudhra 인증서 사고 | |
|---|---|---|
| 공격자 위치 | 인터넷 어디서나 | 통신 경로 위 (같은 Wi-Fi, 공유기, DNS) |
| 결과 | 서버 즉시 장악 | 통신 가로채기, 토큰 탈취, 다운로드 바꿔치기로 장악까지 가능 |
| 영향 범위 | PHP로 돌리는 서버만 | 언어와 무관, 자기 명단을 쓰는 모든 프로그램. AI 에이전트가 설치한 도구까지 포함해 개발자가 아닌 사람의 PC도 해당 |
| 끝나는 시점 | PHP 업그레이드로 끝 | 프로그램마다 명단을 따로 고쳐야 해서 오래감 |
| Gonnector | 확인한 범위에서 해당 없음 | 영향받는 프로그램 있었음, 주요 경로 조치 |
정리하면 PHP2Shell은 걸린 서버 하나하나에 치명적이고, 인증서 사고는 넓고 오래가는 문제입니다. PHP를 쓰지 않는 Gonnector에게는 인증서 사고가 실제로 더 큰 문제였습니다.
방향은 맞습니다. 다만 두 가지를 짚어야 정확합니다.
첫째, 해킹의 형태가 다릅니다. 이번 사고로 바로 생기는 일은 통신 가로채기(가짜 github.com, 가짜 PyPI로 위장)입니다. 그러나 가로챈 뒤에는 토큰과 키를 훔치거나, 지문을 고정하지 않은 설치와 업데이트에 악성 코드를 끼워 넣어 PC 장악까지 갈 수 있습니다. 이번 대응에서 pip과 certifi는 설치 파일의 지문을 고정하고, 다른 도구는 공식 체크섬과 서명을 대조한 이유가 이것입니다.
둘째, "문제 인증서를 쓰는 프로그램"이 아니라 "문제 본부를 믿는 프로그램"이 위험합니다. 같은 Python이나 Git이라도 상대를 어떻게 검증하느냐에 따라 결과가 갈립니다.
| 프로그램 | 검증 방식 | 이번 사고의 영향 |
|---|---|---|
| Git (Windows 방식 schannel로 설정) | Windows 검증 엔진 | 차단 적용됨 |
| Git (OpenSSL 방식으로 설정) | 자체 명단 | 영향받음 Windows 방식으로 전환하면 해결 |
| Python 표준 기능 (urllib 등) | Windows 명단을 복사해서 자체 검증 | 영향받음 필터 또는 CPython 패치 필요 |
| pip 24.2 이상 (Python 3.10 이상) | Windows 엔진 + 자체 명단 | 자체 명단 쪽이 영향받음 업그레이드로 해결 |
예전에는 Python, Git, uv 같은 도구가 주로 개발자의 PC에 있었습니다. 지금은 다릅니다. 코딩 도우미, 업무 자동화 에이전트, 에이전트가 불러 쓰는 도구 서버(MCP 서버)가 일을 하면서 필요한 도구를 스스로 설치하고 씁니다. 사용자는 Python을 몰라도, 매일 쓰는 AI 에이전트 덕분에 PC 안에 Python 환경이 여러 개 생깁니다.
그래서 이번 사고로 위험에 노출된 PC와 노트북은 "개발자 PC"라는 말로 짐작하는 것보다 훨씬 많을 것으로 봅니다(Gonnector의 판단). 이런 환경 변화를 누가 챙기느냐가 관건입니다. AI 에이전트를 쓰는 만큼, 에이전트가 만들어 둔 환경도 에이전트가 찾아내 점검하고 고쳐야 합니다. Gonnector는 이번에 AI 팀원 둘이 그 일을 나눠 맡았습니다(7장).
AI 에이전트를 쓰고 있다면, 그 에이전트에게 "이 PC에 있는 Python, pip, certifi, uv와 Git의 인증서 설정을 2026년 10월 eMudhra 인증서 사고 기준으로 점검해 줘"라고 요청하는 것부터 시작할 수 있습니다. 이때 에이전트가 자기가 설치한 환경과 앱 안에 들어 있는 Python까지 빠짐없이 찾는지, "0건" 같은 결과를 그대로 안전으로 믿지 않는지 확인하세요(8장).
Gonnector의 AI 팀원 둘이 역할을 나눴습니다. TARS가 만들고 TRON이 지키는 구조 그대로, 수집은 TARS, 판정 기준과 검수는 TRON이 맡았습니다. 판정 기준은 한 파일에만 두고 둘 다 그 파일을 읽게 해서, 둘의 판단이 서로 어긋나지 않게 했습니다.
| 층 | 무엇을 봤나 | 담당 | 결과 |
|---|---|---|---|
| 코드 저장소 (적혀 있는 상태) | 회사 GitHub 저장소와 로컬 저장소 전체의 설정 파일, Docker 파일, 인증서 파일 | TRON | 확인한 범위에서 이상 없음 PHP 사용 없음, 회사 자체 코드의 경고 없음 |
| 설치 상태 (실제 깔린 것) | 탐색한 위치의 Python 인터프리터와 가상환경, 인증서 명단 파일, Windows 저장소, Git, WSL, 컨테이너 이미지, Node.js | TARS | 영향 있음 4장 표의 "적용 안 됨" 항목들 → 주요 경로 조치 |
| 배포 환경 (서비스 중인 곳) | 배포 사이트와 CI | TARS | 확인한 범위에서 이상 없음 사이트에서 PHP/Python 실행 없음 |
보안 점검에서 가장 위험한 것은 "문제없다"는 거짓 결과입니다. 그래서 다음 장치를 넣었습니다.
사고 공개 사이트의 원본 파일에서 자동으로 뽑아 판정 기준을 만들었습니다. 지문 한 글자만 틀려도 판정 전체가 틀어지기 때문입니다.
일부러 위험한 파일과 안전한 파일을 섞은 시험용 저장소를 만들어 점검 도구가 맞게 판정하는지 먼저 확인했습니다. 이 과정에서 도구가 특정 형식의 인증서 파일을 못 읽는 빈틈을 찾아 고쳤습니다.
실제로 여러 번 있었습니다. 점검 도구가 인증서 저장소를 0건으로 읽거나, 어떤 Python이 명단을 0개로 읽거나, 명단 파일을 옮겨 오다 빈 파일이 되는 일이 있었습니다. 모두 겉보기에는 "안전"이었습니다. 그래서 0건이면 판정을 보류(UNKNOWN)하고, 명단이 아예 없는 경우는 따로 표시하도록 도구를 고쳤습니다.
점검하려고 꺼내 둔 위험 인증서와 시험용 파일이 "PC에서 발견된 위험"으로 다시 집계된 일이 있었습니다. 작업 폴더를 점검에서 빼고, 빼면 숫자가 얼마가 돼야 하는지 미리 계산한 뒤 다시 돌려 정확히 맞는지 확인했습니다.
시험 하나는 Windows가 위험한 본부를 스스로 내려받아 명단에 넣을 수 있어서 일부러 생략했습니다. 실행한 시험은 앞뒤로 인증서 저장소 8곳을 비교해 바뀐 것이 0건임을 확인했습니다.
"Windows가 막혀 있다"는 결론은 TRON의 차단 목록 원본 직접 확인, TARS의 별도 확인, 실제 검증 시험(Windows가 거절함) 세 가지가 모두 일치한 뒤에 확정했습니다. 수정본 pip과 certifi도 각자 다른 도구로 깨끗한지 확인했고, 설치할 파일의 지문은 PyPI에서 다시 받아 서로 맞춰 봤습니다.
필터를 넣을 자리에 기존 설정 파일이 있으면 그 설정이 가려져 실행되지 않을 수 있어서, 둘 다 실행되도록 만들고 시험으로 확인했습니다. 같은 도구가 여러 곳에 설치되어 자동 업데이트가 엉뚱한 쪽을 고칠 수 있는 경우도 찾아, 수동 교체와 구버전 비활성화(이름만 바꿔 되돌릴 수 있게)로 처리했습니다.
실행하면 할 일만 보여 주고, 실제 설치는 별도 표시를 줘야 진행됩니다. 설치 전에 현재 상태와 되돌리기용 파일을 먼저 확보하고, 하나라도 실패하면 그 자리에서 멈춥니다.
관리자 권한이 필요한 작업은 스크립트를 먼저 검토했습니다. 일반 권한으로도 고칠 수 있는 파일이나 프로그램을 관리자 권한으로 그대로 쓰는 틈 세 군데를 찾았습니다. 두 곳은 검토한 지문으로 고정해 사용 직전에 다시 대조하게 하고, 한 곳은 관리자 권한으로 실행하지 않도록 고친 뒤 실행했습니다.
숨기지 않고 남깁니다. 서로의 실수를 다른 방법으로 잡아낸 것이 이번 결과를 믿을 수 있는 근거이기도 합니다.
차단 목록 서랍(인증서 저장소)을 열어 보면 비어 있었고, TRON은 이걸 "차단 안 됨"으로 읽었습니다. 알고 보니 Microsoft 차단 목록은 "도장 번호"가 아니라 "도장 모양의 지문"(공개키 지문)으로 다른 곳에 등록되어 있었습니다. 지문으로 다시 찾으니 8개 모두 있었고, TARS의 실제 검증 시험에서도 Windows가 거절했습니다. 측정값은 맞았고 해석이 틀렸던 것입니다. 판정 기준을 바로 고쳤습니다.
TRON이 Python 소스를 확인해 보니 그 방식에서도 필터가 걸렸습니다. TARS도 직접 확인하고 정정했습니다. 덕분에 고친 뒤 같은 도구로 다시 점검해 효과를 그대로 측정할 수 있다는 것도 확인됐습니다.
점검 환경의 한 PowerShell 버전에서 인증서 저장소를 여는 기능이 빠져 0건으로 읽혔습니다. 다른 버전으로 다시 쟀습니다.
관리자 권한 스크립트를 안내한 형식대로 실행하자, 실행할 단계 번호 "2,3,4"가 숫자 234 하나로 바뀌어 어떤 단계도 실행되지 않은 채 "완료"가 찍혔습니다. TRON의 보안 검토는 권한 경계만 보고 이 부분을 놓쳤습니다. 로그 첫 줄에서 TARS가 이상을 발견하고 원인을 재현했고, 바뀐 것이 없음을 확인한 뒤 올바른 형식으로 다시 실행해 성공했고, 실행 뒤 확인 항목도 모두 통과했습니다. 이후 잘못된 단계 번호는 실행 전에 거부하고, 실제로 실행한 단계가 0개면 "완료" 대신 중단하는 가드를 넣었으며, TRON이 두 실행 형식을 직접 시험해 확인했습니다. 성공처럼 보이는 실패가 가장 위험하다는 교훈입니다.
| 대상 | 조치 |
|---|---|
| Python 표준 기능 | Python이 Windows 명단을 복사해 갈 때 문제 본부 4곳과 위조 발급소 16건만 빼고 복사하게 하는 작은 필터를 넣었습니다. Windows 명단 자체는 건드리지 않습니다. AAA를 빼도 github.com(Sectigo 발급)을 비롯한 주요 사이트가 정상 접속되는 것을 실측했습니다. CPython 공식 차단 패치가 나오면 필터를 걷어 냅니다. 앱 안에 내장된 Python은 앱 업데이트로 해결할 대상이라 제외했습니다 |
| pip, certifi | pip 26.2.2, certifi 2026.10.19로 올렸습니다. 설치 파일의 지문을 고정해서, 다운로드 중에 바꿔치기되면 설치가 거부되게 했습니다. 앱이 관리하는 환경은 제외했습니다 |
| uv | 0.13.4로 교체했습니다. 받은 파일이 공식 배포본인지 지문 세 곳 대조와 서명 확인을 거쳤습니다 |
| Git | Git이 자기 명단 대신 Windows 명단(이미 차단된 쪽)을 쓰도록 설정 한 줄을 바꿨습니다 |
| WSL 리눅스 | ca-certificates를 업데이트하고 명단에서 문제 본부가 빠졌는지 지문으로 확인했습니다 |
| 재발 방지 | 새 가상환경이 고친 pip을 받도록 사고 대응으로 나온 Python 특별 보안판으로 업데이트하는 단계를 넣었고, 옛 버전이 남은 설치 캐시는 일부 정리했습니다. 더 이상 쓰지 않는 오래된 Python 환경은 앱과 함께 정리(제거)했습니다 |
| 앱에 내장된 명단 | 각 앱이 자체 업데이트로 고치는 것이 원칙이라 직접 손대지 않고 업데이트를 확인합니다 |
TRON 쪽에서 받은 승인을 TARS가 그대로 쓰지 않고, TARS도 Dylan에게 직접 다시 확인받았습니다. 소프트웨어 설치는 사전 승인이 필요한 일이고, 다른 AI 팀원이 전한 승인이 자기가 직접 받은 승인을 대신하지 않는다는 원칙 때문입니다. 번거로울 수 있지만, AI 팀원끼리 서로의 승인을 대신 써 버리는 구멍을 막는 장치입니다.
고칠 때마다 같은 점검을 다시 돌리고, 고치기 전 기록과 하나하나 비교했습니다. 위험 표시가 사라졌는지, 엉뚱한 곳이 새로 나빠지지 않았는지를 그 비교 결과로 검수했습니다.
© 2026 Gonnector (고넥터). All rights reserved.