هشدار امنیتی SafeNest
| CVE | CVE-2026-105744 |
| Vendor / Product | docling-project / Docling و Docling Slim |
| Severity | High |
| CVSS v3.1 | 7.5 |
| نوع آسیب‌پذیری | Arbitrary File Read/Write و در شرایط خاص Command Execution |
| CWE | CWE-22 / CWE-73 / CWE-1188 |
| نسخه‌های آسیب‌پذیر | Docling و Docling Slim از 2.94.0 تا قبل از 2.132.0 |
| نسخه اصلاح‌شده | 2.132.0 و جدیدتر |
| شرط اصلی | فعال بودن موتور اختیاری Tectonic و پردازش TikZ غیرقابل اعتماد |
| وضعیت KEV | در زمان تهیه این گزارش در CISA KEV ثبت نشده است |
خلاصه مدیریتی
CVE-2026-105744 یک آسیب‌پذیری با شدت High در Docling است؛ پروژه‌ای متن‌باز برای پردازش و تبدیل انواع اسناد که در سناریوهای هوش مصنوعی، استخراج متن، ساخت Pipelineهای سند و آماده‌سازی داده برای مدل‌های زبانی استفاده می‌شود. این آسیب‌پذیری به استفاده اختیاری از موتور Tectonic برای رندر محتوای TikZ مربوط است و زمانی اهمیت پیدا می‌کند که ورودی غیرقابل اعتماد توسط یک سامانه یا سرویس پردازش شود.
طبق اطلاعات DBU و Advisory پروژه، نسخه‌های Docling و Docling Slim از 2.94.0 تا قبل از 2.132.0 تحت تأثیر قرار دارند. در شرایط آسیب‌پذیر، محتوای TikZ می‌تواند از محدودیت مورد انتظار عبور کرده و باعث دسترسی به فایل‌های محلی شود. بسته به تنظیمات محیط و قابلیت‌های فعال‌شده، این مسئله می‌تواند از خواندن فایل فراتر رفته و نوشتن فایل را نیز ممکن کند. اگر Tectonic با قابلیت shell-escape یا محیطی معادل آن اجرا شود، ریسک اجرای فرمان نیز مطرح می‌شود.
شرح فنی آسیب‌پذیری
Docling برای تبدیل و پردازش ساختارهای مختلف سند، از Backendها و موتورهای متنوع استفاده می‌کند. یکی از قابلیت‌های اختیاری آن پشتیبانی از Tectonic برای رندر محتوای LaTeX/TikZ است. TikZ یک زبان قدرتمند برای تولید نمودار و محتوای گرافیکی است، اما همین انعطاف‌پذیری در صورتی که ورودی از منبع غیرقابل اعتماد دریافت شود، نیازمند محدودسازی دقیق دسترسی فایل و محیط اجرا است.
در CVE-2026-105744، مرز امنیتی مورد انتظار به اندازه کافی اعمال نمی‌شود و ورودی خاص می‌تواند بر مسیرهای فایل اثر بگذارد. نتیجه بالقوه آن دسترسی به فایل‌هایی خارج از محدوده سند پردازش‌شده است. در یک سرویس پردازش سند، این موضوع اهمیت زیادی دارد؛ زیرا فرایند Docling ممکن است روی سروری اجرا شود که فایل‌های پیکربندی، Secretها، داده‌های موقت یا سایر اسناد در همان محیط قرار دارند.
این نقص از دیدگاه دفاعی در چند دسته مهم قرار می‌گیرد: کنترل ناکافی مسیر فایل، استفاده از نام یا مسیر فایل کنترل‌شده توسط ورودی و قرار گرفتن قابلیت‌های حساس در معرض داده غیرقابل اعتماد. اگرچه بهره‌برداری موفق به پیکربندی خاص Tectonic وابسته است، سازمان‌هایی که Docling را به‌عنوان یک API، سرویس پردازش خودکار یا بخشی از RAG و GenAI Pipeline اجرا می‌کنند باید آن را جدی بگیرند.
چرا این آسیب‌پذیری مهم است؟
سامانه‌های پردازش سند معمولاً ورودی‌هایی را از کاربران، ایمیل، سامانه‌های مدیریت محتوا یا منابع بیرونی دریافت می‌کنند. در چنین معماری‌ای، فرض «فایل فقط یک سند است» می‌تواند خطرناک باشد؛ زیرا یک Parser یا Renderer آسیب‌پذیر ممکن است داده سند را به عملیات فایل یا اجرای مؤلفه‌های جانبی تبدیل کند.
در سناریوهای سازمانی، فایل‌های محلی قابل دسترسی ممکن است شامل فایل‌های تنظیمات، کلیدهای API، Tokenهای سرویس، Credentialهای اتصال به پایگاه داده یا داده‌های پروژه باشند. حتی اگر تنها خواندن فایل ممکن باشد، افشای این اطلاعات می‌تواند زمینه حملات بعدی را ایجاد کند. امکان نوشتن فایل نیز می‌تواند یکپارچگی محیط را تحت تأثیر قرار دهد و در برخی پیکربندی‌ها مسیر رسیدن به اجرای کد را باز کند.
محصولات و نسخه‌های تحت تأثیر
بر اساس اطلاعات منتشرشده، دو بسته اصلی تحت تأثیر قرار دارند:
- Docling: نسخه‌های 2.94.0 تا قبل از 2.132.0
- Docling Slim: نسخه‌های 2.94.0 تا قبل از 2.132.0
نسخه 2.132.0 شامل اصلاح امنیتی است. اگر Docling از طریق Container، Python environment یا تصویر آماده در زیرساخت سازمانی نصب شده است، صرفاً بررسی نسخه Package Manager کافی نیست و باید Imageها، Lock Fileها و محیط‌های Runtime نیز بررسی شوند.
پیامدهای امنیتی احتمالی
- خواندن فایل‌های محلی خارج از محدوده سند پردازش‌شده
- افشای فایل‌های پیکربندی و اطلاعات حساس سرویس
- نوشتن فایل در مسیرهای قابل دسترسی برای فرایند Docling
- تغییر داده یا فایل‌های پردازش‌شده در محیط سرویس
- در برخی پیکربندی‌ها، افزایش ریسک اجرای فرمان
- تأثیر بر Pipelineهای RAG، GenAI و پردازش خودکار سند
سناریوی ریسک در سطح معماری
فرض کنید یک سازمان سرویسی دارد که کاربران فایل‌های PDF یا اسناد ترکیبی را برای استخراج محتوا بارگذاری می‌کنند. این سرویس Docling را در Backend فراخوانی می‌کند و قابلیت Tectonic نیز برای برخی فرمت‌ها فعال است. در این شرایط، یک سند غیرقابل اعتماد می‌تواند باعث شود Renderer به منابعی در محیط Host یا Container دسترسی پیدا کند که جزو محتوای ورودی نبوده‌اند. به همین دلیل جداسازی Parserها و Rendererهای سند از سایر اجزای حساس زیرساخت اهمیت زیادی دارد.
راهکار پیشنهادی
مهم‌ترین اقدام، ارتقا Docling و Docling Slim به نسخه 2.132.0 یا جدیدتر است. تیم‌های فنی باید تمام محیط‌هایی را که Docling در آنها استفاده می‌شود شناسایی کنند؛ از جمله Notebookها، سرویس‌های Backend، Containerها، Workerها و Pipelineهای پردازش اسناد.
اگر ارتقای فوری امکان‌پذیر نیست، قابلیت Tectonic برای ورودی‌های غیرقابل اعتماد باید غیرفعال شود. همچنین پردازش اسناد باید در محیطی محدود با حداقل دسترسی فایل‌سیستم انجام شود. اجرای Parser داخل Container با Root filesystem فقط‌خواندنی، Mount کردن حداقلی Volumeها و عدم در اختیار قرار دادن Secretهای غیرضروری به همان Runtime از مهم‌ترین کنترل‌های جبرانی هستند.
کنترل‌های جبرانی
- غیرفعال کردن Tectonic برای ورودی‌های غیرقابل اعتماد تا زمان Patch
- اجرای Docling در Container یا Sandbox جداگانه
- استفاده از Read-only filesystem تا حد امکان
- عدم Mount کردن مسیرهای حساس Host داخل Container پردازش سند
- جدا کردن Secretها و Credentialها از Runtime پردازش اسناد
- محدودسازی دسترسی شبکه خروجی Workerهای پردازش سند
- پایش خطاهای غیرعادی مرتبط با TikZ، Tectonic و دسترسی فایل
اولویت اقدام
بالا. برای سازمان‌هایی که Docling را فقط روی فایل‌های داخلی و قابل اعتماد اجرا می‌کنند، ریسک عملیاتی کمتر است؛ اما در هر محیطی که کاربر یا سامانه بیرونی می‌تواند سند ارسال کند، ارتقا به 2.132.0 باید در اولویت قرار گیرد. سرویس‌های عمومی پردازش سند، سامانه‌های RAG و Pipelineهای هوش مصنوعی بیشترین حساسیت را دارند.
منابع
تصویر شاخص: Steve A Johnson / Unsplash.