최초 악용부터 KEV 등재까지 42일: 신호는 어디에 있었나

최초의 공개 경고는 X나 CVE ID 기반 피드에 나타나지 않았습니다. 경고는 프로젝트 자체의 GitHub 이슈 트래커에 올라왔습니다. 2026년 9월 11일, 한 Nextcloud 관리자가 내장 Collabora 문서 서버 앱(앱 이름 richdocumentscode)에 대한 공격을 보여 주는 액세스 로그를 게시했습니다. CVE ID가 공개되기 32.5일 전이자, CISA가 이 취약점을 KEV 카탈로그(Known Exploited Vulnerabilities)에 추가하기 42.2일 전이었습니다. 2026년 10월 26일 싱가포르 시간(SGT) 10:17부터 10:56까지 EveryInfra에 60건의 요청을 보냈습니다(52건 과금, 총 $0.029576). 그 결과를 NVD 변경 이력, FIRST EPSS 시계열, 최근 KEV 항목 24건과 비교했습니다.

결과는 분명합니다. X에서 CVE ID로 검색하자 게시물 106건이 나왔습니다. CVE 이전 게시물은 0건이었고, KEV 이후 게시물은 80건이었습니다. 각 게시물은 사전에 작성한 규칙으로 한 번 분류했으며(두 번째 분류자 없음), 93.4%가 리포스트, 봇, 홍보였습니다. CVE 레코드의 기계 판독용 SSVC 필드는 9일 동안 “악용되지 않음”으로 표시돼 있었습니다. EPSS는 10일 동안 1.2%에 머물렀습니다.

이 글에서 말하는 “감사 가능한 신호-대응 프로세스”는 매일 수행하는 다섯 단계로 이뤄집니다. 프로젝트 이슈 트래커, 벤더 포럼, 몇몇 소셜 플랫폼에서 CVE ID뿐 아니라 사용 중인 컴포넌트 이름으로도 검색합니다. 각 원본 응답을 시각과 함께 저장합니다. 결과를 자산 목록과 대조하고 노이즈를 제거합니다. 그런 다음 업그레이드, 제거, 조사 중 하나를 실행하고, 각 단계를 누가, 언제, 어떤 근거로 수행했는지 기록합니다. 이 프로세스는 운영팀과 보안팀에 어떤 항목을 먼저 처리해야 하는지와 그 이유를 알려 주지만, 악용을 예측하거나 벤더 권고문을 대체하지는 않습니다.

다루지 않는 내용

이 글은 모니터링과 대응만 다룹니다. 공격 방법, 악용 세부 사항, 요청 형식은 설명하지 않습니다. 침해를 언급할 때는 관리자가 어디에, 언제, 무엇을 보고했는지만 적습니다. 개인 계정 이름은 가리고, 기관 계정(예: CISA, CERT.LV, 이탈리아 CSIRT, Censys)과 프로젝트 메인테이너만 이름을 밝힙니다. 어떤 벤더의 공개 결정도 평가하지 않으며, 공개 기록의 시각을 나란히 놓을 뿐입니다.

미국 연방 기관의 독자에게 가장 중요한 세부 사항이 하나 있습니다. BOD 26-04에 따라 CISA는 KEV 등재 여부, 자동화 가능한 악용, 기술적 영향, 인터넷 노출이라는 네 가지 입력으로 조치 기한을 정합니다. 이 CVE의 KEV 항목은 기관에 3일의 기한을 주고 포렌식 트리아지를 요구했으며, 이는 지침에서 가장 촉박한 기한입니다. 이 기한은 KEV 등재 시점부터 시작되지만, 공격은 그보다 42일 전에 시작됐습니다. 이 글은 그 공백과, 그 공백을 확인할 수 있었던 공개 장소를 다룹니다.

첫 요청 전에 정한 기준

10월 26일 10:16 SGT, 첫 요청을 보내기 전에 점검 파일에 기준 다섯 가지를 기록했습니다. 10:29 SGT에는 횡단 비교 결과를 열기 전에 기준 두 가지를 추가했습니다. 아래 표는 각 기준과 결과를 나란히 보여 주며, 각 수치의 출처는 이후 섹션에서 제시합니다.

기준 2에는 설명이 필요합니다. X에서는 두 검색 방식(CVE ID 검색, 제품명 + 증상 검색) 모두 CVE 이전 관련 게시물이 0건이었습니다. 따라서 X만으로는 차이를 보여 줄 수 없습니다. 차이는 프로젝트 이슈 트래커와 포럼에서 나옵니다. 둘 다 컴포넌트 이름으로 감시할 수 있는 공개 장소입니다. 기준 6을 “형식상 통과”로 적은 이유는 선행 시간 1일과 30일의 가치가 크게 다르기 때문입니다. 이 수치는 뒤의 섹션에서 나눠 살펴봅니다.

주요 사례: 첫 공격 로그부터 KEV까지

해당 CVE는 CVE-2026-110447입니다. Collabora 보안 권고문에 따르면 이 취약점은 선택 설치형 Nextcloud 앱 하나, “Collabora Online - Built-in CODE Server”에만 영향을 줍니다. 이 앱은 Nextcloud 서버 안에서 문서 서버 사본을 실행합니다. 독립형 Collabora Online 서버는 영향을 받지 않으며, Nextcloud 포럼 경고는 Docker와 Linux 배포판 패키지도 안전하다고 덧붙입니다. 수정 버전은 26.4.303이며, 권고문은 앱을 업그레이드하거나 제거해야 한다고 명시합니다(비활성화만으로는 충분하지 않음). NVD 레코드에는 이 취약점이 “2026년 9월과 10월에 실제 환경에서 악용됨”이라고 적혀 있습니다.

공개 기록에서 초 단위로 확인할 수 있는 시점을 모두 수집했으며, 요약이 아닌 원본 API를 사용했습니다. GitHub issues API는 이슈와 각 댓글의 created_at 시각을 제공합니다. Nextcloud 포럼은 Discourse(API 문서) 기반이므로 토픽 URL 끝에 .json을 붙이면 각 게시물의 시각을 얻을 수 있습니다. 예약 시각과 공개 시각은 CVE.org 레코드의 기반 API에서 가져왔습니다. NVD 필드별 변경 시각은 NVD CVE change history API에서 가져왔습니다. KEV 시각은 CISA KEV JSON의 dateReleased이며, 표의 모든 시각은 UTC입니다.

이 표에 나오는 두 번의 “70분”과 한 번의 “0.7초”는 자세히 볼 만합니다. 버전 26.4.303은 9월 11일 13:43에 나왔습니다. 70분 뒤, 피해를 입은 첫 관리자가 이슈를 열고 전날부터 시스템이 침해된 상태였다고 밝혔습니다.

그 시점에는 양쪽 모두 상대의 상황을 몰랐던 것으로 보입니다. 릴리스 노트에는 보안 관련 문구가 없었고, 관리자는 이슈에서 누군가 요청한 뒤에야 업그레이드했습니다. 두 번째 70분은 10월 14일에 있었습니다. CVE.org가 02:27에 ID를 공개했고, ID가 포함된 첫 X 게시물은 69.8분 뒤에 올라왔습니다.

0.7초는 CVE.org API에서 확인할 수 있습니다. dateReserved 값은 02:27:41.637이고 datePublished 값은 02:27:42.315입니다. 즉 33일 동안 이 취약점에는 예약된 ID조차 없었습니다. CVE ID 기반으로 작동하는 프로세스는 이 33일 동안 매칭할 대상이 전혀 없었습니다. ID를 기준으로 취약점 정보를 접수하는 모든 팀이 안고 있는 핵심 문제가 바로 이것입니다.

2차 출처가 원본 기록과 일치하지 않는 부분도 하나 발견했습니다. Censys의 10월 16일 권고문은 보고자의 로그에서 첫 악성 요청이 9월 16일에 나타났다고 설명합니다. 하지만 이슈 본문에는 9월 10일 19:51과 9월 11일 09:56(+0200 시간대)의 로그 줄이 있습니다.

이슈 자체가 9월 11일에 열렸으므로 9월 16일 로그 줄을 첫 요청으로 인용할 수는 없습니다. 33일이라는 기간에서 요약본의 날짜 하나가 틀리면 6일의 오차가 생기므로, GitHub API의 이슈 본문을 사용합니다. 노출 수치는 같은 권고문에서 그대로 가져왔습니다. 앱이 설치된 호스트는 19,454개, 웹 프로퍼티는 103,350개였습니다. Censys는 이들 모두가 취약한 것으로 확인된 것은 아니라고 밝혔으며, 두 수치 모두 같은 앱의 ARM64 빌드(호스트 1,001개)를 포함합니다.

33일 동안 CVE가 없었던 이유

CISA의 기준 페이지에 따르면 KEV 등재에는 세 가지 필수 요건이 있습니다. 취약점에 CVE ID가 있어야 합니다. 실제 악용에 대한 신뢰할 수 있는 증거가 있어야 합니다. 명확한 조치 지침이 있어야 합니다. 이 취약점은 9월 11일에 두 번째와 세 번째 요건을 충족했습니다. 이슈에 관리자 세 명의 보고가 있었고 수정 버전도 나와 있었기 때문입니다. 첫 번째 요건이 걸림돌이었고, ID 없이 보낸 32.5일 때문에 전체 기간이 42일이 됐습니다.

Collabora의 10월 14일 블로그 글은 두 가지 사실을 나란히 제시합니다. 올해 AI의 도움을 받은 보안 보고가 매우 많이 접수됐다는 점, 그리고 GitHub를 통해 CVE를 받는 데 걸리는 시간이 약 하루에서 여러 주로 늘었다는 점입니다. 이 글은 전자가 후자의 원인이라고 말하지 않습니다. 대신 대기 시간을 줄이기 위해 Collabora가 현재 CVE 번호 부여 기관(CNA, CVE Numbering Authority) 지정을 신청하고 있다고 밝힙니다.

CVE.org 레코드를 보면 최종 할당 기관은 MITRE였고, 예약과 공개가 같은 초에 이뤄졌습니다. 이는 일반적인 대기열보다는 MITRE가 최후 수단의 할당 기관(assigner of last resort)으로 처리한 경우에 가까워 보입니다. 이 사례에 대한 공식 설명은 찾지 못했으므로 원인을 추측하지 않습니다.

이 사례가 특이한 것은 아닙니다. 10월에 보안 기업 Second Security는 The Patchless Window라는 연구를 발표했습니다. 이 연구는 2026년 1월부터 8월까지의 오픈소스 CVE 18,594건을 각각 처음 수정한 공개 커밋까지 거슬러 추적했습니다. 공개 수정부터 CVE 공개까지 걸린 시간의 중앙값은 1월 5.1일, 8월 39.2일이었습니다. Collabora의 공백은 32.5일로 8월 중앙값보다 짧았습니다. 오픈소스 컴포넌트에서는 “수정이 먼저, ID는 한 달 뒤”가 점점 일반적인 일이 되고 있습니다.

BleepingComputer의 10월 15일 보도가 이 연구를 인용했으며, 수치는 연구 사이트에서 직접 확인했습니다. The Hacker News도 이 사례를 보도했습니다. CVE ID 기준으로 취약점 인텔리전스를 구독하는 팀에게 의미하는 바는 간단합니다. 이제 첫 알림은 평균적으로 수정이 공개되고 한 달 이상 지나서 도착합니다. 그 한 달 동안 수정은 존재하지만, 그것이 보안 수정이라고 알려 주는 곳은 없습니다.

맥락이 하나 더 있습니다. 2026년 4월 15일부터 NIST는 모든 CVE를 빠짐없이 보강하지는 않습니다. KEV 항목, 연방 정부가 사용하는 소프트웨어, “중요 소프트웨어(critical software)”를 우선 처리합니다. NIST는 그 이유로 2020년부터 2025년까지 CVE 제출 건수가 263% 증가한 점을 들었습니다. 10월 26일 기준 NVD API에서 이 레코드는 여전히 Deferred 상태였습니다(할당 기관의 CVSS 4.0 점수와 CISA의 SSVC만 있음). NIST의 목표는 KEV 항목을 영업일 기준 1일 이내에 보강하는 것인데, KEV 등재 후 이미 이틀 넘게 지난 상태였습니다.

즉 KEV 등재 전은 물론 등재 후 한동안도 NVD 필드 상당수가 비어 있을 수 있습니다. NVD 점수로 취약점을 대기열 맨 앞에 올릴 계획이라면, 바로 이 기간에 그 계획이 실패할 수 있습니다. 설명 텍스트는 공개 후 1시간 안에 이미 있었습니다. 구조화된 필드는 나중에 채워졌으며, 얼마나 늦었는지는 다음 테스트에서 측정합니다.

테스트 1: CVE 이전에 소셜 플랫폼에는 무엇이 있었나

누군가 X에서 이 컴포넌트를 감시했다면 더 일찍 알아챘을까요? 10월 26일 10:24부터 10:26 SGT까지 X (Twitter) 검색 스크래핑 API(twitter/search)로 세 번 검색했습니다. 각 검색의 날짜 범위는 9월 1일부터 10월 14일까지였습니다. 첫 번째 검색은 앱 이름 richdocumentscode를, 두 번째 검색은 제품명과 증상 단어(nextcloud (hacked OR webshell OR compromised OR backdoor))를, 세 번째 검색은 nextcloud collabora만 사용했습니다.

결과는 일치했습니다. 처음 두 검색은 각각 게시물 3건과 5건을 반환했는데, 모두 10월 14일 당일 또는 그 이후 게시물이어서 CVE 이전 게시물은 0건이었습니다. 세 번째 검색은 CVE 이전 게시물 16건을 반환했지만, 취약점이나 침입을 언급한 게시물은 하나도 없었습니다. 스위스 연방 공무원과 오픈소스 오피스 도구, 유럽의 디지털 주권, 관리형 Nextcloud 호스팅에 관한 내용이었습니다. 또한 세 요청 모두 until:2026-10-14를 지정했는데도 응답에는 10월 14일 당일 또는 그 이후 게시물이 각각 3건, 5건, 6건 포함돼 있었습니다. 날짜 상한(X 고급 검색 도움말의 “특정 날짜 이전”)이 엄격하게 적용되지 않았으므로, 각 게시물의 posted_at 값으로 다시 필터링했습니다.

Reddit의 경우 Reddit 검색 스크래핑 API(reddit/search)는 항상 최근 한 달을 대상으로 합니다. 10월 26일에 실행한 검색은 9월 26일부터의 기간을 포함했으며, 여기에는 CVE 이전 18일이 들어 있습니다. 10:42 SGT에 richdocumentscode를 최신순으로 검색하자 게시물 14건이 나왔습니다. 14건 모두 이 취약점에 관한 것이었지만, CVE 이전 게시물은 없었습니다. 첫 게시물은 10월 14일 20:04에 올라온 보안 뉴스 리포스트로, CVE 공개 17.6시간 뒤였습니다.

가장 유용한 Reddit 게시물은 10월 22일에 올라왔습니다. r/NextCloud의 한 관리자가 내장 Collabora 앱을 통해 서버가 침해된 경위를 설명했고, 이 게시물에는 댓글 52개가 달렸습니다. 13초 뒤 같은 작성자가 r/Malware에도 같은 글을 올렸습니다. Hacker News는 HN Algolia 검색 API로 검색했으며, richdocumentscode 검색 결과는 0건이었습니다. 9월 1일 이후를 대상으로 nextcloud collabora를 검색했을 때 첫 관련 항목은 10월 15일의 링크 게시물(22:06 UTC, 2포인트, 댓글 0개)이었습니다.

각 플랫폼의 첫 관련 항목을 CVE 공개 시점 기준으로 순서대로 정리했습니다. GitHub 이슈는 32.5일, Nextcloud 포럼은 10.7일 앞섰습니다. X는 0.05일, Reddit은 0.73일, Hacker News는 1.8일 늦었습니다. YouTube 검색 스크래핑 API(youtube/search, 결과 10건 중 10건에 ID 포함)는 2.5일, LinkedIn 검색 스크래핑 API(linkedin/search, 10건 중 8건)는 4.0일 늦었습니다. Weibo 검색 스크래핑 API(weibo/search)는 다른 취약점(PHP2Shell)에 관한 게시물 9건과 Collabora를 한 줄 언급한 요약 게시물 1건을 반환했습니다. Threads 검색 스크래핑 API(threads/search)는 최근 19시간 동안의 게시물 25건만 반환해 최초 포착 시점을 확인할 수 없었습니다.

이 표의 논리는 단계별로 따라갈 수 있습니다. 첫째, CVE 이전의 공개 신호는 모두 프로젝트에 속한 공간, 즉 이슈 트래커와 벤더의 사용자 포럼에 있었습니다. 둘째, 그곳의 작성자는 피해를 입은 관리자와 메인테이너였고, 게시물에는 확인 가능한 로그와 버전 번호가 있었습니다. 셋째, 첫 소셜 게시물은 CVE 이후에 나왔으며, 이슈 트래커가 아니라 CVE 레코드를 읽는 보안 뉴스 계정이 올린 것이었습니다. 따라서 주된 감시 대상은 “컴포넌트 이름 기준의 프로젝트 이슈와 포럼”이어야 합니다. 소셜 플랫폼은 나중에 정보를 확산시키고 피해 보고를 더해 주지만, 이 사례에서는 조기 경보 수단이 되지 못했습니다.

이 결론에는 한계가 있습니다. 이번 피해자는 자체 호스팅 환경을 운영하는 소규모 조직이었고, 이런 조직은 프로젝트 이슈 트래커에서 도움을 구합니다. 피해자가 대기업이라면 첫 신호는 벤더의 유료 지원 채널에 나타날 가능성이 더 큽니다. 공개 데이터로는 그 채널을 볼 수 없습니다. 따라서 이 패턴은 소규모 팀이 직접 운영하는 오픈소스 컴포넌트에 가장 잘 들어맞습니다.

테스트 2: CVE 이후 게시물 수는 KEV를 따라간다

10:26 SGT에 X에서 CVE-2026-110447을 limit 200, 최신순으로 한 번 검색했습니다. 응답은 게시물 106건으로 한도에 미치지 않았습니다. 게시물을 세 기간으로 나눴습니다. CVE 이전은 0건, CVE부터 KEV까지 9.7일 동안은 26건이었습니다. KEV 이후 2.3일 동안은 80건이었고, 그중 49건이 10월 24일 하루에 올라왔습니다. KEV 이후 첫 48시간의 게시물이 전체의 71.7%를 차지했습니다.

이 차트의 모양은 한 가지를 분명히 보여 줍니다. X에서 KEV는 신호가 아니라 증폭기 역할을 합니다. 취약점은 9월에 악용됐고, CVE 설명에는 10월 14일에 이미 “실제 환경에서 악용됨”이라고 적혀 있었습니다. 대형 보안 뉴스 계정들도 같은 날 게시물을 올렸습니다. 하지만 본격적인 리포스트 물결은 CISA KEV 공지 이후에야 일어났습니다. 많은 보안 뉴스 계정과 봇은 매일의 KEV 업데이트를 입력으로 쓰며, 많은 기업이 KEV 항목에 대해서만 티켓을 엽니다.

모니터링 관점에서 보면, 이 사례에서 “특정 ID의 X 게시물 수 급증” 알림은 KEV 이후에야 울렸을 것입니다. 게시물 수는 사람들이 지금 무엇을 이야기하는지 알려 줄 뿐, 누가 이미 공격당했는지는 알려 주지 않습니다. 파이프라인에서 소셜 게시물 수를 트리거로 쓴다면 관심도를 측정하는 셈이며, 관심은 가장 늦게 찾아왔습니다.

언어 구성도 참고할 만합니다. 106건 중 영어 68건, 일본어 18건, 프랑스어 5건, 스페인어 4건, 한국어 3건, 중국어 1건이었습니다. 미국 팀에게 중요한 것은 일본어 비중입니다. KEV 이전 X에서 유일한 직접 침해 보고가 일본어 게시물이었기 때문입니다. 영어 게시물만 남기는 감시였다면 이 보고를 놓쳤을 것입니다. 언어로 필터링한다면 사용자가 소프트웨어를 운영하는 모든 국가의 언어를 포함해야 합니다.

테스트 3: 노이즈 93.4%, 그 실체는 무엇인가

사전에 작성한 규칙으로 게시물 106건을 6개 범주로 나눴습니다. 한계를 분명히 밝혀 두면, 106건은 규칙에 따라 한 번만 분류했고 두 번째 분류자가 독립적으로 검토하지 않았습니다. 따라서 93.4%는 규칙 기반 분류를 한 차례 수행한 결과이며, 오차 범위는 알 수 없습니다. 공식 보고서에 사용하기 전에 다른 사람이 같은 규칙으로 106건을 다시 분류하게 하고, 두 결과의 일치도를 함께 보고해야 합니다. “신호”는 CVE 레코드나 벤더 권고문에 없는 사실을 더하는 게시물입니다. “노이즈”는 세 범주로 나뉩니다. 권고문이나 뉴스 기사의 리포스트, 템플릿 봇과 일일 요약, 홍보 또는 무관한 콘텐츠입니다.

결과는 리포스트 80건, 봇과 요약 12건, 홍보 또는 무관한 게시물 7건으로 총 99건(93.4%)이었습니다. 신호 게시물 7건 중 4건은 자체 데이터를 가진 기관인 CERT.LV(라트비아), CSIRT(이탈리아), Censys, CISA가 올린 것이었습니다. 2건은 기록을 확인한 사람들이 밝힌 새로운 사실이었습니다. 하나는 SSVC 필드가 설명과 모순된다는 점을, 다른 하나는 NVD에 CVSS 4.0 점수만 있고 3.x 점수는 없다는 점을 지적했습니다. 마지막 1건은 일본인 관리자의 게시물(10월 23일 08:29 UTC)로, 그 전주에 이 취약점을 통해 서버에 채굴 소프트웨어가 설치됐다는 내용이었습니다.

이 7건 중 KEV 이전에 올라온 것은 4건뿐입니다. 따라서 KEV 이전에 ID가 포함된 게시물을 모두 읽은 팀은 유용한 게시물 4건을 찾기 위해 26건을 읽어야 했습니다. KEV 이후에는 비율이 더 나빠서 80건 중 유용한 것은 3건이었습니다. 읽는 비용은 KEV와 함께 늘어나지만 가치는 늘지 않습니다.

홍보 및 무관한 게시물 7건 중 일부는 다른 취약점에서도 다시 보게 될 유형이므로 노이즈 규칙에 추가해 두는 것이 좋습니다. 헤드라인을 이용해 암호화폐 토큰을 홍보하는 게시물과 “AI 봇을 URL에 연결하고 알림을 받으세요” 같은 제품 광고가 있었습니다. 패치되지 않은 시스템을 찾아 테스트하는 방법을 알려 주는 “버그 바운티 팁” 게시물도 있었는데, 이는 제외했으며 여기서 내용을 반복하지 않습니다. “매주 하늘이 무너지는 것 같다”는 일반적인 댓글 하나는 ID가 들어 있다는 이유만으로 검색에 걸렸습니다.

노이즈는 X에만 있는 것이 아닙니다. 게시물 7개로 이루어진 Nextcloud 포럼 스레드에서 3번과 6번 게시물은 같은 신규 계정이 올린 것이었습니다. 두 게시물 모두 “무료 30초 자가 진단”을 내세운 외부 페이지로 연결되었습니다. 7번 게시물은 커뮤니티 리더가 남긴 메모로, 두 링크가 거의 같으며 팀이 스팸을 모니터링하고 있다고 밝혔습니다. Weibo에서는 결과 10건 중 8건이 계정 8개가 2초 안에 올린 같은 PHP2Shell 텍스트였으며, 이는 전형적인 계정 팜 패턴입니다. Threads에서는 “Nextcloud Collabora” 검색 결과 25건 중 6건이 동사 “collabora”(“함께 일하다”)를 쓴 이탈리아어 게시물이었습니다.

테스트 4: 기계 판독용 위험 필드는 설명 텍스트보다 늦었다

많은 취약점 파이프라인은 설명 텍스트를 읽지 않고 구조화된 필드를 읽습니다. 그 출처 중 하나는 CISA가 Vulnrichment 프로젝트를 통해 CVE 레코드에 기록하는 세 가지 SSVC 결정 지점으로, exploitation(악용), automatable(자동화 가능성), technical impact(기술적 영향)입니다. 다른 하나는 FIRST가 매일 발표하는 EPSS 점수로, 향후 30일 안에 악용 활동이 관측될 확률을 추정합니다. BOD 26-04 지침은 KEV 등재 여부, automatable, technical impact, 노출 여부를 기준으로 연방 기관의 조치 기한을 정하며, CISA는 이 중 세 가지를 Vulnrichment로 제공합니다.

NVD 변경 이력 API로 이 레코드의 SSVC 데이터에 대한 모든 변경 사항을 가져왔습니다. 시계열은 EPSS API로 가져왔습니다. CVE 설명에는 10월 14일 03:17부터 “exploited in the wild”라는 문구가 있었습니다. SSVC 데이터는 표와 같이 바뀌었습니다.

즉 9.7일 동안 설명에는 “exploited”라고 적혀 있었지만, 구조화된 필드는 처음에 비어 있다가 9일 동안 “악용되지 않음”으로 표시되었습니다. 필드가 “악용됨”으로 바뀐 것은 KEV 등재 47분 후였습니다. EPSS는 이 10일 동안 1.2%(당시 약 68번째 백분위수)에 머물렀고, KEV 등재 이틀 뒤에야 12.3%에 도달했습니다. “SSVC가 active이거나 EPSS가 10%를 넘으면 티켓을 연다” 같은 규칙이었다면 KEV 등재 1~2일 후에 작동했을 것입니다. 설명 텍스트보다 11일 늦은 셈입니다.

한 X 사용자가 이 불일치를 알아챘습니다. 이 사용자는 10월 23일 21:03 UTC에 업데이트를 올렸습니다. 불일치를 지적한 첫 게시물 약 6분 뒤 KEV에 이 취약점이 추가되었고, SSVC도 이제 active로 바뀌었다는 내용이었습니다. 게시물은 파이프라인에 이전 값이 남아 있다면 데이터를 다시 가져오라고 권했습니다. 연방 기관의 기한이 10월 26일이라는 점도 언급했습니다. 106건의 게시물 가운데 파이프라인에 직접 쓸모가 있는 몇 안 되는 게시물이었습니다.

그렇다고 SSVC와 EPSS가 쓸모없다는 뜻은 아닙니다. EPSS FAQ는 EPSS가 완전한 위험 점수가 아니라고 밝히며, SSVC는 근거가 필요한 분석가의 판단입니다. 우리가 관찰한 내용은 이보다 범위가 좁습니다. 근거가 프로젝트 이슈 트래커에만 있는 동안에는 두 필드 모두 이를 반영하지 못했습니다. 구조화된 필드는 관문이 아니라 정렬에 사용하세요. 설명에 “exploited in the wild” 같은 문구가 있는지 확인하는 텍스트 규칙을 따로 추가하세요.

테스트 5: 최근 KEV 항목 24건, X는 얼마나 빨랐나

사례 하나로는 충분하지 않습니다. 9월 26일부터 10월 23일까지 KEV에 추가된 항목 30건을 모두 가져왔습니다. 그중 6건은 2015~2025년의 오래된 ID였습니다(예: 2015년의 ProFTPD와 BIND). 나머지 24건은 SGT 10:28~10:41에 twitter/search로 ID마다 한 번씩 X를 검색했으며, limit은 200이었습니다. KEV 시각으로는 NVD 변경 이력의 첫 KEV 주석을 사용했습니다. 이 주석은 CISA 발표 후 몇 분에서 몇 시간 뒤에 붙으므로 상한값이며, X의 선행 시간을 약간 크게 만듭니다. CISA KEV JSON의 dateReleased(10월 23일 19:30)를 사용한 주요 사례와는 기준이 다릅니다. 같은 CVE의 NVD KEV 주석은 47분 뒤인 20:17에 붙었습니다. 이전 카탈로그 버전은 항목별 발표 시각을 제공하지 않으므로, 횡단 분석에서는 24건 모두에 NVD 주석을 사용했고, 주요 사례도 같은 기준으로 9.7일로 나타납니다.

결과: 24건 중 23건(95.8%)은 KEV 이전에 ID가 포함된 X 게시물이 최소 1건 있었으며, 형식상으로는 기준 6을 충족합니다. 그러나 반올림하지 않은 값으로 계산한 선행 시간의 중앙값은 약 1.16일(12번째와 13번째 값은 1.12일과 1.19일)이었고, 1일 넘게 앞선 것은 24건 중 13건뿐이었습니다. 더 중요한 점은 CVE 17건에서 첫 X 게시물이 NVD 공개 후 0.3일 안에 나왔다는 것입니다. 이유는 NVD와 KEV 사이의 간격에 있습니다. 24건 중 12건은 KEV가 NVD와 같은 날이나 다음 날 나왔으며, 대부분 벤더가 확인한 제로데이(Citrix NetScaler, Fortinet, Ivanti)였습니다. X가 빨라 보이는 것은 이 간격이 길 때뿐이며(Atlassian 10일, Ahsay 10일, 주요 사례 9.7일), 그 선행 시간은 거의 전적으로 CVE가 먼저 공개된 데서 비롯됩니다.

NVD에서 KEV까지의 간격을 달력 기준 일수로 정렬하면 분포가 더 분명해집니다. 간격은 9건이 0일, 3건이 1일, 2건이 2일이었습니다. 5일, 6일, 9일은 각각 1건, 10일은 3건, 27일은 4건이었습니다. 중앙값은 1.5일이었습니다.

따라서 이번 달 KEV 항목은 두 그룹으로 나뉩니다. 첫 번째 그룹에서는 벤더가 제로데이를 확인하고, CVE와 KEV가 거의 동시에 나옵니다. 두 번째 그룹에서는 CVE가 훨씬 전에 공개되었고, 악용 증거는 나중에 나왔습니다.

첫 번째 그룹에서 X는 긴급한 벤더 권고를 더 빨리 확인하는 데 도움이 되며, 선행 시간은 몇 시간입니다. 두 번째 그룹에서 X의 선행 시간은 공개 이후 누군가 그 CVE를 알아챘는지에 달려 있습니다. Plex 사례처럼 3주 동안 아무도 언급하지 않을 수도 있습니다. 또한 CVE 6건은 NVD에 추가되기 전에 ID가 포함된 X 게시물이 있었는데, 대개 벤더 권고문이 ID를 먼저 밝혔기 때문입니다. 따라서 타임라인을 만들 때 NVD 접수 시각을 ID 공개 시각으로 간주하지 마세요.

예외는 Plex Media Server CVE 4건입니다. NVD는 9월 23일에 이를 공개했지만, 이 ID가 포함된 첫 X 게시물은 10월 18일에 나왔습니다. 24.9일 뒤이자 KEV 등재 2.2일 전이며, 다음 섹션에서 이 사례를 살펴봅니다. 두 가지를 덧붙입니다. CVE-2026-88771과 CVE-2026-102764는 검색 결과가 200건을 꽉 채웠으므로, 이 둘의 첫 확인 시각은 하한값입니다. 또한 X 검색은 모든 게시물이 아니라 순위가 매겨진 표본을 반환합니다.

SSVC 결과는 더 단순합니다. 30개 항목 중 KEV 등재 전에 exploitation: active였던 항목은 하나도 없었으므로, 이 샘플에서 SSVC의 “active”는 KEV를 그대로 반영한 값입니다. KEV 등재 전날 EPSS 데이터가 있던 CVE 12개는 12개 모두 점수가 10% 미만이었습니다. 이 샘플에서는 두 필드 모두 카탈로그보다 먼저 경고를 주지 못했습니다.

비교 사례 3건: NetScaler, Plex2Shell, PHP2Shell

패턴이 있는지 보기 위해 같은 기간의 사건 3건을 비교했습니다. 사건마다 X를 한 번씩 검색하고, CVE 공개 시점을 0일로 삼아 1차 출처의 기록 시각을 나란히 정리했습니다.

NetScaler: X가 빨랐지만 초기 내용은 소문. SGT 10:54에 9월 26~28일 기간으로 NetScaler를 검색해 게시물 176건을 얻었습니다. 첫 게시물은 9월 26일 15:07 UTC에 올라왔습니다. 한 대형 계정이 알려지지 않은 NetScaler 제로데이가 활발히 악용되고 있어 여러 기관이 장비를 내렸다고 전했습니다. NVD는 9월 27일 17:16에 CVE-2026-88771을 접수했는데, 그때 X에는 이미 게시물이 77건 있었습니다.

초기 게시물 여러 건은 이 소문이 Reddit의 시스템 관리자 토론에서 시작되었다고 밝혔습니다. CISA는 그날 20:16경 이 취약점을 추가했습니다.

CISA는 별도 경보에서 조직들에 패치 전에 침해 여부부터 확인하라고 안내했습니다. Citrix도 같은 날 보안 게시판을 발표했습니다. 대형 벤더, 제로데이, 엣지 장비가 겹칠 때의 전형적인 패턴입니다. 피해자는 대규모 조직이며, 소식은 먼저 실무자 사이에서 “뭔가 이상하다”는 형태로 퍼집니다. 그다음 벤더 공지, CVE, KEV가 하루 안에 나옵니다. X는 26시간 빨랐지만 그 내용은 검증되지 않은 소문이었습니다. “로그 확인” 플레이북을 시작하기에는 충분하지만, 결론을 내리기에는 부족합니다.

Plex2Shell: 벤더는 일찍 알렸지만 아무도 듣지 못함. Plex는 9월 1일 18:30 UTC에 포럼 공지를 올렸습니다. 버전 1.43.3에서 여러 보안 문제를 수정했으며 CVE를 요청했다는 내용이었습니다. 이 공지의 조회 수는 현재 86,684회입니다. 그러나 9월 1일부터 22일까지 plex "security update"로 X를 검색하자 게시물은 1건뿐이었습니다.

CVE(예: CVE-2026-96652)는 9월 23일에 나왔습니다. ACN의 권고문(ACN은 이탈리아 국가사이버보안청)에는 CVE별로 4.3, 6.5(CVSS 3.1)처럼 그리 높지 않은 점수가 표시되어 있습니다. 그래서 주목하는 사람이 적었습니다.

전환점은 10월 16일이었습니다. 한 연구자가 취약점 4개가 어떻게 연쇄되는지 전체 분석을 공개했습니다. 10월 17일에는 다른 연구자의 허니팟이 악용을 기록했습니다(해당 블로그). “Plex2Shell”이 들어간 첫 X 게시물은 10월 18일 15:59에 나왔고, CISA는 10월 20일에 이 CVE들을 추가했습니다. 패턴은 이렇습니다. 점수가 낮은 취약점들이 결합했을 때의 위험은 공개 분석이 나온 뒤에야 드러났고, 첫 공개 신호는 벤더 자체 공지였습니다. 모니터링은 “important security update, details to follow” 같은 문구도 읽어야 합니다. Reddit의 피해 보고(r/unRAID, 댓글 109개)는 KEV 이후인 10월 21일에 올라왔습니다.

PHP2Shell: X에서 가장 큰 관심을 받았지만 여전히 KEV 미등재. 10월 20일 PHP 팀은 치명적인 취약점 2건의 수정을 발표했습니다. CVE-2026-109618이 포함된 첫 X 게시물은 10월 20일 18:56 UTC에 나왔는데, 이는 수정 버전과 CVE(CVE.org 기준 10월 21일 13:48 UTC)보다 약 19시간 빠릅니다. 한 번의 검색만으로도 10월 21일 14:00 엠바고 해제 전에 이미 게시물이 68건 있었습니다. AWS 위협 인텔리전스는 블로그 게시물에서 자사 허니팟 네트워크가 공개 4일 전인 10월 17일에 악용 시도를 관측했다고 밝혔습니다. EU 기관인 CERT-EU도 권고문에 이 사건을 기록했습니다.

그러나 10월 26일에 KEV 카탈로그를 확인했을 때는 여전히 버전 2026.10.23이었고 이 ID들은 포함되어 있지 않았습니다. SGT 10:52에 실행한 검색은 10월 20~23일 기간에 대해 200건을 꽉 채워 반환했으며, 이번에도 날짜 상한이 엄격하게 적용되지 않았습니다. 이 사례는 소셜 관심도와 KEV 등재가 연동되지 않는다는 것을 보여 줍니다. KEV에는 실제 환경에서 악용되었다는 신뢰할 만한 증거가 필요하며, 허니팟을 대상으로 한 시도만으로는 충분하지 않을 수 있습니다. PHP2Shell 같은 취약점은 KEV를 기다리지 말고, 자체 노출 상황을 기준으로 수정 일정을 잡으세요.

네 사례를 나란히 놓고 보면 결론은 “소셜 플랫폼은 쓸모없다”가 아닙니다. 첫 공개 신호는 첫 피해자들이 이야기하는 곳에서 나타납니다. 소규모 셀프호스팅 조직은 프로젝트 이슈 트래커와 사용자 포럼에서 피해를 알립니다. 대규모 조직의 실무자는 소셜 플랫폼에서 서로 묻습니다. 벤더는 포럼과 릴리스 노트에서 조용히 경고하고, 연구자는 블로그와 저장소에 결과를 공개합니다. CVE ID 기반 구독은 이 모든 채널에서 신호가 나온 뒤에야 정보를 포착합니다.

신호에서 대응까지: 하루 한 번 실행하는 프로세스

1단계는 소스 모니터링입니다. 목록은 CVE ID가 아니라 운영 중인 컴포넌트 이름(richdocumentscode, Plex Media Server, NetScaler 등)으로 만듭니다. 컴포넌트마다 소스는 세 종류입니다. 첫째는 프로젝트 이슈 트래커와 릴리스입니다(GitHub는 새 이슈와 릴리스를 확인하는 무료 API를 제공합니다). 둘째는 벤더 포럼이나 보안 공지 페이지(많은 포럼이 JSON을 반환하는 Discourse로 운영됩니다)이고, 셋째는 몇몇 소셜 플랫폼의 키워드 검색입니다. KEV JSON과 CVE 설명은 확인과 기한 파악용이며, 출발점이 아닙니다.

이번 사례에서 richdocumentscode 이슈 트래커를 매일 읽었다면 9월 11일 이슈 제목에서 “Hack”을 보았을 것입니다. ID 기반 구독보다 한 달 빠른 시점입니다. 비용은 컴포넌트당 하루 한 번의 무료 API 호출이고, 얻는 가치는 32.5일입니다.

2단계는 증거 보관입니다. 각 원본 응답을 수정 없이 요청 파라미터, UTC 시각, 파일 해시와 함께 저장합니다. 이유는 두 가지입니다. 첫째, 나중에 BOD 26-04가 요구하는 포렌식 트리아지와 사고 보고서에서 “언제 알았는가?”라는 질문에 답할 수 있어야 합니다. 둘째, 플랫폼 콘텐츠는 바뀝니다. 게시물은 삭제되고, 댓글은 수정되며, 요약에는 오류가 있습니다. Censys 날짜 불일치도 저장해 둔 이슈 텍스트를 다시 확인했기 때문에 발견할 수 있었습니다.

3단계는 자산 매칭입니다. 인벤토리는 CVE ID가 아니라 컴포넌트 이름으로 매칭하세요. 8월 Patchless Window 중앙값에 따르면 ID가 없는 기간이 39.2일이었기 때문입니다. 매칭에는 배포 유형도 포함해야 합니다. 이 취약점은 내장 CODE 앱에만 영향을 주며, 독립 실행형 Collabora는 안전합니다. “Collabora를 쓰는가?”로 매칭하면 오탐이 많이 생깁니다. 더 나쁜 점은 그 속에 실제로 영향을 받는 서버 한 대가 묻힐 수 있다는 것입니다.

4단계는 노이즈 제거입니다. 각 항목에 테스트 3의 분류 6가지로 라벨을 붙입니다. 재게시, 봇, 홍보, 공격 팁 게시물은 대응 큐에서 빼되, 나중에 확인할 수 있도록 아카이브에는 남깁니다. 이번 테스트에서는 ID 기반 X 검색 결과의 93.4%가, CVE 이전 제품명 검색 결과는 100%가 제거되었습니다. 규칙은 언어 간 단어 충돌(이탈리아어 “collabora”), 계정 팜(계정 8개, 2초), 포럼의 “무료 자가 진단” 링크도 다뤄야 합니다.

5단계는 대응입니다. Collabora 권고문은 비활성화만으로는 충분하지 않으므로 26.4.303으로 업그레이드하거나 앱을 제거하라고 안내합니다. 지원이 종료된 Nextcloud 29 이하를 운영한다면 Nextcloud를 업그레이드하거나 앱을 제거하세요.

Nextcloud 포럼의 4번 게시물은 실용적인 확인 방법을 알려 주었습니다. 업그레이드 후 Nextcloud 무결성 검사에서 앱 폴더에 “extra file”이 있다고 보고되었다는 것입니다. 이탈리아 CSIRT는 웹 셸 설치와 자격 증명 탈취를 언급했습니다. 따라서 9월 10일 이후 노출된 인스턴스라면 세 가지 조치를 추가로 권장합니다. 무결성 검사를 실행하고, 액세스 로그를 검토하고, 웹 서버가 읽을 수 있는 비밀번호를 교체하세요.

여기서는 방어 조치만 설명하며, 공격 요청의 형태는 다루지 않습니다. 패치는 공격자가 이미 심어 둔 파일을 제거하지 않으므로 무결성 검사가 중요합니다. 패치된 서버에도 백도어가 남아 있을 수 있습니다. KEV 항목이 수정 외에 포렌식 트리아지를 요구하는 이유입니다.

6단계는 사례 종료입니다. 각 사례는 네 가지 질문에 답해야 합니다. 누가 처리했는지, 언제 처리했는지, 어떤 증거에 근거했는지(아카이브의 원본 응답을 가리키는 참조 정보), 무엇을 했는지입니다. KEV에 취약점이 추가되면 해당 항목의 기한과 사례 종료 시각을 비교하세요. 아래 표는 권장하는 최소 기록 필드이며, 이번 테스트에서 모두 사용했습니다.

비용: 컴포넌트 50개, 한 달 기준

SGT 기준 10월 26일 10:13에 기능 카탈로그를 확인했으며, 기준은 요금 페이지입니다. twitter/search, reddit/search, youtube/search, linkedin/search, threads/search는 각각 요청당 $0.000556입니다. weibo/search는 요청당 $0.000806입니다. 결과 수가 아니라 요청 수에 따라 과금됩니다. CVE 이전 게시물을 찾기 위해 웹과 포럼에서 quick 깊이(건당 $0.000694)로 EveryInfra 검색도 3회 실행했으며, 3회 모두 결과가 0건이었습니다.

인터넷에 노출된 컴포넌트가 50개인 소규모 팀이 컴포넌트마다 하루에 X 검색 1회, Reddit 검색 1회를 실행한다고 가정해 보겠습니다. 하루 요청 100건 × $0.000556 = $0.0556이며, 30일이면 $1.668입니다. GitHub 이슈 API, Discourse 포럼, NVD, CVE.org, KEV, EPSS는 무료 공개 API이므로 이 비용에 포함되지 않습니다.

빈 결과와 실패한 요청은 과금되지 않습니다. 요청 60건 중 6건은 요청 속도 제한에 걸렸고(상태 429), 1건은 파라미터가 잘못되었으며(상태 422), 1건은 빈 결과였습니다. 이 8건은 모두 과금되지 않았습니다. 과금된 요청은 52건($0.029576)이었고, 히어로 이미지와 일러스트 1장에 $0.06이 추가로 들었습니다.

루프를 매시간 실행해야 할까요? 같은 컴포넌트 50개로 매시간 실행하면 하루 2,400건, 즉 하루 $1.3344, 한 달 약 $40.03입니다. 하루 1회 실행 비용의 24배이지만, 신호 확인 시점은 하루도 채 앞당겨지지 않습니다. 이번 사례에서는 첫 신호가 CVE보다 32.5일 앞섰으므로, 그 규모에서는 일 단위와 시간 단위의 차이가 의미가 없습니다. 시간 단위 모니터링은 CVE와 KEV가 하루 안에 나오는 NetScaler 같은 엣지 장비 제로데이에 적합합니다. 이런 목록은 대개 짧으니 따로 관리하고, 전체 목록은 하루 1회로 유지하세요.

코드나 AI 클라이언트로 같은 데이터 가져오기

ID로 X를 검색하는 단일 curl 요청(API 키는 자리 표시자입니다):

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

이 글에서 사용하는 응답 필드는 모두 카탈로그에 있는 twitter/search의 response_fields와 대조해 확인했습니다.

Reddit은 reddit/search에 keyword와 sort 파라미터(newest, relevance 등)를 사용합니다. 가장 많이 쓰게 될 필드는 community, comment_count, posted_at입니다. 검색 기간은 항상 최근 1개월입니다. 30일이 넘는 기록이 필요하다면 그때그때 결과를 아카이브하세요.

Claude Code에서 같은 검색을 실행하려면 빠른 시작에서 API 키를 발급받고 원격 MCP 서버를 추가하세요:

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

그런 다음 지시 하나만 내리면 됩니다. “everyinfra_call_api를 사용해 X에서 richdocumentscode와 CVE-2026-110447을 검색하고, 2026-10-14 02:27 UTC를 기준으로 게시물을 나눠 줘.” 이어서 기관 계정과 개인 계정을 구분해 나열해 달라고 요청할 수 있습니다. 답변은 위 표와 같은 posted_at, author_username 필드를 사용합니다.

이번 테스트에서 확인한 오류와 과금 결과는 다음과 같습니다. Reddit의 sort를 존재하지 않는 값인 oldest로 설정하자 422 invalid_value 응답이 왔습니다. 오류에는 허용되는 값이 모두 나열되어 있었고 “Nothing was charged”라는 문구가 있었습니다. 같은 테스트 키의 다른 요청이 분당 10건 한도를 소진했을 때는 retry_after 값이 포함된 429 rate_limited 응답이 왔습니다. 이 역시 과금되지 않았으며, retry_after에 10초를 더한 뒤 실행한 재시도는 모두 성공했습니다.

동기 요청이 빈 결과를 반환하면 count가 0이고 billing.reason이 empty_result_refunded로 설정된 200 응답이 오며, 과금되지 않습니다. 건별 정산 대조는 실패 환불과 정산 대조를 참고하세요. X 검색이 한도만큼 결과를 꽉 채워 반환하면 가장 이른 게시물이 잘릴 수 있으며, 응답에는 오류가 표시되지 않습니다. count를 한도와 직접 비교하세요.

최근 60일간의 변화와 관련 연구

2026년 10월 23일: CISA가 3일 기한과 포렌식 트리아지 요건을 붙여 CVE-2026-110447을 추가. CISA 경보를 참고하세요. 실무 시사점: KEV 항목의 forensicTriage: Yes 필드에는 별도 규칙을 둘 만합니다. 이 필드는 “패치한 뒤 침해되었는지 확인하라”는 뜻입니다.

2026년 10월 21일: PHP2Shell 공개, AWS는 악용이 4일 앞서 시작되었다고 발표. 위 비교 사례를 참고하세요. 실무 시사점: 조사할 때는 가장 이른 것으로 알려진 악용 시점부터 거슬러 따져 보세요. 권고 날짜부터 앞으로 세지 마세요.

2026년 10월 20일: CISA가 취약점 6건을 한꺼번에 추가, 그중 4건이 Plex2Shell. 실무 시사점: 점수가 낮은 취약점도 연쇄되면 KEV에 오를 수 있습니다. 단일 CVSS 점수 기준 필터는 이를 놓칩니다.

2026년 10월 14일: Collabora가 CVE 요청 대기열을 지연 원인으로 지목하고 CNA 등록을 신청. 실무 시사점: 오픈소스 프로젝트가 CNA가 되면 ID가 더 빨리 나올 것입니다. 그전까지는 ID 기반 구독이 한 달 늦을 수 있습니다.

2026년 10월: Second Security가 Patchless Window 연구를 발표. 8월에는 수정이 공개된 뒤 CVE가 공개되기까지 걸린 시간의 중앙값이 39.2일이었습니다. 실무 시사점: 오픈소스 컴포넌트는 ID를 기다리지 말고 커밋, 릴리스, 이슈로 모니터링하세요.

2026년 9월 25일: GitHub 익스플로잇 저장소의 스타, 포크, 사용자 수로 우선순위를 매기는 지표 GPM을 제안한 arXiv 논문 발표 (arXiv 2609.31004). 논문에 따르면 GPM은 EPSS 버전 5에 통합되었습니다. 실무 시사점: 공개 저장소 활동이 이제 공식 점수 산정의 일부가 되었습니다. 하지만 이번 신호는 익스플로잇 코드가 아니라 이슈 트래커의 피해 보고였으므로, 이 지표로는 잡히지 않습니다.

2026년 8월 19일: 실제 운영 중인 위협 지식 그래프를 위협 관련 소셜 게시물 10,000건과 비교한 연구 (Information 저널). 그래프에는 게시물 속 조치 가능한 취약점의 96%가 이미 들어 있었고, 보고 속도도 최소한 같았습니다. 소셜 미디어가 앞선 부분은 활성 악용에 대한 조기 경보뿐이었습니다. 실무 시사점: 이 연구는 우리 결과와 일치합니다. 소셜 데이터의 가치는 CVE 커버리지가 아니라 소수의 피해 보고와 소문에 있습니다.

2026년 8월: STINER 연구가 X의 경보로 유럽 위협 현황을 분석 (arXiv 2608.14418). 국가마다 공격이 X에서 드러나는 정도가 크게 다르다는 결과를 얻었습니다. 실무 시사점: 소셜 모니터링에서 언어와 지역은 고정 변수입니다. 이번 사례에서 KEV 이전 X에 올라온 유일한 직접 보고는 일본어 게시물 1건이었습니다. 방법론 배경으로, 2015년 USENIX Security 논문이 이미 Twitter 게시물로 실제 익스플로잇을 예측하려 시도했습니다.

이 글의 한계

첫째, 주요 사례는 하나뿐이며 비교 사례도 각각 한 번씩만 검색했습니다. 악용되지 않은 취약점으로 구성한 대조군이 없으므로 오탐률을 계산할 수 없습니다. 또한 “해킹당했다”는 이슈가 모두 실제 취약점을 뜻한다고 말할 수도 없습니다. 이번에 이슈 신호를 믿을 수 있었던 것은 로그가 있었고, 여러 사람이 같은 현상을 보았고, 메인테이너가 3일 안에 답했기 때문입니다. 다른 이슈에는 이 세 가지가 모두 갖춰져 있지 않을 수 있습니다.

둘째, X 검색은 순위가 매겨진 표본을 반환합니다. ID 검색은 게시물 106건을 반환해 한도에 이르지 않았지만, X에 더 이른 게시물이 없다고 증명할 수는 없습니다. until 날짜 상한은 이를 사용한 요청 4건 모두에서 엄격하게 적용되지 않았으므로 posted_at으로 필터링했습니다. Reddit 검색은 최근 1개월만 다루므로 9월 10~25일의 Reddit은 확인할 수 없었습니다. 10월 14일 이전의 reddit.com을 대상으로 일반 웹 검색을 해 보니 오래된 설치 관련 질문만 나왔고, 침해 보고는 없었습니다.

셋째, 노이즈 라벨은 미리 작성한 규칙으로 한 번만 붙였으며, 두 번째 라벨러는 없었습니다. “신호”와 “재게시”의 경계에는 어느 정도 판단이 개입합니다. 예를 들어 권고문을 체크리스트로 다시 쓴 게시물은 재게시로 분류했지만, 다른 사람은 신호로 볼 수도 있습니다.

넷째, SSVC와 EPSS에 관한 관찰은 설명에 이미 악용 사실이 적혀 있는 한 가지 상황에만 해당합니다. 이를 “이 필드들은 항상 느리다”로 확대하지 마세요. EPSS는 확률을 추정하며, KEV를 되풀이하는 것이 목적이 아닙니다.

FAQ

CISA가 취약점을 KEV에 추가하면 무슨 의미인가요?

CISA가 CVE ID, 실제 환경에서 악용되었다는 신뢰할 만한 증거, 명확한 해결 지침을 확보했다는 뜻입니다. BOD 26-04에 따라 연방 기관은 항목에 적힌 기한까지 수정해야 합니다. 이번 사례에서는 기한이 3일이었고 포렌식 트리아지도 필요했습니다. KEV는 항상 CVE 공개 뒤에 나옵니다. 이번에는 CVE보다 9.7일, 첫 공개 보고보다 42.2일 늦었습니다. (검색 추천어 “cisa kev meaning”에서 가져온 질문입니다.)

EPSS와 CISA KEV, 우선순위를 정할 때 무엇을 써야 하나요?

둘은 서로 다른 질문에 답합니다. KEV는 악용이 확인되었음을 알려 주고, EPSS는 향후 30일 안에 악용이 관측될 확률을 추정합니다. 이번 사례에서 EPSS는 KEV 등재 전 10일 동안 1.2%에 머물렀습니다. 표본 중 데이터가 있는 KEV CVE 12건은 KEV 전날 EPSS 점수가 모두 10% 미만이었습니다. 정렬에는 둘 다 사용하고, “exploited in the wild”를 찾는 텍스트 규칙을 추가하세요. (검색 추천어 “epss vs cisa kev”에서 가져온 질문입니다.)

Nextcloud Collabora 취약점은 어떻게 해결하나요?

“Collabora Online - Built-in CODE Server” 앱을 26.4.303으로 업그레이드하거나 제거하세요. 비활성화만으로는 충분하지 않습니다. Nextcloud 29 이하를 운영한다면 Nextcloud를 업그레이드하거나 앱을 제거하세요. 독립 실행형 Collabora 서버는 영향을 받지 않습니다. 인스턴스가 노출되었다면 무결성 검사 실행, 로그 검토, 자격 증명 교체도 함께 진행하세요. (검색 추천어 “nextcloud collabora vulnerability fix”에서 가져온 질문입니다.)

관련 글

• 플랫폼 페이지: X (Twitter) 스크래핑 API, Reddit 스크래핑 API, Weibo 스크래핑 API
• 기능 페이지: X 검색, Reddit 검색, YouTube 검색, LinkedIn 검색, Threads 검색, Weibo 검색
• 같은 시리즈: 제품으로서의 취약점 인텔리전스, 펌프 앤 덤프 소셜 신호, 연구 표본으로서의 소셜 데이터

참고 자료

1. CollaboraOnline/richdocumentscode, GitHub 이슈 #354 “Security issue - Hack”, 2026년 9월 11일, https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode, 릴리스 26.4.303, 2026년 9월 11일, https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub, REST API endpoints for issues, 2026년 10월 26일 접속, https://docs.github.com/en/rest/issues/issues
4. Nextcloud 커뮤니티 포럼, “To Collabora Built-in User: Update ASAP”, 2026년 10월 3일, https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse, API 문서, 2026년 10월 26일 접속, https://docs.discourse.org/
6. CVE Program, CVE-2026-110447 레코드, 2026년 10월 14일, https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API, CVE-2026-110447 레코드 메타데이터, 2026년 10월 26일 접속, https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD, CVE-2026-110447 상세 정보, 2026년 10월 14일 공개, 2026년 10월 24일 수정, https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD, CVE Change History API, 2026년 10월 26일 접속, https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online, 보안 권고 GHSA-g3vx-3m76-fghh, 2026년 10월 14일, https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online, “Stay Safe: Upgrade Everything Regularly”, 2026년 10월 14일, https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys, “Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection”, 2026년 10월 16일, https://censys.com/advisory/cve-2026-110447/
13. CISA, Known Exploited Vulnerabilities Catalog, 2026년 10월 26일 접속, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA, KEV JSON 피드(버전 2026.10.23), 2026년 10월 26일 접속, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA, “Reducing the Significant Risk of Known Exploited Vulnerabilities”(KEV 기준), 2026년 10월 26일 접속, https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security, “The Patchless Window”, 2026년 10월, https://thepatchlesswindow.com/
17. BleepingComputer, “Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers”, 2026년 10월 15일, https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST, “NIST Updates NVD Operations to Address Record CVE Growth”, 2026년 4월 15일, https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News, Algolia 검색 API, 2026년 10월 26일 접속, https://hn.algolia.com/api
20. Hacker News, “Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers” 링크 게시물, 2026년 10월 15일, https://news.ycombinator.com/item?id=50111052
21. Reddit r/NextCloud, 관리자 보고 “Nextcloud compromised via the built-in Collabora app”, 2026년 10월 22일, https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
22. cisagov, Vulnrichment 저장소, 2026년 10월 26일 접속, https://github.com/cisagov/vulnrichment
23. FIRST, EPSS Frequently Asked Questions, 2026년 10월 26일 접속, https://www.first.org/epss/faq
24. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 2026년 6월 10일, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
25. FIRST, EPSS “Get the Data”(API 포함), 2026년 10월 26일 접속, https://www.first.org/epss/data
26. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC), 2026년 10월 26일 접속, https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
27. CISA, “Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway”, 2026년 9월 27일(10월 9일 업데이트), https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
28. Citrix, 보안 게시판 CTX697096, 2026년 9월 27일, https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
29. NIST NVD, CVE-2026-88771 상세 정보, 2026년 9월 27일, https://nvd.nist.gov/vuln/detail/CVE-2026-88771
30. Plex 포럼, “Important Security Update for Plex Media Server v1.43.2 and earlier”, 2026년 9월 1일, https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. Agenzia per la Cybersicurezza Nazionale (ACN), “Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell”, 2026년 10월, https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog, “Plex vulnerabilities being exploited in the wild to drop a cryptominer”, 2026년 10월 17일, https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA, “CISA Adds Six Known Exploited Vulnerabilities to Catalog”, 2026년 10월 20일, https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. NIST NVD, CVE-2026-96652 상세 정보, 2026년 9월 23일, https://nvd.nist.gov/vuln/detail/CVE-2026-96652
35. AWS Security Blog, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, 2026년 10월 21일, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
36. CERT-EU, 보안 권고 2026-018 “Critical Vulnerabilities in PHP”, 2026년 10월 20일, https://cert.europa.eu/publications/security-advisories/2026-018
37. NIST NVD, CVE-2026-109618 상세 정보, 2026년 10월 21일, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
38. CISA, “CISA Adds One Known Exploited Vulnerability to Catalog”(CVE-2026-110447), 2026년 10월 23일, https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
39. Akhoundali 외, “GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)”, arXiv 2609.31004, 2026년 9월 25일, https://arxiv.org/abs/2609.31004
40. “Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph”, Information 17(8):794, 2026년 8월 19일, https://www.mdpi.com/2078-2489/17/8/794
41. Ech-Chammakhy 외, “STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X”, arXiv 2608.14418, 2026년 8월 14일, https://arxiv.org/abs/2608.14418
42. Sabottke, Suciu, Dumitraș, “Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits”, USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
43. X 고객센터, “How to use advanced search”, 2026년 10월 26일 접속, https://help.x.com/en/using-x/x-advanced-search
44. NIST NVD, CVE API 문서, 2026년 10월 26일 접속, https://nvd.nist.gov/developers/vulnerabilities
45. The Hacker News, “Hackers Backdoor Nextcloud Servers Through Critical Flaw in Collabora’s Built-in CODE App”, 2026년 10월, https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html