بیشتر مطالب امنیتی این خبرنامه درباره چیزهایی است که مستقیماً برای شما رخ میدهند: یک پیامک فیشینگ، یک گذرواژه افشاشده، یا یک سایت خرید جعلی. اما این مورد متفاوت است. حوادث زیر برای توسعهدهندگان رخ دادهاند — همان افرادی که برنامهها و سرویسهایی را مینویسند که هر روز استفاده میکنید. اما دلیل سادهای دارد که این موضوع به اینجا مربوط میشود: اگر کسی ابزارهای مورد استفاده برای ساخت نرمافزار را مسموم کند، این سم نزد سازنده باقی نمیماند؛ همراه محصول ارسال میشود.
اخیراً دو اتفاق رخ داد که این موضوع را بهخوبی نشان میدهند. هیچکدام مانند یک رخنه بزرگ امنیتی تیتر خبرها نشدند، چون هیچکدام، مشخصاً رخنهای در مورد شما نیستند. هر دو حمله به زنجیرهای هستند که نرمافزاری را تولید میکند که در نهایت نصبش میکنید، بازش میکنید یا وارد آن میشوید.
افزونههای تقلبی با ظاهر برندهای معتبر
Open VSX یک بازار عمومی برای افزونههای ویرایشگر کد است — افزونههای کوچک و جانبیای که توسعهدهندگان برای دریافت تکمیل خودکار، بررسی خطا و یکپارچهسازی با ابزارهایی که هر روز استفاده میکنند نصب میکنند (Visual Studio Code و چند مورد از نسخههای متنباز مشابه آن، افزونههایشان را از این بازار دریافت میکنند). بین 26 ژوئیه و 1 اوت 2026، پژوهشگران امنیتی Manifold Security، 77 افزونه تقلبی را در این مخزن پیدا کردند. هرکدام نام و فضای نام یک افزونه واقعی و مورداعتماد را کپی کرده بود، اما از حسابی منتشر شده بود که مالک نسخه اصلی نبود — اقدامی کلاسیک برای جعل هویت که گاهی «تصاحب فضای نام» نامیده میشود.
نامهای تصاحبشده تصادفی نبودند. آنها هویتهای AMD، LEGO Education، Hyperledger، Azure، پروژههای متنباز Salesforce، یک نهاد فدرال ایالات متحده و — با نوعی طنز تلخ — خود بازار افزونهها را借 گرفتند. هر 77 بسته به یک دامنه واحد متصل میشد که فقط 11 روز پیش از ظاهر شدن نخستین بسته جعلی ثبت شده بود؛ الگویی که بیشتر از کپیبرداری فرصتطلبانه، نشاندهنده یک کارزار هماهنگ و هدفمند است.
بیشتر افزونههای جعلی کار نسبتاً سادهای انجام میدادند: بیسروصدا نام میزبان را به سرور مهاجم گزارش میکردند؛ کاری که بهتنهایی شاید فقط بررسی این باشد که چه کسی طعمه را نصب کرده است. اما پژوهشگران دریافتند که حدود یکچهارم 77 مورد — 19 بسته — فراتر رفتند. چند ثانیه پس از فعالسازی، نام میزبان، نام کاربری سیستمعامل، جزئیات ویرایشگر و شناسه دستگاه را جمعآوری میکردند. سپس هر پروژهای را که توسعهدهنده باز گذاشته بود میخواندند: مخزن راه دور git (که سازمان و میزبان مخزن را مشخص میکند)، دامنه ایمیل commit، شاخه فعلی و جدیدترین commit. آنها همچنین مقادیر یکپارچهسازی پیوسته را استخراج میکردند — اطلاعات کاربری و پیکربندیای که به سیستمهای خودکار اجازه میدهد بدون وارد کردن گذرواژه توسط انسان در هر بار، کد را بسازند و مستقر کنند.
هیچیک از این دادهها برای خالی کردن حساب بانکی کسی مفید نیست. کاربردشان چیز دیگری است: فهمیدن اینکه توسعهدهنده برای کدام شرکتها کار میکند، زیرساخت داخلی آنها چه شکلی است و چگونه میتوان در آن جای پایی پیدا کرد.
باگ 9.8 از 10 در دستگاهی که نرمافزار را میسازد
حادثه دوم مربوط به TeamCity است؛ بستری برای یکپارچهسازی پیوسته و تحویل پیوسته (CI/CD) که JetBrains ساخته است. اگر ویرایشگر کد جایی است که توسعهدهندگان نرمافزار را در آن مینویسند، پلتفرم CI/CD کف کارخانه خودکاری است که کد در آن کامپایل، آزمایش و به محیط تولید ارسال میشود — اغلب بدون اینکه هیچ انسانی اصلاً روی «deploy» کلیک کند. TeamCity بخش مرکزی این سازوکار در بسیاری از شرکتهاست.
آسیبپذیریای با شناسه CVE-2026-63077 و امتیاز شدت 9.8 از 10 ممکن، در نسخههای درونسازمانی TeamCity افشا شد. این یک نقص در فرایند deserialization است — دستهای از باگها که در آن برنامه آنقدر به دادههای ورودی اعتماد میکند که آنها را مستقیماً به کد در حال اجرا تبدیل میکند، بدون اینکه ابتدا بررسی کند آن داده واقعاً چیست. در عمل، مهاجم میتوانست بدون نیاز به ورود، درخواستی به یک سرور آسیبپذیر TeamCity ارسال کند و فرمانهای دلخواه را با همان سطح دسترسی سرویس TeamCity اجرا کند. JetBrains وصلههایی منتشر کرده است (نسخههای 2025.11.7 و 2026.1.3، بهعلاوه یک افزونه وصله برای نصبهای قدیمیتر 2017.1 به بعد)، اما آژانس امنیت سایبری و امنیت زیرساخت ایالات متحده (CISA) از آن زمان هشدار داده است که مهاجمان بهطور فعال در حال سوءاستفاده از سیستمهای وصلهنشده هستند.
هرکس سرور ساخت یک شرکت را کنترل کند، کنترل میکند آن شرکت چه چیزی را عرضه میکند. این یک فرضیه نیست — کارکرد واقعی این ابزار دقیقاً همین است.
یک نقشه راه، دو درِ متفاوت
اینها حوادثی نامرتبط و حاصل پژوهشگران متفاوتاند، اما شکل مشترکی دارند. هیچکدام به محصول نهایی حمله نمیکنند. هر دو یک مرحله زودتر را هدف میگیرند — ویرایشگری که توسعهدهنده در آن کد مینویسد، یا سروری که آن کد را به نسخه قابل عرضه تبدیل میکند. این ویژگی تعیینکننده حمله به زنجیره تأمین نرمافزار است: بهجای نفوذ به یک هدف، چیزی را در بالادست که اهداف متعدد به آن وابستهاند به خطر میاندازید و میگذارید فرایند مورداعتماد خودشان دسترسی شما را بهجای شما جلو ببرد.
ارزش دارد درباره چیزهایی که هنوز نمیدانیم صادق باشیم. هیچیک از گزارشهایی که این هفته منتشر شدند، مورد تأییدشدهای از بهخطر افتادن یک برنامه یا کاربر پاییندست را در نتیجه مستقیم این حوادث افشا نکردند — کارزار افزونهها شبیه شناسایی و جمعآوری اطلاعات دسترسی است و بهرهبرداری از TeamCity فعال توصیف شده، اما قربانی مشخصی نام برده نشده است. این عادی است؛ به خطر افتادن زنجیره تأمین اغلب مدتها پیش از ردیابی نتیجه نهایی (یا بهجای آن)، در نقطه ورود کشف میشود.
چرا این مشکل شماست، نه فقط مشکل آنها
احتمالاً هرگز یک افزونه برنامهنویسی نصب نمیکنید یا یک سرور CI/CD راه نمیاندازید. اما از خروجی صدها مورد از آنها استفاده میکنید: برنامه بانکیتان، مدیر گذرواژهتان، پرتال مدرسه فرزندتان، و مرورگری که این مطلب را در آن میخوانید. همه اینها پیش از رسیدن به تلفن شما، از ویرایشگر یک توسعهدهنده و خط لوله ساخت یک شرکت عبور کردهاند. اگر هرکدام از این پیوندها بیسروصدا به خطر افتاده باشد، تغییر مخرب میتواند همراه یک بهروزرسانی عادی و معمول نرمافزار منتقل شود — همان نوع بهروزرسانیای که نصب میکنید چون به شما گفتهاند بهروزرسانی کردن کار امنی است.
به همین دلیل است که توصیههای گزارش بررسی پس از رخنه گاهی برای خوانندگان غیرفنی عجیب به نظر میرسد: شرکتی میگوید سیستمهایش از طریق یک سرور ساخت، یک اعتبارنامه دزدیدهشده توسعهدهنده یا یک وابستگی مخرب به خطر افتادهاند، و این در کنار جمله «یک نفر گذرواژهام را حدس زد» انتزاعی به نظر میرسد. اما انتزاعی نیست. نتیجه همان است — دادههای شما یا یکپارچگی برنامهتان به خطر افتاده — فقط از دری وارد شده که هرگز نمیدانستید وجود دارد.
آنچه واقعاً کمک میکند
شما نمیتوانید خط لوله CI/CD بانکتان را ممیزی کنید و نباید هم مجبور باشید. اما چند عادت واقعاً مواجهه شما با این دسته از خطرها را کاهش میدهد:
بهروزرسانی خودکار را روشن نگه دارید، اما بهروزرسانیها را بهطور خودکار قابلاعتماد فرض نکنید. وصلهها همان چیزی هستند که اصلاحاتی مانند مورد TeamCity بالا را به نرمافزاری که اجرا میکنید میرسانند — بهروز ماندن، پنجرههایی را که مهاجمان فعالانه بررسی میکنند میبندد. در عین حال، کیفیت یک بهروزرسانی فقط به اندازه خط لولهای است که آن را تولید کرده؛ و دقیقاً همین خط لوله در اینجا هدف قرار گرفته است. در برابر یک نسخه بالادستی واقعاً مسمومشده، هیچ دفاع فردی کاملی وجود ندارد؛ به همین دلیل این اساساً مشکل مسئولیت فروشنده است، نه مشکل شما.
اگر با توسعهدهندگان کار میکنید یا مدیریتشان میکنید، دو کار مشخص و قابلبررسی انجام دهید: مطمئن شوید هر افزونه ویرایشگر کد از حساب واقعی و تأییدشده ناشر نصب شده است، نه صرفاً حسابی با نام مشابه (Open VSX و بازارهای مشابه هویت ناشر را نشان میدهند — آن را بررسی کنید و فقط به نماد و عنوان اعتماد نکنید)؛ و اگر سازمان شما TeamCity را بهصورت درونسازمانی اجرا میکند، همین امروز تأیید کنید که روی 2025.11.7 یا 2026.1.3 است، یا افزونه وصله روی آن اعمال شده است، نه در پنجره تعمیر و نگهداری بعدی — هشدار CISA یعنی این آسیبپذیری بهطور فعال مورد سوءاستفاده قرار میگیرد، نه اینکه صرفاً نظری باشد.
برای بقیه، تغییر مفید فقط آگاهی است: وقتی درباره رخنهای در یک شرکت میخوانید که ریشهاش به «یک ابزار توسعهدهنده به خطر افتاده» یا «یک سیستم ساخت» برمیگردد، این یک پانوشت فنی تخصصی نیست. این همان دسته رویدادی است که رخنههای گذرواژه و کلاهبرداریهای فیشینگ این خبرنامه بیشتر پوشش میدهد — فقط یک لایه بالاتر در زنجیره، پیش از آنکه محصول اصلاً به شما برسد، آغاز شده است.
