أداة إعادة إنتاج إلغاء التسلسل غير الآمن لـ camel-jms JMS ObjectMessage (CVE-2026-40860)

يعرض هذا المشروع ثغرة إلغاء تسلسل في Java في مكوّن camel-jms الخاص بـ Apache Camel (وبالتبعية في camel-sjms، وcamel-sjms2، وcamel-amqp، وcamel-activemq، وcamel-activemq6)، وتُتتبَّع باسم CVE-2026-40860. يقوم JmsBinding.extractBodyFromJms() بإلغاء تسلسل حمولة رسالة JMS ObjectMessage الواردة عبر ObjectMessage.getObject() بدون أي ObjectInputFilter أو قائمة سماح أو قائمة منع للفئات. ولأن هذا التنفيذ يحدث كلما كان mapJmsMessage=true (الوضع الافتراضي) وكانت Camel مستهلكًا لـ JMS، فإن أي مهاجم قادرًا على نشر ObjectMessage مزيّفة إلى قائمة انتظار/موضوع مستهلك يمكنه تحقيق تنفيذ برمجي عن بُعد عند وجود سلسلة أدوات (gadget chain) على مسار الفئات (classpath).

الإشعار الأمني: https://camel.apache.org/security/CVE-2026-40860.html

ملخص الثغرة

التفاصيل التقنية

// JmsBinding.extractBodyFromJms(Exchange, Message) - affected version
if (message instanceof ObjectMessage objectMessage) {
    Object payload = objectMessage.getObject();   // <-- deserializes with no ObjectInputFilter
    if (payload instanceof DefaultExchangeHolder holder) {
        ...
    }
    return payload;
}

يستدعي getObject() أسلوب ObjectInputStream.readObject() الخاص بمزوّد JMS على جسم الرسالة. ولا يضيف Camel أي تصفية فئات خاصة به، لذلك يتم تنفيذ سلسلة أدوات (gadget chain) موجودة على مسار الفئات أثناء إلغاء التسلسل.

ماذا يفعل الإصلاح (وحدوده)

يضيف الإصلاح (4.14.7 / 4.18.2 / 4.20.0) قائمة سماح افتراضية عبر ObjectInputFilter (java.**;javax.**;org.apache.camel.**;!*)، ويمكن تخصيصها عبر خيار نقطة النهاية الجديد deserializationFilter أو عبر خيار JVM العام -Djdk.serialFilter. إليك نص رسالة الالتزام الخاصة بـ Camel لهذا الإصلاح:

يتم هذا الفحص بعد أن يكون مزوّد JMS قد ألغى تسلسل الحمولة بالفعل. فهو يمنع الفئات غير المتوقعة من الانتشار إلى المسار، لكنه لا يستطيع وحده إيقاف سلاسل الأدوات التي يتم فيها استدعاء readObject() داخل ObjectInputStream الخاص بالمزوّد. تتطلب الحماية الكاملة ضبط مرشّح إلغاء التسلسل الخاص بمزوّد JMS و/أو -Djdk.serialFilter العام على مستوى JVM.

إذًا الحماية الكاملة = ترقية Camel + تقييد مرشّح المزوّد / JVM. يستخدم هذا الإثبات المفاهيمي (PoC) عميل ActiveMQ مع trustAllPackages=true (وهو إعداد شائع في البيئات الحقيقية) لكي يقوم المزوّد بإلغاء تسلسل الحمولة؛ وعلى إصدار Camel المتأثر لا يوجد أي حاجز آخر.

مسار الضحية (الطرف المتضرر)

from("jms:queue:evil")            // mapJmsMessage defaults to true
    .log("Consumed: ${body.class.name}");

مجرد استلام ObjectMessage يؤدي إلى تشغيل إلغاء التسلسل — ومحتوى المسار غير ذي صلة.

هيكل المستودع — المهاجم مقابل الضحية

الضحية هي مستهلك Camel JMS. أما المهاجم فهو أي مُنتِج يمكنه النشر إلى قائمة الانتظار. يتواصل كلاهما مع وسيط Apache ActiveMQ Artemis حقيقي يعمل في Docker.

CVE-2026-40860/
├── pom.xml                 # camel-jms 4.18.1 + activemq-client 6.2.4 + commons-collections 3.2.1 (gadget)
├── Dockerfile              # runs the app (--add-opens only to build the gadget)
├── docker-compose.yml      # Artemis broker (quay.io) + the reproducer app
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── JmsConfig.java          # OpenWire ConnectionFactory (trustAllPackages=true) + jms component
    │   ├── VictimRoute.java        # victim: from("jms:queue:evil")
    │   ├── Gadget.java             # CommonsCollections6 gadget, fires during getObject()
    │   └── ExploitController.java  # attacker: publishes ObjectMessage(gadget) to the queue
    └── resources/
        └── application.properties

في هجوم حقيقي، يتم إنتاج البايتات المسلسلة دون اتصال من قبل المهاجم (مثلًا باستخدام ysoserial)؛ فقط الضحية تحتاج إلى سلسلة الأدوات على مسار الفئات. يبني هذا الإثبات المفاهيمي الأداة داخل العملية من أجل الراحة، ولهذا يعمل JVM مع --add-opens java.base/java.util=ALL-UNNAMED — وهو تفصيل خاص ببناء الأداة، لا علاقة له بالثغرة.

المتطلبات الأساسية

• Java 17+ وMaven 3.8+
• Docker (يشغّل الوسيط والتطبيق)

خطوات إعادة الإنتاج

الخطوة 1: البناء وتشغيل كل شيء

mvn clean package -DskipTests
docker compose up -d --build

يؤدي هذا إلى تشغيل وسيط Artemis (quay.io/artemiscloud/activemq-artemis-broker) وتطبيق إعادة الإنتاج، الذي يتصل به عبر OpenWire.

الخطوة 2: تفعيل إلغاء التسلسل (RCE)

curl -s http://localhost:8080/exploit/attack
# -> ObjectMessage published to queue 'evil'.
#    camel-jms consumer called ObjectMessage.getObject() -> deserialization.
#
#    >>> RCE proof — /tmp/pwned exists: true

الخطوة 3: التحقق

docker exec cve-2026-40860 ls -la /tmp/pwned

التنظيف

docker compose down

نواقل الهجوم

أي مستهلك Camel JMS (camel-jms، camel-sjms، camel-sjms2، camel-amqp، camel-activemq، camel-activemq6) يقرأ من وجهة يمكن للمهاجم النشر إليها — وسيط مشترك، أو موضوع بمُنتِجين مفتوحين، أو قائمة انتظار تغذّيها جهة علوية غير موثوقة — مع mapJmsMessage=true (الافتراضي).

شروط الاستغلال

1. مستهلك Camel JMS مع mapJmsMessage=true (الافتراضي).
2. يستطيع المهاجم إدراج ObjectMessage في الوجهة المستهلكة.
3. يقوم مزوّد JMS بإلغاء تسلسل الحمولة (مثل ActiveMQ مع trustAllPackages=true، أو مزوّد بدون مرشّح تقييدي).
4. مكتبة أدوات (gadget) على مسار الفئات (هنا commons-collections:3.2.1).

الإصلاح الموصى به

قم بترقية Camel إلى 4.14.7 / 4.18.2 / 4.20.0، وقيّد عملية إلغاء التسلسل من البداية إلى النهاية:

• اضبط قائمة سماح على مستوى JVM: -Djdk.serialFilter=java.**;org.apache.camel.**;!* (أو خيار نقطة النهاية الجديد deserializationFilter).
• اضبط مرشّح إلغاء التسلسل الخاص بمزوّد JMS (مثل ActiveMQ trustedPackages، ولا تستخدم trustAllPackages=true).

التخفيف من الأثر

إلى حين الترقية:

1. فضّل الحمولات غير ObjectMessage؛ واضبط mapJmsMessage=false عندما تكون الرسالة الخام مقبولة.
2. قيّد الحزم الموثوقة لدى مزوّد JMS؛ ولا تستخدم أبدًا trustAllPackages=true على وجهات غير موثوقة.
3. طبّق -Djdk.serialFilter.
4. أزل مكتبات الأدوات (gadget) من مسار الفئات (قم بترقية/إزالة commons-collections 3.x وما يشابهها).

إخلاء مسؤولية

تم توفير هذه الأداة لإعادة الإنتاج لأغراض البحث الأمني والاختبار المصرّح به فقط، وذلك لثغرة تم الكشف عنها وإصلاحها علنًا. لا تستخدمها ضد أي أنظمة دون إذن صريح.