در ۲۳ سپتامبر، نسخههای مخربی از بستههای MemOS متعلق به MemTensor هم در npm و هم در PyPI منتشر شد و مؤلفهای که برای ایجاد حافظهٔ بلندمدت در عاملهای هوش مصنوعی طراحی شده بود، به مسیر حملهٔ زنجیرهٔ تأمین برای سرقت اعتبارنامه تبدیل شد. پژوهشگران Socket و StepSecurity سه نسخهٔ آلوده از افزونهٔ رسمی OpenClaw یعنی @memtensor/memos-cloud-openclaw-plugin با نسخههای 0.1.21، 0.1.23 و 0.1.25 و همچنین MemoryOS نسخهٔ 2.0.34 در PyPI را شناسایی کردند. OSV نیز اکنون بستهٔ پایتونی را بهعنوان کد مخرب ثبت کرده است.
اهمیت این رخداد فقط به یک کتابخانهٔ آلوده محدود نمیشود. سامانههای حافظه در پشتهٔ عاملها به دادههای حساسی مانند پرامپتها، زمینهٔ بازیابیشده، اعتبارنامههای توسعهدهنده، تنظیمات ابزارها و وضعیت ماندگار نزدیکاند. اگر همین لایه آلوده شود، میتواند از سطح اعتمادی استفاده کند که معمولاً برای محیط اجرای اصلی عامل در نظر گرفته میشود.
چه چیزی آلوده شد؟
بستههای آسیبدیده یک کد مخرب چندسکویی نوشتهشده با Go با نام sckit داشتند. Socket گزارش کرد که این باینریها در پوشهٔ خانگی توسعهدهنده بهدنبال اطلاعات حساس میگشتند و دادهها را به زیرساختی در دامنهٔ skyleen[.]fr ارسال میکردند. تحلیل StepSecurity نیز نشان داد که اهداف شامل اعتبارنامههای کنترل نسخه، سرویسهای ابری، مخزنهای بسته و ابزارهای توسعه بوده است.
نحوهٔ اجرا از خود payload مهمتر است. این حمله فقط به یک اسکریپت نصب وابسته نبود که بتوان با غیرفعالکردن hookهای نصب جلوی آن را گرفت. طبق بررسی پژوهشگران، افزونهٔ OpenClaw میتوانست هنگام راهاندازی gateway و همچنین در جریان عادی بازیابی حافظه کد مخرب را اجرا کند. در نسخهٔ پایتونی نیز واردکردن ماژول memos میتوانست اجرای آن را فعال کند. OSV میگوید کد آلوده قابلیتهایی برای انتقال خود به مخزنها یا بستههای دیگری که با اعتبارنامههای سرقتشده قابل دسترسی بودند نیز داشت.
در نتیجه یک وابستگی ممکن است مرحلهٔ نصب را بدون هشدار پشت سر بگذارد اما هنگام اجرای عادی برنامه خطرناک شود.
چرا حافظهٔ عامل دامنهٔ آسیب را بزرگتر میکند؟
افزونهٔ حافظه یک وابستگی سادهٔ رابط کاربری نیست. وظیفهٔ آن مشاهدهٔ وضعیت گفتگو، بازیابی زمینهٔ قبلی و معمولاً اجرای خودکار قبل یا بعد از هر نوبت عامل است. در محیط عملیاتی، چنین مؤلفهای ممکن است در همان فرایندی اجرا شود که کلید API، توکن کنترل نسخه، دسترسی ابری و اطلاعات اتصال ابزارها را در اختیار دارد.
حادثهٔ MemTensor یک مشکل مرز اعتماد را آشکار میکند: ممکن است یک تیم امنیت مدل و چارچوب عامل را با دقت ارزیابی کند اما حافظه را فقط یک قابلیت جانبی بداند. از نظر عملیاتی، حافظه میتواند بخشی از پایهٔ مورد اعتماد سامانه باشد.
این خطر ماهیت ماندگار هم دارد. یک مؤلفهٔ حافظه قرار است بین نشستها باقی بماند و بارها در چرخهٔ اجرا شرکت کند. اگر آلوده شود، فرصتهای متعددی برای مشاهدهٔ پرامپت یا محیط اجرا خواهد داشت. StepSecurity مشخصاً گزارش کرده است که هنگام بازیابی حافظه، متن پرامپت در اختیار اجراکنندهٔ مخرب قرار میگرفت.
نتیجهٔ عملی برای Aipolix روشن است: حافظهٔ عامل باید مانند یک اتصال اجرایی با سطح دسترسی بالا طبقهبندی شود، نه صرفاً یک رابط ذخیرهسازی.
مرز واقعی امنیت، مسیر انتشار است
بررسیها این رخداد را یک حملهٔ سادهٔ جعل نام بسته توصیف نمیکنند. نسخههای مخرب با هویت رسمی بستههای MemTensor منتشر شدند. Socket اشاره کرده است که انتشار npm از حسابی انجام شده بود که سابقهٔ انتشار نسخههای معتبر را داشت، اما فرادادهٔ نسخههای مشکوک با مسیر معمول انتشار پروژه همخوان نبود.
این تفاوت مهم است، چون فهرست مجاز نام بسته جلوی چنین حملهای را نمیگیرد. وقتی خود هویت یک بستهٔ معتبر مورد سوءاستفاده قرار میگیرد، منشأ و زنجیرهٔ تولید artefact اهمیت بیشتری از شناخت نام پیدا میکند.
تیمها باید بدانند هر artefact از کدام commit ساخته شده، کدام workflow اجازهٔ انتشار داشته، آیا منشأ آن قابل راستیآزمایی است و آیا اعتبارنامهٔ انتشار میتواند خارج از مسیر مورد انتظار استفاده شود. سیاستی که فقط میپرسد «آیا این بسته تأیید شده است؟» از سیاستی که میپرسد «آیا این artefact دقیقاً از مسیر انتشار تأییدشده ساخته شده؟» ضعیفتر است.
وضعیت فعلی registryها نیز نشان میدهد بررسی latest کافی نیست. صفحهٔ npm اکنون 0.1.24 را بهعنوان latest نشان میدهد، در حالی که نسخههای مخرب point releaseهای دیگری بودند. PyPI نیز فرادادهٔ نسخهٔ 2.0.34 را در دسترس دارد. بنابراین موجودی نرمافزار باید بر اساس نسخهٔ دقیق نصبشده بررسی شود.
تیمهای آسیبدیده چه چیزی را باید بررسی کنند؟
سازمانهایی که یکی از نسخههای شناساییشده را نصب یا اجرا کردهاند، نباید موضوع را فقط با بازگشت به نسخهٔ قبلی تمامشده تلقی کنند. تحلیلهای منتشرشده توصیه میکنند اعتبارنامههایی که فرایند به آنها دسترسی داشته بررسی شوند، فعالیت مخزن و registry کنترل شود و احتمال استفاده از اعتبارنامههای انتشار در artefactهای بعدی نیز ارزیابی شود.
نسخههای گزارششده عبارتاند از:
- npm: `@memtensor/memos-cloud-openclaw-plugin` نسخههای 0.1.21، 0.1.23 و 0.1.25
- PyPI: `MemoryOS` نسخهٔ 2.0.34
پژوهشگران 0.1.20 و 2.0.33 را آخرین نسخههای پایهٔ شناختهشده پیش از انتشارهای مخرب معرفی کردهاند و npm اکنون latest را روی 0.1.24 قرار داده است. اما نصب نسخهٔ سالم جدید، اعتبارنامههایی را که قبلاً از یک سیستم آلوده کپی شدهاند باطل نمیکند.
پاسخ مناسب گستردهتر است: سیستمهای در معرض خطر باید ایزوله شوند، اعتبارنامهها از یک محیط پاک تعویض شوند، فعالیت CI و registry بررسی شود و artefactهای پاییندستی نیز دوباره اعتبارسنجی شوند.
این رخداد چه چیزی را برای مهندسی عامل تغییر میدهد؟
درس اصلی معماری است. سامانههای عاملمحور امروز زنجیرهای از افزونههای حافظه، سرورهای MCP، رابطهای ابزار، مسیریابهای مدل و گردشکارهای خودکار را کنار هم میگذارند. بسیاری از این اجزا با همان اختیار محیطی عامل اجرا میشوند.
اسکن وابستگی همچنان لازم است، اما زیرساخت عامل یک سؤال اضافه دارد: این وابستگی هر بار که عامل اجرا میشود چه چیزهایی را میتواند ببیند؟
حادثهٔ MemTensor این سؤال را از حالت نظری خارج کرده است. اتصال حافظهٔ بلندمدت میتواند پلی میان دادهٔ گفتگو، رازهای توسعهدهنده و اختیار انتشار نرمافزار باشد. طراحی امنتر باید اعتبارنامههای محیطی را محدود کند، افزونههای عامل را ایزوله نگه دارد، نسخهها و artefactها را ثابت و راستیآزمایی کند و منشأ artefact را بخشی از سیاست استقرار بداند.