diff --git a/src/binary-exploitation/libc-heap/heap-overflow.md b/src/binary-exploitation/libc-heap/heap-overflow.md
index 6c0a3cc6e92..1aef236e817 100644
--- a/src/binary-exploitation/libc-heap/heap-overflow.md
+++ b/src/binary-exploitation/libc-heap/heap-overflow.md
@@ -47,6 +47,35 @@ python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
   - We use an Integer Overflow vulnerability to get a Heap Overflow.
   - We corrupt pointers to a function inside a `struct` of the overflowed chunk to set a function such as `system` and get code execution.
 
+### Parser-Driven Heap Overflow Exploitation (file formats, mods, asset packs)
+
+Binary deserializers often allocate a destination buffer from one attacker-controlled field and then copy data using a **different attacker-controlled count**. A classic pattern is:
+
+```c
+uint32_t alloc = width * height;   // 32-bit wrap possible
+buf = new uint8_t[alloc];
+memcpy(buf, src, count);           // count is attacker-controlled
+```
+
+This gives a forward heap overflow in **two independent ways** and often starts from an [**integer overflow**](../integer-overflow-and-underflow.md):
+
+- `width * height` wraps and the allocation becomes much smaller than the logical object size.
+- `count > alloc` even without arithmetic wrap.
+
+Source-side checks such as `count <= remaining_input` are **not enough**. The parser must also verify that **every file-controlled count fits the destination capacity**. This applies to arrays of strings, booleans, DWORDs, structs, and nested objects: a loop can stay inside the input buffer and still walk past the end of a heap object.
+
+#### Exploitation pattern
+
+1. **Pick the allocator bucket on purpose.** Tune dimensions or string lengths so the vulnerable buffer lands in the same size class / segment as the target C++ object. On Windows, attackers may prefer **Segment Heap** over LFH for more deterministic adjacency.
+2. **Use a second parser feature for heap grooming.** Variable-length, reference-counted objects are excellent placeholders: allocate many equal-sized chunks, keep references only to selected ones, and let cleanup free the rest to create reusable holes.
+3. **Split the chain into stages.** One embedded asset can groom the heap and another can allocate the victim object and trigger the overflow. Container formats that embed several independently parsed files are ideal for this.
+4. **Hijack control flow before cleanup.** If freeing the corrupted chunk would validate heap metadata and crash, corrupt a pointer/vtable-adjacent field that will be consumed by a **later parsing step in the same load routine**.
+5. **Forge the minimum object graph.** Rebuild only the fields read before the indirect call (for example a count, an array pointer, the first fake child object, and the vtable slot used next).
+6. **Exploit 32-bit heap sprays.** Large page-aligned strings/textures can repeat fake objects, pivot data, ROP, and shellcode across a large fraction of the 32-bit address space, making partial ASLR bypasses practical.
+7. **Pivot from the forged virtual call.** If the indirect call leaves the fake object in a register such as `EAX`, a stable gadget like `xchg esp, eax ; ... ; ret` turns the virtual call into a [**stack pivot**](../stack-overflow/stack-pivoting.md) toward heap-resident ROP.
+
+This pattern is especially relevant in **games, importers, asset packs, media parsers, and mod/plugin ecosystems**, where a “passive” file can trigger complex stateful parsing and attacker-controlled heap shaping.
+
 ### Real-World Example: CVE-2025-40597 – Misusing `__sprintf_chk`
 
 In SonicWall SMA100 firmware 10.2.1.15 the reverse-proxy module `mod_httprp.so` allocates an **0x80-byte** heap chunk and then concatenates several strings into it with `__sprintf_chk`:
@@ -82,6 +111,7 @@ Practical exploitation would require **heap grooming** to place a controllable o
 
 ## 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/)
+* [Synacktiv – Exploiting Titan Quest: Arbitrary Code Execution Through Malicious Custom Maps](https://synacktiv.com/en/publications/exploiting-titan-quest.html)
 
 {{#include ../../banners/hacktricks-training.md}}