۵۴ مورد از گزارش‌های آسیب‌پذیری SQLite با هوش مصنوعی جعل شده بود

اگر مدیر امنیت اطلاعات هستید و هر روز ده‌ها هشدار با امتیاز ۱۰ از دیتابیس‌های خود دریافت می‌کنید، باید بدانید که برخی از این بحران‌ها اصلاً وجود خارجی ندارند. یک موج از گزارشات جعلی در مورد SQLite نشان داد که اکنون هوش مصنوعی می‌تواند «ترس» را در مقیاس صنعتی تولید کند.

به گزارش JFrog، یک مخزن گیت‌هاب به نام 'programmervuln/cveadvisory-' بیش از ۵۰ مورد CVE جعلی منتشر کرد که اکثر آن‌ها توسط یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — ساخته شده بود. بررسی دقیق ۵۵ گزارش منتشر شده توسط این حساب کاربری نشان داد که ۵۴ مورد آن‌ها کاملاً ساختگی بودند و تنها یک مورد حاوی باگ واقعی بود که آن هم در بسته‌ای از متادیتای تاییدنشده قرار داشت.

این حادثه در لحظه‌ای رخ می‌دهد که زیرساخت‌های جهانی امنیت سایبری در وضعیت شکننده‌ای هستند. از فوریه ۲۰۲۴، پایگاه داده ملی آسیب‌پذیری (NVD) با حجم عظیمی از گزارشات انباشته شده درگیر است و عملاً تحلیل‌های دستی عمیقی که پیش‌تر به عنوان یک توری نجات برای گزارشات ورودی عمل می‌کردند، متوقف شده‌اند. در دنیایی که اسکنرهای خودکار بر اساس امتیازات شدت اثر (Severity Scores)، تیکت‌های فوری صادر می‌کنند، این شکاف اجازه می‌دهد «آشغال‌های AI» (AI Slop) بدون شناسایی وارد سوابق رسمی شوند. آزمایش‌های Gptzero تایید کرد که گزارشات موجود در این مخزن توسط هوش مصنوعی تولید شده‌اند و ترکیب آن‌ها در یک فایل واحد، هشدارهای بیشتری مبنی بر تولید محتوا توسط AI فعال کرد.

همان‌طور که در تحلیل قبلی ما درباره‌ی اثر Temperature بر کیفیت خروجی مدل‌ها اشاره کردیم، این اتفاق وجه تاریک‌تر تصادفی بودن مدل‌هاست: توانایی تولید متنی که کاملاً منطقی به نظر می‌رسد اما از نظر فنی توخالی است. این مسئله یادآور خطرات مشابهی است که در توزیع بسته‌های توهمی و بدافزاری توسط هوش مصنوعی مشاهده شده است، جایی که توهمات مدل منجر به معرفی ابزارهای خطرناک می‌شود. در حالی که یک کاربر عادی ممکن است یک شعر عجیب تولید شده توسط AI را نادیده بگیرد، اما یک CISO (مدیر ارشد امنیت اطلاعات) نمی‌تواند امتیاز «بحرانی ۱۰.۰» را برای یک آسیب‌پذیری در موتور دیتابیس مرکزی خود نادیده بگیرد.

کالبدشکافی یک توهم

بررسی‌کنندگان JFrog برای رد این ادعاها، یک گردش کار سخت‌گیرانه و دقیق را اجرا کردند. این فرآیند شامل چهار مرحله کلیدی بود:

• بررسی منبع: کلون کردن مخزن رسمی sqlite/sqlite و بررسی تگ‌های هدف، به‌طور مشخص نسخه‌های version-3.41.0، version-3.51.2 و version-3.51.3.
• ساخت محیط پاک: کامپایل نسخه‌های رسمی SQLite مستقیماً داخل کانتینرهای ایزوله داکر برای جلوگیری از هرگونه آلودگی محیطی یا تداخلات سیستمی.
• اجرای PoC: وارد کردن دقیق دستورات SQL موجود در گزارشات (PoC) به باینری‌های کامپایل شده با استفاده از ابزار AddressSanitizer (ASan) برای شناسایی هرگونه باگ حافظه. در این راستا، ابزارهای تحلیل استاتیک پیشرفته‌تر مانند سیستم sqlsure می‌توانند با بازرسی قطعی، تفاوت بین خطاهای واقعی SQL و توهمات AI را تشخیص دهند.
• حسابرسی NVD و متادیتا: ارزیابی الگوهای CPE و متادیتای گزارش‌ها در فیدهای NVD و GHSA.

نتایج تکان‌دهنده بود. پژوهشگران چندین «پرچم قرمز» تکراری در گزارشات تولید شده توسط AI یافتند که ویژگی آن‌ها کدهای غیرموجود، منطق غیرممکن و شماره خطوط خیالی بود.

تحلیل جزئیات CVEهای ساختگی

از طریق این حسابرسی، JFrog شکست‌های خاصی را در چندین آسیب‌پذیری گزارش شده مستند کرد:

• CVE-2026-51302 (UAF در exprComputeOperands): با امتیاز ۹.۸ (بحرانی) گزارش شد. در این گزارش ادعا شده بود که یک خطای heap use-after-free زمانی رخ می‌دهد که تابع sqlite3ReleaseTempReg() یک اشاره‌گر معلق در regFree1 باقی می‌گذارد. در واقعیت، تابع exprComputeOperands() در نسخه ۳.۴۱ اصلاً وجود نداشت و در اواسط سال ۲۰۲۵ (تراکنش‌های e24f20a و 280559b) اضافه شد. علاوه بر این، تابع sqlite3ReleaseTempReg() صرفاً شاخص‌های رجیستر را در یک آرایه بازیافت می‌کند و این امر وقوع UAF را از نظر طراحی غیرممکن می‌سازد.
• CVE-2026-51303 (UAF در ExprListDelete): با امتیاز ۹.۸ (بحرانی) گزارش شد. ادعا شد که ExprListDelete() در پاک‌سازی ارجاعات معکوس در ساختارهای والد شکست می‌خورد و ادعای وجود یک وصله در نسخه ۳.۵۱.۳ مطرح شد. با این حال، مقایسه تفاوت (diff) بین نسخه‌های ۳.۵۱.۲ و ۳.۵۱.۳ نشان داد که هیچ تغییری در فایل src/expr.c رخ نداده است. همچنین کد PoC ارائه‌شده، یک SQL نامعتبر بود و در مرحله تجزیه (parser) شکست خورد.
• CVE-2026-5100 (UAF در sqlite3ExprDelete): با امتیاز ۹.۱ (بحرانی) گزارش شد. این گزارش به خطوط ۱۰۱۲ و ۱۰۲۶ در فایل expr.c ارجاع داد. در واقعیت، این خطوط به ترتیب یک «کامنت» و یک «فراخوانی تخصیص حافظه» بودند. چون این تابع در هنگام مدیریت خطای OOM (کمبود حافظه) در انتهای یک Scope فراخوانی می‌شود، اشاره‌گر هرگز دوباره مورد استفاده قرار نمی‌گیرد.
• CVE-2026-51297 (UAF از طریق jsonBlobEdit): با امتیاز ۸.۸ (بالا) گزارش شد. در گزارش به تابع jsonBlobEdit() اشاره شده بود، اما این تابع در نسخه ۳.۴۱.۰ وجود نداشت، زیرا بعدها برای پیاده‌سازی JSONB معرفی شد. اجرای PoC تنها منجر به خطای JSON نامعتبر شد و هرگز به منطق تغییرات نرسید.
• CVE-2026-51296 (UAF در jsonRemoveFunc): با امتیاز ۷.۵ (بالا) گزارش شد. ادعای گزارش به خطوط ۳۵۵۵ و ۳۵۷۵ در فایل json.c اشاره داشت. اما در نسخه ۳.۴۱.۰، کل فایل src/json.c تنها ۲۷۰۶ خط است. تابع واقعی ۲۰۰۰ خط جلوتر قرار داشت و هیچ نقص حافظه‌ای نداشت.
• CVE-2026-51304 (UAF از طریق pOrderBy->nExpr): با امتیاز ۷.۵ (بالا) گزارش شد. گزارش تابعی را با تعداد آرگومان اشتباه نشان داد؛ در حالی که امضای واقعی تابع به یک اشاره‌گر به بافت دیتابیس (sqlite3 *db) نیاز دارد. علاوه بر این، SQLite صراحتاً اشاره‌گر را پس از حذف صفر می‌کند (مثلاً pPrior->pOrderBy = 0 در select.c:3761) و این کار از دسترسی غیرمجاز (dereferencing) جلوگیری می‌کند.

شکست‌های سیستمی در اعتبارسنجی

هشداردهنده‌ترین بخش، نحوه کسب مشروعیت این جعل‌ها است. شرکت Red Hat ابتدا به CVE-2026-51302 امتیاز بحرانی ۱۰.۰ داد و بعداً آن را به ۷.۶ کاهش داد. هر دو سازمان NVD و ADP متعلق به CISA در ابتدا این موارد را بحرانی اعلام کردند، زیرا فرآیند ارسال گزارشات از طریق فرم عمومی MITRE هیچ‌گونه احراز هویت واقعی برای هویت ارسال‌کننده ندارد.

در گذشته، NIST به عنوان یک توری نجات عمل می‌کرد و متخصصان NVD گزارشات ورودی را به صورت دستی تحلیل و اعتبارسنجی می‌کردند. از فوریه ۲۰۲۴ این خط لوله تکه تکه شده است. چون هیچ مرحله‌ای در سیستم فعلی، ارائه یک نمونه اثبات مفهوم (PoC) یا بازتولید باگ را الزامی نمی‌کند، یک گزارش ساختگی اما متقاعدکننده می‌تواند به راحتی از این مسیر عبور کرده و در GHSA، دیتابیس‌های پایین‌دستی و اسکنرهای سازمانی ثبت شود. در چنین شرایطی، هرگونه آسیب‌پذیری واقعی و تأیید شده، مانند آسیب‌پذیری شدید در سامانه‌های FortiSandbox، می‌تواند در میان انبوهی از گزارشات جعلی گم شود و تریاژ آن با تأخیر مواجه گردد.

ریسک اصلاحات مبتنی بر AI

این «آشغال‌های اطلاعاتی» یک چرخه بازخورد خطرناک برای شرکت‌هایی می‌سازد که از عامل‌های هوش مصنوعی (AI Agents) — برنامه‌هایی که می‌توانند به‌طور مستقل تصمیم بگیرند و ابزارها را اجرا کنند — برای اولویت‌بندی و تریاژ خودکار آسیب‌پذیری‌ها استفاده می‌کنند. یک عامل AI که با یک CVE جعلی مواجه می‌شود، ممکن است سعی کند تابع آسیب‌پذیر را پیدا کند، یک وصله (Patch) تولید کند یا تغییراتی را بر اساس کدهایی توصیه کند که اصلاً وجود ندارند. این کار به‌جای کمک به تیم‌های امنیتی، آن‌ها را به مسیری کاملاً اشتباه می‌برد و منجر به معرفی تغییرات غیرضروری در کد و تلف کردن زمان می‌شود.

برای جلوگیری از این نویز، JFrog توصیه می‌کند سازمان‌ها اعتماد کورکورانه به CVEهای جدید از منابع تاییدنشده را متوقف کنند. تیم‌ها باید تاییدیه فروشنده (Vendor Corroboration) — مانند بررسی صفحه رسمی sqlite.org/cves.html — را در اولویت قرار دهند و قبل از استقرار وصله‌های اضطراری، سعی کنند با استفاده از PoCهای ارائه شده، مشکل را در یک محیط امن بازتولید کنند. پرچم‌های قرمز کلیدی شامل نبود هش‌های کامیت (Commit Hashes)، تعاریف محصول CPE خالی و محدوده‌های نسخه‌ای است که با روایت گزارش تضاد دارد.

تحلیلگران معتقدند این اتفاق نقطه‌ی عطفی در مدیریت آسیب‌پذیری است. عصر اعتماد به فیدهای خودکار CVE به پایان رسیده و جای خود را به مدل «اعتماد صفر» (Zero Trust) در پذیرش داده‌ها می‌دهد؛ جایی که بار اثبات مجدداً بر دوش گزارش‌دهنده است. JFrog این یافته‌ها را رسماً به GHSA، Red Hat و NVD گزارش کرده است تا به اصلاح این سوابق کمک کند.

گام بعدی شما

• بررسی مجدد تمام CVEهای بحرانی اخیر دیتابیس‌های خود که منبع آن‌ها ناشناس یا غیررسمی است.
• تنظیم اسکنرهای امنیتی برای اولویت دادن به توصیه‌های رسمی Vendor به‌جای امتیازات خام NVD.
• پیاده‌سازی یک محیط ایزوله برای تست PoC‌ها پیش از هرگونه تغییر در کدهای عملیاتی.

اما خطر بزرگ‌تر زمانی است که این توهمات وارد داده‌های آموزشی مدل‌های بعدی شوند — در تحلیل ما درباره مسموم‌سازی داده‌ها (Data Poisoning) بیشتر بخوانید.