آبان
اخبار
آسیب‌پذیری EMBRACE: ضعف مرورگر داخلی در Cursor، Codex، VS Code و Claude Desktop
پژوهشگران شرکت Forever Security از خانوادهٔ تازه‌ای از ضعف‌های امنیتی به نام EMBRACE پرده برداشته‌اند؛ ضعف‌هایی در مرورگر داخلی پنج ابزار محبوب کدنویسی با هوش مصنوعی که می‌تواند از اجرای کد روی سیستم تا سرقت کلیدهای SSH را ممکن کند.
لیست مطالب
۱) ماجرا از چه قرار است؟
ابزارهای کدنویسی مبتنی بر هوش مصنوعی در یکی دو سال اخیر از یک ویرایشگر ساده به یک «محیط کامل» تبدیل شده‌اند. حالا دستیار هوشمند فقط کد پیشنهاد نمی‌دهد؛ دستور اجرا می‌کند، فایل می‌خواند و حتی صفحهٔ وب را داخل خود برنامه باز می‌کند تا نتیجهٔ کار را نشان دهد. همین مرورگر داخلی، که برای راحتی توسعه‌دهنده اضافه شده، حالا کانون یک موج تازه از گزارش‌های امنیتی شده است.
گال وایزمن (Gal Weizman) از شرکت امنیتی Forever Security پژوهشی را منتشر کرده که در آن پنج ابزار پرکاربرد بررسی شده‌اند. نتیجه این است که هر پنج ابزار، به شکلی متفاوت، مرورگر داخلی خود را بیش از اندازه قابل‌اعتماد فرض کرده‌اند. این پژوهش ۲۹ اکتبر ۲۰۲۶ عمومی شد و پیش از آن در اختیار رسانهٔ Hackread قرار گرفته بود.
به گفتهٔ این شرکت، دامنهٔ اثر بسیار گسترده است. در گزارش به حدود چهل میلیون توسعه‌دهندهٔ VS Code و بیش از پنج میلیون کاربر هفتگی Codex اشاره شده است. این اعداد برآورد خود پژوهشگران‌اند و تعداد واقعی افرادی که در معرض حمله بوده‌اند لزوماً همین نیست، اما نشان می‌دهد چرا موضوع جدی گرفته شده است.
۲) EMBRACE یعنی چه؟
نام EMBRACE مخفف عبارت «EMbedded BRowser, trusted like a real one» است؛ یعنی مرورگر توکارِ برنامه که مثل یک مرورگر واقعی به آن اعتماد می‌شود. مشکل از همین‌جا شروع می‌شود: مرورگر معمولی سال‌ها سخت‌ترین آزمون‌های امنیتی را پشت سر گذاشته و محدودیت‌های سفت‌وسختی دارد، اما مرورگر داخل یک ابزار توسعه معمولاً قابلیت‌های اضافه‌ای دارد. مثلاً با دستیار هوش مصنوعی ارتباط دارد یا به فایل‌های پروژه دسترسی می‌گیرد.
وقتی چنین مرورگری یک صفحهٔ نامطمئن را باز می‌کند، مرز بین «محتوای اینترنت» و «سیستم توسعه‌دهنده» کم‌رنگ می‌شود. حمله‌کننده دیگر لازم نیست خود سیستم‌عامل را هک کند؛ کافی است صفحه‌ای را جلوی چشم مرورگر داخلی بگذارد و از پل‌های ارتباطی آن سوءاستفاده کند. اگر با مفهوم عامل‌های هوش مصنوعی آشنا نیستید، می‌توانید مقالهٔ OpenAI چیست؟ را بخوانید تا با این فضا بیشتر آشنا شوید.
۳) Cursor: وقتی یک صفحهٔ وب دستور اجرا می‌کند
در Cursor، طبق توضیح پژوهشگران، یک صفحهٔ مخرب می‌توانست از پل ارتباطی میان مرورگر داخلی و دستیار هوشمند استفاده کند و دستورهای پنهانی را در بخش نوشتن فرمان تزریق کند. در آزمایش، دستیار یک دستور نصب را اجرا کرد و برنامهٔ ماشین‌حساب روی سیستم میزبان باز شد؛ نمونه‌ای ساده اما گویا برای اثبات اجرای کد دلخواه.
نکتهٔ قابل‌توجه این است که اولین تلاش به یک محدودیت جعبهٔ شنی (sandbox) خورد، اما خودِ عامل آن محدودیت را غیرفعال کرد و دوباره تلاش کرد. پژوهشگران تأکید کرده‌اند که موفقیت حمله به رفتار مدل هم بستگی داشت؛ یعنی این حمله در همهٔ شرایط تضمین‌شده نبوده است. به گزارش منتشرشده، Cursor این مشکل را ۱۰ سپتامبر دریافت کرد و تا ۱ اکتبر وصله منتشر شد.
این ماجرا نمونه‌ای است از خطر «تزریق دستور» (prompt injection) در ابزارهایی که به عامل هوش مصنوعی اجازهٔ اجرای فرمان می‌دهند. برای درک بهتر اینکه چرا نوشتن دستور دقیق و محدود برای مدل مهم است، به راهنمای نوشتن پرامپت برای مبتدیان سر بزنید.
۴) گیت‌هاب کوپایلت: نوار آدرسی که دروغ می‌گوید
ضعف کوپایلت از نوع دیگری بود. در نسخهٔ ۱٫۱٫۲۷، یک صفحهٔ مخرب می‌توانست نشانی نمایش‌داده‌شده در پیش‌نمایش مرورگر کوپایلت را تغییر دهد، بدون اینکه واقعاً به آن نشانی برود. نتیجه این بود که بالای صفحه می‌توانست github.com/login دیده شود، در حالی که محتوای زیر آن کاملاً دست حمله‌کننده بود.
این جعل برای فیشینگ ایده‌آل است. هم کاربر انسانی و هم عامل هوشمندی که بر اساس نشانی صفحه تصمیم می‌گیرد، می‌توانند فریب بخورند. طبق گزارش، گیت‌هاب این مورد را مستقل از پژوهشگران ۲۶ سپتامبر شناسایی کرد و در نسخهٔ ۱٫۱٫۲۹ در ۱۳ اکتبر آن را اصلاح کرد.
۵) Codex، VS Code و Claude Desktop: فرار از پوشهٔ پروژه
خطرناک‌ترین بخش پژوهش به سه ابزار آخر مربوط است. به گفتهٔ وایزمن، اگر یک فایل HTML محلی داخل این برنامه‌ها باز شود، می‌تواند به فایل‌های بیرون از محدودهٔ پروژه دسترسی پیدا کند. در VS Code و Claude Desktop، «وب‌ورکرها» (web workers) توانستند بررسی‌های مسیر پوشه را که روی صفحهٔ اصلی اعمال شده بود دور بزنند، و در Codex این محدودیت اصلاً وجود نداشت.
پژوهشگران نشان دادند که با این روش می‌توان کلیدهای SSH، توکن‌های توسعه‌دهنده و اسناد خصوصی را خواند و بیرون فرستاد. برای کسی که روی یک دستگاه هم کار شخصی و هم کار شرکتی دارد، یعنی یک فایل HTML داخل یک مخزن کد دانلودشده ممکن است درِ خانه را باز کند. اگر می‌خواهید دیدگاه گسترده‌تری دربارهٔ مرزهای امکان و ریسک در هوش مصنوعی داشته باشید، مقالهٔ پتانسیل و محدودیت‌های واقعی هوش مصنوعی را ببینید.
۶) وضعیت وصله‌ها و جدول زمانی افشا
طبق اطلاعات منتشرشده در گزارش Hackread، وضعیت هر ابزار تا زمان انتشار به این شکل بود. باید توجه کرد که این وضعیت متعلق به همان تاریخ است و ممکن است تا زمانی که این مطلب را می‌خوانید تغییر کرده باشد.
- Cursor: گزارش ۱۰ سپتامبر، وصله ۱ اکتبر.
- گیت‌هاب کوپایلت: شناسایی ۲۶ سپتامبر، اصلاح در نسخهٔ ۱٫۱٫۲۹ در ۱۳ اکتبر.
- OpenAI Codex: گزارش ۲۷ جولای؛ به گفتهٔ وایزمن هنگام انتشار هنوز وصله نشده بود.
- VS Code: گزارش ۱۰ سپتامبر؛ هنگام انتشار وصله نشده بود.
- Claude Desktop: تاریخ گزارش و وضعیت وصله در منبع اصلی ذکر نشده است.
فاصلهٔ حدود سه ماه میان گزارش به OpenAI در جولای و انتشار عمومی در اکتبر، یکی از دلایل جنجال این پژوهش شد. در عمل، ضعفی که ماه‌ها باز بماند، فرصت کافی به مهاجم‌ها می‌دهد.
۷) بحث «Workspace Trust»؛ آیا پیام اعتماد کافی است؟
بخش جنجالی ماجرا پاسخ برخی شرکت‌هاست. بر اساس یک گزارش ثانویه در DEV Community، Anthropic و مایکروسافت این گزارش‌ها را با استناد به قابلیت Workspace Trust رد کرده‌اند؛ یعنی همان پیامی که از کاربر می‌پرسد آیا به پوشهٔ باز شده اعتماد دارد یا نه. چون این روایت از منبع دست‌دوم است و متن رسمی پاسخ شرکت‌ها در گزارش‌های دیگر نیامده، بهتر است آن را با احتیاط بخوانیم.
استدلال پژوهشگران این است که پیام اعتماد را خود کاربر کنترل می‌کند و حمله‌کننده می‌تواند پروژه را طوری بسازد که معقول به نظر برسد. بنابراین به نظر آن‌ها این پیام یک حفاظ واقعی نیست. این بحث قدیمی در امنیت نرم‌افزار است: چه مقدار از مسئولیت بر عهدهٔ سازنده است و چه مقدار بر عهدهٔ کاربری که روی «اعتماد» کلیک می‌کند؟ هیچ‌کدام از دو طرف را نمی‌توان از این گزارش قطعی داور کرد.
۸) توسعه‌دهنده‌ها همین حالا چه کار کنند؟
پژوهشگران توصیه می‌کنند سازمان‌ها بدانند این ابزارها روی کدام دستگاه‌ها نصب شده‌اند و کنترل‌های امنیتی مرورگر داخلی هر ابزار را بازبینی کنند. بر پایهٔ همین توصیه‌ها و گزارش‌های منتشرشده، چند اقدام عملی وجود دارد.
- پروژه‌های ناشناس و مخزن‌های دانلودشده از منبع نامطمئن را ابتدا در کانتینر یا ماشین مجازی موقت باز کنید.
- روی «اعتماد به پوشه» کلیک نکنید، مگر اینکه فایل‌های HTML و اسکریپت‌های آن را پیش‌تر مرور کرده باشید.
- فهرست پروژه‌های مورد اعتماد در تنظیمات هر ابزار را بازبینی کنید و موارد ناآشنا را پاک کنید.
- اگر روی دستگاهی پروژهٔ نامطمئن را در Codex یا VS Code باز کرده‌اید، کلیدهای SSH و توکن‌های آن دستگاه را عوض کنید.
- توکن‌ها را محدود به یک پروژه بسازید، نه کل حساب.
- برنامه‌ها را به‌روز نگه دارید و منتظر انتشار وصله‌های رسمی بمانید.
این توصیه‌ها فقط بخشی از مشکل را حل می‌کنند. اگر در حال ساخت محصول بر پایهٔ این ابزارها هستید، فراتر از امنیت باید به بحث «واقعیت‌سنجی» هم فکر کنید؛ مقالهٔ توهم هوش مصنوعی: توسعه‌دهندهٔ تنها در برابر مهندس واقعی زاویهٔ جالبی به این بحث اضافه می‌کند.
۹) چرا این خبر برای کاربران ایرانی مهم است؟
بخش بزرگی از برنامه‌نویسان فارسی‌زبان از Cursor، کوپایلت، Codex و VS Code برای کار شخصی، پروژه‌های مستقل و حتی سفارش‌های خارج از کشور استفاده می‌کنند. بسیاری از ما مخزن‌ها و قالب‌های آماده را از اینترنت می‌گیریم و بی‌درنگ داخل ویرایشگر باز می‌کنیم. دقیقاً همین الگو، مهم‌ترین سناریوی سوءاستفاده از EMBRACE است.
از طرف دیگر، رشد استفادهٔ کسب‌وکارها از هوش مصنوعی باعث شده دستگاه توسعه‌دهنده به دروازه‌ای برای دسترسی به سرورها و حساب‌های ابری تبدیل شود. در مقالهٔ اهمیت هوش مصنوعی در کسب‌وکار دربارهٔ همین روند نوشته‌ایم، و برای پیگیری خبرهای مرتبط می‌توانید به بخش اخبار هوش مصنوعی و آموزش‌های ChatGPT سر بزنید.
پرسش‌های متداول
EMBRACE دقیقاً چیست؟
نامی است که Forever Security برای دستهٔ تازه‌ای از ضعف‌های امنیتی گذاشته که از اعتماد بیش از حد به مرورگر داخلی ابزارهای کدنویسی با هوش مصنوعی ناشی می‌شود.
کدام ابزارها تحت تأثیر قرار گرفتند؟
طبق پژوهش، Cursor، گیت‌هاب کوپایلت، OpenAI Codex، ویژوال استودیو کد و Claude Desktop. نوع ضعف در هر ابزار متفاوت بود.
آیا همهٔ این ضعف‌ها وصله شده‌اند؟
خیر. طبق گفتهٔ پژوهشگر، هنگام انتشار گزارش، ضعف Codex و VS Code هنوز وصله نشده بود. Cursor و کوپایلت اصلاح شده‌اند و وضعیت Claude Desktop در منبع اصلی مشخص نشده است.
آیا داده‌های من سرقت شده است؟
گزارش‌ها دربارهٔ حملهٔ واقعی علیه کاربران صحبت نکرده‌اند و نمونه‌ها در محیط آزمایشی نشان داده شده‌اند. با این حال، احتیاط دربارهٔ پروژه‌های نامطمئن منطقی است.
ساده‌ترین راه محافظت چیست؟
باز کردن پروژه‌های ناشناس در کانتینر یا ماشین مجازی، نزدن دکمهٔ اعتماد بدون بررسی، و به‌روز نگه داشتن ابزارها.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
