ثغرة حرجة في Fastjson 1.x تسمح للمهاجمين بتنفيذ أكواد في تطبيقات Spring Boot دون وجود تصحيح متاح

وفقًا لتقرير من The Hacker News، يُستغل على نطاق واسع ثغرة أمنية حرجة لتنفيذ الكود عن بُعد في Fastjson 1.x، وهي مكتبة علي بابا المستخدمة على نطاق واسع لتسلسل JSON في Java. الثغرة، المُسجَّلة باسم CVE-2026-16723 وبدرجة CVSS 9.0، تؤثر على الإصدارات 1.2.68 إلى 1.2.83 وتسمح للمهاجم بتنفيذ كود عشوائي بصلاحيات عملية Java — دون مصادقة، ودون الحاجة إلى تفعيل خاصية AutoType في Fastjson، ودون الاعتماد على فئات أدوات طرف ثالث التي كانت تتطلبها استغلالات Fastjson السابقة.

كيف تعمل سلسلة الاستغلال

تستهدف الثغرة تطبيقات Spring Boot المنشورة بصيغة "fat-JARs" القابلة للتنفيذ — وهي صيغة JAR المتكاملة ذات الملف الواحد التي يُنتجها Spring Boot عادةً للنشر. تم تأكيد الاستغلال في جميع إصدارات Spring Boot 2.x و3.x و4.x، العاملة على JDK 8 و11 و17 و21، مما يغطي الغالبية العظمى من بيئات Java التي لا تزال تستخدم Fastjson 1.x في الإنتاج.

يعمل الهجوم بإرسال طلب JSON مصمَّم يحتوي على قيمة @type معدَّلة، مما يؤدي إلى تشغيل منطق حل الأنواع في Fastjson لإجراء بحث عن موارد الصفوف. داخل fat-JAR متوافق مع Spring Boot، يمكن لمسار JAR متداخل تم إنشاؤه خصيصًا جلب bytecode يتحكم فيه المهاجم. بعد ذلك، تتعامل Fastjson مع التعليق التوضيحي @JSONType المرافق على ذلك المورد كإشارة ثقة، مما يسمح للفئة الخبيثة بتجاوز آليات التحقق من الأنواع في Fastjson بالكامل والتحميل في التطبيق قيد التشغيل. نظرًا لأن الاستغلال يعمل تحت التهيئة الافتراضية لـ Fastjson — حيث يكون SafeMode معطلًا افتراضيًا — فإن أي خدمة Spring Boot غير مصححة ومواجهة للإنترنت تستخدم إصدار Fastjson متأثرًا قد تكون قابلة للاستغلال بدون أي تهيئة خاصة من جانب المهاجم.

لا يوجد تصحيح، لكن توجد وسائل تخفيف

حتى 25 يوليو 2026، لم تصدر علي بابا أي تصحيح رسمي خاص بفرع Fastjson 1.x تحديدًا. أمام فرق الأمن ثلاثة خيارات عملية في الوقت الحالي. الأول هو تمكين SafeMode مباشرة عبر خاصية النظام -Dfastjson.parser.safeMode=true، مما يمنع سلوك حل الأنواع الذي يعتمد عليه الاستغلال. الثاني هو التبديل إلى المتغير الحزمة المحدد com.alibaba:fastjson:1.2.83_noneautotype، والذي يزيل وظائف AutoType بالكامل. الثالث، وهو الخيار الذي توصي به علي بابا كحل طويل الأمد، هو الانتقال من Fastjson 1.x إلى Fastjson2، المكتبة الخلفية التي يتم صيانتها بنشاط.

ما لا يتأثر

تتطلب سلسلة الاستغلال المحددة صيغة نشر fat-JAR التي يستخدمها Spring Boot بشكل افتراضي — أما JARs العادية غير fat-JAR، وJARs العامة المُنشأة بأدوات مثل Maven Shade، والتطبيقات المنشورة كملفات WAR داخل Tomcat أو Jetty فهي غير معرضة لهذا المسار الهجومي تحديدًا، لأنها لا تعرض بحث مورد الصفوف في JAR المتداخل الذي يعتمد عليه الاستغلال. يقلل ذلك من الجمهور المتأثر لكنه لا يلغي الخطر: نشر fat-JAR هو الخيار الافتراضي والأكثر شيوعًا لتغليف تطبيقات Spring Boot تحديدًا لأنه يبسط النشر إلى ملف واحد قابل للتنفيذ.

لماذا يهم هذا أكثر من مكتبة واحدة

لدى Fastjson تاريخ طويل من الثغرات الخطيرة في إلغاء التسلسل يعود لما يقرب من عقد من الزمن، ولا يزال Fastjson 1.x مستخدمًا على نطاق واسع في أنظمة Java الإنتاجية رغم توصية علي بابا نفسها بالانتقال إلى Fastjson2. المؤسسات التي تدير نشر Spring Boot fat-JAR مع Fastjson 1.x في النطاق 1.2.68–1.2.83 يجب أن تتعامل مع هذا كأولوية تصحيح طارئة: تفعيل SafeMode فورًا كإجراء مؤقت، والتعامل مع الانتقال إلى Fastjson2 باعتباره عاجلًا وليس اختياريًا، لأن قرار علي بابا بعدم تصحيح الفرع 1.x يشير إلى أن الثغرات المستقبلية في هذا الخط من غير المرجح أيضًا أن تُصلح.