2026년 10월 Go 보안 이슈 정리와 해결 방법 (net/http·HTTP/2, eMudhra 인증서, x/net)

2026.10.29 · Go Security Roundup

2026년 10월 Go 보안 이슈 정리: net/http·HTTP/2, eMudhra 인증서, x/net까지

10월 들어 Go 쪽 보안 업데이트가 연달아 나왔습니다. 10월 8일 정기 보안 릴리스에서 15건, 10월 19일에는 Go 역사상 처음으로 URGENT(긴급) 트랙 릴리스가 나왔고, 10월 27일에는 golang.org/x/net도 보안 태그를 새로 찍었습니다. Go로 API 서버나 프록시, 크롤러를 운영하고 있다면 한 번 점검해 보시는 게 좋습니다.

결론부터

1. 툴체인을 Go 1.27.3 이상 또는 Go 1.26.10 이상으로 올리고, 반드시 다시 빌드해서 배포하세요. Go는 표준 라이브러리가 바이너리에 정적으로 들어가므로 서버의 Go만 바꿔서는 소용없습니다.
2. golang.org/x/net을 직접 쓰고 있다면 v0.62.0 이상으로 올리세요(HTTP/2 수정은 v0.60.0, html 수정은 v0.62.0).
3. Go 1.25 이하는 지원이 끝나 패치가 나오지 않습니다. 이번 기회에 1.26/1.27로 옮기는 것을 권합니다.

1. 타임라인

날짜	릴리스	내용
10/8	Go 1.27.2 / 1.26.9 x/net v0.60.0	보안 수정 15건. net/http(HTTP/2 포함), crypto/tls, html/template, net/textproto, os, go 명령
10/19 (미국 시간)	Go 1.27.3 / 1.26.10	crypto/x509: 키가 유출된 eMudhra 중간 인증서 신뢰 차단(CVE-2026-111943). 첫 URGENT 트랙 릴리스
10/27	x/net v0.62.0	x/net/html 파서·렌더러 보안 수정 2건

2. 가장 급한 것: eMudhra 중간 인증서 문제 (CVE-2026-111943)

10월 17일 Mozilla가 eMudhra 루트 아래의 중간 인증서 8개를 차단했고, 조사 결과 이 인증서들의 개인키가 마이크로초 단위로 복구될 만큼 약했던 것으로 드러났습니다. 이 루트는 대부분의 신뢰 저장소에 들어 있었기 때문에, 키를 얻은 공격자는 아무 도메인의 TLS 인증서나 발급해서 중간자 공격(MITM)을 할 수 있는 상황이었습니다.

Go는 Windows·macOS에서는 OS 검증 API를 쓰지만, Linux에서는 자체 검증기를 쓰고 Linux에는 통일된 인증서 폐기 확인 수단이 없습니다. 그래서 Go 팀은 알림을 받은 지 약 7시간 반 만에 해당 중간 인증서를 차단하는 패치를 내놓았습니다. 리눅스 서버에서 돌아가는 Go 서비스가 외부 API를 HTTPS로 호출한다면 사실상 모두 해당됩니다.

• 영향 범위: net/http, crypto/tls를 직접 쓰거나 gRPC 등 이를 쓰는 라이브러리를 통해 TLS로 바깥과 통신하는 모든 바이너리
• 해결: Go 1.27.3 / 1.26.10 이상으로 다시 빌드하면 해당 중간 인증서로 이어지는 체인은 자동으로 거부됩니다.

3. net/http, HTTP/2 취약점 (10/8, Go 1.27.2 / 1.26.9)

Go로 웹 서버를 운영한다면 이쪽 비중이 가장 큽니다. TLS를 직접 받는 Go 서버는 기본으로 HTTP/2가 켜져 있으므로 아래 HTTP/2 항목에 해당됩니다.

CVE	내용	영향
CVE-2026-97032	HTTP/2 HPACK 인코더 경쟁 상태. 클라이언트가 헤더 테이블 크기를 바꾸며 요청을 반복하면 서버가 크래시	서버 다운(DoS)
CVE-2026-78659	Trailer 헤더에 필드를 대량 선언해 MaxHeaderBytes 등 제한을 우회	메모리 고갈
CVE-2026-78669	스트림을 많이 연 뒤 SETTINGS_INITIAL_WINDOW_SIZE를 반복 전송	CPU 과부하(클라이언트·서버)
CVE-2026-78663	스트림 리셋 시 흐름 제어 크레딧을 두 번 돌려줌	연결별 버퍼 제한 우회
CVE-2026-78660	HTTP/2 트랜스포트가 잘못된 framing 관련 헤더를 그대로 받아 HTTP/1 클라이언트로 전달	리버스 프록시에서 응답 스머글링
CVE-2026-56866	본문이 있는 CONNECT 요청이 거절된 뒤 연결이 풀로 돌아가 어긋남	ReverseProxy에서 다른 사용자 응답이 섞임
CVE-2026-94439	CONNECT에 2xx 응답 후 하이재킹 없이 반환하면 서버가 계속 HTTP로 해석	요청 스머글링 가능성
CVE-2026-78667	작은 Range를 수천 개 넣은 요청(FileServer, ServeContent, ServeFile)	CPU 과부하
CVE-2026-94440	multipart 파싱 시 남은 한도가 400바이트 미만이면 긴 줄을 무제한 읽음	메모리 제한 우회

패치 후 동작 변화도 알아두세요.

• HTTP/1 서버와 클라이언트 트랜스포트는 CONNECT 요청 뒤에는 응답 코드와 상관없이 연결을 닫습니다.
• httputil.ReverseProxy는 들어오는 CONNECT 요청을 405 Method Not Allowed로 거절합니다.
• FileServer 계열은 Range가 200개를 넘으면 Range 헤더를 무시합니다. 필요하면 GODEBUG=httpservecontentmaxranges=N으로 조정할 수 있습니다(0이면 제한 해제).

4. 그 밖의 10/8 수정 사항

• crypto/tls (CVE-2026-97031): ECH outer extension 참조를 여러 번 넣은 패킷으로 서버 메모리를 고갈시킬 수 있던 문제
• cmd/go (CVE-2026-94444, CVE-2026-94447): 악성 프로젝트와 악성 GOPROXY를 함께 쓰면 golang.org/fips140, golang.org/toolchain 모듈의 체크섬 검증을 우회할 수 있던 문제
• html/template (CVE-2026-94448, CVE-2026-97030): JS 템플릿 리터럴 안의 연속 표현식, yield 키워드 주변의 이스케이프 누락
• os (CVE-2026-56857, Windows): Root.Mkdir/MkdirAll이 junction을 따라 루트 밖에 디렉터리를 만들 수 있던 문제

5. golang.org/x/net v0.62.0 (10/27)

• CVE-2026-78661: x/net/html 파서가 텍스트 노드를 합칠 때 문자열을 계속 이어 붙여 O(n²) 할당이 발생. 조작된 HTML로 CPU·메모리를 크게 소모시킬 수 있습니다.
• CVE-2026-97045: 외부 네임스페이스(SVG/MathML)가 섞인 트리를 렌더링할 때 조상 체인을 끝까지 확인하지 않아, 다시 파싱하면 다른 구조로 해석될 수 있던 문제(새니타이저 우회 가능성).

사용자가 넣은 HTML을 파싱하거나 정제하는 서비스(크롤러, 메일·게시판 새니타이저 등)라면 꼭 올려야 합니다.

6. 해결 방법: 단계별 체크리스트

① 지금 쓰는 버전과 운영 중인 바이너리 버전 확인

# 로컬 툴체인
go version

# 실제 배포된 바이너리가 어떤 Go로 빌드됐는지
go version -m ./myserver | head -n 3

# go.mod에 고정된 버전 확인
grep -E '^(go|toolchain) ' go.mod
grep 'golang.org/x/net' go.mod

② govulncheck로 실제 영향 여부 점검

GOTOOLCHAIN=go1.27.3+auto go install golang.org/x/vuln/cmd/govulncheck@latest

# 소스 기준 (호출 경로까지 분석)
govulncheck ./...

# 배포된 바이너리 기준
govulncheck -mode=binary ./myserver

③ 툴체인과 x/net 올리기

# go.mod의 toolchain 지시어 갱신 (1.26 계열이면 go1.26.10)
go get toolchain@go1.27.3

# x/net 직접 의존 시
go get golang.org/x/net@v0.62.0
go mod tidy

# 다시 빌드하고 버전 확인
go build -o myserver ./cmd/server
go version -m ./myserver | head -n 1

④ Docker로 빌드한다면 베이스 이미지도 교체

# Dockerfile
FROM golang:1.27.3 AS build      # 또는 golang:1.26.10
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/myserver ./cmd/server

FROM gcr.io/distroless/static
COPY --from=build /out/myserver /myserver
ENTRYPOINT ["/myserver"]

※ golang:1.27처럼 마이너 태그만 쓰면 캐시된 옛 이미지가 그대로 쓰일 수 있으니 docker build --pull로 새로 받거나 패치 버전까지 고정하세요.

⑤ 바로 배포가 어렵다면 임시 완화책

// (1) 사용하지 않는 CONNECT 메서드 차단 미들웨어
func blockConnect(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if r.Method == http.MethodConnect {
			http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
			return
		}
		next.ServeHTTP(w, r)
	})
}

// (2) 서버 기본 제한값 명시
srv := &http.Server{
	Addr:              ":8443",
	Handler:           blockConnect(mux),
	ReadHeaderTimeout: 5 * time.Second,
	ReadTimeout:       30 * time.Second,
	IdleTimeout:       60 * time.Second,
	MaxHeaderBytes:    1 << 20, // 1MB
}

# (3) HTTP/2가 꼭 필요하지 않다면 서버 측 HTTP/2를 잠시 끄기
GODEBUG=http2server=0 ./myserver

이건 어디까지나 임시방편입니다. eMudhra 인증서 문제는 다시 빌드하는 것 외에 Go 쪽에서 막을 방법이 없으므로(시스템 인증서 저장소 업데이트는 별도로 진행), 최대한 빨리 패치 버전으로 재배포하는 것이 정답입니다.

7. 내 서비스는 얼마나 급한가

운영 형태	우선순위	이유
Go 서버가 TLS를 직접 받음(HTTP/2 활성)	매우 높음	HTTP/2 크래시·자원 고갈을 외부에서 바로 유발 가능
httputil.ReverseProxy·API 게이트웨이	매우 높음	응답 스머글링, 다른 사용자 응답 혼입
Linux에서 외부 HTTPS API를 호출	높음	eMudhra 인증서를 이용한 MITM 가능성
LB/Nginx 뒤에서 HTTP/1.1로만 받음	중간	HTTP/2 항목 영향은 줄지만 CONNECT·Range·multipart는 해당
사용자 HTML 파싱(x/net/html)	중간~높음	조작된 입력으로 자원 고갈, 새니타이저 우회 가능성

출처

· golang-announce, "[security] Go 1.27.2 and Go 1.26.9 are released"(2026.10.08)
· golang-announce, "[security] Go 1.27.3 and Go 1.26.10 are released"(2026.10.20)
· The Go Blog, "Our Response To The eMudhra Key Disclosure Incident"(2026.10.26)
· golang-announce, "[security] Vulnerabilities in golang.org/x/net"(v0.62.0, 2026.10.27)
· go.dev Release History, pkg.go.dev/vuln(GO-2026-6603, 6610, 6611, 6612), cve.org

※ 코드 예시는 일반적인 완화 방법이며, 서비스 구조에 맞게 검토 후 적용하세요.