diff --git a/src/pentesting-web/ssti-server-side-template-injection/README.md b/src/pentesting-web/ssti-server-side-template-injection/README.md
index 5d053b9b94f..f5cec7a7cef 100644
--- a/src/pentesting-web/ssti-server-side-template-injection/README.md
+++ b/src/pentesting-web/ssti-server-side-template-injection/README.md
@@ -24,6 +24,27 @@ The payload `{{bad-stuff-here}}` is injected into the `name` parameter. This pay
To prevent server-side template injection vulnerabilities, developers should ensure that user input is properly sanitized and validated before being inserted into templates. Implementing input validation and using context-aware escaping techniques can help mitigate the risk of this vulnerability.[[4]](#references)
+### Stored / second-order SSTI through deferred rendering
+
+SSTI is not always reflected in the request that supplies the payload. An application may first persist attacker-controlled data in a report, session, request-header record, nested API property, upload metadata, or another application object, and only interpret it later when an email, report, preview, document, or scheduled job is rendered. The second request only has to invoke that legitimate workflow; code executes while the server constructs the output, even if delivery fails or no user opens it. This **source -> storage -> render sink** pattern is also called stored or second-order template injection.[[12]](#references)
+
+Test each stage separately and use a unique, non-destructive canary. A useful workflow is:[[12]](#references)
+
+1. Enumerate every value the renderer loads, including values copied indirectly from headers, error records, session objects, uploads, and custom-option metadata.
+2. Store a syntax canary appropriate for the suspected template/language context. If the rendered result is not observable, use an authorized per-request DNS/HTTP OAST identifier.
+3. Trigger every server-side consumer of that record (email generation, failure handling, preview, export, document conversion, or a scheduled renderer).
+4. Correlate the callback, worker error, or generated artifact with both the write request and the later rendering event. Repeat with other writable sources: blocking or relocating one backend does not remove the vulnerable data flow.
+
+```text
+request A: attacker input -> persisted record (unique canary)
+request B: normal workflow -> template loads record -> expression evaluation
+ |-> DNS/HTTP callback when output is blind
+```
+
+A Magento/Adobe Commerce attack observed in the wild used GraphQL `styles` input to poison data later processed while Magento built a **Payment Transaction Failed Reminder** email. Report records, request headers, session data, and uploaded custom-option files were relevant storage candidates; changing session storage alone therefore did not prevent exploitation. The published request fragments do not disclose the complete parameters or gadget chain, so treat them as detection clues rather than a reproducible exploit.[[12]](#references)
+
+For detection, correlate unusual writes or injection-shaped requests with subsequent bursts of renderer-driven workflows and inspect the persisted values themselves, not only the final HTTP response. Preserve application reports, queue/worker logs, serialized records, upload metadata, and generated-message events; otherwise the first-stage payload may be missed after the second-stage execution.[[12]](#references)
+
### Detection
To detect Server-Side Template Injection (SSTI), initially, **fuzzing the template** is a straightforward approach. This involves injecting a sequence of special characters (**`${{<%[%'"}}%\`**) into the template and analyzing the differences in the server's response to regular data versus this special payload. Vulnerability indicators include:[[4]](#references)
@@ -1211,5 +1232,6 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssti.txt
- [9] [blog.shoebpatel.com - The Secret Parameter LFR And Potential RCE In NodeJS Apps](https://blog.shoebpatel.com/2021/01/23/The-Secret-Parameter-LFR-and-Potential-RCE-in-NodeJS-Apps)
- [10] [PhoenixStorybook advisory - unauthenticated RCE via HEEx template injection (CVE-2026-8467)](https://github.com/phenixdigital/phoenix_storybook/security/advisories/GHSA-55hg-8qxv-qj4p)
- [11] [WhoAreMe - Plausible Analytics: Pre-Auth RCE, Cross-Tenant IDORs, and SSRF-to-RCE](https://whoareme.com/blog/plausible-analytics-multiple-criticals)
+- [12] [Sansec - StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack](https://sansec.io/research/stylesmuggler)
{{#include ../../banners/hacktricks-training.md}}