مرز امنیتی رجیستری Cargo در دو نقطه شکست: سازندگان Rust چه چیزهایی را باید ممیزی کنند؟

مرز امنیتی Cargo فقط به کامپایلر محدود نمی‌شود. URLهای رجیستری، توکن‌های احراز هویت، استخراج آرشیوها و کش محلی کد منبع نیز بخشی از آن هستند. دو هشدار منتشرشده از سوی تیم پاسخ‌گویی امنیتی Rust در ۲۵ مه ۲۰۲۶ این مرز را روشن کردند.

نخستین مشکل، CVE-2026-5222، نسخه‌های Cargo همراه با Rust 1.68 تا پیش از Rust 1.96 را تحت تأثیر قرار می‌داد. Cargo هنگام کار با رجیستری‌های sparse، قاعده‌ای را که برای رجیستری‌های Git نوشته شده بود دوباره استفاده می‌کرد. در یک آرایش بسیار محدود میزبانی، ممکن بود https://example.com/index و https://example.com/index.git دارای اعتبارنامه مشترک تلقی شوند، در حالی که یک سرور HTTPS می‌تواند این دو منبع را متفاوت بداند. مهاجمی که امکان انتشار در یک رجیستری و بارگذاری فایل در دیگری را داشت، می‌توانست وابستگی‌ای بسازد که باعث ارسال توکن Cargo قربانی به رجیستری مخرب شود.

مشکل دوم، CVE-2026-5223، به symlinkهای داخل tarballهای crate از رجیستری‌های شخص ثالث مربوط بود. حفاظ‌های Cargo مانع خروج فایل از پوشه کش همان crate می‌شدند، اما یک آرشیو دست‌کاری‌شده می‌توانست یک سطح پایین‌تر از آن پوشه بنویسد و کد کش‌شده crate دیگری را در همان رجیستری بازنویسی کند. این یک مشکل تمامیت زنجیره تأمین است: build بعدی ممکن است کدی را کامپایل کند که با بسته مورد انتظار یکسان نیست.

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

Rust 1.96.0 اصلاحات مرتبط را اضافه کرد. برای CVE-2026-5222، Cargo فقط در URLهای رجیستری با پروتکل Git پسوند .git را حذف می‌کند. برای CVE-2026-5223، Cargo وجود symlink در tarballهای crate را رد می‌کند. هشدار رسمی می‌گوید کاربران crates.io از مشکل symlink آسیب‌پذیر نیستند، زیرا crates.io از ابتدا بارگذاری crateهای دارای symlink را ممنوع کرده است. مشکل رجیستری sparse به ترکیبی بسیار محدودتر از شرایط میزبانی و مجوزهای انتشار در رجیستری‌های شخص ثالث وابسته است.

این تفاوت باید سیاست build در ICP·Dev را شکل دهد. نخست مشخص کنید CI یا رایانه‌های توسعه از رجیستری‌های جایگزین، mirrorها یا ایندکس‌های sparse خصوصی استفاده می‌کنند یا نه. دوم، نسخه Cargo موجود در image ابزار را pin و بررسی کنید و فرض نکنید وضعیت rustup میزبان به‌روز است. سوم، از اپراتور رجیستری بپرسید آیا symlink را رد می‌کند و آیا namespaceهای رجیستری را در لایه HTTP و اعتبارنامه از هم جدا می‌سازد. در نهایت، با توکن‌های Cargo مانند اعتبارنامه‌های حساس رفتار کنید؛ صرفاً شبیه‌بودن دو URL نباید باعث عبور توکن از مرز رجیستری شود.

یک نکته احتیاطی درباره امتیازدهی فعلی وجود دارد: رکورد NVD برای CVE-2026-5222 هم ارزیابی CVSS-B برابر با ۲٫۳ و سطح Low از سوی Rust و هم امتیاز CVSS 3.1 برابر با ۶٫۵ و سطح Medium از سوی NIST را نشان می‌دهد. این اعداد از دو دیدگاه امتیازدهی متفاوت می‌آیند؛ پاسخ عملی باید بر بررسی شرایط در معرض خطر متمرکز باشد، نه بر یک برچسب واحد.

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