एजेंटिक वर्कफ़्लो इंजेक्शन: फ़िक्स्चर और एक कवरेज तुलना

CVE-2026-44246 (nnU-Net, एजेंटिक वर्कफ़्लो इंजेक्शन, CVSS 7.2, CWE-1427) के रूप में प्रकाशित बग वर्ग के लिए पुनरुत्पादनीय vulnerable/fixed फ़िक्स्चर, साथ ही उनके विरुद्ध तीन डिटेक्टरों का मापा गया आउटपुट।

यह इसलिए मौजूद है क्योंकि किसी डिटेक्टर को परखने के लिए कुछ नहीं था। इस वर्ग के लिए नियम लिखने का मतलब है हाथ से एक फ़िक्स्चर लिखना और उम्मीद करना कि वह faithful है; प्रकाशित revisions केवल यह जानकर उपलब्ध थे कि किस commit को देखना है, जो कि दिलचस्प हिस्सा निकला।

वर्ग

एक GitHub Actions वर्कफ़्लो अविश्वसनीय टेक्स्ट को एक AI एजेंट को सौंपता है जिसके पास रिपॉज़िटरी की credentials होती हैं।

चार शर्तें, सभी आवश्यक:

1. एक अविश्वसनीय ट्रिगर। issues, issue_comment, pull_request_review — ऐसे events जिनका टेक्स्ट GitHub अकाउंट रखने वाला कोई भी लिख सकता है।
2. जॉब पर एक write scope। issues: write, contents: write, इत्यादि।
3. action के अपने actor check से opt-out। claude-code-action और codex-action बिना write permission वाले run actor को मना कर देते हैं जब तक कोई input (allowed_non_write_users, allow-users) उन्हें स्पष्ट रूप से opt in न करे। उस input के बिना कोई अविश्वसनीय लेखक कभी एजेंट तक नहीं पहुँचता, और वर्कफ़्लो इसके बजाय सुरक्षित कॉन्फ़िगरेशन होता है।
4. टेक्स्ट का एजेंट तक पहुँचना। या तो वर्कफ़्लो में interpolate किया गया (prompt: के अंदर ${{ github.event.issue.body }}) या run time पर fetch किया गया (gh issue view) उस token के साथ जो जॉब सौंपता है।

यह template injection नहीं है। कुछ भी shell के रूप में evaluate नहीं होता; payload गद्य है, और interpreter मॉडल है। इसीलिए सामान्य सलाह — अपने variables को quote करें, eval न करें — लागू नहीं होती, और इसीलिए नीचे दिया गया fix input को escape करने के बारे में नहीं बल्कि इस बारे में है कि एजेंट क्या reach कर सकता है।

जानने लायक हिस्सा: fix commit ही fix नहीं है

nnU-Net ने इस वर्कफ़्लो को दो commits में harden किया, और जो डिटेक्टर "before" और "after" को binary मानता है वह बीच वाले को गलत आँकता है।

revision	commit	date	agent's --allowedTools	verdict
vulnerable	94300b49e716	2026-04-13	gh issue comment, gh issue edit	reachable write
"the fix"	4e4770b0b0e6	2026-04-24	gh issue comment only; labelling moved to a wrapper script	still reachable write
later	11bd8746fc06	2026-04-27	neither; a later step posts from a file the agent writes	not reachable

जिस commit को हर कोई fix कहेगा — उसका message है "hardened issue and PR agents" — उसने gh issue edit हटाया और labels को .github/scripts/safe-label.sh के माध्यम से भेजा, लेकिन एजेंट के पास Bash(gh issue comment:*) छोड़ दिया। एजेंट को अब भी comment करने के लिए steer किया जा सकता था, और allowlist pattern gh issue comment:* triggering issue तक सीमित नहीं है, इसलिए target मॉडल का चुनाव था। केवल तीसरे commit ने इसे बंद किया: एजेंट अब /tmp/issue-comment.md लिखता है और बाद का, गैर-एजेंट step उसे ISSUE: ${{ github.event.issue.number }} के साथ post करता है जो event से लिया गया है।

इससे दो बातें निकलती हैं, और यही कारण है कि यह रिपॉज़िटरी केवल दो फ़ाइलें नहीं है:

"Fixed" एक revision के बारे में दावा है, version के बारे में नहीं। v2.4.1 को fixed release के रूप में उद्धृत किया जाता है, लेकिन उसके .github/workflows/ में केवल codespell.yml है — agent workflows उस tag में बिल्कुल नहीं हैं। आप tag से fix verify नहीं कर सकते; आपको commit pin करना होगा।

permissions block कभी नहीं बदलता। issues: write तीनों revisions में मौजूद और सही है, अंतिम सहित, क्योंकि बाद के एक step को इसकी आवश्यकता है। जो डिटेक्टर केवल permissions पर key करता है वह revision 1 को revision 3 से अलग नहीं कर सकता। उन्हें अलग करने वाली बात यह है कि agent क्या call कर सकता है।

मापी गई कवरेज

तीन डिटेक्टर, दोनों fixtures और तीनों वास्तविक revisions पर चलाए गए। पूरा raw output और tool versions results.md में।

revision	agentbound 0.1.3	sisakulint v0.3.7	zizmor 1.30.1
1-vulnerable	HIGH write-scope, HIGH untrusted-content	ai-action-prompt-injection	—
2-fix-commit	HIGH write-scope, CRITICAL author-association	— (generic only)	—
3-later	LOW write-scope, CRITICAL author-association	ai-action-excessive-tools, ai-action-execution-order	—

यहाँ कोई भी डिटेक्टर सीधे "गलत" नहीं है — वे अलग-अलग प्रश्नों का उत्तर देते हैं:

• zizmor एक सामान्य-उद्देश्य Actions auditor है। यह तीनों revisions पर pinned-action और credential-persistence hygiene की समान रूप से रिपोर्ट करता है। डिज़ाइन से इस वर्ग के दायरे से बाहर, और इसे इसलिए शामिल किया गया क्योंकि "प्रसिद्ध linter vulnerable फ़ाइल पर साफ़ था" को आसानी से clean bill of health समझ लिया जाता है।
• sisakulint में उद्देश्य-निर्मित AI rules हैं और यह यहाँ एकमात्र tool है जो CVE के अपने mechanism का नाम लेता है: ai-action-prompt-injection vulnerable revision पर fire होता है, जहाँ issue body prompt: में interpolate होता है, और interpolation हटते ही रुक जाता है। सही। later revision पर इसके findings पर कार्रवाई करने से पहले उन्हें पढ़ना उचित है — ai-action-excessive-tools Write को flag करता है, जिसे यह वर्कफ़्लो जानबूझकर उस फ़ाइल को लिखने के लिए उपयोग करता है जिसे बाद का step post करता है; और ai-action-execution-order एजेंट को अंत में चाहता है, जिससे यह डिज़ाइन बचता है, क्योंकि privileged steps मॉडल की बारी समाप्त होने के बाद आते हैं।
• agentbound एकमात्र tool है जो revision 2 को revision 3 से अलग करता है, जॉब के permissions के बजाय एजेंट की tool allowlist पढ़कर। इसका ci-agent-missing-author-association finding later revision पर critical पर रिपोर्ट होता है और इसका अपना README इसे false के बजाय over-severe बताता है: auto-triage का मतलब है कि कोई भी इसे reach कर सके।

यहाँ हर tool का कोई न कोई finding ऐसी revision पर है जिसके लेखक ने उस सटीक शर्त पर पहले ही विचार कर लिया था। यह एक heuristic की सामान्य स्थिति है, और यही कारण है कि coverage table pass/fail column से अधिक उपयोगी है।

इसका उपयोग

git clone https://github.com/sushant-me/agentic-workflow-injection
cd agentic-workflow-injection

bash scripts/fetch-revisions.sh   # the three real revisions, pinned by SHA
bash scripts/benchmark.sh         # runs every detector that is installed

benchmark.sh किसी अनुपस्थित डिटेक्टर को चुपचाप skip करने के बजाय अनुपस्थित बताता है, क्योंकि जो coverage table किसी tool को चुपचाप छोड़ दे वह उसके बारे में कुछ सिद्ध नहीं करता।

fixtures घटाया गया रूप हैं, इस रिपॉज़िटरी के लिए लिखे गए और बाकी की तरह MIT-licensed। वे प्रतियाँ नहीं बल्कि mechanism-faithful हैं: fixtures/vulnerable.yml में चारों शर्तें हैं और कुछ नहीं, और fixtures/fixed.yml वही फ़ाइल है उन छह बदलावों के साथ जो मायने रखते हैं, प्रत्येक annotated। यदि आप कोई rule जोड़ रहे हैं, तो वे दो फ़ाइलें सबसे छोटे inputs हैं जिन्हें उसे सही पाना है।

दो interface quirks, script में handled लेकिन जानने लायक:

• sisakulint किसी git repository के बाहर की फ़ाइल का विश्लेषण नहीं करता। ऐसी फ़ाइल दिए जाने पर, यह not found प्रिंट करता है और 3 पर exit करता है। बिना ध्यान दिए, यह एक clean scan जैसा ही दिखता है।
• agentbound का JSON path एक basename है, इसलिए समान नाम वाली फ़ाइलों पर directory scan अस्पष्ट हो जाता है।

इसे ठीक करना

Detection आसान आधा है। docs/mitigations.md दूसरे आधे को cover करता है: एजेंट के authority को कैसे सीमित करें, परतों को एक प्रश्न से ranked करते हुए — क्या यह नियंत्रण इस बात पर निर्भर करता है कि मॉडल अनुपालन करना चुने?