بازگشت کنترل‌نشده در Java Thrift
CVE-2026-120135 به بخشی از کتابخانهٔ جاوای Apache Thrift مربوط است که هنگام عبور از داده‌های ناشناخته باید ساختار پیام را پیمایش کند. بنیاد آپاچی در رکورد منتشرشده در ۳۱ اکتبر ۲۰۲۶ توضیح می‌دهد که عمق بازگشت در TProtocolUtil.skip به صورت پیش‌فرض محدود نمی‌شود. نسخه‌های پیش از 0.24.0 در محدودهٔ اعلام‌شده قرار دارند و توصیهٔ مستقیم سازنده ارتقا به 0.24.0 است. این موضوع برای سامانه‌هایی اهمیت دارد که پیام Thrift را از طرفی دریافت می‌کنند که کنترل کامل آن در اختیار همان سازمان نیست. اثر اعلام‌شده اختلال در دسترس‌پذیری است و نباید بدون شاهد مستقل آن را به سرقت اطلاعات یا اجرای کد تبدیل کرد.
Thrift امکان تعریف قرارداد سرویس و تولید کد برای زبان‌های مختلف را فراهم می‌کند. در چنین معماری‌ای قرارداد یک پیام همیشه با نسخهٔ کد مصرف‌کننده کاملاً یکسان نیست. ممکن است فرستنده فیلدی جدید اضافه کرده باشد و گیرندهٔ قدیمی بخواهد آن فیلد را نادیده بگیرد. تابعی که مسئول عبور از مقدار ناشناخته است باید بتواند نوع و اندازهٔ ساختار را بفهمد و از آن بگذرد. همین مسیر سازگاری، هنگامی که محدودیت عمق نداشته باشد، به نقطه‌ای تبدیل می‌شود که دادهٔ بیرونی هزینهٔ محاسباتی و مصرف پشتهٔ پردازش را تعیین می‌کند.
مرز میان پیام بزرگ و پیام عمیق
اندازهٔ پیام و عمق تودرتویی دو ویژگی مستقل هستند. محدودکردن تعداد بایت‌های قابل دریافت لزوماً تعداد لایه‌هایی را که یک تحلیلگر باید باز کند محدود نمی‌کند. یک پیام ممکن است نسبتاً کوچک باشد اما ظرف‌هایی را درون ظرف‌های دیگر قرار دهد و تابع عبور از داده را بارها وارد خودش کند. تحلیل دفاعی این پرونده بنابراین باید علاوه بر سقف اندازهٔ درخواست، به عمق ساختار و بودجهٔ زمانی پردازش توجه کند. اضافه‌کردن یک محدودیت عمومی در پراکسی، بدون شناخت قالب Thrift، اثبات نمی‌کند که مسیر آسیب‌پذیر دیگر قابل دسترس نیست.
بازگشت در برنامه‌نویسی زمانی مفید است که شکل مسئله خودش تودرتو باشد. مشکل امنیتی وقتی شکل می‌گیرد که حد پایان عملیاتی فقط به ورودی اعتماد کند. هر فراخوانی می‌تواند اطلاعاتی را روی پشته نگه دارد و زنجیرهٔ طولانی فراخوانی‌ها منابع محدود فرایند را مصرف کند. عنوان رسمی این CVE بر نبود محدودیت پیش‌فرض تمرکز دارد. از این عنوان نمی‌توان نتیجه گرفت که هر استفاده از Thrift، با هر زبان و هر تنظیمی، یکسان آسیب‌پذیر است. این رکورد مشخصاً پیوندهای جاوا را نام می‌برد و شناسایی دارایی باید همین دامنه را حفظ کند.
یافتن وابستگی واقعی در برنامه
نام بستهٔ ثبت‌شده در دادهٔ رسمی org.apache.thrift:libthrift است. برای سازمانی که چند سرویس جاوا دارد، جست‌وجوی نام پروژه در فهرست نرم‌افزارهای نصب‌شده کافی نیست. کتابخانه ممکن است وابستگی مستقیم برنامه باشد، از طریق چارچوب دیگری وارد شود یا در یک فایل اجرایی تجمیع‌شده قرار گرفته باشد. تیم توسعه باید درخت وابستگی نسخهٔ ساخته‌شده را بررسی کند و نتیجه را با محتوای بسته‌ای که واقعاً اجرا می‌شود تطبیق دهد. تغییر فایل پروژه بدون ساخت و استقرار مجدد، نسخهٔ داخل فرایند فعال را عوض نمی‌کند.
در محیط‌هایی که چند ماژول دارند، امکان وجود نسخه‌های متفاوت هم هست. یک ماژول جدید ممکن است 0.24.0 را بگیرد، اما ابزار داخلی یا پردازشگر صف هنوز نسخهٔ قدیمی را همراه خود داشته باشد. بهتر است فهرست بررسی شامل نام سرویس، مالک، نوع بسته‌بندی، نسخهٔ مؤثر کتابخانه و مسیر دریافت پیام باشد. اگر اسکنر فقط یک تطابق متنی نشان داده است، آن تطابق باید به یک فایل قابل شناسایی و یک فرایند یا تصویر کانتینر مشخص برسد. این کار هم خطای مثبت را کم می‌کند و هم از جاافتادن سرویس‌های کمتر دیده‌شده جلوگیری خواهد کرد.
دسترسی به مسیر پردازش
امتیاز CVSS نسخهٔ چهار در رکورد آپاچی 8.2 است. بردار آن دسترسی شبکه‌ای، نبود نیاز به حساب و نبود تعامل کاربر را نشان می‌دهد، اما مؤلفهٔ نیازمندی حمله نیز حاضر است. برای استفادهٔ عملی از این اطلاعات باید مسیر واقعی دریافت داده را بررسی کرد. آیا سرویس مستقیم به شبکهٔ عمومی وصل است، پشت یک دروازهٔ احراز هویت قرار دارد، از شریک تجاری پیام می‌گیرد یا فقط دادهٔ تولیدشده در یک فرایند مورد اعتماد را می‌خواند؟ این تفاوت‌ها اولویت اصلاح را تغییر می‌دهند، هرچند ماهیت نقص کتابخانه ثابت می‌ماند.
در یک شبکهٔ داخلی نیز اعتماد باید مشخص باشد. اگر هر سرویس بتواند به درگاه RPC سرویس دیگر وصل شود، نفوذ به یک بار کاری می‌تواند سطح دسترسی به تحلیلگرهای داخلی را افزایش دهد. محدودسازی مسیر شبکه یک اقدام کاهش خطر است و جایگزین ارتقای کتابخانه نیست. برای ثبت استثنا باید روشن باشد کدام مبدأها مجاز هستند، این سیاست کجا اعمال می‌شود و چگونه آزموده شده است. عبارت کلی «داخلی است» برای ارزیابی این آسیب‌پذیری اطلاعات کافی نمی‌دهد، چون بسیاری از پردازش‌های داخلی همچنان ورودی کاربر را حمل می‌کنند.
برنامهٔ ارتقا به نسخهٔ اصلاح‌شده
اقدام اصلی اعلام‌شده ارتقا به 0.24.0 است. پیش از تغییر تولید، یک ساخت آزمایشی با همان نسخهٔ جاوا و همان تنظیمات عملیاتی تهیه شود. سپس پیام‌های واقعی و پاک‌سازی‌شدهٔ سامانه روی آن بازپخش شوند. این مرحله باید پیام‌های عادی، فیلدهای اختیاری، فیلدهای ناشناخته و ارتباط میان سرویس‌هایی با نسخه‌های متفاوت قرارداد را پوشش دهد. هدف این است که رفع محدودیت امنیتی با نیاز مشروع به سازگاری میان نسخه‌ها تعارض پنهان ایجاد نکند. آزمون باید رفتار مصرف‌کننده را نیز بسنجد و فقط موفقیت کامپایل را معیار قرار ندهد.
در استقرار مرحله‌ای، ابتدا یک نمونهٔ کم‌ریسک ارتقا یابد و نرخ خطا، تأخیر و تعداد اتصال‌های باز با خط پایه مقایسه شود. اگر کتابخانه در تصویر پایه یا بستهٔ مشترک سازمانی جاسازی شده است، انتشار آن بسته باید با بازسازی مصرف‌کنندگان همراه باشد. برای بازگشت اضطراری، نسخهٔ قبلی را می‌توان از نظر عملیاتی نگه داشت، اما بازگرداندن آن خطر امنیتی شناخته‌شده را نیز برمی‌گرداند. بنابراین طرح بازگشت باید محدودیت شبکه و زمان پایان مشخص داشته باشد و به وضعیت دائمی تبدیل نشود.
آزمون دفاعی بدون فشار بر تولید
آزمون مناسب این پرونده در محیطی جدا با منابع محدود انجام می‌شود. تیم می‌تواند پیام‌های معتبر با عمق‌های متفاوت تولید کند و بررسی کند که نسخهٔ اصلاح‌شده در مرز تعریف‌شده رفتار کنترل‌شده دارد. لازم نیست برای اثبات نصب وصله، تولید را تا آستانهٔ ازکارافتادن تحت فشار گذاشت. شواهد کافی می‌تواند شامل نسخهٔ بسته، نتیجهٔ آزمون واحد، پاسخ کنترل‌شدهٔ پردازشگر و ثابت‌ماندن سلامت فرایند باشد. اگر تیم از فازینگ استفاده می‌کند، محدودیت حافظه و زمان اجرای هر مورد باید جداگانه اعمال شود تا خود آزمایش به اختلال زیرساخت منجر نشود.
یک آزمون ارزشمند باید همچنین بررسی کند که شکست تحلیل یک پیام، ارتباط‌ها و درخواست‌های دیگر را بی‌دلیل از بین نمی‌برد. این نکته به معماری برنامه بستگی دارد و ادعایی دربارهٔ نتیجهٔ قطعی CVE نیست. در سرویس‌هایی با صف کاری محدود، گیرکردن چند پردازشگر می‌تواند زمان انتظار سایر مشتریان را بالا ببرد. ثبت تعداد کارهای در صف، زمان تحلیل و نرخ پاسخ‌های ناموفق نشان می‌دهد که دفاع برنامه در کنار اصلاح کتابخانه چگونه رفتار می‌کند. آزمون‌های سالم باید امکان تشخیص تفاوت میان رد ورودی و سقوط کامل سرویس را فراهم کنند.
پایش پس از انتشار
برای پایش عملیاتی، خطاهای تحلیل پیام و استثناهای مربوط به پشته باید همراه با نام سرویس و نسخهٔ انتشار ثبت شوند. افزایش این خطاها به تنهایی اثبات حمله نیست و ممکن است از ناسازگاری قرارداد یا مشتری قدیمی ناشی شود. با این حال ارتباط زمانی آن‌ها با افزایش مصرف پردازنده، ری‌استارت فرایند و افت موفقیت درخواست‌ها ارزش بررسی دارد. نگهداری متن کامل پیام‌های مشتری در لاگ معمولاً لازم نیست و می‌تواند دادهٔ حساس را تکثیر کند. یک شناسهٔ درخواست، نوع خطا، اندازهٔ پیام و مشخصات مبدأ مجاز اغلب برای شروع تحلیل مناسب‌تر هستند.
اگر اختلالی پیش از وصله رخ داده است، گزارش حادثه باید دامنهٔ شواهد را دقیق نگه دارد. این CVE در رکورد رسمی اثر مستقیم بر دسترس‌پذیری دارد. مشاهدهٔ ری‌استارت به معنای اثبات دسترسی مهاجم به داده یا اجرای فرمان نیست. تیم پاسخ‌گویی می‌تواند لاگ دروازه، متریک‌های سرویس و تاریخچهٔ انتشار را کنار هم بگذارد و مشخص کند آیا یک الگوی ورودی مشترک وجود داشته است. نگهداری این تمایز از تبدیل یک تشخیص فنی محدود به ادعای گسترده و بی‌پشتوانه جلوگیری می‌کند.
کنترل‌های معماری مکمل
این پرونده فرصت مناسبی برای مرور سیاست پذیرش داده در RPC است. اندازهٔ پیام، عمق ساختار، زمان پردازش، تعداد درخواست همزمان و نرخ اتصال باید هر کدام جایگاه مشخص داشته باشند. این محدودیت‌ها مشکلات متفاوتی را پوشش می‌دهند و نمی‌توان یکی را جای همه گذاشت. مستندسازی آن‌ها به توسعه‌دهندهٔ سرویس بعدی کمک می‌کند بداند چه چیزی در کتابخانه تضمین می‌شود و چه چیزی مسئولیت برنامه است. اگر سازمان از چند زبان استفاده می‌کند، تنظیمات هر پیاده‌سازی باید جداگانه خوانده شود و نتیجهٔ بررسی جاوا به همهٔ زبان‌ها تعمیم داده نشود.
برای پایان‌دادن به کار، پروندهٔ تغییر بهتر است نسخهٔ پیشین و جدید، شناسهٔ ساخت، سرویس‌های مستقرشده، آزمون سازگاری و زمان مشاهدهٔ پایدار را ثبت کند. دارایی‌هایی که هنوز ارتقا نیافته‌اند باید مالک و مهلت داشته باشند. با این روش، اعلان امنیتی به یک اصلاح قابل اندازه‌گیری تبدیل می‌شود. ارزش وصله فقط در تغییر شمارهٔ بسته نیست؛ ارزش اصلی آن این است که دادهٔ بیرونی دیگر نتواند بدون مرز تعریف‌شده عمق پردازش را تعیین کند و تیم بتواند این مرز را در محیط واقعی خود نشان دهد.
چرا محدود کردن اندازه کافی نیست؟
ساختار تو در تو ممکن است با حجم ظاهری اندک، تعداد بسیار زیادی فراخوانی بازگشتی ایجاد کند. بنابراین در سامانه‌ای که پیام را با Apache Thrift در جاوا پردازش می‌کند، سقف اندازه بایت ورودی و سقف عمق ساختار دو کنترل متفاوت‌اند. بررسی باید نوع پروتکل، نسخه کتابخانه، مسیر deserialization و دسترسی فرستنده را همزمان در نظر بگیرد. پیش از ارتقا در محیط عملیاتی، یک نمونه داده سالم با عمق عادی و چند نمونه نامعمول اما غیرمخرب برای آزمون محدودیت‌های پردازش تهیه کنید. پس از ارتقا، علاوه بر موفقیت پیام‌های عادی، رفتار خطا و آزاد شدن منابع را ثبت کنید. اگر پردازشگر در یک مسیر عمومی قرار دارد، محدودسازی نرخ درخواست و جداسازی منابع پردازش از بخش‌های حساس به دسترس‌پذیری نیز به کاهش اثر کمک می‌کند. تحلیل مستند باید روشن کند این اقدامات مکمل وصله‌اند و جایگزین رفع نقص نسخه آسیب‌پذیر نمی‌شوند.
