یک پژوهش امنیتی تازه توجه را به بخشی از عامل‌های برنامه‌نویسی جلب می‌کند که معمولاً کمتر دیده می‌شود: هوک‌های چرخه اجرا که می‌توانند مستقل از مسیر انتخاب ابزار توسط مدل، روی سیستم فرمان اجرا کنند.

مقاله A Blind Trust, the Bloody Thrust در ۳ سپتامبر در arXiv ثبت شد. سناریو این است که کاربر ابتدا افزونه‌ای سالم را نصب می‌کند و بعد نسخه‌ای به‌روزشده را می‌پذیرد که تنظیمات هوک‌های آن تغییر کرده است. در مدل تهدید مقاله، مهاجم به فرار از محیط ایزوله یا سوءاستفاده از یک باگ نیاز ندارد؛ پیکربندی تازه می‌تواند اجرای فرمان را به رویدادی عادی در چرخه کار عامل متصل کند.

پژوهشگران برای آزمایش این وضعیت HookPry را ساخته‌اند. آن‌ها در ۱۰۰۰ اجرای کامل، هفت محیط عامل، پنج مدل زبانی و ۲۵ ترکیب محیط و مدل را آزموده‌اند. میانگین موفقیت گزارش‌شده ۷۷٫۰ درصد است و بیشترین نتیجه برای یک محیط به ۹۲٫۵ درصد رسیده است.

این اعداد فقط نتیجه گزارش‌شده در مقاله‌اند و بازتولید مستقل برای آن‌ها پیدا نشد. آزمایش‌ها در محیط‌های موقت و با داده‌های ساختگی انجام شده‌اند، ۴۰ مورد حمله را پوشش می‌دهند و همه سیستم‌عامل‌ها، پوسته‌ها، سیاست‌های سازمانی، شبکه‌ها یا نسخه‌های آینده را در بر نمی‌گیرند. مقاله نیز فرض می‌کند نصب یا پذیرش به‌روزرسانی طبق روند عادی انجام می‌شود و احتمال نصب واقعی یک بسته مخرب را اندازه نمی‌گیرد.

مرز امنیت فقط جایی نیست که مدل ابزار را انتخاب می‌کند

نکته مهم پژوهش معماری سامانه است. بسیاری از دفاع‌ها روی مسیری تمرکز دارند که از خود مدل می‌گذرد: مقابله با تزریق دستور، محدودکردن ابزارها، گرفتن تأیید و اعمال سیاست روی اقداماتی که مدل انتخاب می‌کند. هوک چرخه اجرا مسیر دیگری می‌سازد. با رخ‌دادن رویداد مربوط، محیط عامل می‌تواند فرمانی از پیش تنظیم‌شده را اجرا کند، بدون اینکه مدل دوباره درباره آن تصمیم بگیرد.

مستندات رسمی Claude Code مستقل از مقاله تأیید می‌کند که این بخش اختیار اجرایی دارد. Anthropic می‌گوید هوک‌های فرمان، دستورهای پوسته‌ای تعریف‌شده توسط کاربر هستند که در رویدادهای مشخص خودکار اجرا می‌شوند و با تمام مجوزهای حساب کاربر محلی کار می‌کنند. همین مستندات سازوکار اعتماد به پوشه کاری و رویداد ConfigChange را نیز توضیح می‌دهد؛ رویدادی که می‌تواند بعضی تغییرات تنظیمات را ثبت یا در همان نشست مسدود کند.

مستندات OpenCode هم هوک‌های رویدادمحور برای نشست‌ها، ابزارها و نصب افزونه‌ها را نشان می‌دهد. رفتار محصولات یکسان نیست؛ پس نتیجه HookPry را نمی‌توان اثبات یک آسیب‌پذیری کاملاً یکسان در همه محیط‌ها دانست. اما اسناد رسمی نشان می‌دهند پیکربندی چرخه اجرا می‌تواند خارج از تصمیم مستقیم مدل، اختیار واقعی برای اجرای فرمان داشته باشد.

اسکن ایستا در این آزمایش کافی نبود

مقاله سه روش ایستا را روی ۴۰ نمونه مخرب و ۴۰ نمونه سالم آزمایش کرده است. نویسندگان گزارش می‌کنند Microsoft Defender هیچ‌یک از ۴۰ نمونه مخرب را تشخیص نداد، HookPolicy بیست مورد و یک تنظیم پنج‌قاعده‌ای Semgrep نوزده مورد را شناسایی کرد. ترکیب هر سه روش ۲۱ مورد را پیدا کرد و ۱۹ مورد، یعنی ۴۷٫۵ درصد، تشخیص داده نشد.

این نتیجه باید محدود به همان آزمایش تفسیر شود. Defender ابزار عمومی امنیت نقطه پایانی است، در حالی که HookPolicy و Semgrep با تنظیم پژوهشگران استفاده شده‌اند. نمونه‌های سالم نیز ساختگی و کم‌خطر بوده‌اند و پژوهش، محصولات تخصصی امنیت زنجیره تأمین یا تشخیص رفتاری پویا را مقایسه نکرده است. نتیجه قابل اتکاتر این است که اسکن محتوای بسته به‌تنهایی برای مجاز دانستن پیکربندی اجرایی کافی نیست.

افزایش اختیار در به‌روزرسانی باید دوباره مجوز بگیرد

برداشت عملی Aipolix این است که نسخه‌ای که اختیار اجرایی تازه می‌آورد باید مانند تغییر مجوز بررسی شود، نه یک به‌روزرسانی عادی.

چهار کنترل عملی از این اصل به دست می‌آید. نخست، هنگام نصب و هر به‌روزرسانی، تغییرات پیکربندی اجرایی به‌صورت معنایی مقایسه شود و رویدادهای تازه، فرمان‌های تغییرکرده، مقصدهای شبکه جدید، مسیرهای اسکریپت متفاوت و دسترسی بیشتر به محیط به‌عنوان تغییر امنیتی نمایش داده شوند.

دوم، هرجا دامنه اختیار بیشتر می‌شود تأیید دوباره لازم باشد. مجوز باید به پیکربندی و توانایی‌های واقعی نسخه گره بخورد، نه فقط به نام بسته یا ناشر.

سوم، هوک‌ها با کمترین سطح دسترسی لازم اجرا شوند. محدودکردن فایل‌های قابل مشاهده، شبکه، اعتبارنامه‌ها و محیط اجرا می‌تواند پیامد یک هوک مخرب یا معیوب را کاهش دهد.

چهارم، منشأ اجرا ثبت شود: نسخه افزونه، هش پیکربندی، رویداد فعال‌کننده، فرمان اجراشده و زمینه امنیتی. اگر هوک خروجی ابزار را پیش از رسیدن به مدل تغییر می‌دهد، خروجی اولیه و سابقه تغییر هر دو باید نگهداری شوند.

پیکربندی اجرایی می‌تواند زیر سیاست قرار بگیرد

این راهکار فقط نظری نیست. در مستندات فعلی Claude Code، رویداد ConfigChange برای حسابرسی تغییرات تنظیمات و اعمال سیاست امنیتی در نظر گرفته شده و برای بعضی منابع می‌تواند تغییر را در نشست جاری مسدود کند.

این سازوکار تمام مسئله زنجیره تأمین مقاله را حل نمی‌کند و محیط‌های دیگر مدل‌های متفاوتی دارند. اما جهت طراحی روشن است: تنظیمی که اختیار اجرایی می‌آورد باید قابل مشاهده، قابل مقایسه و مشمول تصمیم سیاستی باشد.

HookPry همچنان یک نتیجه پژوهشی است، نه مدرکی از سوءاستفاده گسترده در دنیای واقعی. کد از طریق یک مخزن پژوهشی ناشناس در دسترس است، آزمایش‌ها ساختگی‌اند و نویسندگان می‌گویند یافته‌ها را به فروشندگان مربوط اطلاع داده‌اند و هنوز منتظر پاسخ‌اند. بازتولید مستقلی برای اعداد ۷۷٫۰، ۹۲٫۵ یا ۴۷٫۵ درصد پیدا نشد.

قاعده عملی روشن است: حاکمیت عامل نباید به پرامپت و ابزارهایی که مدل انتخاب می‌کند محدود بماند. هر سازوکاری که می‌تواند بیرون از مدل روی سیستم اثر بگذارد، از جمله پیکربندی اجرایی هوک‌ها، باید زیر همان قواعد مجوز، حداقل دسترسی و حسابرسی قرار گیرد.

منابع
- https://arxiv.org/abs/2609.03884
- https://arxiv.org/html/2609.03884
- https://code.claude.com/docs/en/hooks
- https://opencode.ai/docs/plugins/