تحديث Apache Tomcat الأمني في أكتوبر 2026: حدّث وتحقق

أعلن Apache Tomcat في 20 أكتوبر 2026 عن حزمة أمنية تتضمن ثلاث مشكلات مصنفة Important عبر الفروع المدعومة: فشل مصادقة مفتوح في JNDIRealm، واختلاط Request/Response في HTTP/2، واختلاط استجابات AJP في Tomcat 11. يجب على فرق الإنتاج التحديث إلى Tomcat 9.0.123 أو10.1.61 أو11.0.27، واستبدال كل Instance عاملة، والتحقق من الإصدار والإعدادات التي تخدم الترافيك فعليًا. Reverse Proxy أوWAF لا يصلحان الخلل داخل Tomcat.

يفصل هذا الدليل بين حقائق المورد والتحليل الهندسي. النطاقات المتأثرة والإصدارات المصححة وتصنيفات الشدة وآليات الثغرات مأخوذة من صفحات Apache Tomcat الأمنية، وتم التحقق منها في 25 أكتوبر 2026. أما خطوات النشر والكشف فهي توصيات دفاعية. لا تدعي نشرات Apache وجود استغلال نشط، ولذلك لا يصف المقال مجرد وجود نسخة متأثرة بأنه اختراق مؤكد.

القرار في جدول واحد

انتهى دعم Tomcat 10.0. وتوضح Apache أن الثغرات المبلغ عنها بعد 31 أكتوبر 2022 لا تفحص على هذا الفرع ولن تصلح فيه. انقل بيئات 10.0 إلى 10.1 أو11 مدعوم بدل اعتبار الإصدار القديم غير متأثر.

CVE-2026-101296: مصادقة JNDIRealm قد تفشل بشكل مفتوح

الخطر الأكبر على الهوية هو CVE-2026-101296. عندما يستخدم JNDIRealm آلية SASL غير GSSAPI، قد تسمح خطوة تحقق مفقودة بالمصادقة دون كلمة المرور الصحيحة. تصنف Apache المشكلة Important.

النطاقات المتأثرة واسعة:

• Tomcat 9.0.0.M1 حتى 9.0.122؛
• Tomcat 10.1.0-M1 حتى 10.1.60؛
• Tomcat 11.0.0-M1 حتى 11.0.26.

تعتمد الثغرة على الإعداد. الخادم الذي لا يستخدم JNDIRealm مع non-GSSAPI SASL ليس معرضًا عبر هذا المسار بعينه. لا تستنتج الأمان من رقم الحزمة وحده، ولا تستنتج الاختراق منه أيضًا.

احصر Realm الفعلي لا Template الموجود في Source Control فقط. افحص server.xml ومصادر الإعداد المضمنة بحثًا عن JNDIRealm وsaslMechanism وعناوين Directory وRealms البديلة وHelm Values وOverrides الخاصة بكل بيئة. احم ناتج التشخيص لأن Directory URLs وهويات Bind قد تكون حساسة.

إذا تحقق الشرط، أعط الخدمة أولوية لأنها تمس حد المصادقة. بعد التحديث شغل اختبارات إيجابية وسلبية في Staging وCanary: بيانات صحيحة تمر، وكلمة مرور خاطئة تفشل، ومستخدم معطل يفشل، ومستخدم صحيح دون Role المطلوبة يرفض. لا تختبر بمهاجمة حسابات الإنتاج.

CVE-2026-101356: اختلاط بيانات HTTP/2 بين المستخدمين

تنتج CVE-2026-101356 عن إعادة تدوير واستخدام غير صحيحين لكائنات داخلية بعد خطأ أثناء Async Servlet Processing. وتوضح Apache أنها قد تسبب اختلاط Request و/أو Response بين المستخدمين.

النطاقات المتأثرة:

• Tomcat 9.0.118 حتى 9.0.122؛
• Tomcat 10.1.55 حتى 10.1.60؛
• Tomcat 11.0.22 حتى 11.0.26.

يتطلب التعرض مسار HTTP/2 وAsync Processing المعني. حدد هل ينتهي HTTP/2 عند Tomcat أم Proxy أمامه، وهل تستخدم التطبيقات Async Servlets أوServlet 3 Async APIs أوReactive Bridges أوLong Polling. قد يقلل إنهاء البروتوكول في Proxy الوصول المباشر، لكنه لا يثبت أن كل الاتصالات الداخلية ومسارات الأخطاء تتجنب الخلل.

حدث أولًا. ثم اختبر ترافيك HTTP/2 واقعيًا في Canary مع مستخدمين متزامنين وأخطاء تطبيق آمنة متعمدة. تحقق أن Correlation IDs وAuthenticated Principals وResponse Bodies وCache Keys وTracing Spans تبقى مرتبطة بالطلب الأصلي. هذا اختبار صحة وخصوصية وليس بديلًا عن الإصدار المصحح.

CVE-2026-103119: اختلاط استجابة AJP في Tomcat 11

تؤثر CVE-2026-103119 في Tomcat 11.0.0-M25 حتى 11.0.26. قد يقسم Buffer Under-read أثناء Large Non-blocking Write جسم الاستجابة بين طلب AJP الحالي والطلب التالي على الاتصال نفسه. وتذكر Apache أن النتيجة المرجحة هي فشل الطلب الثاني مع احتمال تسرب بيانات من الاستجابة الأولى إليه.

تهم المشكلة البيئات التي تشغل AJP وتستقبل عبره ترافيك. احصر Connectors ذات protocol="AJP/1.3" أو ما يعادلها، وProxy Modules التي تستخدمها، وإعادة استخدام الاتصالات، وBind Addresses، وسياسة secretRequired. عطّل AJP غير المستخدم؛ وإن كان مطلوبًا فحدّثه واربطه بشبكة موثوقة مع Secret. تقليل الوصول الشبكي لا يصلح Buffer Bug.

لا تولد Payloads عدائية ضخمة ضد الإنتاج. تحقق من الإصلاح في بيئة مضبوطة باستخدام استجابات Async كبيرة عادية، وطلبات متزامنة، وعلامة فريدة لكل Response، وAssertions تمنع انتقال أي علامة بين الطلبات.

الإصدار يتضمن إصلاحات Low أيضًا

تتضمن الإصدارات نفسها مشكلات Low مختلفة حسب الفرع، مثل فشل TLS 1.3 المتقطع، وتلوث HTTP/2 Trailer، واستمرار معالجة JSP بعد JSTL Redirect، واستمرار التشغيل خارج FIPS المطلوب عند فشل OpenSSL-FFM FIPS. ويصلح Tomcat 9 أيضًا سباق صلاحيات APR Unix Domain Socket.

قد تكون هذه المشكلات مهمة تشغيليًا في البيئات المنظمة أومتعددة المستأجرين حتى مع تصنيف Low. استهلك الإصدار المصحح كاملًا بدل انتقاء ثلاث إصلاحات فقط. Apache لا توفر Binary Patches؛ العلاج المعتاد إصدار مدعوم أوVendor Package موثق يعيد Backport للـcommits المعنية.

احصر الإصدار الذي يعمل فعلًا

ابدأ من Process وArtifact وليس Package Manifest على Build Workstation:

$CATALINA_HOME/bin/version.sh
java -cp "$CATALINA_HOME/lib/catalina.jar"   org.apache.catalina.util.ServerInfo

في Containers نفذ الفحص على Image Digest الثابتة نفسها التي ينشرها Orchestrator. قد يشير Tag متحرك إلى Build جديدة بينما تظل Pods قديمة تشغل Digest ضعيفة. وافحص Tomcat المضمن داخل Executable JARs؛ version.sh على Host لا يحدد خادمًا مدمجًا خاصًا داخل Artifact.

أنشئ سجلًا لكل Service يشمل Owner والبيئة وفرع Tomcat والإصدار الكامل وArtifact Digest وJava Version ونوع Realm وSASL Mechanism ونقطة إنهاء HTTP/2 واستخدام Async Servlet وحالة AJP وحالة النشر. الإعداد المجهول يحتاج تحقيقًا، لا تصنيفًا تلقائيًا بأنه غير متأثر.

مسار تحديث آمن

1. اختر فرعًا مصححًا: 9.0.123 أو10.1.61 أو11.0.27. اعتبر Distribution Backport صالحًا فقط عندما يربط Vendor Advisory رقم Build بالـCVEs.
2. أعد البناء بثبات: حدث Base Image أوServer Package، وأعد بناء التطبيق، وسجل Digest الجديدة. احذف نسخ lib JARs التي قد تطغى على مكتبات الخادم المصححة.
3. قارن الإعداد: راجع Connectors وRealms وValves وTLS وAJP وHTTP/2 وSessions وJVM Flags. لا تستبدل أسرار الإنتاج بقيم افتراضية.
4. نفذ اختبارات توافق: غط فشل Login وRole Mapping وAsync Errors وHTTP/2 Concurrency وProxy Headers وSessions وUploads وWebSockets وGraceful Shutdown.
5. استخدم Canary: وجّه نسبة صغيرة إلى الصورة المصححة وراقب Authentication Failures و5xx وHTTP/2 Resets وAJP Errors وLatency وSession Behavior.
6. استبدل Fleet: حدّث كل Replicas وJobs وStandby Nodes وAutoscaling Templates، واسحب الاتصالات القديمة عند خطر Response Mix-up.
7. تحقق: اقرأ Version وImage Digest من كل Instance عاملة. تأكد أن Load Balancer أوScheduled Job أوRollback Target أوDR Pool لا يعيد نسخة قديمة.

التحقق في Kubernetes وContainers

تحقق من Image المعلنة ومن Image ID التي تعمل:

kubectl -n prod get deploy,sts -o wide
kubectl -n prod get pods   -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image,ID:.status.containerStatuses[*].imageID'

ثم نفذ فحص الإصدار عبر مسار إداري معتمد داخل Pods ممثلة. لا تنشر Endpoint يكشف Version للعامة لأجل هذا التحديث. إذا كان التطبيق يضمن Tomcat، فاقرأ Build Metadata أوEmbedded Server Library بدل افتراض أن Base Image تملك Runtime.

اكتمال Deployment Rollout لا يكفي إذا ظلت CronJobs أوJobs أوHPA Templates أوRegion أخرى تشير إلى Digest قديمة. افحص مصدر النشر وحالة Cluster الحية.

التحقيق دون ادعاء اختراق

تثبت نشرات المورد شروط الثغرة، لا الاستغلال في بيئتك. استخدم ثلاثة تصنيفات:

• Vulnerable Exposure: وُجد إصدار متأثر وإعداد يمكن الوصول إليه.
• Attempted Exploitation: تظهر Logs أوTelemetry سلوكًا مصممًا لتشغيل المسار الضعيف.
• Confirmed Compromise: تثبت أدلة مستقلة مصادقة غير مصرح بها أوCross-user Disclosure أوProcess Control أوأثرًا لاحقًا.

بالنسبة إلى JNDIRealm، احفظ Authentication Outcomes وDirectory Bind Results ومعرفات المستخدمين وSource Metadata وRole Decisions وتاريخ الإعداد. ابحث عن Sessions ناجحة مع Credential Validation فاشل أوغائب، لكن راع Service Accounts وSSO وRetries وClock Skew وLog Sampling قبل الاستنتاج.

بالنسبة إلى HTTP/2 أوAJP، اربط Request IDs وPrincipals وConnection IDs وStream IDs وTrace IDs وResponse Hashes وأخطاء 5xx وبلاغات المستخدمين. قد ينتج Log Mismatch منفرد من عيب Instrumentation؛ عززه بأدلة التطبيق والProxy والشبكة والأعمال.

إذا دلت الأدلة على مصادقة غير مصرح بها أوتسرب بين مستخدمين، فاحفظ Logs والأدلة المتطايرة وفق السياسة، وحدد الهويات المتأثرة، وألغ Sessions، ودوّر Credentials القابلة للوصول، وأشرك Incident Response. Restart قد يعيد التوافر لكنه لا يثبت الاحتواء.

أفضل الممارسات وAnti-patterns

أفضل الممارسات

• حدّث إلى فرع مدعوم ومصحح وسجل Artifact Digest الثابتة.
• حافظ على Inventory حي لإصدار Tomcat وConnectors وRealm ونقطة إنهاء الترافيك.
• عطّل AJP ما لم يكن مطلوبًا؛ وإن استُخدم فقيّد Bind واطلب Secret.
• اختبر Negative Authentication وعزل الطلبات أثناء Canary.
• احتفظ بمعرفات Request وPrincipal وConnection وStream وTrace للتحقيق دون تسجيل أسرار.
• اختبر Rollback، لكن اجعل Artifacts الرجوع مصححة أيضًا.

Anti-patterns

• وصف كل نسخة متأثرة بأنها مخترقة.
• اعتبار Reverse Proxy أوWAF أوPrivate Subnet Patch.
• فحص Maven أوOS Package Metadata فقط بينما Tomcat مدمج أومنسوخ يخدم الترافيك.
• تحديث Mutable Tag دون استبدال كل Pods القديمة.
• تعطيل HTTP/2 أوAJP مؤقتًا ونسيان مشكلة JNDIRealm الواسعة.
• نشر Diagnostics تكشف الإصدار الدقيق أوالأسرار.

خلاصة تنفيذية

1. احصر كل Tomcat مستقل ومدمج.
2. حدث إلى 9.0.123 أو10.1.61 أو11.0.27.
3. أعط الأولوية لـJNDIRealm مع non-GSSAPI SASL، وHTTP/2 مع Async Servlet، وAJP في Tomcat 11.
4. أعد بناء Images ثابتة واختبر المصادقة وأخطاء Async وحدود HTTP/2 وAJP.
5. استبدل كل Instance وتحقق من Version وDigest الفعليتين.
6. احفظ الأدلة وافصل التعرض ومحاولة الاستغلال والاختراق المؤكد.
7. احذف Rollback Images وAutoscaling Templates الضعيفة.

اقرأ أيضًا: دليل تحديث Node.js في أكتوبر 2026، ودليل PHP2Shell، وتدوير شهادات TLS في Kubernetes، ومكتبة المقالات الهندسية.

المراجع الأساسية

• نشرات Apache Tomcat 9 الأمنية
• نشرات Apache Tomcat 10 الأمنية
• نشرات Apache Tomcat 11 الأمنية
• اعتبارات Apache Tomcat الأمنية
• مرجع AJP Connector
• مرجع Realm
• رخصة Unsplash
• Taylor Vick — صورة مركز البيانات المرخصة

إعداد: Noor Yasser