diff --git a/src/pentesting-web/crlf-0d-0a.md b/src/pentesting-web/crlf-0d-0a.md
index adcbe776e..85ff31e83 100644
--- a/src/pentesting-web/crlf-0d-0a.md
+++ b/src/pentesting-web/crlf-0d-0a.md
@@ -6,11 +6,11 @@
 
 Il Carriage Return (CR) e il Line Feed (LF), collettivamente noti come CRLF, sono sequenze di caratteri speciali utilizzate nel protocollo HTTP per denotare la fine di una riga o l'inizio di una nuova. I server web e i browser utilizzano CRLF per distinguere tra le intestazioni HTTP e il corpo di una risposta. Questi caratteri sono impiegati universalmente nelle comunicazioni HTTP/1.1 attraverso vari tipi di server web, come Apache e Microsoft IIS.
 
-### CRLF Injection Vulnerability
+### Vulnerabilità di Iniezione CRLF
 
-L'iniezione CRLF comporta l'inserimento di caratteri CR e LF nell'input fornito dall'utente. Questa azione inganna il server, l'applicazione o l'utente facendoli interpretare la sequenza iniettata come la fine di una risposta e l'inizio di un'altra. Sebbene questi caratteri non siano intrinsecamente dannosi, il loro uso improprio può portare a HTTP response splitting e ad altre attività malevole.
+L'iniezione CRLF comporta l'inserimento di caratteri CR e LF nell'input fornito dall'utente. Questa azione inganna il server, l'applicazione o l'utente facendoli interpretare la sequenza iniettata come la fine di una risposta e l'inizio di un'altra. Sebbene questi caratteri non siano intrinsecamente dannosi, il loro uso improprio può portare a una divisione della risposta HTTP e ad altre attività malevole.
 
-### Example: CRLF Injection in a Log File
+### Esempio: Iniezione CRLF in un File di Log
 
 [Example from here](https://www.invicti.com/blog/web-security/crlf-http-header/)
 
@@ -35,12 +35,12 @@ L'attaccante quindi maschera le proprie attività malevole facendole apparire co
 
 #### Descrizione
 
-HTTP Response Splitting è una vulnerabilità di sicurezza che si verifica quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa le intestazioni dal corpo utilizzando una sequenza di caratteri specifica, Carriage Return (CR) seguita da Line Feed (LF), collettivamente chiamata CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un'intestazione di risposta, può manipolare efficacemente il contenuto della risposta successiva. Questo tipo di manipolazione può portare a gravi problemi di sicurezza, in particolare Cross-site Scripting (XSS).
+HTTP Response Splitting è una vulnerabilità di sicurezza che si verifica quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa le intestazioni dal corpo utilizzando una sequenza di caratteri specifica, Carriage Return (CR) seguito da Line Feed (LF), collettivamente denominata CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un'intestazione di risposta, può manipolare efficacemente il contenuto della risposta successiva. Questo tipo di manipolazione può portare a gravi problemi di sicurezza, in particolare Cross-site Scripting (XSS).
 
 #### XSS attraverso HTTP Response Splitting
 
 1. L'applicazione imposta un'intestazione personalizzata come questa: `X-Custom-Header: UserInput`
-2. L'applicazione recupera il valore per `UserInput` da un parametro di query, diciamo "user_input". In scenari privi di una corretta validazione e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da contenuti malevoli.
+2. L'applicazione recupera il valore per `UserInput` da un parametro di query, diciamo "user_input". In scenari privi di una corretta validazione e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da contenuto malevolo.
 3. Un attaccante crea un URL con un 'user_input' appositamente creato: `?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>`
 - In questo URL, `%0d%0a%0d%0a` è la forma codificata in URL di CRLFCRLF. Inganna il server facendogli inserire una sequenza CRLF, costringendo il server a trattare la parte successiva come il corpo della risposta.
 4. Il server riflette l'input dell'attaccante nell'intestazione di risposta, portando a una struttura di risposta non intenzionata in cui lo script malevolo viene interpretato dal browser come parte del corpo della risposta.
@@ -61,7 +61,7 @@ Location: http://myweb.com
 ```
 http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
 ```
-#### In URL Path
+#### Nel percorso URL
 
 Puoi inviare il payload **all'interno del percorso URL** per controllare la **risposta** dal server (esempio da [qui](https://hackerone.com/reports/192667)):
 ```
@@ -76,11 +76,11 @@ https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.
 
 ### Iniezione di Header HTTP
 
-L'iniezione di header HTTP, spesso sfruttata attraverso l'iniezione CRLF (Carriage Return e Line Feed), consente agli attaccanti di inserire header HTTP. Questo può compromettere meccanismi di sicurezza come i filtri XSS (Cross-Site Scripting) o la SOP (Same-Origin Policy), portando potenzialmente ad accessi non autorizzati a dati sensibili, come i token CSRF, o alla manipolazione delle sessioni utente tramite l'inserimento di cookie.
+L'iniezione di header HTTP, spesso sfruttata attraverso l'iniezione CRLF (Carriage Return e Line Feed), consente agli attaccanti di inserire header HTTP. Questo può compromettere meccanismi di sicurezza come i filtri XSS (Cross-Site Scripting) o il SOP (Same-Origin Policy), portando potenzialmente ad accessi non autorizzati a dati sensibili, come i token CSRF, o alla manipolazione delle sessioni utente tramite l'inserimento di cookie.
 
 #### Sfruttare CORS tramite Iniezione di Header HTTP
 
-Un attaccante può iniettare header HTTP per abilitare CORS (Cross-Origin Resource Sharing), eludendo le restrizioni imposte dalla SOP. Questa violazione consente a script provenienti da origini malevole di interagire con risorse di un'origine diversa, accedendo potenzialmente a dati protetti.
+Un attaccante può iniettare header HTTP per abilitare CORS (Cross-Origin Resource Sharing), eludendo le restrizioni imposte dal SOP. Questa violazione consente a script provenienti da origini malevole di interagire con risorse di un'origine diversa, accedendo potenzialmente a dati protetti.
 
 #### SSRF e Iniezione di Richiesta HTTP tramite CRLF
 
@@ -117,7 +117,7 @@ Puoi iniettare intestazioni essenziali per garantire che il **back-end mantenga
 ```
 GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
 ```
-Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge tipicamente [HTTP request smuggling](http-request-smuggling/), una tecnica in cui intestazioni o elementi del corpo extra aggiunti dal server dopo l'iniezione possono portare a vari exploit di sicurezza.
+Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge tipicamente [HTTP request smuggling](http-request-smuggling/), una tecnica in cui intestazioni o elementi del corpo aggiunti dal server dopo l'iniezione possono portare a vari exploit di sicurezza.
 
 **Sfruttamento:**
 
@@ -129,15 +129,15 @@ Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge t
 
 `GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
 
-### Iniezione di Memcache
+### Iniezione Memcache
 
-Memcache è un **key-value store che utilizza un protocollo in chiaro**. Maggiori informazioni in:
+Memcache è un **archivio chiave-valore che utilizza un protocollo in chiaro**. Maggiori informazioni in:
 
 {{#ref}}
 ../network-services-pentesting/11211-memcache/
 {{#endref}}
 
-**Per informazioni complete leggi il**[ **report originale**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
+**Per informazioni complete leggi il**[ **documento originale**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
 
 Se una piattaforma sta **prendendo dati da una richiesta HTTP e utilizzandoli senza sanitizzazione** per effettuare **richieste** a un server **memcache**, un attaccante potrebbe abusare di questo comportamento per **iniettare nuovi comandi memcache**.
 
@@ -153,9 +153,9 @@ Inoltre, i ricercatori hanno anche scoperto che potevano desincronizzare le risp
 
 Per mitigare i rischi di iniezioni CRLF (Carriage Return e Line Feed) o HTTP Header nelle applicazioni web, si raccomandano le seguenti strategie:
 
-1. **Evitare Input Diretti dell'Utente negli Intestazioni di Risposta:** L'approccio più sicuro è astenersi dall'incorporare input forniti dall'utente direttamente nelle intestazioni di risposta.
-2. **Codificare Caratteri Speciali:** Se evitare input diretti dell'utente non è fattibile, assicurati di utilizzare una funzione dedicata alla codifica di caratteri speciali come CR (Carriage Return) e LF (Line Feed). Questa pratica previene la possibilità di iniezione CRLF.
-3. **Aggiornare il Linguaggio di Programmazione:** Aggiorna regolarmente il linguaggio di programmazione utilizzato nelle tue applicazioni web all'ultima versione. Scegli una versione che di per sé non consenta l'iniezione di caratteri CR e LF all'interno delle funzioni incaricate di impostare le intestazioni HTTP.
+1. **Evitare l'Input Diretto dell'Utente negli Intestazioni di Risposta:** L'approccio più sicuro è astenersi dall'incorporare input forniti dall'utente direttamente nelle intestazioni di risposta.
+2. **Codificare i Caratteri Speciali:** Se evitare l'input diretto dell'utente non è fattibile, assicurati di utilizzare una funzione dedicata alla codifica di caratteri speciali come CR (Carriage Return) e LF (Line Feed). Questa pratica previene la possibilità di iniezione CRLF.
+3. **Aggiornare il Linguaggio di Programmazione:** Aggiorna regolarmente il linguaggio di programmazione utilizzato nelle tue applicazioni web all'ultima versione. Opta per una versione che non consenta intrinsecamente l'iniezione di caratteri CR e LF all'interno delle funzioni incaricate di impostare le intestazioni HTTP.
 
 ### CHEATSHEET
 
@@ -181,20 +181,57 @@ Per mitigare i rischi di iniezioni CRLF (Carriage Return e Line Feed) o HTTP Hea
 • %E5%98%BC = %3C = \u563c (<)
 • Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
 ```
+### Vulnerabilità Recenti (2023 – 2025)
+
+Negli ultimi anni sono stati prodotti diversi bug di iniezione CRLF/HTTP header ad alto impatto in componenti ampiamente utilizzati sia lato server che lato client. Riprodurli e studiarli localmente è un ottimo modo per comprendere i modelli di sfruttamento nel mondo reale.
+
+| Anno | Componente | CVE / Avviso | Causa principale | Evidenza PoC |
+|------|-----------|---------------|------------------|---------------|
+| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | L'helper `AddHeader()` non sanitizzava CR/LF, consentendo la costruzione di più intestazioni di richiesta quando RestSharp viene utilizzato come client HTTP all'interno di servizi back-end. I sistemi downstream potrebbero essere costretti a SSRF o request smuggling. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
+| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Gli attributi dell'intestazione sui metodi dell'interfaccia venivano copiati parola per parola nella richiesta. Incorporando `%0d%0a`, gli attaccanti potevano aggiungere intestazioni arbitrarie o persino una seconda richiesta quando Refit veniva utilizzato da lavori di server-side worker. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
+| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | Il parametro `redirect` fornito dall'utente veniva ripetuto in un'intestazione `Location:` senza codifica, abilitando il reindirizzamento aperto + avvelenamento della cache. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
+
+Questi bug sono importanti perché vengono attivati **all'interno del codice a livello di applicazione** e non solo al confine del server web. Qualsiasi componente interno che esegue richieste HTTP o imposta intestazioni di risposta deve quindi applicare un filtro CR/LF.
+
+### Bypass Avanzati di Unicode / Caratteri di Controllo
+
+Le moderne stack WAF/rewriter spesso rimuovono i caratteri letterali `\r`/`\n` ma dimenticano altri caratteri che molti back-end trattano come terminatori di riga. Quando CRLF è filtrato, prova:
+
+* `%E2%80%A8` (`U+2028` – SEPARATORE DI RIGA)
+* `%E2%80%A9` (`U+2029` – SEPARATORE DI PARAGRAFO)
+* `%C2%85`  (`U+0085` – PROSSIMA RIGA)
+
+Alcuni framework Java, Python e Go convertono questi in `\n` durante l'analisi delle intestazioni (vedi la ricerca Praetorian 2023). Combinali con payload classici:
+```
+/%0A%E2%80%A8Set-Cookie:%20admin=true
+```
+Se il filtro normalizza prima l'UTF-8, il carattere di controllo viene trasformato in un normale a capo e l'intestazione iniettata viene accettata.
+
+### Evasione WAF tramite il trucco del `Content-Encoding` duplicato (2023)
+
+I ricercatori di Praetorian hanno anche dimostrato che iniettando:
+```
+%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
+```
+in un'intestazione riflessa, i browser ignoreranno il corpo fornito dal server e renderizzeranno l'HTML fornito dall'attaccante che segue, dando XSS memorizzato anche quando il contenuto dell'applicazione è inattivo. Poiché `Content-Encoding: identity` è consentito da RFC 9110, molti reverse-proxy lo inoltrano invariato.
+
 ## Strumenti Automatici
 
-- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
-- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
+* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – scanner attivo veloce scritto in Go.
+* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – fuzzer basato su wordlist che supporta payload di newline Unicode.
+* [crlfix](https://github.com/glebarez/crlfix) – utility del 2024 che patcha le richieste HTTP generate da programmi Go e può essere utilizzata in modo autonomo per testare servizi interni.
 
 ## Elenco di Rilevamento Brute-Force
 
-- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
+- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
 
 ## Riferimenti
 
-- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
-- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
-- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
-- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/)
+- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/)
+- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
+- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
+- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
 
 {{#include ../banners/hacktricks-training.md}}