TCP 해제 후 사용 취약점: CVE-2026-98432 / CVSS 9.8

요약

리눅스의 IPv4 TCP 연결 처리에서 인증 없이 원격으로 건드릴 수 있는 CVSS 9.8 버그가 나왔습니다.

보안 업체 아틀라스 시큐리티의 권고문입니다. 앤트로픽 연구자가 보고한 이 해제 후 사용(이미 해제한 메모리를 다시 읽는 버그) 취약점은 10월 중순까지 커널 안정 버전에서 고쳐졌습니다. 하지만 10월 31일 기준으로 Ubuntu와 RHEL에는 수정 커널이 없습니다.

왜 중요한가

애플리케이션이 연결을 넘겨받기 전에 커널에서 일어나는 문제라 공격자에게 계정이 필요 없습니다.
컨테이너도 호스트 커널을 쓰므로, 수정 전 커널을 쓰는 서버라면 컨테이너 환경도 예외가 아닙니다.
Ubuntu와 RHEL 사용자는 수정 커널이 나올 때까지 임시 완화책에 기대야 합니다.

핵심 내용

커널이 저장한 접속 측 IPv4 옵션을 다른 CPU가 아직 읽는 중에 해제하는 것이 원인입니다.
앤트로픽은 Claude가 만든 공격 코드가 MPTCP(여러 경로를 묶는 TCP 확장) 리스너 서버에서 root 명령을 실행했다고 밝혔습니다.
Go 1.24 이상은 리스너에서 MPTCP를 기본으로 켜지만, 버그 자체는 MPTCP만의 문제가 아닙니다.
경합에 져도 연결 하나만 실패하므로 공격자는 반복해서 시도할 수 있습니다.
근본 조치는 수정 커널 설치 후 재부팅이고, 임시로는 IPv4 옵션이 붙은 TCP 패킷을 버리거나 MPTCP를 끕니다.

HN 반응

MPTCP 리스너는 드물다는 의견에, Go 프로그램이 기본으로 연다는 반론과 점검해 보니 실제로 있었다는 경험담이 이어졌습니다.
인터넷에서는 ISP 라우터가 IP 옵션 패킷을 대부분 버려 공격이 어렵다는 분석이 나왔지만, 보장은 없다며 직접 차단하는 사례도 공유됐습니다.

30개 표시 · 전체 315개

asveikau1일 전 HN

TCP 해제 후 사용(Use-After-Free): CVE-2026-98432 / CVSS 9.8

HN에서 군더더기 정보를 빼려고 제목을 고치는 게 관례인 건 알지만, 여기서 "Linux"를 뺀 건 유용하고 꼭 필요한 정보를 날려 버린 거예요. 이건 리눅스 취약점이에요. *BSD나 맥, 윈도를 쓴다면 영향이 없어요.
gerdesj1일 전 HN

맞는 말이긴 한데, 실제로는 꽤 드물어 보입니다.

"긴급한 이유: 이 버그는 모든 Linux 서버가 IPv4 TCP 연결을 받을 때 실행하는 코드, 즉 애플리케이션이 연결을 보기 전 단계에 있다. 이를 보고한 연구원의 소속사인 Anthropic에 따르면, 자사의 Claude 모델이 인증 정보 없이 "멀티패스 TCP 리스너가 있는 Linux 서버"에서 root 권한으로 명령을 실행하는 동작하는 개념 증명(PoC) 익스플로잇을 작성했다. Go Security Team에 따르면 Go 프로그램은 기본적으로 이런 리스너를 연다. 타임라인을 참고하라."

제가 관리하는 Linux 장비가 꽤 많은데, 멀티패스 TCP 리스너를 돌리는 건 하나도 떠오르지 않습니다. MP라고 하면 보통 어떤 종류든 라우터를 뜻하고, 벤 다이어그램에서 교집합은 점점 작아지기만 합니다...

그래도 문제는 문제이니 패치해야 하지만, 해당되는 경우는 드물 겁니다. 아주 드물 겁니다.
reissbaker1일 전 HN

드물지 않습니다. Go에서는 모든 TCP 연결이 기본적으로 MPTCP를 켭니다 [1]. 이 동작을 명시적으로 끄지 않은 채 TCP를 쓰는 Go 프로그램을 돌리기만 해도 실행 중인 커널이 취약해집니다.

1: https://groups.google.com/g/golang-announce/c/PCoQcdxoScw
dada21614시간 전 HN

제 RHEL 서버들은 전부 기본값이 비활성화이고, Debian 계열도 같을 거라고 생각합니다.

sysctl -a | grep net.mptcp.enabled net.mptcp.enabled = 0

그 경우 Go 앱은 알아서 MPTCP 없이 동작하도록 물러납니다.
RetroTechie11시간 전 HN

Debian 계열도 같을 거라고 생각합니다

Debian 13(Trixie)에서는 "sysctl -a | grep net.mptcp.enabled"가 "net.mptcp.enabled = 1"로 나옵니다. 참고로 서버가 아닌 데스크톱 설치본입니다.

수정: 보안 권고문은 여기 있습니다. (10월 16일자) https://lists.debian.org/debian-security-announce/2026/msg00482.html
ForHackernews13시간 전 HN

그럼 Caddy도 취약하다는 뜻인가요? 제 기억에 Go로 만들어진 걸로 아는데요.
philipwhiuk13시간 전 HN

*Go 1.24부터입니다
compumike22시간 전 HN
이걸 한번 실행해 보세요.
```
  sudo ss -lnp -A mptcp
```
Go 코드를 돌리고 있다면 깜짝 놀랄 수도 있습니다. 저는 놀랐습니다.
megous11시간 전 HN

이거 돌려 보고 VPS에 방치해 둔 anubis 설치본을 지웠어요.
kunley12시간 전 HN
참고로 Go 프로그램에서는 환경 변수뿐 아니라 go.mod에서도 끌 수 있습니다.
```
    godebug multipathtcp=0
```
이거 좋네요.
snvzz11시간 전 HN

Tailscale이 뜨네요.
pwagland7시간 전 HN

기사에 이런 내용이 있습니다.

Go 팀은 "근본적인 버그는 MPTCP에만 국한되지 않는다. MPTCP 리스너가 없는 시스템도 비슷한 공격에 취약할 가능성이 있다"고 덧붙였다.

알려진 익스플로잇에만 MPTCP가 필요할 뿐, 반드시 필요한 건 아닙니다.
tcdent1일 전 HN

"TCP 스택"과 "Linux TCP 스택"은 관련성 면에서 OOM만큼 차이가 나요.
arcanemachiner1일 전 HN

메모리 부족이라고요?! 큰일이네요!
_leom1일 전 HN

저도 그렇게 생각했는데, 실제로는 무슨 뜻이에요?
smallerize1일 전 HN

Order of magnitude(자릿수)예요.
loloquwowndueo1일 전 HN

에이, 말도 안 돼요. 다음엔 뭐예요? TCP가 Totally Cool Presentation의 약자라고 하겠네요?
ButlerianJihad1일 전 HN

2008년 4월 1일에는 "OOM"이 난독증 걸린 소가 내는 소리였는데, 지금은 진짜 해석만 14개나 있어요.

https://en.wikipedia.org/w/index.php?title=OOM&diff=prev&oldid=203137905
literalAardvark14시간 전 HN

유머라곤 모르는 편집자가 그걸 지워 버렸다니 비극이네요. 이런 맛깔나는 글은 언제나 환영인데요.
jamilbk9시간 전 HN
NIST 링크는 여기 있습니다: https://nvd.nist.gov/vuln/detail/cve-2026-98432

Claude와 방어용 접근 권한으로 파고들면서 지금까지 정리한 내용입니다.
1. MPTCP만의 문제가 아닙니다. 옵션이 붙은 IPv4 패킷을 받기만 해도 문제의 조건이 만들어집니다.
2. NetLabel/CIPSO(CIPSOV4 매핑을 쓰는 SELinux 또는 Smack)를 쓸 때도 IP 옵션이 있는 패킷과 같은 조건이 만들어지는 것으로 보입니다. 이걸 쓰고 있다면 IP 옵션이 있는 IPv4 패킷을 차단해도 완전한 완화책이 되지 못할 수 있습니다.
3. 적어도 저희 Azure 테스트 VM(가속 네트워킹)에서는 미국 ISP 세 곳에서 보낸 옵션 달린 IPv4 패킷이 하나도 통과하지 못했습니다. 안타깝게도 Microsoft는 네트워크 패브릭이 이를 차단하는지에 대한 문서를 공개하지 않으니, 결과는 환경마다 다를 수 있습니다.
패치된 커널이 나올 때까지 저희는 간단한 XDP 프로그램으로 완화하고 있습니다(아이디어를 준 @tptacek에게 감사드립니다).

https://github.com/jamilbk/drop-ipv4-opt
dachris7시간 전 HN
Claude가 재부팅 후에도 유지되도록 systemd 유닛과 함께 쓰라며 아래 nftables-ipopt 설정을 제안했는데, 이것도 문제를 해결해 줄 거라고 합니다. 스택에서 충분히 앞단에 있어서 이 문제까지 막아 주는지 아시는 분 있나요?
```
  cat > /etc/nftables-ipopt.nft <<'EOF'
  table inet ipopt {
    chain pre {
      type filter hook prerouting priority raw - 10; policy accept;
      ip hdrlength != 5 counter drop
    }
  }
  EOF
```
그리고 Hetzner 클라우드 서버끼리(서로 다른 네트워크)에서도 옵션이 달린 IPv4 패킷이 통과하지 못했지만, 보장할 수는 없습니다.
peanut-walrus1일 전 HN
이 건에 대해 제가 메모해 둔 내용입니다.
- MPTCP는 필수 조건이 아닙니다. 일반적인 use-after-free입니다.
- 인터넷을 통한 공격 가능성은 낮습니다. 대부분의 ISP 라우터가 IP 옵션 필드가 있는 패킷을 버립니다.
- 적어도 Red Hat에 따르면, IP 옵션이 있는 패킷을 직접 차단하는 게 도움은 되지만 완전한 완화책은 아닙니다.
- 익스플로잇이 성공하려면 여러 CPU 코어가 패킷을 처리해야 하므로, 코어가 하나뿐인 시스템이나 패킷 처리를 단일 코어에 고정한 시스템은 영향을 받지 않습니다.
wahern1일 전 HN

인터넷을 통한 공격 가능성은 낮습니다. 대부분의 ISP 라우터가 ipoptions 필드가 있는 패킷을 버립니다.

그건 앞뒤가 안 맞는데요. 애플 아이폰이 MPTCP를 많이 쓰고, 요청 대다수가 MPTCP를 지원한다고 보고하는 걸로 알고 있어요. 제 기억에 70% 이상이었습니다.
peanut-walrus1일 전 HN

MPTCP는 TCP 옵션 필드를 쓰고, 이 취약점은 IP 옵션에 있습니다.
stingraycharles21시간 전 HN

멀티패스 TCP는 두 종류가 있고, 둘은 전혀 다릅니다.

애플이 하는 건, 예를 들어 WiFi와 5G로 서로 다른 IP와 경로를 쓰면서 동시에 연결을 유지하는 겁니다.

좀 더 전통적인 서버 쪽 멀티패스는 포트가 4개인 네트워크 카드(예: 25Gbit 4개)를 라우터에 연결하고, 그 물리 포트(경로) 4개가 하나의 인터페이스처럼 동작하게 하는 겁니다. 부하 분산이나 이중화에 도움이 됩니다.

이 취약점이 다루는 건 후자입니다.
hdgvhicv16시간 전 HN

그건 보통 멀티패스가 아니라 LACP 같은 걸로 하죠.
_bernd14시간 전 HN

죄송하지만 그건 완전히 틀린 말입니다.

2계층 LAG도, 3계층 ECMP도 4계층 MPTCP와는 아무 관련이 없습니다.

취약한 건 MPTCP입니다.
pigggg1일 전 HN

안타깝게도 IP 옵션을 차단하는 곳이 충분히 많지 않습니다. 저는 2000년대 초에 미국의 아주 큰 네트워크에서 차단했고 만족스러웠습니다. 이유는 뻔한 게 많습니다. IP 옵션은 예전부터 라우터를 마비시키는 DDoS 경로였거든요(RE/RP 예외 경로로 넘겨져서, 필터링을 제대로 안 하면 loopback/라우팅 엔진 ACL을 우회하는 좋은 방법이 되기도 합니다). 몇 년에 한 번씩 학계에서 데이터그램에 쓸데없는 걸 더 욱여넣을 수 있으니 IP 옵션을 쓰자고 들고 나오는데, 항상 나쁜 생각입니다.
iknowstuff20시간 전 HN

에이, 이래서 네트워크가 굳어 버리고 집 WiFi에서 5G로 넘어갈 때 연결이 유지되는 것 같은 좋은 기능을 못 누리는 거예요. MPTCP는 중요해요. 예를 들어 Siri가 쓰는 걸로 알고 있는데요?
pigggg19시간 전 HN

MPTCP는 IP 옵션이 필요 없습니다. 무슨 말씀을 하시려는 건지 모르겠습니다.

Hacker News에서 보기 ↗