diff --git a/src/pentesting-web/account-takeover.md b/src/pentesting-web/account-takeover.md
index 06ebeba60f3..405ccf33cf3 100644
--- a/src/pentesting-web/account-takeover.md
+++ b/src/pentesting-web/account-takeover.md
@@ -88,6 +88,37 @@ If you find a limited XSS or a subdomain take over, you could play with the cook
 hacking-with-cookies/
 {{#endref}}
 
+## **Predictable SSO / bearer cookies and staged login replay**
+
+Some cross-application SSO stacks treat a client-visible cookie as a **bearer secret** and use it directly as the **server-side cache key** for the authenticated identity. If the value is generated from **low-entropy data** such as `System.currentTimeMillis()`, a sequential ID, or an encoded timestamp with no MAC/signature, the attacker only needs to predict the victim's login window and replay candidate values.
+
+Quick triage:
+
+- Inspect post-login cookies for **13-digit timestamps**, **sequential values**, or trivially encoded IDs.
+- Review **product-specific overrides**: the shared framework may use a safe UUID generator while one SSO subclass replaces it with a predictable value.
+- If the SSO resolver only runs for tickets claiming to come from **another integrated application**, try a **mismatched app tag / source-product cookie** to force the cross-product branch.
+
+Typical exploitation pattern:
+
+1. Send a request to a protected endpoint with the candidate ticket and the alternate-app tag.
+2. If the ticket resolves, the first request may only **stage the victim identity in a new server-side session** and return an auto-submitting login form.
+3. Replay the returned form or its equivalent auth endpoint (`/j_security_check`, SAML/OIDC bridge, custom login handler, etc.) because this **second step often establishes the authenticated principal**.
+4. Confirm the takeover with a follow-up protected request (`200`) versus the normal login redirect (`302`).
+
+```http
+GET /protected.do HTTP/1.1
+Host: target.tld
+Cookie: CUSTOM_SSO_TICKET=<candidate>; CUSTOM_SSO_APP_TAG_NAME=<other-product>
+```
+
+Important constraints:
+
+- The correct ticket may only work from the **victim's source IP**, shared NAT, internal foothold, or a path through a **trusted proxy**. Check whether proxy-trust settings let `X-Forwarded-For` override the recorded client IP.
+- A **rolling throttle** on path + real source IP can make even a 1-second millisecond window (~1,000 candidates) slow to enumerate. Reuse the ideas in [Rate Limit Bypass](rate-limit-bypass.md), but remember that distributing guesses across random IPs will fail if only the victim's IP can produce a hit.
+- Replacing predictable tokens with UUIDs stops unauthenticated guessing, but a separately stolen live cookie may still replay if the token remains a **pure bearer credential**. For generic cookie abuse patterns see [Cookies Hacking](hacking-with-cookies/README.md).
+
+Safe detection tip: send an **impossible historical token** plus the **mismatched app tag** to a protected path and look for **branch-specific cleanup `Set-Cookie` headers** (forced cookie deletion / logout). That proves the cross-application SSO replay path is reachable without resolving a real victim session, but it does **not** prove the generator is still predictable.
+
 ## **Attacking Password Reset Mechanism**
 
 
@@ -233,5 +264,7 @@ access_token=PAGE_ACCESS_TOKEN&method=post
 - [Steal DATR Cookie](https://ysamm.com/uncategorized/2026/01/15/steal-dtsg-cookie.html)
 - [Dfns - The Magic Link Vulnerability](https://www.dfns.co/article/the-magic-link-vulnerability)
 - [USENIX Security 2025 - Demystifying the (In)Security of QR Code-based Login in Real-world Deployments](https://www.usenix.org/conference/usenixsecurity25/presentation/zhang-xin)
+- [Bishop Fox - A Millisecond of Predictability: Why CVE-2026-11374 Is Hard to Exploit](https://bishopfox.com/blog/millisecond-of-predictability-why-cve-2026-11374-hard-to-exploit)
+- [Bishop Fox - CVE-2026-11374 detection tool](https://github.com/BishopFox/CVE-2026-11374-check)
 {{#include ../banners/hacktricks-training.md}}