شناسه CVE-2026-7482 :CVE
CWE-125 :CWE
yes :Advisory
منتشر شده: می 4, 2026
به روز شده: می 4, 2026
امتیاز: 9.1
نوع حمله: Heap Out-of-Bounds Read

اثر گذاری: Information Disclosure
حوزه: نرم افزارهای کاربردی
برند: Ollama
محصول: Ollama
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch شده

چکیده

یک آسیب‌پذیری بحرانی در پلتفرم Ollama از نوع خواندن خارج از محدوده حافظه Heap شناسایی شده است که در فرآیند پردازش فایل‌های مدل GGUF رخ می‌دهد. این ضعف امنیتی می‌تواند باعث افشای بخش‌هایی از حافظه پردازه سرور شود و اطلاعات حساسی مانند کلیدهای API، متغیرهای محیطی، پرامپت‌های سیستمی و داده‌های کاربران را در معرض دسترسی غیرمجاز قرار دهد.

توضیحات

آسیب‌پذیری CVE-2026-7482 از نوع خواندن خارج از محدوده حافظه Heap (Out-of-Bounds Read) مطابق با CWE-125 است. این دسته از آسیب‌پذیری‌ها زمانی رخ می‌دهند که یک برنامه در هنگام پردازش داده‌ها، اقدام به خواندن حافظه‌ای فراتر از محدوده اختصاص‌یافته به یک بافر یا ساختار داده کند. در چنین شرایطی، داده‌هایی که نباید در دسترس برنامه یا کاربر قرار گیرند از بخش‌های مجاور حافظه خوانده شده و ممکن است افشا شوند. این ضعف برخلاف آسیب‌پذیری‌های نوشتن خارج از محدوده حافظه، معمولاً منجر به تغییر مستقیم داده‌ها نمی‌شود، اما می‌تواند اطلاعات حساسی را از حافظه پردازه (Process Memory) استخراج کند و زمینه را برای حملات پیچیده‌تر فراهم سازد.

بر اساس اطلاعات منتشرشده ، منشأ این آسیب‌پذیری در مکانیزم بارگذاری مدل‌های GGUF در Ollama قرار دارد. GGUF یک قالب ذخیره‌سازی مدل‌های زبانی بزرگ (LLM) است که برای ذخیره وزن‌ها (Weights)، تنسورها (Tensors) و متادیتای مدل استفاده می‌شود. در نسخه‌های آسیب‌پذیر Ollama، ‎/api/create Endpoint ‎ امکان دریافت و پردازش فایل‌های GGUF را فراهم می‌کند. این آسیب‌پذیری زمانی رخ می‌دهد که مهاجم یک فایل GGUF دستکاری‌شده بارگذاری کند که در آن مقادیر Offset و Size تنسورها با طول واقعی فایل مطابقت نداشته باشند. به عبارت دیگر، فایل به‌گونه‌ای ایجاد می‌شود که اطلاعات متادیتای آن وجود حجم بیشتری از داده را نشان دهد، در حالی که این داده‌ها عملاً در فایل وجود ندارند.

هنگام پردازش این فایل‌ها در کامپوننت‌های fs/ggml/gguf.go و server/quantization.go و به‌ویژه در مرحله کوانتیزه‌سازی (Quantization)، بررسی‌های لازم برای اطمینان از معتبر بودن اندازه و موقعیت تنسورها به‌طور کامل انجام نمی‌شود. در نتیجه، تابع WriteTo() بر اساس اطلاعات موجود در متادیتای فایل تلاش می‌کند داده‌هایی را بخواند که فراتر از محدوده واقعی فایل قرار دارند. این موضوع باعث می‌شود عملیات خواندن از انتهای فایل (End of File – EOF) عبور کرده و به بخش‌های مجاور حافظه Heap دسترسی پیدا کند. در چنین شرایطی، بخشی از داده‌های موجود در حافظه پردازه ممکن است به‌عنوان داده معتبر مدل پردازش شوند؛ داده‌هایی که می‌توانند شامل اطلاعات حساس مربوط به سرویس، کاربران یا درخواست‌های هم‌زمان باشند.

بررسی‌های فنی منتشرشده در کد اثبات مفهومی (PoC) نشان می‌دهد که سوءاستفاده از این آسیب‌پذیری نسبتاً ساده است. پژوهشگران امنیتی موفق شده‌اند با ایجاد یک فایل GGUF دستکاری شده، سامانه را وادار کنند که هنگام پردازش تنسور token_embd.weight به داده‌هایی خارج از محدوده فایل دسترسی پیدا کند. در این سناریو، فایل فیزیکی عمداً کوتاه‌تر از مقداری است که در متادیتای داخلی GGUF اعلام شده است. در نتیجه، زمانی که موتور پردازش مدل عملیات خواندن داده‌های تنسور را آغاز می‌کند، به انتهای فایل رسیده و داده‌های موجود در حافظه Heap را به‌عنوان بخشی از مدل پردازش می‌کند.

یکی از مهم‌ترین جنبه‌های این آسیب‌پذیری، زنجیره استخراج اطلاعات (Exfiltration Chain) آن است. مهاجم ابتدا فایل مخرب را از طریق ‎/api/create‎ بارگذاری می‌کند و پس از ایجاد آرتیفکت مدل، از Endpoint ‎/api/push‎ برای انتقال مدل تولیدشده به یک رجیستری (Registry) تحت کنترل خود استفاده می‌کند. رجیستری در اینجا مخزنی برای ذخیره و توزیع مدل‌ها است که عملکردی مشابه ریجستریDocker دارد. به این ترتیب، داده‌های استخراج‌شده از حافظه سرور می‌توانند از محیط قربانی خارج شده و در اختیار مهاجم قرار گیرند.

داده‌های افشاشده ممکن است شامل متغیرهای محیطی (Environment Variables)، کلیدهای API، توکن‌های احراز هویت، پرامپت‌های سیستمی، تنظیمات داخلی سرویس و حتی داده‌های مربوط به تعاملات سایر کاربران باشد. این موضوع به‌ویژه در محیط‌هایی که Ollama به‌عنوان زیرساخت اجرای مدل‌های هوش مصنوعی برای چندین کاربر یا چندین برنامه کاربردی استفاده می‌شود، می‌تواند پیامدهای امنیتی گسترده‌ای ایجاد کند.

با وجود اینکه پیکربندی پیش‌فرض Ollama سرویس را روی آدرس 127.0.0.1 محدود می‌کند، مستندات رسمی محصول استفاده از متغیر OLLAMA_HOST=0.0.0.0 را برای دسترسی شبکه‌ای پشتیبانی می‌کنند. طبق گزارش پژوهشگران امنیتی، تعداد قابل توجهی از استقرارهای واقعی Ollama با همین پیکربندی در اینترنت در دسترس قرار گرفته‌اند. در چنین شرایطی، مهاجم می‌تواند بدون نیاز به دسترسی اولیه یا اعتبارنامه معتبر، مستقیماً فرآیند اکسپلویت را آغاز کند.

از منظر اثرات امنیتی، این آسیب‌پذیری تأثیر شدیدی بر محرمانگی (Confidentiality) اطلاعات دارد، زیرا می‌تواند منجر به افشای داده‌های حساس موجود در حافظه پردازه شود. همچنین با توجه به امکان بروز خطا و ناپایداری در هنگام پردازش فایل‌های مخرب، دسترس‌پذیری (Availability) سامانه نیز تحت تأثیر قرار می‌گیرد.

توسعه‌دهندگان Ollama برای رفع این آسیب‌پذیری، در نسخه 0.17.1 اعتبارسنجی اندازه تنسورها و بررسی محدوده داده‌های قابل خواندن را اصلاح کرده‌اند تا از دسترسی به حافظه خارج از محدوده جلوگیری شود.

CVSS

Score	Severity	Version	Vector String
9.1	CRITICAL	3.1	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
8.8	HIGH	4.0	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/ SC:N/SI:N/SA:N/AU:Y/R:A/V:D/RE:L/U:Red

شکل 1: تفسیر جدول CVSS

لیست محصولات آسیب پذیر

Versions	Product
affected from 0 before 0.17.1	ollama

لیست محصولات بروز شده

Versions	Product
0.17.1	ollama

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که ollama را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Search Query (Dork)	Product
8,990	site:.ir “ollama”	ollama

نتیجه گیری

این آسیب‌پذیری بحرانی در پلتفرم Ollama امکان افشای اطلاعات حساس موجود در حافظه پردازه سرور را از طریق یک زنجیره حمله کاملاً از راه دور و بدون نیاز به احراز هویت فراهم می‌کند. وجود PoC عمومی و قابلیت خودکارسازی حمله، احتمال سوءاستفاده عملی از این ضعف را به میزان قابل توجهی افزایش داده است.

برای کاهش ریسک، اقدامات زیر توصیه می‌شود:

به‌روزرسانی فوری Ollama: تمامی سامانه‌های آسیب‌پذیر باید در اسرع وقت به نسخه 17.1 یا نسخه‌های جدیدتر به‌روزرسانی شوند. این اقدام مؤثرترین و مهم‌ترین راهکار برای رفع آسیب‌پذیری است. سایر راهکارهای امنیتی نقش مکمل داشته و می‌توانند ریسک سوءاستفاده از این آسیب‌پذیری و تهدیدات مشابه را کاهش دهند.
محدودسازی دسترسی شبکه‌ای: در صورت عدم وجود نیاز عملیاتی، سرویس Ollama نباید روی تمامی رابط‌های شبکه (0.0.0) در دسترس قرار گیرد. توصیه می‌شود این سرویس تنها روی آدرس لوکال (127.0.0.1) یا شبکه‌های داخلی مورد اعتماد اجرا شود و دسترسی مستقیم از اینترنت به آن مسدود گردد.
اعمال احراز هویت و کنترل دسترسی روی APIها: دسترسی به Endpointهای ‎/api/create‎ و ‎/api/push‎ باید از طریق مکانیزم‌های احراز هویت (Authentication) و کنترل دسترسی مناسب محدود شود. همچنین در صورت عدم وجود نیاز عملیاتی، قابلیت ایجاد (Create) و Push مدل‌های سفارشی محدود یا غیرفعال گردد و تنها کاربران و سامانه‌های مورد اعتماد امکان استفاده از این Endpointها را داشته باشند.
استفاده از فایروال: دسترسی به سرویس Ollama باید تنها به میزبان‌ها و کاربران مجاز محدود شود و از قرار گرفتن مستقیم آن در معرض اینترنت عمومی جلوگیری گردد. اعمال قوانین مناسب در فایروال می‌تواند دسترسی به Endpointهای حساس مانند ‎/api/create‎ و ‎/api/push‎ را صرفاً به آدرس‌های IP یا شبکه‌های مورد اعتماد محدود کرده و احتمال سوءاستفاده از این آسیب‌پذیری را کاهش دهد.
مانیتورینگ و تحلیل رخدادهای امنیتی: لاگ‌های مربوط به عملیات ‎/api/create‎ و ‎/api/push‎ باید به‌صورت مستمر در سامانه مدیریت رخداد و اطلاعات امنیتی (SIEM) مانیتور شوند تا فعالیت‌های مشکوک شناسایی گردند.
تفکیک شبکه (Network Segmentation): سرویس‌های Ollama باید از طریق تفکیک شبکه از سایر سامانه‌های حساس سازمان جدا شوند تا در صورت وقوع رخداد، دامنه اثرگذاری محدود بماند.

اجرای این اقدامات، به‌ویژه به‌روزرسانی به نسخه پچ‌شده، می‌تواند احتمال سوءاستفاده موفق از این آسیب‌پذیری و افشای اطلاعات حساس را به میزان قابل توجهی کاهش دهد.

امکان استفاده در تاکتیک‌های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)

مهاجم برای بهره‌برداری از این آسیب‌پذیری نیازی به دسترسی اولیه فیزیکی یا محلی به سیستم هدف ندارد. از آنجایی که این آسیب‌پذیری از طریق یک endpoint شبکه قابل دسترسی است، مهاجم می‌تواند از راه دور و با ارسال یک فایل مدل GGUF دستکاری‌شده به سرور Ollama (مثلاً از طریق API بارگذاری یا اجرای مدل)، حمله را آغاز کند. این کار ممکن است از طریق میزبانی یک مدل مخرب در ریجستری‌های عمومی و فریب کاربر برای دانلود آن، یا ارسال مستقیم به یک سرور Ollama که در شبکه در معرض دید (Exposed) قرار دارد، انجام شود.

Execution (TA0002)

اجرای مخرب زمانی رخ می‌دهد که سرویس Ollama شروع به پردازش و بارگذاری فایل مدل GGUF مخرب می‌کند. در حین تجزیه (Parse) یا تانسورهای فایل GGUF، کد آسیب‌پذیر فعال شده و خواندن خارج از محدوده (Out-of-bounds Read) در حافظه Heap رخ می‌دهد. در اینجا مهاجم منطق برنامه را وادار به خواندن بخش‌های غیرمجاز حافظه می‌کند.

Defense Evasion (TA0005)

فایل مدل GGUF مخرب دارای ساختار باینری پیچیده‌ای است و داده‌های دستکاری‌شده می‌توانند در میان متادیتای مدل پنهان شوند. از آنجایی که فایل همچنان تا حدی شبیه به یک مدل قانونی به نظر می‌رسد و حمله در حین عملیات عادی بارگذاری مدل رخ می‌دهد، ممکن است توسط سیستم‌های تشخیص نفوذ (IDS) یا آنتی‌ویروس‌هایی که صرفاً بر اساس امضای فایل‌های اجرایی مخرب کار می‌کنند، شناسایی نشود.

Credential Access (TA0006)

یکی از پیامدهای اصلی این آسیب‌پذیری، نشت اطلاعات از حافظه پردازش (Process Memory) است. اگر سرویس Ollama در حافظه Heap خود به اطلاعات حساسی مانند کلیدهای API، متغیرهای محیطی، یا داده‌های احراز هویت دسترسی داشته باشد، مهاجم با تحلیل داده‌های خوانده شده از محدوده غیرمجاز (مثلاً از طریق پاسخ‌های سرور، پیام‌های خطا یا نشت تدریجی داده‌ها)، می‌تواند به این اعتبارنامه‌ها و اطلاعات محرمانه دسترسی پیدا کند.

Impact (TA0040)

بهره‌برداری موفق از این آسیب‌پذیری دو پیامد اصلی دارد؛ نشت اطلاعات و محروم‌سازی از سرویس (DoS). مهاجم می‌تواند به اطلاعات حساس موجود در حافظه Heap دسترسی پیدا کند که محرمانگی (Confidentiality) سیستم را نقض می‌کند. همچنین، تلاش برای خواندن آدرس‌های حافظه نامعتبر می‌تواند باعث از کار افتادن (Crash) فرآیند Ollama شود که منجر به محروم‌سازی کاربران از سرویس هوش مصنوعی و کاهش در دسترس بودن (Availability) سیستم می‌گردد.

منابع

گزارش اثبات آسیب‌پذیری CVE-2026-7482

اطلاعات آسیب‌پذیری

عنوان: Ollama Memory Leak (Bleeding Llama) – Information Disclosure via Heap Out-of-Bounds Read

شناسه: CVE-2026-7482

وضعیت مشاوره: Advisory / Patch Available

امتیاز: CVSS: 9.1 (CRITICAL)

محصول: Ollama

محصول / نسخه‌های آسیب‌پذیر

در نسخه‌های زیر:

Ollama نسخه‌های 0.12.10 تا 0.17.5
همه نسخه‌های قبل از 0.17.1

محیط‌های درگیر

تمام سازمان‌هایی که از Ollama به عنوان سرویس دهنده مدل‌های زبانی استفاده می‌کنند
توسعه‌دهندگان و سازمان‌هایی که از Ollama در معماری AI/ML خود استفاده می‌کنند
سرورهای Ollama که مدل‌های GGUF را پردازش می‌کنند

کامپوننت‌های آسیب‌پذیر

GGUF Model Loader
مکانیزم Quantization
فایل fs/ggml/gguf.go – پردازشگر فایل‌های GGUF
فایل server/quantization.go – تابع WriteTo در فرآیند ساخت مدل
اندپوینت /api/create – پذیرش فایل‌های GGUF تزریقی بدون احراز هویت
اندپوینت /api/push – خروجی گرفتن مدل حاوی حافظه نشتی به رجیستری مهاجم

ریشه مشکل (Root Cause Analysis)

ریشه اصلی این آسیب‌پذیری به اعتبارسنجی ناکافی داده‌های موجود در فایل GGUF (فرمت استاندارد ذخیره مدل‌های زبان بزرگ) بازمی‌گردد. بارگذار مدل هنگام پردازش فایل بارگذاری‌شده، مقادیر Offset و Size مربوط به Tensorها را بدون اطمینان از قرار گرفتن آنها در محدوده واقعی فایل می‌پذیرد.

هنگامی که یک فایل GGUF به Ollama ارسال می‌شود، سرور اطلاعات Tensor (شامل offset و size) را از فایل می‌خواند. در نسخه‌های آسیب‌پذیر، Ollama بدون بررسی اینکه آیا offset و size اعلام‌شده با طول واقعی فایل مطابقت دارد یا خیر، اقدام به پردازش می‌کند.

مهاجم یک فایل GGUF مخرب می‌سازد که در آن tensor offset و tensor size بسیار بزرگتر از طول واقعی فایل هستند

هنگامی که سرور وارد مرحله quantization (کاهش دقت مدل از F16 به Q4_K_M) می‌شود، تابع WriteTo در server/quantization.go سعی می‌کند داده‌های tensor را از بافر مبدأ به بافر مقصد کپی کند. اما چون offset و size اعلام‌شده از طول واقعی فایل بیشتر است، فرآیند خواندن از محدوده بافر تخصیص‌یافته heap عبور کرده و شروع به خواندن حافظه مجاور می‌کند. این حافظه شامل هر چیزی است که سرور Ollama در آن لحظه در heap خود دارد در ادامه فرآیند quantization از یک تبدیل float-16 به float-32 استفاده می‌کند. این تبدیل نه تنها داده‌های خارج از محدوده را خراب نمی‌کند، بلکه آن‌ها را دقیقاً همان‌طور که هستند در مدل خروجی ذخیره می‌کند. در نتیجه، حافظه heap به داخل فایل مدل خروجی (که قرار است به عنوان مدل quantization شده ذخیره شود) جاسازی می‌شود.

مهاجم با فراخوانی API ساده، بدون هیچ احراز هویتی، می‌تواند کل حافظه heap فرآیند Ollama (که شامل اطلاعات حساس سایر کاربران، کلیدهای API، پرامپت‌های سیستمی و اعتبارنامه‌های محیطی است) را به سرور خود منتقل کند

بخش آسیب‌پذیر

رفتار ناامن سیستم:

Ollama هنگام پردازش فایل‌های GGUF ارسالی به اندپوینت /api/create مقدار offset و size اعلام‌شده برای tensor را بدون اعتبارسنجی نسبت به طول واقعی فایل می‌پذیرد. در طول فرآیند quantization، این نقص منجر به خواندن خارج از محدوده بافر تخصیص‌یافته روی heap می‌شود و محتویات حافظه مجاور (شامل داده‌های سایر کاربران و متغیرهای محیطی) را به داخل مدل خروجی نشت می‌دهد. سپس مهاجم می‌تواند از اندپوینت /api/push برای ارسال مدل آلوده به رجیستری تحت کنترل خود استفاده کند.

نحوه سوءاستفاده مهاجم:

مهاجم یک فایل GGUF جعلی را از طریق اندپوینت /api/blobs آپلود می‌کند
مهاجم اندپوینت /api/create را با درخواست quantization به Q4_K_M فراخوانی می‌کند
مهاجم می‌تواند با استفاده از اندپوینت /api/push فایل مدل را که حال شامل داده های حساس است را دانلود کرده و آن ها را استخراج کند

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری یک نقطه ورود اولیه (Initial Access) و ابزار استخراج اطلاعات (Information Disclosure) بسیار خطرناک در زنجیره حمله محسوب می‌شود. با توجه به نمره CVSS 9.1 (بحرانی)، ماهیت کاملاً بدون احراز هویت (Unauthenticated) و قابلیت بهره‌برداری از راه دور (Remote) مهاجم می‌تواند بدون هیچ تعامل با کاربر و تنها با سه درخواست API، حافظه فرآیند Ollama را تخلیه کند. داده‌های قابل دسترس شامل موارد زیر است.

کلیدهای API سرویس‌های خارجی (OpenAI، Claude، Gemini، Replicate و غیره)
اعتبارنامه‌های ابری (AWS، GCP، Azure از طریق متغیرهای محیطی)
تعاملات کاربران (شامل اطلاعات محرمانه، کدهای منبع، داده‌های تجاری حساس)
پرامپت‌هی سیستمی (System Prompts) که اغلب حاوی منطق تجاری محرمانه هستند
خروجی ابزارهای متصل (coding assistants، agent workflows)

در سازمان‌هایی که Ollama به ابزارهای داخلی متصل است، ریسک به مراتب بیشتر می‌شود. مهاجم می‌تواند از اطلاعات به دست آمده در جهت موارد زیر بهره‌برداری کند:

دسترسی به سرویس‌های ابری سازمان با کلیدهای API سرقت‌شده
جعل هویت کاربران با استفاده از محتوای گفتگوها
سرقت مالکیت فکری از پرامپت‌هی سیستمی و کدهای پروژه
حرکت جانبی به سایر سرویس‌های داخلی سازمان

پیش‌نیازهای بهره‌برداری (Prerequisites)

استفاده از نسخه آسیب‌پذیر ollama
دسترسی شبکه مهاجم به سرویس Ollama هدف از طریق پورت‌های HTTP
عدم وجود احراز هویت روی API
امکان ارسال فایل GGUF به سرویس
فعال بودن اندپوینت های /api/create و /api/push (پیش‌فرض فعال)
فعال بودن قابلیت‌های پردازش مدل در سرور
عدم نصب وصله امنیتی

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

اعتبارسنجی کامل Offset و Size تمام Tensorها پیش از پردازش
جلوگیری از دسترسی به داده‌های خارج از محدوده فایل
رد کردن فایل‌های GGUF دارای Metadata نامعتبر
فرآیند quantization نباید هرگز فراتر از بافر تخصیص‌یافته (allocated buffer) خواندن انجام دهد
پیاده‌سازی proper bounds checking در توابع fs/ggml/gguf.go و server/quantization.go
اضافه کردن احراز هویت اجباری به تمام اندپوینت های حساس (حداقل برای /api/create و /api/push)

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک:

به‌روزرسانی فوری Ollama
محدود کردن دسترسی شبکه به سرویس Ollama
محدود کردن دسترسی به API از طریق فایروال
عدم انتشار مستقیم API روی اینترنت عمومی

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک:

محدودسازی دسترسی به /api/create
مانیتورینگ بارگذاری مدل‌های ناشناس
بررسی و بازنشانی کلیدهای API حساس
استقرار پروکسی احراز هویت در مقابل تمام نمونه‌های Ollama، زیرا API داخلی فاقد احراز هویت است

اقدامات بلندمدت برای کاهش ریسک:

استقرار راهکارهای خودکار به‌روزرسانی امنیتی (Patch Management) برای اعمال سریع وصله‌ها
پیاده‌سازی فرآیندهای منظم تست نفوذ
جداسازی سرویس‌های هوش مصنوعی از شبکه عمومی
پیاده‌سازی Web Application Firewall (WAF)
ممیزی امنیتی منظم محیط‌های AI و LLM
پایش مداوم فعالیت‌های بارگذاری مدل

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده:

بارگذاری فایل‌های GGUF غیرعادی
ایجاد مدل‌های ناشناخته توسط کاربران غیرمنتظره
بارگذاری فایل‌های GGUF با حجم بسیار کم
افزایش حجم داده‌های خروجی مدل
الگوهای درخواست پشت سر هم به /api/blobs، /api/create و /api/push در بازه زمانی کوتاه
انتقال مدل‌ها به Registry های ناشناس
ارتباطات خروجی غیرمعمول از سرور Ollama
گزارش‌های خطای مرتبط با خواندن خارج از محدوده (out-of-bounds read) در لاگ‌های سرور

منابع پیشنهادی برای مانیتورینگ و پایش:

لاگ‌های دسترسی API – رصد اندپوینت ها
راهکارهای NDR (Network Detection and Response) – برای شناسایی ترافیک مشکوک به سمت رجیستری‌های ناشناس
راهکارهای SIEM، برای جمع‌آوری و تحلیل مرکزی لاگ‌ها

توجه داشته باشید این حمله به طور پیش‌فرض خطایی در لاگ سرور ثبت نمی‌کند

واکنش به حادثه (Incident Response)

ایزوله‌سازی فوری سامانه آسیب‌دیده
جمع‌آوری لاگ‌های API
بررسی رجیستری‌های خارجی برای یافتن مدل‌های آپلودشده توسط مهاجم
شناسایی مدل‌های ایجادشده توسط کاربران ناشناس
بازنشانی API Key ها و Secret های ذخیره‌شده
بررسی احتمال افشای داده کاربران
نصب فوری وصله امنیتی
مستندسازی کامل حادثه (زمان وقوع، نشانه‌ها، اقدامات انجام‌شده، درس‌آموخته‌ها) و گزارش به مدیریت ارشد و تیم واکنش سریع (CSIRT)

جریان حمله (Attack Flow)

در نمودار زیر (شکل ۱)، مهاجم ابتدا یک فایل GGUF دستکاری‌شده تهیه می‌کند. سپس این فایل از طریق Endpoint مربوط به ایجاد مدل در Ollama بارگذاری می‌شود. در فرآیند Quantization، نرم‌افزار به دلیل اعتبارسنجی ناکافی، داده‌هایی را از خارج از محدوده فایل و از حافظه Heap فرایند می‌خواند.

شکل 1: جریان اجرای آسیب پذیری

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte، این آسیب‌پذیری را در محیط ایزوله و کنترل‌شده با استفاده از نسخه آسیب‌پذیر بررسی و اجرا کرده است

این آزمایشگاه شامل نسخه آسیب‌پذیر Ollama است
فایل forge.py برای ساخت فایل GGUF جعلی با tensor offset/size بزرگ و truncation فیزیکی استفاده شده است
فایل registry.py برای سرور رجیستری مخرب برای دریافت دامپ حافظه و فایل exploit.py برای اجرای زنجیره سه مرحله‌ای حمله مورد استفاده قرار گرفت
اجرای PoC در محیط آزمایشگاهی منجر به ساخت فایل با پسوند gguf در دایرکتوی /exfiles که حاوی اطلاعات نشست شده در heap است ایجاد می شود.
این اثبات مفهوم صرفاً توصیفی و آموزشی بوده و شامل تغییرات مخرب نمی‌شود

شکل 2: اجرای POC

رفع مسئولیت

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

منابع

https://www.cve.org/CVERecord?id=CVE-2026-7482

https://nvd.nist.gov/vuln/detail/CVE-2026-7482

https://cwe.mitre.org/data/definitions/125.html

https://github.com/0x0OZ/CVE-2026-7482-PoC

Ollama

CVE-2026-7482 – Heap Out-of-Bounds Read Vulnerability in GGUF Model Loader Leading to Unauthenticated Remote Process Memory Leak

Affects

Ollama (Open-source framework for running large language models locally)
Versions:
- All versions before 0.17.1 (including all previous versions)
- Ollama 0.12.10 through 0.23.2 (for Windows-specific auto-updater bugs CVE-2026-42248 and CVE-2026-42249 – separate vulnerabilities)
Components:
- GGUF model loader
- Model quantization pipeline
- /api/create endpoint
- /api/push endpoint
Files:
- fs/ggml/gguf.go
- server/quantization.go
Functions:
- WriteTo() in server/quantization.go
- ConvertToF32() in fs/ggml/gguf.go

Description

CVE-2026-7482, nicknamed “Bleeding Llama” , is a critical heap out-of-bounds read vulnerability in Ollama’s GGUF (GPT-Generated Unified Format) model loader .

Ollama is the most widely used open-source platform for running large language models locally, with over 170,000 GitHub stars and 100 million Docker Hub downloads . The vulnerability resides in the model quantization pipeline, specifically how Ollama processes GGUF files submitted to the /api/create endpoint.

When processing a GGUF file, Ollama reads tensor metadata declaring offset and size values. The vulnerable code fails to validate that these declared values do not exceed the file’s actual length. An attacker can craft a malicious GGUF file declaring a tensor shape that is far larger than the actual data present (e.g., declaring 1,000,000 elements while providing only a few bytes) . During quantization, the server reads past the allocated heap buffer boundary, accessing whatever sensitive data resides in adjacent memory.

The attack then leverages a lossless float-16 to float-32 conversion path, which preserves every stolen byte intact rather than corrupting it through lossy quantization . The leaked memory contents become embedded in the resulting model artifact, which the attacker exfiltrates via Ollama’s built-in /api/push endpoint to an attacker-controlled registry.

The vulnerability is exacerbated by critical configuration issues:

No authentication is built into Ollama’s REST API
Default binding to 127.0.0.1 is often overridden with OLLAMA_HOST=0.0.0.0, exposing the service to all network interfaces
Approximately 300,000 Ollama servers are estimated to be publicly exposed on the internet

Attack Vector

Primary Attack Vector:
Remote / Unauthenticated (Network Access to TCP Port 11434)

Attack Scenario – Three API Calls:

The entire attack requires just three unauthenticated HTTP POST requests :

Step	Endpoint	Action
1	`POST /api/blobs/sha256:<digest>`	Upload a malicious GGUF file with an inflated tensor shape (e.g., F16 tensor declared as 1,000,000 elements with only a few bytes of actual data)
2	`POST /api/create`	Trigger model creation. During quantization, Ollama performs the out-of-bounds read, reading past the heap buffer and folding leaked memory into the model artifact
3	`POST /api/push`	Push the resulting model artifact (now containing stolen heap memory) to an attacker-controlled registry, exfiltrating the data

Key Characteristics:

No authentication required – All three endpoints are completely open by default
No user interaction required – Zero-click exploitation
Exploitable over network via HTTP – Default port 11434
Leaves no error in logs – Detection without dedicated endpoint monitoring is practically impossible
Exploit Complexity: Low – Public proof-of-concept available
Public PoC Status: Already published on GitHub

Conditions Increasing Risk:

Public exposure of Ollama service (port 11434)
Default configuration unchanged (OLLAMA_HOST=0.0.0.0)
Lack of firewall or authentication proxy
Containerized deployments using outdated base images
Lack of network segmentation for AI/ML workloads

Impact

Successful exploitation allows an unauthenticated attacker to silently exfiltrate the entire heap memory of the Ollama process . The heap retains data across requests, exposing everything the server has processed since its last restart .

Confirmed data types at risk include:

Category	Exposed Data
AI Conversations	User prompts and chat messages sent to the API by any user or application
	System prompts from all models loaded on the same server
	Conversation history across concurrent users
Environment Variables	API keys (OpenAI, Claude, Gemini, etc.)
	Database credentials and connection strings
	Cloud service secrets (AWS, GCP credentials)
	Authentication tokens
Development & Business Data	Proprietary code submitted to AI assistants (e.g., via Claude Code, Cursor, Continue)
	Customer data and contracts reviewed via AI
	Tool outputs from connected coding assistants

Secondary Impact:

Credential abuse – Stolen API keys enable unauthorized access to downstream systems and cloud resources
Lateral movement – Compromised credentials can lead to further network intrusion
Regulatory non-compliance – Exposure of PII, PHI, or privileged information may violate GDPR, HIPAA, or other regulations
Reputational damage – Public disclosure of sensitive conversation data or business logic

Observed Exploitation & Threat Activity

Discovery: February 2, 2026 – Reported by Dor Attias of Cyera Research
Patch Available: February 24, 2026 – Ollama v0.17.1 shipped with fix
CVE Assignment Delayed: MITRE did not respond for two months; Echo CNA assigned CVE-2026-7482 on April 28, 2026
Public Disclosure: May 2026 – Cyera published technical writeup on May 2
Public PoC: Available on GitHub
In-the-Wild Exploitation: Not confirmed as of May 2026, but the existence of public PoC and ~300,000 exposed instances makes exploitation highly likely
CVSS Score: 9.1 (Critical) (NVD rates 8.8/8.9 )

Disclosure Timeline :

Date	Event
February 2, 2026	Vulnerability reported to Ollama
February 24, 2026	Ollama ships v0.17.1 with fix (not flagged as security update)
March 2, 2026	CVE request submitted to MITRE – no response
April 28, 2026	Echo CNA assigns CVE-2026-7482
May 2, 2026	Cyera publishes technical writeup
May 2026	Public disclosure and broad media coverage

The three-month gap between patch availability and public awareness left many operators vulnerable without knowing it .

Severity & Metrics

CVSS v3.1 (Cyera/CISA-ADP): Critical (9.1)
CVSS v3.1 (NVD): High (8.8)
Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality Impact: High
Integrity Impact: None (information disclosure only)
Availability Impact: Low (potential for service crashes)

Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L

Relevant CWE:

CWE-125 – Out-of-bounds Read
CWE-122 – Heap-based Buffer Overflow (variant)
CWE-119 – Improper Restriction of Operations within Memory Bounds

NOTE: Two separate Windows auto-updater vulnerabilities (CVE-2026-42248 and CVE-2026-42249, CVSS 7.7 High) affect Windows Ollama versions 0.12.10 through 0.23.2 but are distinct from CVE-2026-7482 .

Patch & Vendor Status

Official Patch Available: Yes – Ollama v0.17.1 (released February 24, 2026)
Download: https://github.com/ollama/ollama/releases/tag/v0.17.1
Fix validation: The patch adds bounds checking to validate tensor element counts against actual buffer sizes before any quantization loop executes
Release notes DID NOT flag as security fix – Operators may have skipped the update

GitHub Security Advisory: Published by GitLab Advisory Database

Mitigation & Remediation

Immediate Actions (Within 24 Hours)

Action	Command / Method
Upgrade to Ollama v0.17.1 or later	`ollama --version` to check; pull latest via `ollama pull ollama/ollama:latest`
Block port 11434 via firewall	`sudo ufw deny 11434` or `sudo iptables -A INPUT -p tcp --dport 11434 -j DROP`
Stop binding to 0.0.0.0	Remove `OLLAMA_HOST=0.0.0.0` from production unless strictly required. The default `127.0.0.1` is correct
Audit all Ollama instances	Use asset inventory or Shodan to identify any publicly exposed Ollama instances
Restrict network access	If patching impossible, block external access to port 11434 at firewall level

If your instance was internet-accessible before patching, treat it as compromised and rotate all secrets immediately .

Short-Term Hardening (Within 1 Week)

Deploy an authentication proxy – Place Ollama behind Caddy, Nginx with mTLS or basic auth, an API gateway, or a service mesh sidecar
Rotate exposed secrets – Assume environment variables and credentials in memory may be compromised; rotate API keys, tokens, and cloud credentials immediately
Review agentic integrations – Audit Claude Code, LangChain, or other tool integrations routing traffic through Ollama; treat all data passed through these tools as potentially disclosed
Network segmentation – Ensure Ollama servers are on isolated network segments with strict egress controls to prevent future exfiltration attempts

Long-term Defensive Measures

Implement least privilege – Run Ollama with non-root user if possible
Disable unnecessary functionality – Restrict or disable model upload features where not operationally required
Avoid passing sensitive environment variables to the Ollama process
Rebuild container images and roll deployments with patched versions
Enable monitoring for /api/create and /api/push activity, especially references to external registry URLs

Detection & Monitoring

Recommended Log Sources :

Source	Location / Method	Purpose
Ollama access logs	Application-level logging	Detect suspicious `/api/create` or `/api/push` calls
Firewall / Netflow	Port 11434 traffic	Identify unexpected inbound connections
Full Packet Capture	Span port / mirror	Analyze API request payloads for GGUF anomalies
EDR / Process Monitoring	Host-based	Detect unusual child processes from Ollama
API Gateway logs	If deployed	Monitor model uploads and pushes

Indicators of Attempted Exploitation :

Unexpected /api/create calls referencing newly uploaded blobs
/api/push requests pointing to external registry URLs not matching your organization’s registry
High volume of model creation or push requests from a single source
Unusual model names in push requests (suggesting exfiltration attempts)
Unusual outbound network traffic from the Ollama server to unexpected IPs

Attack Pattern Detection:

Monitor for the sequential pattern of three API calls that defines the exploit chain: /api/blobs/* → /api/create → /api/push within a short time window .

Check version across all instances:

ollama --version

For containerized deployments: Audit all running containers for Ollama image versions older than 0.17.1.

Vulnerability scanning note: Because the CVE was not assigned until April 28 (two months after the patch), NVD-driven scanners had no alert to trigger during that window . Ensure your vulnerability management solution can detect version-based exposures even without active CVE feeds.

Post-Incident Response

If exploitation is suspected or if an Ollama instance was internet-accessible pre-patch:

Isolate affected system from the network immediately to prevent further exfiltration
Preserve forensic evidence (application logs, network captures, memory dumps)
Rotate all credentials and keys stored in environment variables accessible to the compromised Ollama instance
Audit for persistent access – Review any new models, unusual API calls, or unauthorized registry entries
Review downstream systems accessed using compromised credentials (cloud providers, vector databases, tool integrations)
Assume full compromise of all data processed by the Ollama instance since its last restart
Rebuild system from a trusted backup or clean installation after patching
Document timeline and IOCs for potential breach notification requirements

References

CVE-2026-7482

Ollama Memory Leak (Bleeding Llama) — Information Disclosure via Heap Out-of-Bounds Read