.NET 의 위기와 관련해: .NET 8과 .NET 9에 대한 패치 지원이 중단되면 어떻게 될까요?

요약

한 번의 릴리스. 두 가지 프레임워크. 그 이후 패치는 전혀 없습니다.

2026년 11월 10일, 마이크로소프트는 ‘ .NET 8’(현재의 장기 지원(LTS) 릴리스)과 ‘ .NET 9’(현재의 표준 지원(STS) 릴리스)에 대한 지원을 같은 날 종료합니다. 이는 단순히 기다리면 지나갈 수 있는 우연한 일정이 아닙니다. 이 날은 해당 운영 체제에서 여전히 실행 중인 모든 애플리케이션에 대한 패치 제공이 영구적으로 중단되는 날입니다.

‍

귀사에서 .NET 8 또는 .NET 9를 운영 중인 경우, 이 가이드에서는 “지원 종료”로 인해 실제로 어떤 변화가 발생하는지, 규제 대상 팀들이 보안 침해보다는 규정 준수 및 보험 문제를 통해 이를 가장 먼저 체감하는 경향이 있는 이유, 그리고 .NET 10으로 마이그레이션하거나 지속적인 보안 지원을 통해 공백을 메우는 두 가지 현실적인 해결 방안을 단계별로 안내합니다.

‍

이 가이드에서 다루는 내용: “지원 종료”가 실제로 무엇을 중단시키는지, 왜 실제 보안 침해 사고 발생 이전에 규정 준수 및 보험 관련 위험이 먼저 드러나는지, 패치가 적용되지 않은 단일 프레임워크가 이를 기반으로 구축된 모든 시스템에 어떻게 위험을 가중시키는지, 그리고 90일 계획 등을 포함한 두 가지 위기 탈출 경로.

• 2026년 11월 10일: 마이크로소프트가 ‘ .NET 8’ 및 ‘ .NET 9’용 보안 패치를 배포하는 마지막 날
• 같은 날 지원이 종료되는 두 가지 프레임워크: LTS와 STS 릴리스가 동시에
• .NET 6의 지원 종료 이후 56건의 CVE가 공개되었으며, 이는 NES( .NET 6)에서 수정되었습니다.

‍

이 마감일이 왜 특이한가

LTS 및 STS 릴리스는 일반적으로 동시에 만료되지 않습니다.

마이크로소프트의 .NET 릴리스 주기는 위험을 분산하도록 설계되었습니다. .NET 8과 같은 장기 지원(LTS) 릴리스는 3년간 패치를 제공받는 반면, .NET 9과 같은 표준 지원(STS) 릴리스는 18개월간만 제공되므로, STS 릴리스는 이전의 LTS 릴리스보다 6개월 먼저 지원이 종료되었습니다.

‍

2026년 11월 10일은 이 오프셋이 처음으로 사라지는 날입니다. .NET 8(2023년 11월 출시)과 .NET 9(2024년 11월 출시)는 모두 같은 날짜에 지원 기간 상한선에 도달합니다. 이는 마이크로소프트가 2025년 9월, .NET 9를 시작으로 STS 지원 기간을 18개월에서 24개월로 연장했기 때문입니다. 이로 인해 ‘ .NET ’ 9의 지원 종료일은 2026년 5월 12일에서 ‘ .NET ’ 8의 3년 지원 기간이 종료되는 날로 변경되었습니다.

‍

실질적인 결과는, 가장 최근에 출시된 두 버전을 혼합하여 운영함으로써 위험을 분산시키던 팀들(예전에는 흔하고 합리적인 전략이었던)이 이번 주기에서는 단계적 도입의 이점을 전혀 누리지 못한다는 점입니다. 현재 귀사의 ‘ .NET 8’ 또는 ‘.NET 9’ 환경이 어떤 모습이든, 모든 환경에 대해 동일한 날짜를 목표로 한 계획이 필요합니다. 또한 이번이 마지막도 아닐 것입니다. 24개월 정책에 따라, 다음 STS 릴리스인 ‘ .NET 11’은 2028년 11월에 ‘ .NET 10’과 함께 지원 종료 시점에 도달할 예정입니다.

‍

지원 종료 자체는 새로운 일이 아닙니다: .NET 6은 .NET 7보다 6개월 뒤인 2024년 11월 12일에 지원이 종료되었습니다. 마이크로소프트나 생태계 측에서 지원 기간을 연장해 줄 것이라고 가정하거나, 지원 종료된 런타임의 패치되지 않은 CVE가 주목받지 않을 것이라고 생각하며 이를 ‘유연한 마감일’로 여겼던 팀들은, 그 후 1년 동안 감사관, 보험사, 그리고 경우에 따라 고객들에게 해결되지 않은 위험에 대해 설명하느라 시간을 보냈습니다. 2026년 11월 10일은 바로 그 기한이며, 영향을 받는 범위는 두 배로 늘어났습니다.

“지원 종료”가 의미하지 않는 것

그렇다고 해서 .NET 8이나 .NET 9의 운영이 중단되는 것은 아닙니다. 애플리케이션은 전날과 똑같이 계속 실행됩니다. 바로 이 때문에 내부적으로 마감일을 과소평가하기 쉬운 것입니다. 11월 11일에 눈에 띄게 고장 나는 부분은 없기 때문입니다. 변화는 눈에 띄지 않게 일어나지만, 대부분의 규제 대상 기관에 있어서는 그 영향이 훨씬 더 큽니다. 이에 대해서는 다음에서 다루겠습니다.

‍

11월 10일에 실제로 무엇이 바뀌는가

패치 배포는 중단되지만, 취약점은 여전히 존재합니다.

마이크로소프트가 더 이상 패치를 제공하지 않는다고 해서 보안 연구원들과 공격자들이 ‘ .NET ’ 취약점을 찾는 것을 멈추지는 않습니다. ‘ .NET 8’ 및 ‘ .NET 9’ 코드 경로에 영향을 미치는 새로운 CVE는 계속해서 발견될 것입니다. 달라지는 점은 더 이상 공식적인 수정 프로그램이 제공되지 않는다는 것뿐입니다. 11월 10일은 패치 화요일이며, 마이크로소프트는 일반적으로 지원 종료되는 버전에 대한 마지막 릴리스를 마지막 패치 화요일에 배포합니다. 그 이후에 공개되는 모든 취약점에는 마이크로소프트의 수정 프로그램이 제공되지 않습니다. HeroDevs의 보안 팀은 이를 ‘포에버데이(forever-day) 문제’라고 부릅니다. 런타임의 지원이 종료되면, 해당 런타임에 대한 새로 공개되는 모든 취약점은 수정될 길이 없게 됩니다.

‍

패치 스트림은 런타임만을 다루는 것이 아닙니다. .NET 8 또는 .NET 9 설치본은 네 가지 구성 요소로 이루어져 있으며, 이 네 가지 모두에 대한 수정 사항 제공이 중단됩니다. 해당 구성 요소는 .NET 런타임, ASP.NET Core 공유 프레임워크, WPF 및 Windows Forms용 Windows 데스크톱 런타임, 그리고 MSBuild를 포함한 .NET SDK입니다. .NET 6에서는 지원 종료 후의 상황이 어떻게 되는지 보여줍니다. HeroDevs가 NES( .NET ) 6을 위해 제공한 수정 사항들은 이 네 가지 구성 요소 모두에 적용되었습니다: 런타임(6.0.44)의 WebSocket 압축 해제 서비스 거부(DoS) 취약점 및 Linux 진단 소켓 노출 문제, Kestrel(6.0.45)의 HTTP/3 제어 스트림 서비스 거부(DoS) 취약점, WPF 글꼴 및 글리프 렌더링 시 발생하는 힙 범위를 벗어난 쓰기 문제(6.0.44), 그리고 MSBuild 다운로드 파일명 스푸핑 수정 및 SDK 내 dotnet watch 원본 확인 기능(6.0.45 및 6.0.46)이 포함됩니다.

네 가지 실질적인 결과

• 취약점 스캐너는 끝없이 경고를 표시합니다. SCA 및 취약점 관리 도구는 .NET 8/9와 관련된 CVE를 계속해서 탐지해 낼 것이며, 지원되는 런타임과 달리 이들 중 어느 것도 “패치됨” 상태로 전환되지 않을 것입니다. 11월 10일 이후의 모든 스캔 결과는 점점 더 쌓여만 가는 미처리 목록에 추가될 뿐입니다.
• 스캐너는 실제 취약점 노출을 놓칠 수도 있습니다. 마이크로소프트는 지원이 종료된 .NET 버전에 대해서는 CVE나 패치를 공개하지 않으므로, 새로운 CVE에는 지원되는 버전만 영향을 받는 것으로 기재되며, 해당 기록을 기준으로 검사하는 스캐너는 .NET 8이나 .NET 9에서는 경고할 항목이 없습니다. 2025년 10월 14일에 공개된 ASP.NET Core Kestrel 서버의 요청 스머글링(request smuggling) 취약점인 CVE-2025-55315(위험도 9.9)가 그 예입니다: .NET 6은 취약했지만, CVE에는 해당 버전이 포함되지 않았고 마이크로소프트도 패치를 제공하지 않았습니다. HeroDevs는 3일 후 NES .NET 6.0.39 버전을 통해 수정 사항을 배포했습니다.
• 위험도 점수는 고정되어 있지 않습니다. CVSS 4나 5 단계에서는 우선순위가 낮은 것으로 보였던 CVE도, CISA의 ‘알려진 악용 취약점(KEV)’ 목록에 추가되거나 EPSS 악용 가능성 점수가 급등하면 하룻밤 사이에 긴급한 취약점으로 바뀔 수 있으며, 이러한 재분류는 최초 공개 후 수년이 지난 뒤에도 발생할 수 있습니다. 지원되는 런타임 환경에서는 이로 인해 패치 주기가 시작됩니다. 지원 종료(EOL)된 런타임 환경에서는 적용할 패치가 없습니다.
• 경미한 심각도의 취약점은 심각한 심각도의 취약점으로 이어질 수 있습니다. 특정 구성 요소에서 발생한 사소한 문제가 스택 내의 다른 요소와 결합되면, 다단계 공격 경로에서 결정적인 연결 고리가 될 수 있습니다. 개별 CVSS 점수는 이러한 결합을 반영하지 않으며, 오직 자체 위험 분석만이 이를 반영할 수 있습니다. 또한 감사관들은 이러한 분석 결과가 문서화되어 있을 것을 점점 더 기대하고 있습니다.

이는 .NET 에만 국한된 문제가 아닙니다. 모든 오픈소스 생태계에는 이미 지원이 종료되었고, 알려진 CVE가 있으며, 업스트림에서 수정 패치가 제공되지 않는 패키지들이 ‘롱테일’ 형태로 존재합니다. .NET 8과 .NET 9는 기업 규모에서 같은 날, 널리 사용되는 두 가지 런타임을 그 목록에 추가하게 될 것입니다.

‍

이 문제가 실제로 가장 먼저 영향을 미치는 곳은

문제는 대개 보안 침해 사고 때라기보다는 감사나 갱신 시에 드러나게 마련이다.

대부분의 팀은 EOL 위험을 “해킹을 당할 수도 있다”는 식으로 상상합니다. 규제 대상 조직의 경우, 더 시급한 위험은 지원이 중단된 소프트웨어를 계속 사용함으로써 이미 준수해야 하는 규정 프레임워크를 은연중에 위반하게 되며, 이는 자신이 통제할 수 없는 시점에 드러나게 된다는 점입니다.

사이버 보험도 같은 논리에 따라 운영됩니다

보험사들은 이 위험에 대해 직접적으로 보험료를 산정해 왔습니다. 코알리션(Coalition)의 ‘2023년 사이버 보험금 청구 보고서’에 따르면, 지원 종료된 소프트웨어를 사용하는 조직은 기업 규모와 관계없이 보안 사고를 겪을 확률이 3배 더 높았으며, 해결되지 않은 중대한 취약점이 단 하나라도 있는 보험 가입자의 경우 보험금 청구 확률이 33% 더 높은 것으로 나타났습니다.

‍

보험사는 여러 경로를 통해 수명 종료(EOL) 소프트웨어와 관련된 보험금 청구를 거부하거나 제한할 수 있습니다. 여기에는 과실 여부와 관계없이 적용되는 명시적 면책 조항, 애플리케이션에 보안 통제 사항이 잘못 기재된 경우의 계약 해지, 그리고 지원이 중단된 구성 요소와 관련된 침해 사고가 발생할 때 보장을 무효화하는 보증 조항 등이 포함됩니다. 또한 많은 보험 약관은 침해 사고 발생 전 상태로만 복구 비용을 지원하며 업그레이드는 포함하지 않으므로, “침해 사고 발생 후에 해결하겠다”는 식의 전략은 보험사가 보상해 주지 않습니다.

‍

그 곤경에서 벗어날 방법

감사인과 인수사는 귀하가 최신 상태를 유지할 것을 요구하지 않습니다. 그들은 귀하가 뒷받침될 수 있어야 한다고 요구합니다.

대부분의 팀이 마감 기한의 압박 속에서 간과하는 세부 사항은 바로 이것입니다. 앞서 언급한 프레임워크 중 어느 것도 “반드시 최신 버전을 사용해야 한다”고 명시하지 않습니다. 대신, 어떤 버전을 사용하든 해당 공급업체의 지원과 패치 제공 약속을 입증할 수 있어야 한다고 명시하고 있습니다. 이는 완전한 마이그레이션보다 낮은 기준이며, 공급업체가 뒷받침하는 확장된 지원 서비스가 바로 이 기준을 충족하도록 설계된 것입니다.

‍

보험 인수 담당자와 감사인이 일반적으로 인정하는 사항:

• 특정 구성 요소와 버전을 명시한 서명된 지원 계약서
• 해당 버전에 대한 CVE 수정 조치에 관한, 날짜가 명시된 문서화된 기록
• 해당 지원의 범위와 주기를 확인하는 공급업체 확인서

다시 말해, 앞서 설명한 규정 준수 및 보험 관련 위험은 단순히 11월 10일 이전에 마이그레이션을 완료한다고 해서 해결되는 것이 아닙니다. 이는 현재 어떤 환경을 운영하든, 어떤 일정에 따라 운영하든 상관없이 해당 환경에 대한 지원되는 패치 제공 체계가 마련되어야 비로소 해결됩니다. 진정한 선택은 현실적인 일정에 따라 마이그레이션을 진행하는 한편, 그 기간 동안 발생하는 공백을 문서화되고 감사 가능한 지원 관계로 전환하는 것 사이에서 이루어집니다.

‍

현실적으로 가능한 선택지들

.NET s 10으로 마이그레이션하거나, 확장 지원이 제공되는 브리지 버전으로 전환하거나, 두 가지 모두를 수행하십시오.

현재 .NET 8이나 .NET 9를 운영 환경에서 실행 중인 모든 조직은, 그 선택이 명시적으로 이루어졌는지 여부와 관계없이 이 두 가지 경로 중 하나를 선택하고 있습니다. 대부분의 기업은 결국 두 가지 방법을 모두 채택하게 되는데, 즉 현실적으로 이전이 가능한 애플리케이션은 이전하고, 불가능한 애플리케이션은 가교 역할을 통해 해결하는 방식입니다.

경로 A: .NET 10으로 마이그레이션

.NET 10은 현재 LTS(장기 지원) 릴리스이며, 여전히 .NET 8 또는 .NET 9를 사용 중인 모든 시스템이 목표로 삼아야 할 장기적인 버전입니다. 마이크로소프트의 릴리스 노트에 따르면, JIT 및 런타임 성능 개선, 확장된 양자 내성 암호화 지원, 모든 주요 플랫폼에 걸친 최신 TLS 1.3 지원, 콘솔 앱이 Dockerfile 없이도 네이티브로 컨테이너 이미지를 생성할 수 있는 기능, 벡터 검색 및 네이티브 JSON 지원을 포함한 Entity Framework Core 10 업데이트 등이 포함되어 있습니다. 이러한 기능들만으로도, 마감 기한 여부와 상관없이 업그레이드할 가치가 충분합니다. 엔터프라이즈 애플리케이션 업그레이드는 특히 전이적 종속성, 타사 라이브러리 호환성, 회귀 테스트 등이 고려되어야 할 경우, 팀이 처음 예상한 것보다 여전히 더 오랜 시간이 소요되는 것이 일반적입니다. 규정 준수 일정에 따라 마이그레이션이 가능하다면, 이것이 올바른 주된 경로입니다. 그렇지 않다면, 경로 B가 대안을 제시합니다.

경로 B: Never-Ending Support (NES) 를 활용한 브리지 .NET

.NET 용 NES는 더 이상 지원되지 않는 .NET 6, 8 또는 9 런타임을 안전하게 대체할 수 있는 솔루션입니다. 코드 변경이 필요하지 않습니다. 이 솔루션은 감사 담당자와 보험 인수 담당자가 요구하는 지원되는 패치 스트림을 복원해 주며, Microsoft가 정한 일정이 아닌 사용자가 직접 관리하는 일정에 따라 마이그레이션을 진행할 수 있게 해줍니다.

• .NET 보안 프로세스를 직접 확인할 수 있습니다. HeroDevs는 .NET 재단의 기업 후원사이며, 마이크로소프트, 레드햇, IBM, 캐노니컬과 함께 .NET 보안 그룹에 참여하고 있습니다. 이 그룹은 공개 전 패치 적용 및 .NET 의 동시 릴리스를 조정하는 역할을 맡고 있습니다. 회원사들은 공개 약 일주일 전에 소스 코드 패치를 제공받기 때문에, .NET 용 NES 빌드는 마이크로소프트와 동일한 ‘패치 화요일’에 출시됩니다.
• 이 분야에서 이미 그 역량을 입증했습니다. ‘ .NET ’를 위한 NES는 9개의 ‘ .NET 6’ 릴리스에 걸쳐 총 62건의 CVE에 대한 수정 사항을 제공했으며, 그중 56건은 마이크로소프트가 ‘ .NET 6’에 대한 패치 지원을 중단한 이후에 공개된 것입니다.
• 플랫폼 변경이 필요하지 않습니다. Windows와 Linux 모두에서 동일한 런타임 동작과 배포 모델을 유지합니다. 달라지는 점은 패치가 지속적으로 제공된다는 것뿐입니다.
• 스캐너가 읽을 수 있는 OpenVEX 명세서. HeroDevs는 .NET 릴리스에 대해 NES를 포함한 OpenVEX 명세서를 공개하므로, 스캐너는 지원이 종료된 런타임에 대한 포괄적인 문제 목록 대신, 해당 빌드가 어떤 CVE를 수정했는지, 그리고 어떤 CVE에는 적용되지 않는지를 보고합니다.
• 지속적인 생태계 투자를 바탕으로 합니다. HeroDevs의 2,000만 달러 규모의 ‘오픈소스 지속가능성 기금(Open Source Sustainability Fund)’은 .NET 을 비롯한 다양한 오픈소스 생태계의 유지보수자들을 지원합니다.

‍

이를 계획으로 구체화하기

11월 10일까지의 현실적인 전망.

이 문제를 잘 처리하는 팀들은 전체 포트폴리오에 대한 단일한 “마이그레이션 또는 브릿지” 결정을 기다리지 않습니다. 대신 짧고 구체적인 일정에 따라 애플리케이션별로 우선순위를 정합니다. 다음은 작업을 시작할 때 남은 기간이 얼마나 되든 상관없이 적용할 수 있는 실용적인 구조입니다.

1단계: 현황 파악 (1~2주 차)

• .NET 8 또는 .NET 9에서 실행 중인 모든 운영용 애플리케이션을 나열하십시오. 여기에는 내부 도구와 공급업체에서 제공한 시스템도 포함됩니다.
• 규제 대상 데이터(PHI, 카드 소지자 정보, PII)를 다루거나 SOC 2/ISO 27001 감사 범위 내에 포함되는 항목을 표시하십시오.
• .NET 10으로의 이전 경로가 이미 활발하게 진행 중이며, 해당 경로를 담당하는 인력이 배치된 제품들을 확인하십시오.

2단계: 지원 분야별로 결정하기 (3~4주 차)

• .NET 10 호환성 작업의 범위와 자원이 확정되었고, 마감일 전에 현실적으로 완료할 수 있다면 마이그레이션을 진행하십시오.
• 마이그레이션 일정이 11월 10일을 넘기게 되거나, 해당 애플리케이션이 재개발이 아닌 단계적 폐지가 예정된 경우, 또는 마이그레이션 작업이 병행되는 동안 지금 당장 규정 준수 범위를 확정해야 하는 경우에는 NES와 연계하십시오.

3단계: 실행 및 기록 (11월 10일까지)

• 마이그레이션 대상의 경우: 다른 규정 준수 중심 프로젝트와 마찬가지로 범위를 확정하고, 담당자를 지정하며, 마감 기한을 기준으로 진행 상황을 추적하십시오.
• 브리지 후보자분들께: 서명된 지원 합의서와 CVE 시정 기록을 11월 10일 이전에, 그 이후가 아닌, 반드시 준비해 두시기 바랍니다. 이는 향후 감사나 정책 갱신 시 요구될 서류입니다.
• 이미 이전된 신청 건뿐만 아니라 각 신청 건에 대한 계획에 대해, 규정 준수 및 보안 담당자와, 해당되는 경우 귀하의 사이버 보험 중개인에게 간략히 보고하십시오.

4단계: 11월 10일 이후

• 남아 있는 모든 .NET 8/9 애플리케이션이 마이그레이션되었거나 유효한 지원 계약이 체결되어 있는지 확인하십시오. 감사관이 인정할 만한 제3의 상태는 없습니다.
• “지원됨”이 영구적인 해결책이 되는 것을 방치하기보다는, 브리지가 확보하려 했던 일정대로 브리지가 적용된 애플리케이션에 대한 마이그레이션 작업을 계속 진행해야 합니다.

‍

HeroDevs의 역할

만약 어떤 신청서가 마감 기한을 지키지 못하더라도, 바로 그 경우를 위해 ‘ .NET ’의 NES 제도가 마련되어 있습니다.

저희와 상담하기 전에 모든 사항을 완벽하게 정리해 놓을 필요는 없습니다. 대부분의 상담은 한 가지 애플리케이션이나 소수의 애플리케이션에서 시작됩니다. 즉, 마이그레이션이 제때 완료되지 않을 것이 분명한 경우나, 다음 감사 또는 정책 갱신 중 먼저 도래하는 시점까지 서명된 지원 계약이 체결되어야 하는 경우가 바로 그것입니다.

HeroDevs에 NES에 대해 문의하려면 .NET

.NET 6, 8, 9를 위한 안전하고 간편한 패치 솔루션입니다. 코드 변경이나 플랫폼 전환이 필요하지 않으며, .NET 보안 그룹의 공개 절차를 직접 파악하고 있는 팀이 개발했습니다.

‍

맞춤 견적 받기

‍

출처 및 방법론

본 가이드는 일반적인 정보 제공을 목적으로 하며, 법적 또는 규정 준수 관련 조언을 구성하지 않습니다. PCI DSS, HIPAA, SOC 2, ISO 27001 또는 기타 규제 프레임워크의 적용을 받는 조직은 본 가이드를 참고하기 전에, 현재의 요구 사항 세부 내용 및 발효일을 포함한 구체적인 의무 사항을 자체 규정 준수, 법무 및 감사 팀과 확인해야 합니다.

• 마이크로소프트, “ .NET 10 발표”, “.NET 8 및 .NET 9는 2026년 11월 10일에 지원 종료됩니다”, “.NET STS 릴리스는 24개월 동안 지원됩니다”(2025년 9월 16일), “ .NET 보안 그룹 발표”(2025년 10월 14일), .NET 블로그.
• Businesswire를 통해 독립적으로 보도된 Coalition, Inc.의 ‘2023년 사이버 보험 청구 보고서’(2023년 5월)에 따르면, 해결되지 않은 중대한 취약점을 보유한 조직은 사이버 보험 청구를 경험할 가능성이 33% 더 높은 것으로 나타났으며, 지원이 종료된 소프트웨어의 경우 사고 발생 가능성이 3배 더 높은 것으로 밝혀졌다.
• 미국 보건복지부, HIPAA 보안 규정, 45 CFR §164.308(a)(1)(ii)(A) 및 (B).
• ISO/IEC 27001:2022, 부록 A, 통제 사항 8.8(기술적 취약점 관리).
• CISA의 ‘악용 사례 확인된 취약점(KEV) 목록’; FIRST.org의 ‘악용 예측 점수 체계(EPSS)’.
• HeroDevs, “HeroDevs, 오픈 소스 생태계 확보 및 성장을 위해 .NET 재단( .NET )에 합류” 및 .NET 재단( .NET ) 후원사 스포트라이트(dotnetfoundation.org): 2,000만 달러 규모의 오픈 소스 지속가능성 기금 및 .NET 보안 그룹( .NET ) 참여.
• HeroDevs NES for .NET 6.0.x 릴리스 노트: 6.0.38(2025년 6월 4일)부터 6.0.46(2026년 9월 9일)까지의 릴리스를 통해 총 62건의 CVE가 수정되었으며, 이 중 56건은 .NET 6의 지원 종료 이후에 공개된 것입니다.
• HeroDevs, “ASP.NET Core의 9.9 등급 CVE인 CVE-2025-55315에 대한 FAQ” (2025년 11월 5일).

‍