وقتی عبارت JSONPath پایان پیدا نمی‌کند
CVE-2026-120194 نقصی در json-glib است که به ارزیابی برش‌های JSONPath مربوط می‌شود. طبق رکورد صادرشده از سوی Red Hat، تابع json_path_query می‌تواند هنگام دریافت عبارت برش با گام منفی وارد حلقهٔ بی‌پایان شود. برنامه‌ای که عبارت JSONPath تحت کنترل مهاجم را ارزیابی کند ممکن است متوقف بماند و در دسترس نباشد. این تعریف یک پیش‌شرط مهم دارد؛ صرف خواندن دادهٔ JSON یا نصب بستهٔ json-glib به معنی رسیدن ورودی مهاجم به این تابع نیست. ارزیابی باید مسیر دریافت خود عبارت جست‌وجو را مشخص کند.
رکورد در ۳۱ اکتبر ۲۰۲۶ منتشر شده و در دوم نوامبر به‌روزرسانی شده است. امتیاز CVSS نسخهٔ 3.1 برابر 7.5 اعلام شده و اثر آن در بردار بر دسترس‌پذیری متمرکز است. هیچ اثر مستقیم بر محرمانگی یا تمامیت در همان بردار ثبت نشده است. بنابراین توصیف این نقص به عنوان اجرای کد یا خواندن فایل بدون منبع اضافی درست نیست. ارزش عملی خبر برای مدیر سامانه در پیدا کردن برنامه‌هایی است که عبارت پرس‌وجوی قابل کنترل توسط کاربر را به این کتابخانه می‌سپارند و برای زمان اجرای آن مرزی ندارند.
تفاوت دادهٔ JSON و زبان پرس‌وجو
JSON قالب داده است، اما JSONPath برای انتخاب بخش‌هایی از آن داده به کار می‌رود. یک سرویس ممکن است سند JSON را خودش تولید کند و در عین حال به کاربر اجازه دهد مسیر انتخاب را وارد کند. در چنین حالتی حتی اگر سند کاملاً مورد اعتماد باشد، عبارت انتخاب می‌تواند نامطمئن باشد. این تفاوت در بررسی آسیب‌پذیری اهمیت دارد، چون بعضی تیم‌ها فقط منبع سند را بررسی می‌کنند و فراموش می‌کنند که منطق پیمایش نیز ورودی جداگانه دارد. پروندهٔ حاضر روی همین منطق برش و مقدار گام تمرکز دارد.
در پیمایش یک دنباله، گام تعیین می‌کند حرکت میان عناصر چگونه انجام شود. گام منفی می‌تواند برای حرکت معکوس معنا داشته باشد، اما پیاده‌سازی باید شرط پایان را متناسب با جهت حرکت تنظیم کند. اگر این هماهنگی از دست برود، شمارنده ممکن است هرگز به شرط خروج نرسد. این توضیح یک تفسیر عمومی از حلقهٔ بی‌پایان در ارزیابی برش است؛ جزئیات خط کد و اصلاح باید از گزارش رسمی پروژه دنبال شود. برای فهم خطر لازم نیست نمونهٔ مخرب در سرویس واقعی اجرا شود، زیرا اثر اعلام‌شده همان توقف پردازش است.
دارایی‌هایی که باید بررسی شوند
دادهٔ Red Hat بستهٔ json-glib را در چند شاخهٔ RHEL و برخی بسته‌های پایهٔ OpenShift نام می‌برد. فهرست رسمی شامل RHEL 7، 8، 9 و 10 و برخی اجزای CoreOS در OpenShift است. این فهرست نشان می‌دهد وابستگی ممکن است در تصویر پایه وجود داشته باشد، اما حضور بسته به تنهایی به معنای در معرض بودن یک خدمت شبکه نیست. تیم باید مشخص کند چه فرایندی آن را بارگذاری می‌کند و آیا آن فرایند json_path_query را با عبارت بیرونی فراخوانی می‌کند. سطح بسته و سطح کاربرد دو مرحلهٔ جدا از بررسی هستند.
در کانتینرها، بررسی فقط میزبان کافی نیست. یک تصویر قدیمی ممکن است نسخهٔ دیگری از کتابخانه داشته باشد و با ارتقای میزبان تغییر نکند. برعکس، برنامه‌ای که کتابخانه را از محیط میزبان می‌گیرد ممکن است به چرخهٔ به‌روزرسانی سیستم‌عامل وابسته باشد. خروجی موجودی باید تصویر، برچسب، شناسهٔ تغییرناپذیر، بسته و نام سرویس را به هم متصل کند. اگر سازمان از ساخت‌های سفارشی استفاده می‌کند، نسخهٔ منبع و اصلاح‌های برگشتی نیز باید ثبت شوند تا مقایسهٔ سادهٔ شمارهٔ نسخه به نتیجهٔ غلط نرسد.
پیدا کردن ورودی قابل کنترل
مسیرهای محتمل برای بررسی شامل ابزارهای جست‌وجوی داده، تبدیل‌کننده‌های سند، فیلترهای قابل تنظیم و رابط‌هایی است که کاربر در آن‌ها مسیر JSON وارد می‌کند. این فهرست به معنی آسیب‌پذیر بودن همهٔ چنین ابزارهایی نیست. باید در کد یا مستندات معلوم شود که آن‌ها از json-glib و تابع مورد اشاره استفاده می‌کنند. اگر عبارت‌ها ثابت و در کد نوشته شده‌اند، سناریوی ورودی مهاجم ممکن است برقرار نباشد. اگر کاربر می‌تواند قالب، تنظیم یا قانون فیلتر را ذخیره کند، همان تنظیم ذخیره‌شده نیز باید ورودی نامطمئن محسوب شود.
برای هر مسیر، تعیین شود چه کسی اجازهٔ ساخت یا تغییر عبارت را دارد. یک قابلیت مدیریتی محدود با یک فرم عمومی تفاوت اولویت دارد، اما حساب کم‌اختیار داخلی نیز ممکن است برای ایجاد اختلال کافی باشد. همچنین باید روشن شود ارزیابی در فرایند وب، پردازشگر پس‌زمینه یا کار دسته‌ای انجام می‌شود. حلقهٔ بی‌پایان در هر کدام اثر عملی متفاوتی دارد. در پردازشگر مشترک، یک کار معیوب می‌تواند صف را عقب بیندازد؛ در معماری چندفرایندی ممکن است فقط یک کارگر از دسترس خارج شود تا زمانی که درخواست‌ها تکرار شوند.
کنترل زمان و منابع
یک مهلت شبکه‌ای همیشه پردازش داخلی را متوقف نمی‌کند. ممکن است پراکسی پس از چند ثانیه پاسخ خطا بدهد، اما فرایند زیرین همچنان در حلقه بماند و پردازنده مصرف کند. بنابراین کنترل دفاعی باید امکان قطع واقعی کار را بررسی کند. جداکردن ارزیابی نامطمئن در فرایندی که بودجهٔ زمانی و منابع مستقل دارد می‌تواند اثر اختلال را محدود کند. این یک پیشنهاد معماری مکمل است و جایگزین نسخهٔ اصلاح‌شدهٔ کتابخانه نیست. تیم باید آزمایش کند که پایان مهلت واقعاً منابع را آزاد می‌کند و فقط ارتباط مشتری را نمی‌بندد.
محدودکردن طول عبارت نیز به تنهایی کافی نیست، زیرا علت نقص به معنای گام مربوط است و لزوماً به عبارت بسیار طولانی نیاز ندارد. در کاهش خطر موقت، محدودکردن دستور زبان مجاز یا غیرفعال‌کردن قابلیت برش منفی می‌تواند بررسی شود، اما باید با نیاز محصول و رفتار کتابخانه آزموده شود. یک فیلتر متنی ساده ممکن است شکل‌های متفاوت همان معنا را نبیند. تصمیم بهتر بر پایهٔ تجزیهٔ معتبر عبارت و فهرست قابلیت‌های مجاز است، نه چند جایگزینی رشته‌ای که فقط نمونهٔ شناخته‌شده را حذف می‌کند.
وصله در توزیع و در برنامه
رکورد بررسی‌شده نسخهٔ اصلاح‌شدهٔ واحدی برای همهٔ توزیع‌ها اعلام نمی‌کند. مدیر باید وضعیت محصول خود را در صفحهٔ Red Hat و ارجاع مسئلهٔ GNOME دنبال کند. در توزیع‌های سازمانی، اصلاح ممکن است به نسخهٔ قدیمی‌تر برگشت داده شود و شمارهٔ بالادستی تغییر بزرگی نکند. به همین دلیل نتیجهٔ بستهٔ توزیع و شناسهٔ اعلان امنیتی آن از مقایسهٔ ظاهری شماره‌ها معتبرتر است. اعلام یک شمارهٔ حدسی به عنوان نسخهٔ امن می‌تواند هم رفع کاذب ایجاد کند و هم کاربران را به ارتقای ناسازگار سوق دهد.
پس از نصب بسته، فرایندهایی که کتابخانه را قبلاً در حافظه بارگذاری کرده‌اند باید طبق راهنمای محصول بازراه‌اندازی شوند. در کانتینرها، ساخت تصویر تازه بدون جایگزینی نمونه‌های در حال اجرا کافی نیست. فهرست کار باید نمونه‌های قدیمی، کارهای زمان‌بندی‌شده و گره‌هایی را که دیرتر به‌روزرسانی می‌شوند در بر بگیرد. نتیجهٔ مناسب نشان می‌دهد هر مسیر در معرض روی بستهٔ اصلاح‌شده اجرا می‌شود یا با کنترل موقت مشخص از دسترس خارج شده است. صرف موفقیت مدیر بسته در یک میزبان، پایان بررسی کل ناوگان نیست.
آزمون بدون ایجاد اختلال
آزمون رگرسیون بهتر است در یک فرایند جدا و محدود انجام شود. دادهٔ کوچک و ساختگی برای بررسی رفتار برش‌های معمولی، گام مثبت و گام منفی کافی است. هدف این است که ورودی غیرقابل قبول به شکل کنترل‌شده رد شود یا مطابق قرارداد در زمان محدود نتیجه بدهد. برای اثبات نقص نباید یک خدمت مشترک را بدون محدودیت به حلقه انداخت. هر آزمون باید مهلت سخت داشته باشد و خروجی آن شامل زمان، کد نتیجه و وضعیت خاتمهٔ فرایند باشد تا شکست آزمون نیز قابل مدیریت بماند.
آزمون مثبت باید موارد مشروعی را پوشش دهد که تیم محصول به آن‌ها نیاز دارد. اگر یک کنترل موقت همهٔ برش‌ها را ممنوع کرده است، ممکن است گزارش‌های عادی شکسته باشند. این اثر باید شناخته و به کاربر توضیح داده شود. همچنین آزمون هم‌زمانی اهمیت دارد؛ چند کار مستقل نباید با گیرکردن یکی از آن‌ها همگی منتظر بمانند. این آزمون دربارهٔ طراحی برنامه است و به تیم کمک می‌کند اثر دسترس‌پذیری را در معماری خودش اندازه بگیرد، بدون اینکه از امتیاز عمومی CVSS نتیجهٔ قطعی دربارهٔ ظرفیت سرویس بگیرد.
تشخیص در عملیات روزمره
نشانهٔ محتمل می‌تواند افزایش مصرف پردازنده همراه با نبود پیشرفت در یک کار ارزیابی باشد. این علامت اختصاصی نیست و مشکلات دیگر نیز آن را ایجاد می‌کنند. متریک تعداد کارهای کامل‌شده، طول صف، زمان ارزیابی و ری‌استارت کارگر به تفکیک علت کمک می‌کند. نمونه‌برداری از پشتهٔ فرایند در محیط مجاز می‌تواند نشان دهد زمان در کدام تابع صرف می‌شود. نگهداری خود عبارت باید با دقت انجام شود، چون در برخی سامانه‌ها عبارت ممکن است بخشی از نام فیلدها یا منطق تجاری حساس را آشکار کند.
برای بازیابی، فقط افزودن کارگر بیشتر ممکن است هزینه را بالا ببرد و مشکل را پنهان کند. اگر ورودی تکرارشونده‌ای باعث توقف می‌شود، باید مسیر ورود آن محدود شود و کارهای گیرکرده به شکل کنترل‌شده خاتمه یابند. سپس نسخه و پیکربندی اصلاح‌شده جایگزین شود. در گزارش حادثه، از نسبت‌دادن هر افزایش CPU به این CVE خودداری شود مگر اینکه شواهد مسیر json_path_query و عبارت مرتبط وجود داشته باشد. دقت در این نسبت‌دادن باعث می‌شود تیم هم نقص واقعی را رفع کند و هم علت‌های دیگر افت سرویس را از دست ندهد.
معیار پایان کار
این پرونده زمانی بسته می‌شود که مالک برنامه، نسخهٔ مؤثر کتابخانه و وضعیت دسترسی به عبارت بیرونی مشخص باشد و اصلاح یا کاهش خطر آزموده‌شده اعمال شده باشد. ثبت شمارهٔ بسته، تصویر مستقر، نتیجهٔ آزمون محدود و مشاهدهٔ سلامت پس از انتشار به تیم بعدی امکان بازبینی می‌دهد. ارزش این بررسی فراتر از یک CVE است؛ زبان‌های جست‌وجو و فیلتر نیز ورودی اجرایی از نظر هزینهٔ پردازش هستند و باید بودجهٔ مشخص داشته باشند. طراحی این بودجه، همراه با وصلهٔ رسمی، از تبدیل یک عبارت کوچک به توقف طولانی خدمت جلوگیری می‌کند.
ارزیابی ورودی‌های JSONPath در نرم‌افزار
یک پرس‌وجوی JSONPath می‌تواند از فایل تنظیمات ثابت، برنامه داخلی یا ورودی غیرقابل اعتماد کاربر ساخته شود. ریسک واقعی زمانی روشن می‌شود که منبع این عبارت و نقطه اجرای آن شناسایی شود. برای سرویس‌های در معرض درخواست عمومی، محدودسازی زمان پردازش و ثبت درخواست‌های غیرعادی باید در کنار به‌روزرسانی کتابخانه قرار گیرد. در محیط آزمایش، عبارت‌های مرزی با دامنه کوچک و محدودیت منابع اجرا می‌شوند تا بدون ایجاد اختلال در سرویس فعال، رفتار خطا مشاهده شود. نتیجه صرفاً هنگامی قابل تفسیر است که نسخه کتابخانه و تابع مورد استفاده ثبت شده باشد. دفاع در عمق می‌تواند از پذیرش زبان پرس‌وجوی آزاد برای کاربران غیرمجاز جلوگیری کند، اما جایگزین بررسی نسخه اصلاح‌شده و آزمون بازگشتی پس از ارتقا نیست.
