یک پژوهشگر مستقل ۷٫۲۵ میلیون مخزن عمومی Gitee را اسکن کرد و ۲۶٬۴۰۰ کلید ابری و هوش مصنوعی پیدا کرد که هنوز کار میکنند؛ از OpenAI و DeepSeek تا Alibaba Cloud و YouTube. این گزارش نشان میدهد چرا «پاککردن کلید از کد» هیچوقت کافی نیست.
لیست مطالب
۱. ماجرا چیست؟ خلاصهی خبر در یک نگاه
در ۲۸ اکتبر ۲۰۲۶ پژوهشگری مستقل به نام بن زیمرمن نتیجهی یک اسکن یکماهه را منتشر کرد. او مخازن عمومی پلتفرم Gitee را بررسی کرد؛ پلتفرمی که معمولاً «نسخهی چینی GitHub» توصیف میشود و وزارت صنعت و فناوری اطلاعات چین در سال ۲۰۲۰ آن را پایهی یک بستر ملی میزبانی کد متنباز انتخاب کرد. حاصل کار، ۲۶٬۴۰۰ اعتبارنامهی یکتا بود که هنوز در برابر سرویس صادرکنندهی خود احراز هویت میشدند.
این عدد دربارهی «رشتههای شبیه کلید» نیست. هر نتیجه روی سرویس اصلی آزمایش شده و فقط مواردی شمرده شدهاند که واقعاً کار میکردند. یعنی اگر مهاجمی همان لحظه آنها را برمیداشت، میتوانست از حساب صاحب کلید استفاده کند.
اگر تازه با دنیای مدلهای زبانی و API آشنا شدهاید، پیشنهاد میکنیم اول مقالهی OpenAI چیست؟ را بخوانید تا بدانید این کلیدها دقیقاً به چه چیزی دسترسی میدهند.

۲. روش پژوهش؛ چطور ۷٫۲۵ میلیون مخزن بررسی شد؟
زیمرمن حدود یک ماه روی این پروژه کار کرد. Gitee API عمومی محدودی دارد و همین موضوع باعث شده بود پژوهش مشابهی در سال ۲۰۲۱ نیمهکاره رها شود. او با دورزدن این محدودیت، فهرست مخازن عمومی را گرفت و دو ابزار شناسایی راز یعنی TruffleHog و Kingfisher را روی کل تاریخچهی کامیتهای هر مخزن اجرا کرد.
چرا تاریخچهی کامیت مهم است؟
بسیاری از توسعهدهندهها وقتی متوجه میشوند کلیدی را در کد گذاشتهاند، فایل را ویرایش میکنند و کلید را پاک میکنند. اما نسخهی قبلی در تاریخچهی گیت میماند. چون اسکن کل تاریخچه را دیده، کلیدهای «پاکشده» هم پیدا شدهاند و دقیقاً همین نشان میدهد پاککردن بهتنهایی مشکل را حل نمیکند.
اعتبارسنجی و حذف تکراریها
هر اعتبارنامه یک بار شمرده شده، حتی اگر در چند مخزن تکرار شده باشد. سپس با سرویس صادرکننده تماس گرفته شده و فقط کلیدهای فعال نگه داشته شدهاند. نتیجهی نهایی همان ۲۶٬۴۰۰ مورد است.
۳. کدام کلیدها لو رفتند؟ ارقام به تفکیک سرویس
بزرگترین گروه، ۹٬۴۷۳ جفت کلید دسترسی Alibaba Cloud است. پس از آن ۳٬۸۰۵ کلید YouTube API قرار دارد. در بخش هوش مصنوعی، ۳٬۱۷۰ کلید DeepSeek، ۱٬۴۸۹ کلید Zhipu BigModel و ۱٬۳۴۸ کلید OpenAI گزارش شده است. تعداد کمتری هم به GitHub، AWS، Google Cloud و Google Gemini تعلق داشته و یک اعتبارنامهی مدیر سازمان در یک پلتفرم سازمانی هوش مصنوعی هم دیده شده که نام آن اعلام نشده است.
از نظر زمانی، ۱۲٬۲۴۲ کلید، یعنی تقریباً نیمی از کل، به کامیتهای سال ۲۰۲۵ برمیگردد. بعضی نمونهها حتی به اواخر دههی ۲۰۰۰ میلادی میرسند و هنوز کار میکنند. این یعنی بسیاری از صاحبان کلید اصلاً نمیدانند حسابشان در معرض خطر است.
جالب است که دو ابزار اسکن تقریباً نتایج متفاوتی دادند: TruffleHog به ۱۲٬۷۳۷ کلید فعال رسید، Kingfisher به ۱۴٬۶۶۴ و فقط ۱٬۰۰۱ مورد در هر دو مشترک بود. دلیلش هم ساده است؛ مثلاً TruffleHog آشکارساز Zhipu ندارد و همهی کلیدهای BigModel را فقط Kingfisher پیدا کرد.

۴. خطر واقعی برای صاحب کلید چیست؟
کلید API در عمل «رمز عبور حساب پولی» شماست. برای OpenAI، کلید لورفته یعنی دیگران میتوانند از سهمیهی حساب شما بدون اجازه استفاده کنند. پیامدها شامل صورتحساب غیرمنتظره، تمامشدن سهمیه و قطع دسترسی API برای خود شماست.
برای کلیدهای گوگل و یوتیوب، اگر محدودیت API روی کلید نگذاشته باشید، همان کلید با هر API دیگری که از کلیدهای Google Cloud پشتیبانی میکند هم کار میکند. در مورد Alibaba Cloud ماجرا جدیتر است، چون جفت کلید دسترسی میتواند به منابع ذخیرهسازی و داده هم راه بدهد.
اگر دربارهی ابعاد کسبوکاری استفاده از هوش مصنوعی کنجکاوید، مقالهی اهمیت هوش مصنوعی در کسبوکار نشان میدهد چرا امنیت زیرساخت AI به یک موضوع مدیریتی تبدیل شده است.
۵. توصیههای رسمی؛ قدمبهقدم چه کنیم؟
گزارش یک اصل ساده دارد: هر کلیدی که حتی یک بار در مخزن عمومی Gitee بوده را لورفته فرض کنید. حذف فایل، حذف مخزن یا بازنویسی تاریخچه چیزی را باطل نمیکند.
OpenAI
از صفحهی API Keys کلید جدید بسازید، برنامهها را به آن منتقل کنید، کلید قدیمی را حذف کنید و در بخش تنظیمات صورتحساب سقف هزینه تعیین کنید.
Alibaba Cloud
یک جفت AccessKey جدید بسازید، سرویسها را منتقل کنید، سپس کلید قدیمی را غیرفعال و حذف کنید. ردپای فراخوانیها را در ActionTrail (تا ۹۰ روز) و لاگ سرویسهای داده مثل OSS و SLS بررسی کنید و دنبال هزینهی عجیب یا تغییر منبع ناشناخته باشید.
Google و YouTube
کلید را بچرخانید، برنامهها را بهروز کنید، کلید قدیمی را حذف کنید و برای کلید جدید فقط APIهای لازم را مجاز کنید.
اگر هنوز کلیدتان را در محیطهای توسعهی هوشمند نگه میدارید، مقالهی حملهی EMBRACE به مرورگر ابزارهای کدنویسی هوشمند را هم ببینید؛ هر دو خبر یک پیام مشترک دارند.

۶. چرا این خبر برای کاربران ایرانی هم مهم است؟
خیلی از توسعهدهندهها و علاقهمندان فارسیزبان برای ساخت ربات تلگرام، دستیار هوشمند یا اتوماسیون، کلید API میگیرند و کدشان را روی GitHub، GitLab یا Gitee میگذارند. اشتباه رایج این است که کلید مستقیم داخل فایل کد نوشته میشود. درست همین عادت باعث این حجم نشت شده است.
حتی اگر مخزن شما خصوصی بوده، کافی است یک بار عمومی شده باشد یا کد را برای کسی فرستاده باشید. بنابراین اقدام درست، چرخش کلید است نه امیدواری به اینکه «کسی ندیده».
اگر تازه شروع کردهاید، مقالهی آموزشهای ChatGPT و راهنمای نوشتن پرامپت برای مبتدیها نقطهی شروع خوبی هستند، به شرط اینکه از همان ابتدا مدیریت کلید را یاد بگیرید.
۷. چطور از نشت کلید جلوگیری کنیم؟
راهکارهای عملی سادهاند و هزینهای ندارند. این فهرست کوتاه، پایهی هر پروژهی جدی است.
نخست، کلید را هرگز داخل کد ننویسید و از متغیر محیطی یا فایل تنظیمات خارج از مخزن استفاده کنید. دوم، فایلهای محرمانه را در gitignore بگذارید. سوم، پیش از هر کامیت، یک ابزار اسکن راز مثل همان ابزارهایی که پژوهشگر استفاده کرد را اجرا کنید؛ البته به یاد داشته باشید که یک ابزار بهتنهایی همهی سرویسها را پوشش نمیدهد. چهارم، برای هر کلید سقف هزینه و دامنهی دسترسی محدود تعریف کنید. پنجم، کلیدها را بهصورت دورهای بچرخانید.
نمونهی دیگری از رویکرد درست را میتوانید در خبر 1Password for Agents ببینید؛ جایی که عامل هوشمند اصلاً رمز را نمیبیند.
برای تیمها، یک گام دیگر هم لازم است: فهرست همهی کلیدهای فعال سازمان را داشته باشید. بسیاری از شرکتها نمیدانند چند کلید OpenAI یا سرویس ابری در پروژههای قدیمی و آزمایشی پراکنده است. وقتی فهرست مشخصی وجود نداشته باشد، حتی بعد از اعلام نشت هم نمیتوان مطمئن شد همهی کلیدها عوض شدهاند. بهتر است برای هر کلید صاحب مشخص، تاریخ ساخت و تاریخ چرخش بعدی ثبت شود.
همچنین به یاد داشته باشید که ابزارهای هوش مصنوعی کدنویسی، مانند دستیارهایی که فایلهای پروژه را میخوانند، ممکن است محتوای فایلهای محیطی را در لاگ یا تاریخچهی گفتگو نگه دارند. پس فقط مخزن عمومی تنها منبع نشت نیست؛ لاگها، اسکرینشاتها و فایلهای اشتراکی هم باید بررسی شوند. هر جا کلیدی دیده شده، همانجا را هم پاک و کلید را باطل کنید.
در نهایت، این ماجرا نشان میدهد که سرعت رشد هوش مصنوعی باعث شده تعداد کلیدهای API در دنیا بهشدت زیاد شود، اما فرهنگ مدیریت راز همان سرعت را دنبال نکرده است. هر کلید جدید، یک نقطهی ورود جدید است و باید با همان دقتی که برای رمز بانکی قائل هستید، نگهداری شود.
۸. محدودیتهای گزارش و نکات احتیاطی
باید به چند نکته توجه کنیم. اول اینکه این پژوهش مستقل است و نتایج آن را خود پژوهشگر منتشر کرده است. دوم اینکه عدد ۳٫۶۴ کلید فعال در هر هزار مخزن برای Gitee را نباید ملاک مقایسهی مستقیم با GitLab یا Bitbucket گرفت، چون ابزارهای اسکن در پژوهشهای قبلی فرق داشتند. سوم اینکه پژوهشگر به خود توسعهدهندگان نشتیدهنده پیام نداده و در زمان انتشار تأیید نشده بود که کلیدهای گزارششده باطل شده باشند.
پس هنوز نمیدانیم چند درصد این کلیدها تا امروز توسط شرکتها غیرفعال شدهاند. ریسک را کم نگیرید.
برای دید بازتر دربارهی مرز توانایی و ریسک این فناوری، تواناییها و محدودیتهای واقعی هوش مصنوعی را هم بخوانید.
۹. پرسشهای متداول (FAQ)
اگر کلیدم را از فایل پاک کنم کافی است؟
خیر. نسخهی قدیمی در تاریخچهی گیت میماند و کلید تا زمانی که در سرویس باطل نشود، فعال است. باید آن را بچرخانید.
از کجا بفهمم کلیدم سوءاستفاده شده؟
مصرف و صورتحساب را در داشبورد سرویس بررسی کنید. افزایش ناگهانی درخواستها، مدلهایی که استفاده نکردهاید یا IPهای ناشناس نشانهی خطر است. برای Alibaba Cloud، لاگ ActionTrail را هم ببینید.
آیا فقط Gitee مشکل دارد؟
خیر. نشت راز در همهی پلتفرمهای میزبانی کد دیده میشود. پژوهشهای قبلی با TruffleHog روی GitLab و Bitbucket هم نمونههای فعال پیدا کرده بودند، اما اعداد قابل مقایسهی مستقیم نیستند.
سقف هزینه چقدر کمک میکند؟
خیلی. اگر کلید لو برود، سقف هزینه جلوی صورتحساب بزرگ را میگیرد، اما جایگزین چرخش کلید نیست.
خبرهای مشابه را از کجا دنبال کنم؟
بخش اخبار هوش مصنوعی سایت را دنبال کنید.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
