[.NET] CVE-2026-88092란? Kestrel 요청 스머글링, 런타임 올리고 재시작

 

CVE-2026-88092는 ASP.NET Core의 웹 서버 Kestrel이 중단한 HTTP/1 연결에서 아직 읽지 않은 요청 본문을 새 요청으로 다시 읽는 결함이다. 리버스 프록시 뒤에서 HTTP 요청 스머글링으로 이어질 수 있고, CVSS 점수는 9.4다. ASP.NET Core 런타임을 8.0.32·9.0.21·10.0.13 이상으로 올리고 앱을 다시 시작하면 고쳐진다.

 

이 글은 .NET 보안 공지(dotnet/announcements #472), Microsoft 보안 업데이트 가이드(MSRC), GitHub 보안 권고, 10월 릴리스 노트를 대조한다. 대상인지는 「내 서버가 대상인가」, 할 일은 「지금 해야 할 일」에 정리했다.

 

다른 언어로 읽기: English · 日本語 · Tiếng Việt

 

 

한눈에 보는 CVE-2026-88092

공개된 사실만 표로 모았다.

 

2026년 10월 28일 기준, .NET 보안 공지 #472와 MSRC 페이지를 바탕으로 정리했다.

 

항목	내용
공개	2026년 10월 13일(정기 보안 업데이트)
결함 위치	Kestrel(ASP.NET Core 웹 서버)
약점 분류	CWE-444, HTTP 요청 스머글링
점수	CVSS 3.1 기준 9.4(Critical)
MSRC 등급	중요(Important), 변조
공격 조건	인증 없음, 사용자 상호작용 없음
대상	.NET 8·9·10, .NET 11 RC1 이하
악용 여부	공개·악용 없음, 악용 가능성 낮음
조치	런타임 업데이트 후 앱 재시작

 

공지가 지목한 구성 요소는 Microsoft.AspNetCore.Server.Kestrel.Core이고, 결함을 알린 사람으로는 thegoldmandm이 적혀 있다. 10월 13일에 나온 .NET 보안 공지 46건 가운데 점수가 두 번째로 높고, 이름에 ASP.NET Core가 붙은 공지 중에서는 가장 높다.

 

 

무엇이 문제인가: 중단된 연결에 남은 본문

HTTP/1.1에서는 연결 하나로 요청을 여러 개 차례로 보낼 수 있다. 서버는 앞 요청의 본문이 어디서 끝나는지 알아야 다음 요청의 시작을 찾는다. 이 경계를 프록시와 서버가 다르게 보면 생기는 공격이 HTTP 요청 스머글링이다.

 

공지가 밝힌 Kestrel의 결함은 이렇다. Kestrel이 HTTP/1 연결을 중단(abort)할 때 읽지 않은 요청 본문 바이트가 남아 있으면, 그 바이트를 다른 요청으로 다시 해석할 수 있다. 원래 앞 요청의 본문이던 글자가 새 요청이 되는 셈이다.

 

리버스 프록시 뒤에서 일어나는 일(개념도)

1

조작한 요청

인증 없는 공격자가 HTTP/1.1 요청을 리버스 프록시로 보낸다

2

프록시가 요청을 전달한다

프록시는 이 요청을 평소처럼 Kestrel로 넘긴다

3

Kestrel이 연결을 중단

읽지 않은 본문 바이트가 남은 채 연결 처리가 끝난다

4

요청 경계가 어긋난다

남은 바이트가 새 요청으로 해석돼, 의도하지 않은 요청이 끼어들 수 있다

출처: .NET 보안 공지 #472, MSRC FAQ

 

MSRC FAQ가 꼽은 공격 경로는 리버스 프록시를 거쳐 서버로 들어오는 요청이다. 공격자는 계정이 없어도 되고, 누가 무엇을 눌러 줄 필요도 없다. 조작한 HTTP/1.1 요청 하나로 프록시와 Kestrel이 요청의 끝을 서로 다르게 보게 되면, 그 틈으로 의도하지 않은 요청이 들어올 수 있다.

 

일반적으로 요청 스머글링은 끼워 넣은 요청이 프록시의 검사를 거치지 않는다는 점이 위험하다. 이 결함을 .NET 공지는 "보안 기능 우회"로, MSRC는 "변조"로 분류했고 기밀성·무결성을 모두 "높음"으로 평가했다. 다만 공지는 구체적인 피해나 우회 사례를 적지 않았다.

 

 

내 서버가 대상인가

.NET 8·9·10과 .NET 11 미리 보기의 ASP.NET Core 런타임이 대상이다. 공지가 지목한 곳은 Kestrel이고, MSRC가 적은 공격 경로는 리버스 프록시 뒤의 서버다.

 

배포 방식별로 볼 곳

프록시 뒤 Kestrel 공격 경로

Nginx, YARP, IIS out-of-process 같은 리버스 프록시 뒤에서 Kestrel이 요청을 받는 앱

할 일

런타임 업데이트앱 재시작

MSRC FAQ는 리버스 프록시까지만 적었다. 제품 이름은 예시다

자체 포함 배포 self-contained

런타임을 앱 안에 넣어 배포한 앱, 그리고 컨테이너 이미지

할 일

새 SDK로 다시 게시이미지 다시 빌드

서버 런타임을 올려도 바뀌지 않는다

공지가 적지 않은 것 영향 여부 미기재

ASP.NET Core 2.3(.NET Framework)은 대상 목록에 없다. IIS in-process·HTTP.sys는 공지가 영향 여부를 따로 적지 않았다

할 일

대상 버전이면 똑같이 런타임 업데이트

목록은 런타임 버전 범위이지 호스팅 방식 목록이 아니다

출처: .NET 보안 공지 #472, MSRC, Microsoft Learn

 

공지에 적힌 대상과 고친 버전은 다음과 같다. 런타임 버전 기준이다.

 

버전 줄	대상 버전	고친 버전
.NET 8	8.0.0 ~ 8.0.31	8.0.32(SDK 8.0.426)
.NET 9	9.0.0 ~ 9.0.20	9.0.21(SDK 9.0.319)
.NET 10	10.0.0 ~ 10.0.12	10.0.13(SDK 10.0.402)
.NET 11	preview.1 ~ RC1	RC2

 

• IIS in-process 호스팅: Microsoft Learn 문서에 따르면 in-process 호스팅은 Kestrel 대신 IIS HTTP Server를 쓴다. ASP.NET Core 3.0부터 IIS의 기본값이다. 다만 공지는 IIS HTTP Server가 영향받는지 따로 적지 않았다. 업데이트는 서버 종류와 관계없이 공유 런타임 전체를 올리는 일이니 똑같이 한다
• ASP.NET Core 2.3: .NET Framework에서 도는 2.3은 이번 대상 목록에 없다
• Visual Studio: MSRC 표에는 Visual Studio 2022(17.14.42)와 2026(18.10.4)도 올라 있다. 공지는 Visual Studio로 설치한 SDK는 Visual Studio 업데이트로 받도록 안내한다

 

반응형

 

지금 해야 할 일

공지가 요구하는 일은 최신 .NET 런타임·SDK를 설치하고 앱을 다시 시작하는 것이다. 자체 포함 배포 앱은 다시 게시해 재배포해야 한다.

 

# 서버에 설치된 ASP.NET Core 런타임 확인
dotnet --list-runtimes
# 고쳐진 런타임: 8.0.32 / 9.0.21 / 10.0.13 이상

# 자체 포함 배포: 업데이트한 SDK로 다시 게시한다
dotnet publish -c Release -r linux-x64 --self-contained

 

1. 런타임·SDK 업데이트: 앱이 실행되는 서버와 빌드 장비를 모두 업데이트한다. IIS 서버는 .NET 런타임과 ASP.NET Core Module을 함께 설치하는 Hosting Bundle로 올린다. 지금 내려받는 판은 10월 25일 긴급 업데이트(8.0.33·9.0.22·10.0.14)다. 공지의 대상 범위(8.0.31·9.0.20·10.0.12 이하)보다 높은 판이다
2. 앱 다시 시작: 공지는 런타임을 설치한 뒤 앱을 다시 시작해야 반영된다고 적었다. 실행 중인 프로세스는 옛 런타임을 계속 쓴다
3. 자체 포함 배포·컨테이너: Learn 문서대로 자체 포함 배포는 게시하는 장비의 SDK에 든 최신 패치 런타임을 넣는다. 새 SDK로 다시 게시해야 바뀐다. RuntimeFrameworkVersion을 고정해 두었다면 그 값도 고친다. 컨테이너는 mcr.microsoft.com/dotnet/aspnet 기본 이미지를 새로 받아 다시 빌드한다

 

공지의 대상 패키지는 Microsoft.AspNetCore.App.Runtime.<플랫폼>이다. 자체 포함 배포로 게시할 때 앱에 들어가는 런타임 팩이다. 공지는 이 패키지를 프로젝트에서 직접 참조한다면 참조를 고친 버전으로 올리라는 단계도 적었다. 보통은 직접 참조가 없어 위 세 단계로 끝난다. .csproj에서 Microsoft.AspNetCore.App.Runtime을 검색해 확인한다.

 

바로 올릴 수 없다면

공지와 MSRC는 설정으로 막는 임시 조치를 적지 않았다. 공격 경로가 리버스 프록시를 거치는 HTTP/1.1 요청이므로, 외부에 열린 프록시 뒤의 Kestrel 앱부터 먼저 업데이트하는 것이 현실적이다. 이것은 우선순위 판단이지 공식 완화책이 아니다.

 

 

실제 공격은 있었나

MSRC는 이 CVE를 "공개된 적 없음, 악용 없음, 악용 가능성 낮음"으로 평가했다(첫 공개 시점 기준). CVSS 시간(Temporal) 지표도 공격 코드가 증명되지 않음(E:U), 공식 수정 있음(RL:O)으로 적혀 있어 시간 점수는 8.2다.

 

기본 점수가 9.4로 높은 이유는 네트워크로 공격할 수 있고, 인증과 사용자 상호작용이 필요 없으며, 성공하면 기밀성과 무결성 피해가 크기 때문이다. 인터넷에 열린 서비스라면 악용 가능성 평가와 관계없이 먼저 올릴 대상이다.

 

 

한국 기준으로 보면

KISA 보호나라는 10월 15일 「MS 10월 보안 위협에 따른 정기 보안 업데이트 권고」를 냈다. 그 취약점 목록에 ASP.NET Core 변조 취약성(CVE-2026-88092)이 들어 있다. MSRC 한국어 페이지와 같은 이름이다.

 

이 권고는 Microsoft 10월 정기 업데이트 전체를 다루므로 .NET 항목이 긴 목록 안에 들어 있다. 서버마다 .NET 런타임이 올라갔는지는 따로 확인해야 한다.

 

Microsoft Learn 설치 문서에 따르면 .NET은 Windows Update가 아니라 Microsoft Update로 갱신된다. 서버 OS에서는 자동 업데이트 대상이 아니다. WSUS나 Microsoft Update Catalog로 배포하거나, 레지스트리(AllowAUOnServerOS)로 자동 업데이트를 따로 켜야 한다.

 

리눅스 서버와 컨테이너는 배포판 패키지나 이미지로 따로 올린다. 그래서 서버마다 dotnet --list-runtimes 결과를 직접 확인하는 편이 안전하다.

 

 

헷갈리기 쉬운 점

• 이름이 두 가지다: .NET 공지와 릴리스 노트는 "보안 기능 우회(Security Feature Bypass)", MSRC와 CVE 레코드는 "변조(Tampering)"라고 부른다. 같은 결함이다
• 등급도 두 가지다: CVSS 기준으로는 Critical(9.4)이고, MSRC의 최대 심각도는 중요(Important)다. 같은 점수(9.4)를 서로 다른 기준으로 부를 뿐이다
• 작년 CVE-2025-55315와 다른 결함이다: 2025년 10월에도 ASP.NET Core 요청 스머글링 결함(CVSS 9.9)이 있었고, 그때는 ASP.NET Core 2.3도 대상이었다. 이번 것은 새 번호이고 2.3이 대상에 없다
• 대개 패키지가 아니라 런타임을 올린다: 같은 10월 업데이트의 Blazor 디버거 결함(CVE-2026-102870)은 NuGet 패키지를 직접 올려야 했다. 이번 결함은 공유 런타임에 든 Kestrel이 고쳐지므로 런타임 업데이트와 재시작으로 끝난다(자체 포함 배포 제외)
• 고친 버전은 10.0.13이고, 더 높은 판도 된다: 공지 #472의 고친 버전은 8.0.32·9.0.21·10.0.13이다. 10월 25일 긴급 업데이트(8.0.33·9.0.22·10.0.14)는 이 CVE를 따로 다루지 않지만 대상 범위보다 높은 판이다. 공지 #472는 개정되지 않았다(V1.0)

 

반응형

 

자주 묻는 질문

자주 나올 질문 네 가지에 짧게 답한다.

 

CVE-2026-88092는 어떤 취약점인가?

ASP.NET Core의 Kestrel이 중단한 HTTP/1 연결에서 읽지 않은 요청 본문을 새 요청으로 다시 해석하는 결함이다. 리버스 프록시와 서버의 요청 경계가 어긋나 공격자가 요청을 끼워 넣을 수 있다. CVSS 3.1 점수는 9.4다.

 

어떤 버전으로 올려야 하나?

ASP.NET Core 런타임을 8.0.32·9.0.21·10.0.13 이상으로 올린다. .NET 11 미리 보기는 RC2 이상이다. 지금 받는 최신판(8.0.33·9.0.22·10.0.14)도 이 기준 이상이다.

 

프록시를 쓰지 않으면 안전한가?

MSRC가 적은 공격 경로는 리버스 프록시를 거치는 요청이다. 다만 공지는 프록시가 없는 구성이 대상이 아니라고 말하지 않았다. 대상 버전이면 구성과 관계없이 올린다.

 

NuGet 패키지를 고쳐야 하나?

대부분은 고칠 필요가 없다. 공지의 대상 패키지는 자체 포함 배포에 들어가는 런타임 팩이고, 서버의 런타임을 올리고 앱을 다시 시작하면 된다. 다만 .csproj에서 Microsoft.AspNetCore.App.Runtime.* 패키지를 직접 참조한다면 그 참조를 고친 버전으로 올린다.

 

 

한 줄 정리

• CVE-2026-88092는 Kestrel이 중단한 HTTP/1 연결의 남은 본문을 새 요청으로 읽어, 리버스 프록시 뒤에서 요청 스머글링이 생기는 결함이다
• CVSS 9.4로 10월 .NET 공지 가운데 점수가 높은 편이고, 악용은 확인되지 않았다
• ASP.NET Core 런타임을 8.0.32·9.0.21·10.0.13 이상으로 올리고 앱을 다시 시작한다. 자체 포함 배포는 다시 게시하고 컨테이너는 다시 빌드한다

 

참고

• .NET 보안 공지 #472 — CVE-2026-88092
• MSRC — CVE-2026-88092 ASP.NET Core 변조 취약성
• GitHub 보안 권고 GHSA-rv87-ccxw-8ggf(.NET 저장소)
• GitHub Advisory Database — GHSA-rv87-ccxw-8ggf
• .NET 10.0.13 릴리스 노트
• .NET 2026년 10월 긴급 보안 업데이트 공지 #496
• Microsoft Learn — IIS와 ASP.NET Core의 In-process 호스팅
• Microsoft Learn — Hosting Bundle
• Microsoft Learn — 자체 포함 배포의 런타임 롤포워드
• Microsoft Learn — Windows에 .NET 설치(Microsoft Update)
• GitHub Advisory Database — CVE-2025-55315(GHSA-5rrx-jjjq-q2r5)
• KISA 보호나라 — MS 10월 보안 위협에 따른 정기 보안 업데이트 권고

 

함께 보면 좋은 글

• [.NET] CVE-2026-102870이란? Blazor 디버거 결함, 10.0.13도 10.0.14로 — 같은 10월 업데이트지만 런타임이 아니라 NuGet 패키지를 직접 올려야 했던 Blazor 결함이다