تراكيب GitHub Actions قابلة لإعادة الإنتاج للثغرات والإصلاحات الخاصة بحقن سير العمل الوكيلي (CVE-2026-44246)، مع تغطية الكاشف المقاسة وإرشادات التخفيف.

إنه ليس حقن قوالب. لا يُقيَّم أي شيء كـ shell؛ الحمولة نصية، والمُفسِّر هو النموذج. لهذا السبب لا تنطبق النصيحة المعتادة — ضع متغيراتك بين علامات اقتباس، لا تستخدم eval — ولهذا فإن الإصلاح أدناه يتعلق بما يمكن للوكيل الوصول إليه بدلًا من التهريب من المدخلات.

الجزء الجدير بالمعرفة: commit الإصلاح ليس هو الإصلاح

حصّنت nnU-Net سير العمل هذا في اثنين من الـ commits، والكاشف الذي يتعامل مع "قبل" و"بعد" كحالة ثنائية يُخطئ في الوسط.

الـ commit الذي سيسميه الجميع الإصلاح — رسالته هي "hardened issue and PR agents" — أزال gh issue edit ووجّه التسميات عبر .github/scripts/safe-label.sh، لكنه ترك Bash(gh issue comment:*) مع الوكيل. كان لا يزال بالإمكان توجيه الوكيل للتعليق، ونمط قائمة السماح gh issue comment:* غير محصور بالمشكلة المُشغِّلة، لذا كان الهدف بيد النموذج ليختاره. فقط الـ commit الثالث أغلقه: الآن يكتب الوكيل /tmp/issue-comment.md وخطوة لاحقة غير وكيلية تنشره بـ ISSUE: ${{ github.event.issue.number }} مأخوذًا من الحدث.

يترتب على ذلك أمران، وهما سبب كون هذا المستودع ليس مجرد ملفين:

"مُصلَّح" ادعاء عن مراجعة، وليس عن إصدار. يُستشهد بـ v2.4.1 كالإصدار المُصلَّح، لكن .github/workflows/ الخاص به يحتوي فقط على codespell.yml — سير عمل الوكيل غير موجود في ذلك الوسم إطلاقًا. لا يمكنك التحقق من الإصلاح من الوسم؛ عليك تثبيت الـ commit.

كتلة الصلاحيات لا تتغير أبدًا. issues: write موجودة وصحيحة في المراجعات الثلاث، بما في ذلك الأخيرة، لأن خطوة لاحقة تحتاجها. الكاشف الذي يعتمد على permissions وحده لا يمكنه فصل المراجعة 1 عن المراجعة 3. ما يفصل بينهما هو ما يجوز للوكيل استدعاؤه.

التغطية المقاسة

ثلاثة كواشف، شُغّلت على كلا التجهيزين وعلى المراجعات الحقيقية الثلاث. المخرجات الخام الكاملة وإصدارات الأدوات في results.md.

لا يوجد كاشف "مخطئ" ببساطة هنا — إنهم يجيبون على أسئلة مختلفة:

• zizmor هو مدقق Actions عام الغرض. يبلّغ عن نظافة تثبيت الإجراءات واستمرارية بيانات الاعتماد بشكل متطابق على المراجعات الثلاث. خارج النطاق لهذه الفئة بحكم التصميم، وأُدرج لأن "المدقق المعروف كان نظيفًا على الملف المصاب" يُخطئ بسهولة في اعتباره شهادة سلامة.
• sisakulint لديه قواعد ذكاء اصطناعي مبنية لهذا الغرض وهو الأداة الوحيدة هنا التي تسمّي آلية CVE نفسها: ai-action-prompt-injection يُطلق على المراجعة المصابة، حيث يُدرج نص المشكلة في prompt:، ويتوقف بمجرد اختفاء الإدراج. صحيح. نتائجه على المراجعة اللاحقة تستحق القراءة قبل التصرف بناءً عليها — ai-action-excessive-tools يشير إلى Write، الذي يستخدمه سير العمل هذا عن قصد لكتابة الملف الذي تنشره خطوة لاحقة؛ وai-action-execution-order يريد الوكيل أخيرًا، وهو بالضبط ما يتجنبه هذا التصميم، لأن الخطوات ذات الصلاحيات تأتي بعد انتهاء دور النموذج.
• agentbound هو الأداة الوحيدة التي تفصل المراجعة 2 عن المراجعة 3، بقراءة قائمة سماح أدوات الوكيل بدلًا من permissions الخاصة بالمهمة. نتيجته ci-agent-missing-author-association مُبلَّغ عنها بـ critical على المراجعة اللاحقة، ويصف README الخاص به ذلك بأنه مفرط في الشدة بدلًا من كونه خاطئًا: auto-triage مقصود أن يكون قابلًا للوصول من قبل أي شخص.

كل أداة هنا لديها نتيجة تبلّغ عنها على مراجعة كان مؤلفها قد فكّر بالفعل في ذلك الشرط بالضبط. هذه هي الحالة الطبيعية لأي استدلال، وهي السبب في أن جدول التغطية أكثر فائدة من عمود نجاح/فشل.

استخدامه

يبلّغ benchmark.sh عن الكاشف المفقود كمفقود بدلًا من تخطيه بصمت، لأن جدول تغطية يحذف أداة بهدوء لا يثبت شيئًا عنها.

التجهيزات هي الشكل المُختصر، مكتوبة لهذا المستودع ومرخّصة بـ MIT مثل بقية المستودع. إنها وفية للآلية بدلًا من كونها نسخًا: fixtures/vulnerable.yml يحمل الشروط الأربعة ولا شيء غيرها، وfixtures/fixed.yml هو الملف نفسه مع التغييرات الستة المهمة، كل منها مُعلَّق. إذا كنت تضيف قاعدة، فهذان الملفان هما أصغر المُدخلات التي يجب أن تتعامل معها بشكل صحيح.

خصوصيتان في الواجهة، مُعالَجتان في السكربت لكن يجدر معرفتهما:

• sisakulint لا يحلل ملفًا خارج مستودع git. عند إعطائه واحدًا، يطبع not found ويخرج بـ 3. بدون مراقبة، يبدو ذلك مطابقًا لفحص نظيف.
• حقل path في JSON الخاص بـ agentbound هو اسم أساسي، لذا فإن فحص دليل لملفات تحمل الاسم نفسه يكون غامضًا.

إصلاحه

الكشف هو النصف السهل. docs/mitigations.md يغطي النصف الآخر: كيفية تحديد سلطة الوكيل، مع ترتيب الطبقات حسب سؤال واحد — هل يعتمد هذا الضابط على اختيار النموذج للامتثال؟

هذا الترتيب هو بيت القصيد. التعليمات في الـ prompt هي مُدخل، وليست شرط حماية؛ نمط أداة يسمّي هدفه، أو رمز لا يحمله الوكيل أبدًا، هو حد. يعمل الدليل نزولًا من "لا يمكن للنموذج فعل الشيء الخاطئ" إلى "طُلب من النموذج ألا يفعل"، مع قائمة تحقق وتطور nnU-Net كمثال عملي.

يوسم fixtures/fixed.yml كلًا من تغييراته الستة بالطبقة التي ينفذها وبما إذا كان حاملًا للحمل — اثنان منها ليسا كذلك، وموسومان بهذه الطريقة حتى لا يبالغ القارئ في تقدير الملف.

المصدر

يُجلب وقت التشغيل بواسطة commit SHA، ولا يُضمَّن أبدًا:

لا يُعاد توزيع أي نسخة من تكوين nnU-Net هنا؛ أعد تشغيل الجلب وقارن البايتات بنفسك مقابل الـ blobs أعلاه.

النطاق

هذا عمل هندسي للكشف. لا يحتوي على أي استغلال، ولم يُختبر أي شيء هنا مقابل سير عمل حي — المراجعات المصابة هي ملفات ثابتة، منشورة بالفعل في تاريخ nnU-Net ومُشار إليها في إشعار منشور. التجهيزات موسومة بـ do not deploy لأنها موجودة ليُكشف عنها، لا لتُنسخ.

إذا كنت تصون كاشفًا لهذه الفئة وتريد صفًا في الجدول، فسكربت المعيار هو الواجهة: أضف قسمًا يشغّل أداتك على targets ويطبع نتائجه، والتجهيزات والمراجعات المثبتة تفعل الباقي.

MIT.