AI 취약점 대량 발견 시대 패치 주기: GPT-6 Cyber 리눅스 948건이 남긴 기준 [2026]

OpenAI는 11월 5일(시스템 카드 게시일 기준) 보안 특화 모델 GPT-6 Cyber를 공개하면서, 이 모델로 Firefox에서 높음 등급 신규 취약점 81개를 찾고 리눅스 커널에서 일반 사용자를 root로 올리는 권한 상승 공격 코드 948건을 만들었다고 밝혔습니다. 리눅스 연구에서는 후보 결함 2,308건을 12시간 안에 뽑았고, 그중 1,724건을 30시간 안에 실제로 재현했습니다.

취약점이 '가끔 발견되는 사건'에서 '대량으로 쏟아지는 물량'으로 바뀌고 있다는 신호입니다.

이 글은 숫자를 원문 그대로 정리하고, 그 숫자가 우리 회사의 패치·점검 주기에 무엇을 요구하는지 다룹니다. 분기 1회 점검과 월 1회 패치로 버틸 수 있는지, 무엇을 먼저 고칠지 어떻게 정할지, AI가 찾은 결과를 누가 어떻게 검증할지까지 순서대로 봅니다.

한눈에 보기

항목	내용
무엇이 나왔나	OpenAI 보안 특화 모델 GPT-6 Cyber. 시스템 카드 게시일 11월 5일(보도는 11월 6일)
누가 쓸 수 있나	승인된 Daybreak Red 고객 일부부터 API와 Codex로 제공. Daybreak Red API는 기본적으로 허용된 IP에서만 호출 가능
위험 등급	OpenAI 대비 체계(Preparedness Framework)에서 사이버보안 '치명(Critical)'. 이전 모델 GPT-5.6 Cyber는 '높음(High)'
Firefox	높음 등급 신규 취약점 81개, 기존 30개는 알려진 것보다 심각하다고 확인(OpenAI 발표). Mozilla는 10월 27일 Firefox 159 권고(MFSA 2026-118)로 수정 배포
리눅스 커널	10월 중순 최신 커널 대상. 후보 2,308건(12시간), 재현 1,724건(30시간), 작동하는 권한 상승 공격 코드 1,169건, 고유 취약점 기준 948건
비용	10월 캠페인 전체 API 비용 1,213,430달러. 성공한 권한 상승 공격 코드 1건당 평균 약 359달러
패치 진행	자동 스캔과 수동 분석이 끝난 10일 시점에 61건 상위 커널 반영, 43건 반영 대기, 299건 공개 보고·논의 중. 치명 304건은 후보 패치와 함께 관리자에게 전달
기업에 주는 뜻	외부 노출, KEV 등재 여부, 공격 자동화 가능성, 피해 크기로 패치 기한을 나누고, 점검을 '정기'에서 '상시'로 옮길 때

무엇이 발표됐나

GPT-6 Cyber: 찾는 능력과 선을 지키는 능력

OpenAI 발표에 따르면 GPT-6 Cyber는 지정한 취약점을 실제로 공격할 수 있는지 보는 평가(ExploitGym)에서 48.5%를 기록했습니다. 이전 모델 GPT-5.6 Cyber는 32.1%였습니다. 소스 코드 없이 웹 애플리케이션을 탐색하는 모의해킹 평가에서는 취약점 재현율 40.3%로, 일반 모델 GPT-6 Astra의 32.0%보다 높았습니다.

OpenAI는 같은 발표에서 '범위를 벗어나지 않는 능력'도 강조했습니다. 일부러 공격하기 쉬운 주변 서비스를 함께 둔 시험에서, 배포용 안전 지시가 없을 때도 99.93%의 경우 범위 밖 서비스를 공격하지 않았다고 합니다. GPT-5.6 Cyber는 94.49%였습니다. 접근은 승인된 고객부터 단계적으로 넓히고, 탈취된 인증 정보 악용을 막기 위해 IP 허용 목록을 기본으로 요구한다고 밝혔습니다.

Firefox: 81개, 그리고 권고 방식의 변화

OpenAI는 GPT-6 Cyber가 Mozilla 기준 높음 등급의 신규 취약점 81개에 대해 증거와 재현 가능한 시험을 만들었고, 수정안과 함께 Mozilla에 전달했다고 밝혔습니다.

Mozilla의 10월 27일 권고 MFSA 2026-118(Firefox 159에서 수정)을 직접 세어 보면 CVE 항목이 167개이고, 그중 108개가 높음 등급입니다. 제보자가 OpenAI로 표기된 항목은 41개로, 모두 높음 등급입니다. 81개 전부가 이 권고 하나에 실렸는지는 확인되지 않습니다. OpenAI도 '많은 취약점의 수정이 배포됐다'고 썼습니다.

눈여겨볼 점이 하나 더 있습니다. Mozilla는 이 권고부터 내부에서 찾은 메모리 안전성 취약점을 CVE 하나로 묶지 않고 결함마다 따로 권고를 낸다고 공지했습니다. 패치 노트 한 장에 실리는 CVE 수가 앞으로 크게 늘어난다는 뜻입니다. CVE 개수로 위험을 가늠하던 습관은 맞지 않게 됩니다.

리눅스 커널: '30시간에 948건'이 아니다

연구 원문(A thousand fewer paths to root)의 단계별 숫자는 다음과 같습니다. 일부 보도처럼 '30시간 실행으로 948건'을 만든 것이 아니라, 30시간은 재현 단계에 걸린 시간입니다.

단계	결과	걸린 시간·비용
감사 대상 고르기	5,034개 대상, 약 280만 줄(커널 전체의 약 7%)	3,426달러
결함 후보 찾기	중복 제거 뒤 후보 2,308건	12시간 이내, 316,549달러
재현(검증)	1,724건 재현(약 74.7%). 모델의 잘못된 분석은 3.1%	30시간 이내, 73,330달러
공격 가능성 평가	정보 유출 PoC(개념 증명 코드) 291건, 작동하는 권한 상승 공격 코드 1,169건	공격 단계 775,929달러
고유 취약점 정리	서로 다른 패치 948개 기준으로 고유 권한 상승 취약점 948건	전체 10일(자동 스캔과 수동 분석)

시험 환경은 일반 배포판과 같은 커널 보호 기능(SMEP, SMAP, KASLR, HARDENED_USERCOPY)을 켠 상태였습니다. 대상도 '특별한 권한이 없는 일반 사용자가 닿을 수 있는 코드'로 좁혔습니다. 즉 서버에 일반 계정 하나만 있으면 쓸 수 있는 종류의 결함입니다.

모델 세대 차이도 뚜렷합니다. 7월 말 GPT-5.6 Sol로 같은 방식의 스캔을 했을 때는 고유 권한 상승 취약점 166건(비용 513,690달러)이었고, 10월에는 948건이었습니다. 연구진은 '모델 능력이 오르면 이미 점검한 코드도 다시 점검하라'고 정리했습니다.

SecurityWeek 보도에 따르면 OpenAI는 "가까운 시기에는 최신 패치를 하지 않은 운영체제의 저권한 계정 접근을, 자원이 충분한 공격자에게는 root 접근과 사실상 같은 것으로 봐야 한다"고 경고했습니다.

사람 검증이 빠지면 생기는 일

같은 연구에는 기업이 그대로 가져갈 교훈이 있습니다. 초기 실행에서 공격 단계가 '성공' 200건을 보고했는데, 사람이 다시 보니 그중 20건은 배정된 취약점이 아니라 다른 제로데이(아직 알려지지 않은 취약점)로 root를 얻은 것이었습니다. 연구진은 결과뿐 아니라 결과에 이른 경로까지 검증해야 한다고 적었습니다.

OpenAI가 Trail of Bits와 함께 운영하는 오픈소스 지원 사업 Patch the Planet도 같은 원칙을 씁니다. 공지에 따르면 AI가 찾은 결과는 오탐(실제로는 문제가 아닌 결과)도 많이 만들기 때문에, 보안 엔지니어가 관리자에게 넘기기 전에 하나하나 재현하고 중복을 지우고 심각도를 다시 매깁니다. OpenAI는 이 모델을 Brotli 취약점(CVE-2026-111497, 국내에서는 HTTP2Shell로 알려짐)의 원격 코드 실행 가능성 검증에도 썼다고 밝혔습니다. 이 취약점의 대응은 HTTP2Shell(Node2Shell) 대응 글에 정리했습니다.

왜 패치·점검 주기를 바꿔야 하나

미국 CISA는 6월 10일 연방기관용 지침 BOD 26-04 '위험 기반 보안 업데이트 우선순위'를 내고 기존 KEV 지침(BOD 22-01)을 대체했습니다. 배경 설명에 "공격자의 AI 사용이 패치 공개와 악용 사이의 대응 시간을 더 줄일 수 있다"는 문장이 들어 있습니다. 국내 민간 기업에 적용되는 규정은 아니지만, 무엇을 며칠 안에 고칠지 정하는 기준으로 참고할 만합니다.

BOD 26-04는 네 가지 질문으로 기한을 정합니다.

인터넷에 노출된 자산인가
KEV(CISA가 실제 악용을 확인한 취약점 목록)에 올라 있는가
공격자가 공격 단계를 자동화할 수 있는가
공격에 성공하면 자산을 전부 장악하는가, 일부만 영향을 주는가

상황(지침 표 일부)	조치 기한
노출 + KEV 등재 + 전부 장악	3일, 침해 여부 점검 포함
노출 + KEV 미등재 + 자동화 가능 + 전부 장악	3일
노출 + KEV 등재 + 자동화 어려움 + 일부 영향	14일
노출 + KEV 미등재 + 자동화 어려움 + 일부 영향	60일
내부 + KEV 등재 + 자동화 가능 + 전부 장악	3일, 침해 여부 점검 포함
내부 + KEV 미등재 + 자동화 어려움	다음 정기 업그레이드 때

두 가지가 눈에 띕니다. KEV에 오르지 않았어도 노출돼 있고 자동화 가능하며 전부 장악할 수 있는 결함이면 3일입니다. 그리고 내부 시스템이라도 KEV에 올라 있고 자동화 가능하며 전부 장악할 수 있는 취약점이면 3일에 침해 여부 점검까지 요구합니다. 우선순위를 CVSS 점수가 아니라 노출과 악용 여부로 정한다는 뜻입니다. CISA KEV 목록은 11월 6일 판 기준 1,769건이고, 올해 추가된 항목이 285건입니다(CISA 공개 데이터 직접 집계).

정리하면 바뀌는 것은 세 가지입니다.

지금까지	앞으로
분기·반기 정기 점검	외부 노출 자산은 상시 점검, 코드는 변경마다 점검, 사람 모의해킹은 정기적으로
월 1회 일괄 패치	노출·KEV·자동화·피해 크기로 3일, 14일, 60일, 정기 업그레이드로 나눈 기한
CVSS 높은 순	노출 + KEV 먼저. 점수 외 판단 근거는 제로데이 패치 우선순위 글 참고
한 번 점검한 코드는 통과	도구와 모델이 바뀌면 다시 점검
보고서 수만큼 일이 늘어남	AI로 넓게 찾고, 재현된 것만 사람이 검증해 처리

우리 회사에 해당하는지 확인하는 법

아래 중 하나라도 '예'면 이번 소식이 직접 해당합니다.

질문	왜 중요한가	확인 방법
일반 계정이나 남의 코드가 도는 리눅스 서버가 있나	이번 커널 결함은 일반 사용자 권한에서 root로 가는 종류	CI 실행 서버, 공용 개발 서버, 웹 서버(웹셸이 올라오면 웹 실행 계정이 곧 일반 사용자), 여러 고객이 함께 쓰는 서버를 목록으로
컨테이너를 쓰나	컨테이너는 호스트 커널을 함께 쓴다. 커널 결함은 컨테이너 경계에도 영향을 줄 수 있다	컨테이너 호스트의 커널 버전과 배포판 보안 공지 대조
서버 커널을 언제 마지막으로 올리고 재부팅했나	패키지만 설치하고 재부팅하지 않으면 옛 커널이 그대로 돈다	`uname -r`, Ubuntu·Debian은 `/var/run/reboot-required` 파일, RHEL 계열은 `needs-restarting -r`
사내 PC에서 Firefox를 쓰나	10월 27일 권고 하나에 높음 등급 108개	메뉴의 Firefox 정보에서 159 이상인지, 사내 배포 정책이 자동 업데이트를 막지 않는지
패치 기한이 문서로 정해져 있나	기한이 없으면 물량이 늘 때 뒤로 밀린다	보안 정책에 '노출·KEV·피해 크기별 기한'이 있는지
외부 노출 자산 목록이 최신인가	기한 표의 첫 질문이 '노출 여부'	도메인, 하위 도메인, 공인 IP, 관리자 페이지를 실제 응답 기준으로. 방법은 공격표면 관리 자가점검 5단계
AI 도구가 낸 취약점 보고를 받고 있나	보고가 늘면 진짜와 오탐을 가를 절차가 필요	재현 증거, 영향 경로, 중복 여부를 확인하는 절차가 있는지

대응 순서

오늘

사내 Firefox가 159 이상인지 확인한다. ESR 판을 쓰면 Mozilla의 ESR 권고를 따로 본다.
일반 계정이나 외부 코드가 실행되는 리눅스 서버 목록을 만든다. CI 실행 서버, 컨테이너 호스트, 공용 개발 서버, 외부에 열린 웹 서버부터.
그 서버들의 커널 버전과 재부팅 필요 여부를 확인한다(uname -r, 재부팅 필요 표시).
사용하는 배포판의 보안 공지(Ubuntu USN, Debian DSA, Red Hat RHSA 등)와 CISA KEV 신규 등재 알림을 담당자 메일로 받도록 구독한다.

이번 주

패치 기한 표를 정한다. BOD 26-04 표를 회사용으로 줄이면서 칸마다 공식 기한과 같거나 더 짧게 잡은 예시는 '외부 노출 + KEV 등재 또는 자동화 가능: 3일', '외부 노출 그 밖: 14일', '내부 + KEV 등재: 14일(자동화 가능하고 전부 장악이면 3일)', '내부 + KEV 미등재 + 자동화 가능: 60일', '내부 + KEV 미등재 + 자동화 어려움: 정기 업그레이드 때'입니다. 회사 상황에 맞게 숫자를 조정하되 문서로 남긴다.
커널 업데이트를 적용하고 재부팅 창을 잡는다. 재부팅이 어려운 서버는 배포판의 라이브 패치(재부팅 없이 커널을 고치는 기능) 지원 여부를 확인한다.
외부 노출 자산 목록을 실제 응답 기준으로 갱신하고, 목록에 없던 서버는 담당자를 정한다.
AI 도구가 낸 취약점 보고를 처리하는 절차를 정한다. 재현 증거가 있는지, 그 취약점이 실제로 결과를 만든 경로인지, 중복인지 확인한다. 기준은 AI 취약점 보고서 검증 절차 7가지에 정리했다.

이번 달

점검 주기를 바꾼다. 외부 노출 자산은 상시(최소 주 단위), 코드는 변경(배포 전 검토) 단위, 권한·비즈니스 로직처럼 자동 도구가 놓치기 쉬운 부분은 사람의 모의해킹으로 정기 확인한다. 자동 점검과 수동 점검의 역할 차이는 자동 스캔 vs 수동 모의해킹 글을 참고한다.
이미 점검을 마친 핵심 시스템도 새 도구로 다시 점검할 일정을 잡는다. 같은 커널을 7월에 166건, 10월에 948건 찾은 결과가 이유다.
'일반 계정 = root'를 가정하고 설계를 다시 본다. 서버 로그인 계정을 줄이고, 웹 서비스 실행 계정을 분리하고, 키와 비밀번호를 서버 파일에 두지 않는다.
패치 지표를 매달 보고한다. 기한 안에 처리한 비율, 기한을 넘긴 건수, 외부 노출 자산 중 미패치 수.

자가점검

1. 패치 기한이 위험 수준별로 문서화돼 있는가

'월 1회 일괄'만 있다면 해당하지 않습니다. 노출, KEV 등재, 피해 크기로 나눈 기한이 있어야 물량이 늘어도 순서가 무너지지 않습니다.

2. KEV 신규 등재를 누가, 언제 확인하는가

담당자와 확인 주기가 정해져 있는지 봅니다. 등재 뒤 우리 자산 해당 여부를 하루 안에 판단할 수 있어야 합니다.

3. 일반 계정이 접속하거나 외부 코드가 도는 리눅스 서버를 다 알고 있는가

CI 실행 서버와 컨테이너 호스트가 자주 빠집니다. 이번 결함은 바로 이런 서버에서 root로 가는 길이 됩니다.

4. 커널을 올린 뒤 재부팅까지 확인했는가

설치 기록만 보고 끝내지 않았는지 봅니다. 실행 중인 커널 버전이 바뀌어야 조치가 끝난 것입니다.

5. 외부 노출 자산 목록이 지난 한 달 안에 갱신됐는가

목록이 낡으면 기한 표의 첫 질문부터 틀립니다. 테스트 서버와 관리자 페이지가 빠지기 쉽습니다.

6. AI 도구가 낸 결과를 사람이 재현해 보고 처리하는가

OpenAI 연구에서도 '성공' 200건 중 20건은 다른 경로로 얻은 결과였습니다. 재현 증거 없이 바로 티켓으로 넘기면 오탐에 시간을 씁니다.

7. 한 번 점검한 시스템을 다시 점검할 일정이 있는가

도구와 모델이 바뀌면 찾는 범위도 바뀝니다. 핵심 시스템은 연 1회 이상 다시 보는 일정을 둡니다.

AI로 넓게 찾고, 사람이 확인하는 점검

보안 전문 기업 SENTRIX는 레드팀 운영과 보안 실무 10년 경험을 바탕으로 AI 모의해킹·AI 심화 취약점 진단을 제공합니다. AI 자동화로 웹·API를 넓게 훑고, 전문가가 권한 문제, 비즈니스 로직 결함, 여러 취약점을 엮는 연쇄 공격 경로를 직접 확인합니다. LLM과 AI 서비스 자체의 보안 검증도 포함됩니다. 이 글의 연구가 보여 준 것처럼 AI가 찾은 결과는 사람이 재현하고 경로를 확인해야 쓸 수 있는 정보가 됩니다. 수상 이력은 2025 식약처 주최 AI 레드팀 챌린지 최우수상(구성원)입니다. 기업은 웹 서비스 1개에 대해 AI 웹진단 1회를 무료로 받을 수 있습니다(서비스 페이지의 무료 체험 안내 참고). 정기 점검을 상시 점검으로 바꾸는 범위와 일정이 고민이라면 진단 문의하기에서 함께 정합니다.

참고 자료

패치 관리 GPT-6 Cyber AI 취약점 발견 리눅스 커널 권한 상승 Firefox 취약점 KEV 우선순위 상시 보안 점검 전체 태그 →

우리 회사 패치 기한부터 점검받기

보안 실무 10년 전문가가 기업 환경에 맞는 방안을 제시합니다.

진단 문의하기