---

---

वह नियंत्रण कार्रवाई जो नियंत्रित नहीं करती```text

09:00 alice logs in ┐ refresh credential rt-001 │ the attacker steals rt-001 ┘

10:00 alice changes her password ← the one thing a victim can do alone HTTP 200 · password changed · fresh session issued

10:00:03 attacker: POST /refresh rt-002 → HTTP 200 new access credential at-004, issued 10:00:03

10:01:00 attacker: GET /me at-004 → HTTP 200 {"username": "alice", "authenticated": true}

कोई त्रुटि नहीं। कोई विसंगति नहीं। गिनने के लिए कोई विफल प्रमाणीकरण नहीं। हमलावर का एक्सेस क्रेडेंशियल *तीन सेकंड पुराना* है और इसे सर्वर द्वारा, अनुरोध पर, रीसेट के बाद जारी किया गया था।

यहाँ पूरी भेद्यता है:```python
def _revoke_for_security_change(self, user, kind, device_id):
    if device_id:
        revoke_credentials(user, device_id=device_id)   # ← the finding

इसे एक समीक्षक की तरह पढ़ें। Revocation logic ठीक वहीं है। यह सही scope के साथ सही function को call करता है। इसके आस-पास का endpoint password hash को update करता है, 200 return करता है, और एक नया session issue करता है — एक सही password change का हर observable behaviour मौजूद है।

और अगर caller device_id छोड़ देता है, तो कुछ भी revoke नहीं होता, और endpoint फिर भी success report करता है।

यह कोई काल्पनिक स्थिति नहीं है। यह Strapi ≤ 5.33.2 में CVE-2026-22706 है, जहाँ refresh-token invalidation step caller-supplied deviceId पर conditional था। स्कोर 2.1, Low। इस पर नीचे चर्चा की गई है।

---

यह क्यों मायने रखता है

स्कोर इसलिए कम है क्योंकि attacker के पास पहले से ही access था — यही entry condition है, और यह bug कुछ नया नहीं देता। जो यह देता है वह है duration, और यह ऐसा उस एक control को तोड़कर करता है जिसे victim स्वयं operate कर सकता है।

• हर account-takeover runbook reset the password से शुरू होता है। हर product उपयोगकर्ता को यही बात बताता है।
• जब यह चुपचाप fail होता है, तो victim को बताया जाता है कि समस्या हल हो गई है और वह देखना बंद कर देता है — जिससे वह detection signal बंद हो जाता है जो account takeover में सबसे ज़्यादा मायने रखता है: उपयोगकर्ता का ध्यान देना।
• Persistence window refresh credential के lifetime के बराबर है: डिफ़ॉल्ट रूप से 30 दिन, rotating के ज़रिए अनिश्चित काल तक renewable। test_persistence_lasts_as_long_as_the_refresh_credential इसे दिखाने के लिए सात दिनों का simulated time चलाता है।
• उपयोगकर्ता के पास कोई दूसरी कार्रवाई नहीं है। दूसरा password change ठीक उतना ही करता है जितना पहला।

Containment path में Low-scored bug की कीमत feature path में Low-scored bug से ज़्यादा होती है, क्योंकि कीमत incident के दौरान चुकाई जाती है, जब कोई advisories नहीं पढ़ रहा होता।

---

The naive detector

जो rule आप पहले लिखते हैं:```text IF credential.issued_at < credential_change.timestamp: ALERT

यह कोई बेवकूफ़ी भरा नियम नहीं है। यह सस्ता है, एक फ़ील्ड चाहिए, समस्या की परिभाषा जैसा पढ़ा जाता है, और यह **साधारण मामले के बारे में सही है** — रीसेट के बाद चोरी हुए *access* टोकन का उपयोग करने वाला हमलावर पकड़ा जाता है।
`test_the_naive_rule_catches_the_simple_case` यह दावा करता है कि यह काम करता है।

दोनों नियम एक ही क्रेडेंशियल के बारे में एक ही सवाल पूछते हैं। वे जवाब देने के लिए अलग-अलग फ़ील्ड पढ़ते हैं, और दोनों फ़ील्ड असहमत हैं:

![दो पंक्तियाँ, प्रति फ़ील्ड एक। credential.issued_at 10:00:03 पढ़ता है, बदलाव के तीन सेकंड बाद, और निष्कर्ष निकालता है कि क्रेडेंशियल साफ़ दिखता है। lineage.root_issued_at 09:00:00 पढ़ता है, बदलाव से एक घंटा पहले, और अलर्ट करता है।](https://raw.githubusercontent.com/het-p301204/afterlife/main/docs/figures/two-fields.svg)

**तीन सेकंड बाद, या एक घंटा पहले — एक ही क्रेडेंशियल, एक ही क्षण में।** naive नियम हमलावर के नियंत्रण वाला फ़ील्ड पूछता है, और एक `POST /refresh` उसे रीसेट कर देता है।

इसे request log पर चलाएँ, जहाँ यह क्वेरी वास्तव में लिखी जाती है, क्योंकि request logs ही आपके पास होते हैं:```text
NAIVE DETECTOR (NAIVE-001), over the request log

  Result: NO ALERT

  Six requests were served to the attacker after the reset. Every one of them
  carried at-004, minted at 10:00:03 -- three seconds *after* the password
  change. By its own timestamp it is the newest credential on the account.

यहीं रुक जाना आसान होता, और बेईमानी भी, इसलिए लैब naive नियम का सबसे निष्पक्ष संस्करण भी चलाती है — जिसे refresh endpoint को भी देखने के लिए विस्तारित किया गया है:```text NAIVE DETECTOR, widened to include POST /refresh

1 alert at 2026-09-11T10:00:03.000Z: the credential presented to /refresh was rt-002, issued 2026-09-11T09:30:00.000Z. Then it goes blind. 6 events follow that hop and it flags none of them, because every credential from there on carries a post-reset timestamp. Its incident covers 1 accepted request; the lineage rule's covers all of them.

And look at what the alert names: NAIVE-001 revoke rt-002 -- rotated away and already dead at 10:00:03 AFTERLIFE-001 revoke lin-001 -- the live thing every future credential descends from

यही अंतर है जो रात 3 बजे मायने रखता है। भोला नियम उस एक क्षण को पकड़ लेता है जब श्रृंखला सीमा पार करती है, फिर शेष 29 दिनों तक निशान खो देता है — और जिस क्रेडेंशियल का वह नाम लेता है वह *पहले ही घुमाया जा चुका है और सर्वर द्वारा निरस्त कर दिया गया है*। उसे निरस्त करने से कुछ हासिल नहीं होता। `lin-001` वह वस्तु है जिसे आपको खत्म करना है।