CVE-2026-42926 NGINX HTTP/2 프레임 인젝션 실험실

CVE-2026-42926과 관련된 동작을 검증하고 비교하기 위한 통제된 사이버보안 실험실입니다. 이는 취약한 프록시 구성이 사용될 때 특정 NGINX 버전에 영향을 미치는 HTTP/2 프레임 인젝션 문제입니다.

이 저장소는 방어 연구, 패치 검증, 구성 감사, 통제된 실험실 재현만을 목적으로 합니다.

분류: HTTP/2 프레임 인젝션 영향을 받는 버전: NGINX 1.29.4 ~ 1.30.0 수정된 버전: NGINX 1.30.1+ / 1.31.0+

안전 주의사항

이 프로젝트는 귀하가 소유하거나 테스트할 명시적 권한이 있는 격리된 실험실 환경에서만 사용하십시오.

서면 승인 없이 타사 시스템, 공용 인프라, 공유 환경 또는 프로덕션 서비스에 대해 실행하지 마십시오.

권장 격리 방법:

• 로컬 VM
• 일회용 컨테이너
• 개인 테스트 호스트
• 라우팅 불가능한 실험실 네트워크

이 실험실의 기능

이 실험실은 대상 NGINX 바이너리와 구성이 문제를 재현하는 데 필요한 조건과 일치하는지 확인하고, 테스트 위치에 조작된 요청을 보내며, 인젝션된 HTTP/2 프레임 형태의 바이트가 업스트림 측에 도달했는지 증거를 위해 통제된 업스트림 로거를 검사합니다.

일반적인 검증 패턴은 다음과 같습니다:

1. 취약한 NGINX 빌드와 동일한 취약한 프록시 구성을 실행합니다.
2. 패치된 NGINX 빌드와 동일한 취약한 프록시 구성을 실행합니다.
3. 업스트림 증거와 스크립트 판정을 비교합니다.

예상 결과:

• 취약한 빌드: 인젝션 증거가 관찰될 수 있습니다.
• 패치된 빌드: 인젝션 증거가 관찰되지 않아야 합니다.

저장소 내용

요구 사항

• Linux 또는 macOS 셸 환경
• bash
• python3
• php
• PHP cURL 확장
• 비교하려는 버전의 NGINX 테스트 바이너리
• 구성된 NGINX 수신 포트에 바인딩할 권한

컨테이너화된 워크플로의 경우:

• Docker
• Docker Compose v2

샘플 구성은 포트 80에서 수신하며, 일반적으로 루트 권한이 필요합니다. 권한이 없는 로컬 실험실의 경우 nginx_vulnerable.conf에서 listen 80;을 사용 가능한 높은 포트(예: 8080)로 변경한 다음 PHP 명령에서 일치하는 대상 URL을 사용하십시오.

설정

셸 스크립트를 실행 가능하게 만듭니다:

chmod +x nginx_config_verify.sh run_lab_comparison.sh

PHP에 cURL 지원이 있는지 확인합니다:

php -m | grep -i curl

각 NGINX 바이너리가 버전을 출력할 수 있는지 확인합니다:

/path/to/nginx -V

실험실 구성

제공된 nginx_vulnerable.conf에는 필요한 테스트 패턴이 포함되어 있습니다:

location /exploit {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 2;
    proxy_set_body $request_body;
    proxy_set_header Host $host;
    proxy_set_header Content-Length $content_length;
}

중요 세부 사항:

• proxy_http_version 2는 업스트림 로거에 대한 HTTP/2 프록시를 활성화합니다.
• proxy_set_body $request_body는 클라이언트가 제어하는 요청 본문을 사용합니다.
• client_max_body_size 20m은 검증 스크립트에서 사용하는 조작된 16MiB 요청 본문을 허용합니다.
• 업스트림 로거는 기본적으로 127.0.0.1:8081에서 수신합니다.

docker/nginx_vulnerable.docker.conf의 Docker 특정 구성은 동일한 취약한 프록시 패턴을 유지하지만 컨테이너 포트 8080에서 수신하고 Compose 서비스 이름 upstream:8081로 프록시합니다.

Docker 빠른 시작: NGINX 1.29.4 실험실

Dockerfile은 NGINX 1.29.4를 소스에서 빌드하고 실험실에 필요한 PHP/Python 도구를 설치합니다. 그런 다음 Compose는 동일한 이미지에서 세 가지 서비스를 실행합니다:

• upstream: 원시 HTTP/2 프레임 로거
• nginx: docker/nginx_vulnerable.docker.conf를 사용하는 취약한 NGINX 1.29.4
• runner: 단발성 PHP 검증 명령

실험실 이미지를 빌드합니다:

docker compose build

업스트림 로거와 취약한 NGINX를 시작합니다:

docker compose up -d upstream nginx

번들된 NGINX 버전을 확인합니다:

docker compose exec nginx nginx -V

Compose 네트워크 내에서 검증 스크립트를 실행합니다:

docker compose --profile run run --rm runner

실행기는 다음 컨테이너 내 인수를 사용합니다:

php /lab/cve_2026_42926_lab.php \
  http://nginx:8080/exploit \
  /lab/upstream_logs \
  /lab/nginx_config_verify.sh \
  /usr/local/nginx/sbin/nginx \
  /lab/docker/nginx_vulnerable.docker.conf \
  /exploit

생성된 업스트림 로그는 호스트 디렉토리에 기록됩니다:

./upstream_logs/

NGINX 서비스는 다음 주소로 호스트에 노출됩니다:

http://localhost:8080/version

실험실 컨테이너를 중지하고 제거합니다:

docker compose down

빠른 시작: 단일 검증 실행

통제된 업스트림 로거를 시작합니다:

python3 upstream_frame_logger.py 8081 ./upstream_logs

다른 터미널에서 샘플 구성으로 NGINX를 시작합니다:

/path/to/nginx -c "$PWD/nginx_vulnerable.conf"

검증 스크립트를 실행합니다:

php cve_2026_42926_lab.php \
  http://localhost/exploit \
  ./upstream_logs \
  ./nginx_config_verify.sh \
  /path/to/nginx \
  "$PWD/nginx_vulnerable.conf" \
  /exploit

실행 후 NGINX를 중지합니다:

/path/to/nginx -s stop

NGINX를 다른 포트에서 수신하도록 변경한 경우 첫 번째 인수를 업데이트하십시오. 예:

php cve_2026_42926_lab.php http://localhost:8080/exploit ./upstream_logs ./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

빠른 시작: 취약한 버전 vs 패치된 버전 비교

두 NGINX 바이너리의 경로를 설정하고 비교 도구를 실행합니다:

VULNERABLE_NGINX=/usr/local/nginx_1.29.4/sbin/nginx \
PATCHED_NGINX=/usr/local/nginx_1.30.1/sbin/nginx \
bash run_lab_comparison.sh

선택적 구성 재정의:

VULNERABLE_NGINX=/path/to/vulnerable/nginx \
PATCHED_NGINX=/path/to/patched/nginx \
VULNERABLE_CONFIG="$PWD/nginx_vulnerable.conf" \
PATCHED_CONFIG="$PWD/nginx_vulnerable.conf" \
bash run_lab_comparison.sh

비교 스크립트는 다음을 기록합니다:

• vulnerable_result.txt
• patched_result.txt
• upstream_logs_vulnerable/
• upstream_logs_patched/

수동 구성 확인

구성에 취약한 패턴이 포함되어 있는지만 검사하려면 nginx_config_verify.sh를 직접 사용하십시오:

./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

도우미는 다음을 확인합니다:

• proxy_http_version 2
• proxy_set_body와 변수
• 최소 16MiB의 client_max_body_size

스크립트 인수

cve_2026_42926_lab.php는 위치 인수를 받습니다:

php cve_2026_42926_lab.php <target_url> <upstream_log_dir> <config_script> <nginx_binary> <nginx_config> <location> [version_url]

기본값:

판정 및 종료 코드

cve_2026_42926_lab.php는 세 가지 판정 중 하나를 반환합니다:

양성 증거를 위해서는 스크립트가 실행 마커, 관찰된 업스트림 프레임 헤더, 인젝션된 프레임 플래그 및 영향을 받는 NGINX 버전을 연관시켜야 합니다.

출력 아티팩트

업스트림 로거는 다음과 같은 이름의 JSON 파일을 기록합니다:

frames_<timestamp>.json

각 로그에는 파싱된 HTTP/2 프레임 메타데이터, 페이로드 발췌, 바이트 오프셋, 인젝션 탐지 플래그 및 실행 연관 필드가 포함됩니다.

비교 도구는 취약한 실행과 패치된 실행에 대해 별도의 로그 디렉토리를 저장하여 두 실행의 증거가 섞이지 않도록 합니다.

문제 해결

PHP 스크립트가 구성 도우미가 실행 가능하지 않다고 보고하면 다음을 실행하십시오:

chmod +x nginx_config_verify.sh

요청이 413 Request Entity Too Large를 반환하면 client_max_body_size를 최소 16m로 늘리십시오. 샘플 구성은 20m를 사용합니다.

업스트림 로그가 생성되지 않으면 다음을 확인하십시오:

• upstream_frame_logger.py가 실행 중인지 확인하십시오.
• NGINX가 127.0.0.1:8081로 프록시하고 있는지 확인하십시오.
• 대상 URL이 구성된 NGINX 리스너를 가리키는지 확인하십시오.
• 요청이 /exploit 위치에 도달했는지 확인하십시오.

NGINX가 포트 80에 바인딩하지 못하면 실험실 환경에서 적절한 권한으로 실행하거나 구성을 8080과 같은 높은 포트로 변경하십시오.

비교 결과가 확정적이지 않은 경우 vulnerable_result.txt, patched_result.txt 및 해당 업스트림 로그 디렉토리에서 실패한 사전 조건을 검사하십시오.

라이선스

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 LICENSE를 참조하십시오.