Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE2026-42926 — Laboratorio controllato di iniezione di frame HTTP/2 NGINX per la validazione della patch CVE-2026-42926 e la ricerca difensiva. | Kitploit
Strumenti/GitHubGitHub/ikarolaborda/cve2026-42926
Strumenti DifensiviAnalisi delle VulnerabilitàAudit di ConfigurazioneSicurezza WebApprendimento e FormazioneLab e Pratica
GitHubikarolaborda/cve2026-42926

CVE2026-42926

Laboratorio controllato di iniezione di frame HTTP/2 NGINX per la validazione della patch CVE-2026-42926 e la ricerca difensiva.

Vedi Repository
43 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Laboratorio CVE-2026-42926 NGINX HTTP/2 Frame Injection

Un laboratorio di cybersicurezza controllato per validare e confrontare il comportamento relativo a CVE-2026-42926, un problema di HTTP/2 frame injection che interessa versioni specifiche di NGINX quando viene utilizzata una configurazione proxy vulnerabile.

Questo repository è destinato esclusivamente a ricerca difensiva, validazione di patch, audit di configurazione e riproduzione controllata in laboratorio.

Classificazione: HTTP/2 frame injection Versioni interessate: NGINX 1.29.4 fino a 1.30.0 Versioni corrette: NGINX 1.30.1+ / 1.31.0+

Avviso di sicurezza

Utilizza questo progetto solo in un ambiente di laboratorio isolato di cui sei proprietario o che sei esplicitamente autorizzato a testare.

Non eseguirlo contro sistemi di terze parti, infrastrutture pubbliche, ambienti condivisi o servizi di produzione senza un'autorizzazione scritta.

Isolamento consigliato:

  • VM locale
  • Container usa e getta
  • Host di test privato
  • Rete di laboratorio non instradabile

Cosa Fa Questo Laboratorio

Il laboratorio verifica se un binario NGINX di destinazione e la relativa configurazione soddisfano le condizioni necessarie per riprodurre il problema, invia una richiesta appositamente costruita alla location di test e ispeziona un logger upstream controllato per verificare la presenza di prove che byte simili a frame HTTP/2 iniettati abbiano raggiunto il lato upstream.

Il normale schema di validazione è:

  1. Eseguire la stessa configurazione proxy vulnerabile con una build NGINX vulnerabile.
  2. Eseguire la stessa configurazione proxy vulnerabile con una build NGINX corretta.
  3. Confrontare le evidenze upstream e i verdetti dello script.

Risultato atteso:

  • Build vulnerabile: potrebbe essere osservata evidenza di iniezione.
  • Build corretta: non dovrebbe essere osservata alcuna evidenza di iniezione.

Contenuto del Repository

FileDescrizione
README.mdDocumentazione del progetto.
LICENSELicenza MIT.
DockerfileCrea un'immagine di laboratorio autonoma con NGINX 1.29.4, PHP CLI/cURL, Python e gli script del progetto.
docker-compose.ymlAvvia il servizio NGINX vulnerabile, il logger di frame upstream e un runner di validazione opzionale.
cve_2026_42926_lab.phpScript principale di validazione del laboratorio. Verifica le precondizioni di versione/configurazione, invia la richiesta costruita, ispeziona i log upstream e restituisce un verdetto.
nginx_vulnerable.confConfigurazione NGINX di esempio che contiene il pattern proxy vulnerabile utilizzato sia per i confronti con build vulnerabile sia con build corretta.
docker/nginx_vulnerable.docker.confConfigurazione NGINX specifica per Docker che usa lo stesso pattern vulnerabile e il service discovery di Compose.
nginx_config_verify.shHelper che verifica se una configurazione NGINX di destinazione contiene il pattern proxy vulnerabile richiesto.
upstream_frame_logger.pyLogger upstream HTTP/2 raw controllato usato per catturare e ispezionare i frame ricevuti da NGINX.
run_lab_comparison.shOrchestra i confronti tra esecuzioni vulnerabile e corretta.
.dockerignoreMantiene i log generati e i metadati IDE fuori dal contesto di build Docker.

Requisiti

  • Ambiente shell Linux o macOS
  • bash
  • python3
  • php
  • Estensione PHP cURL
  • Binari NGINX di test per le versioni che vuoi confrontare
  • Permesso di bindare la porta di ascolto NGINX configurata

Per il flusso di lavoro containerizzato:

  • Docker
  • Docker Compose v2

La configurazione di esempio ascolta sulla porta 80, che di solito richiede privilegi di root. Per un laboratorio locale senza privilegi, modifica listen 80; in nginx_vulnerable.conf con una porta alta disponibile come 8080, quindi usa l'URL di destinazione corrispondente nel comando PHP.

Configurazione

Rendi eseguibili gli script shell:

root@kitploit:~
chmod +x nginx_config_verify.sh run_lab_comparison.sh

Verifica che PHP abbia il supporto cURL:

root@kitploit:~
php -m | grep -i curl

Verifica che ogni binario NGINX possa stampare la propria versione:

root@kitploit:~
/path/to/nginx -V

Configurazione del Laboratorio

Il file nginx_vulnerable.conf fornito contiene il pattern di test richiesto:

root@kitploit:~
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;
}

Dettagli importanti:

  • proxy_http_version 2 abilita il proxy HTTP/2 verso il logger upstream.
  • proxy_set_body $request_body utilizza un corpo della richiesta controllato dal client.
  • client_max_body_size 20m consente il corpo della richiesta di 16 MiB costruito usato dallo script di validazione.
  • Il logger upstream ascolta su 127.0.0.1:8081 di default.

La configurazione specifica per Docker in docker/nginx_vulnerable.docker.conf mantiene lo stesso pattern proxy vulnerabile ma ascolta sulla porta del container 8080 e fa da proxy verso il nome del servizio Compose upstream:8081.

Avvio Rapido Docker: Laboratorio NGINX 1.29.4

Il Dockerfile compila NGINX 1.29.4 dal sorgente e installa gli strumenti PHP/Python richiesti dal laboratorio. Compose esegue quindi tre servizi dalla stessa immagine:

  • upstream: logger raw dei frame HTTP/2
  • nginx: NGINX 1.29.4 vulnerabile che usa docker/nginx_vulnerable.docker.conf
  • runner: comando di validazione PHP una tantum

Compila l'immagine del laboratorio:

root@kitploit:~
docker compose build

Avvia il logger upstream e NGINX vulnerabile:

root@kitploit:~
docker compose up -d upstream nginx

Verifica la versione NGINX inclusa:

root@kitploit:~
docker compose exec nginx nginx -V

Esegui lo script di validazione all'interno della rete Compose:

root@kitploit:~
docker compose --profile run run --rm runner

Il runner usa questi argomenti all'interno del container:

root@kitploit:~
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

I log upstream generati vengono scritti nella directory host:

root@kitploit:~
./upstream_logs/

Il servizio NGINX è inoltre esposto verso l'host all'indirizzo:

root@kitploit:~
http://localhost:8080/version

Ferma e rimuovi i container del laboratorio:

root@kitploit:~
docker compose down

Avvio Rapido: Esecuzione di Validazione Singola

Avvia il logger upstream controllato:

root@kitploit:~
python3 upstream_frame_logger.py 8081 ./upstream_logs

In un altro terminale, avvia NGINX con la configurazione di esempio:

root@kitploit:~
/path/to/nginx -c "$PWD/nginx_vulnerable.conf"

Esegui lo script di validazione:

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

Ferma NGINX dopo l'esecuzione:

root@kitploit:~
/path/to/nginx -s stop

Se hai modificato NGINX per l'ascolto su un'altra porta, aggiorna il primo argomento. Per esempio:

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

Avvio Rapido: Confronto Vulnerabile vs Corretta

Imposta i percorsi dei due binari NGINX ed esegui lo strumento di confronto:

root@kitploit:~
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

Override opzionali di configurazione:

root@kitploit:~
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

Lo script di confronto scrive:

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

Verifica Manuale della Configurazione

Usa nginx_config_verify.sh direttamente quando vuoi solo verificare se una configurazione contiene il pattern vulnerabile:

root@kitploit:~
./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

L'helper verifica la presenza di:

  • proxy_http_version 2
  • proxy_set_body con una variabile
  • client_max_body_size di almeno 16 MiB

Argomenti dello Script

cve_2026_42926_lab.php accetta argomenti posizionali:

root@kitploit:~
php cve_2026_42926_lab.php <target_url> <upstream_log_dir> <config_script> <nginx_binary> <nginx_config> <location> [version_url]

Valori predefiniti:

ArgomentoValore predefinito
target_urlhttp://localhost/exploit
upstream_log_dir./upstream_logs
config_script./nginx_config_verify.sh
nginx_binarynginx
nginx_config/etc/nginx/nginx.conf
location/exploit
version_urlhttp://localhost/version

Verdetti e Codici di Uscita

cve_2026_42926_lab.php restituisce uno di tre verdetti:

VerdettoSignificatoCodice di uscita
positiveEvidenza di iniezione di frame osservata e correlata all'esecuzione.0
negativePrecondizioni soddisfatte e nessuna evidenza di iniezione osservata.1
inconclusiveUna o più precondizioni o controlli delle evidenze non sono riusciti.2

L'evidenza positiva richiede che lo script correli il marcatore dell'esecuzione, l'header del frame upstream osservato, il flag di frame iniettato e la versione NGINX interessata.

Artefatti di Output

Il logger upstream scrive file JSON con nomi del tipo:

root@kitploit:~
frames_<timestamp>.json

Ogni log contiene metadati dei frame HTTP/2 analizzati, estratti del payload, offset di byte, flag di rilevamento dell'iniezione e campi di correlazione con l'esecuzione.

Lo strumento di confronto archivia directory di log separate per le esecuzioni vulnerabile e corretta, così le evidenze delle due esecuzioni non si mescolano.

Risoluzione dei Problemi

Se lo script PHP segnala che l'helper di configurazione non è eseguibile, esegui:

root@kitploit:~
chmod +x nginx_config_verify.sh

Se la richiesta restituisce 413 Request Entity Too Large, aumenta client_max_body_size ad almeno 16m; la configurazione di esempio usa 20m.

Se non viene creato alcun log upstream, verifica che:

  • upstream_frame_logger.py sia in esecuzione.
  • NGINX stia facendo da proxy verso 127.0.0.1:8081.
  • L'URL di destinazione punti al listener NGINX configurato.
  • La richiesta abbia raggiunto la location /exploit.

Se NGINX non riesce a bindare la porta 80, eseguilo con i privilegi appropriati in un ambiente di laboratorio oppure modifica la configurazione usando una porta alta come 8080.

Se il risultato del confronto è inconcludente, controlla vulnerable_result.txt, patched_result.txt e le directory dei log upstream corrispondenti per identificare la precondizione non soddisfatta.

Licenza

Questo progetto è concesso in licenza sotto la MIT License. Vedi LICENSE per i dettagli.

Scarica lo strumento