تصحيح PaperCut الثاني مطلوب فورًا، لكنه قد يعطل SAML

أبقت PaperCut في 29 أغسطس 2026 على توصيتها بتثبيت Emergency Patch Release 2 لجميع عملاء PaperCut NG وPaperCut MF، بمن فيهم من ركّبوا التصحيح الطارئ الأول. وفي التحديث نفسه، قالت النشرة الأمنية الرسمية لـPaperCut إن بعض العملاء أبلغوا عن عدم عمل SAML والبحث الخارجي بأرقام Card/ID كما هو متوقع بعد تطبيق التصحيح، وإن التحقيق ما زال جاريًا.

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

ما الذي تغيّر مع Release 2؟

يشمل نطاق التأثر جميع إصدارات PaperCut NG وPaperCut MF، لكن حزم Release 2 متاحة للفروع 24 و25 و26 على Windows وLinux وmacOS. ويحدد تنبيه المركز الكندي للأمن السيبراني الأنظمة غير المزودة بـRelease 2 ضمن الفروع الثلاثة بوصفها متأثرة؛ أما العملاء على الإصدار 23 أو أقدم فالمسار الموصى به لهم هو الترقية إلى أحدث إصدار.

تعالج الحزمة ثغرتين مترابطتين. تسمح CVE-2026-81578، في ظروف محددة، لطلبات بعيدة غير موثقة بتعديل بعض إعدادات النظام قبل اكتمال التحقق من الوصول. أما CVE-2026-82078 فتتعلق بتحميل ديناميكي غير آمن للفئات داخل أدوات اتصال قواعد البيانات، وقد تتيح تنفيذ شيفرة Java موجودة في مسار فئات التطبيق إذا استطاع المهاجم التحكم في إعدادات الاتصال.

لا يقتصر نطاق التحديث على Application Server الأساسي. يجب نقل Site Servers والخوادم الثانوية أو خوادم الطباعة إلى إصدار مصحح أيضًا، في حين أن Print Deploy وMobility Print غير متأثرين بهاتين الثغرتين ولا يحتاجان إلى هذه الحزمة.

شجرة القرار: التعرض أولًا ثم الإصدار

الخادم المتاح من الإنترنت يحتاج إلى احتواء شبكي فوري، حتى إذا لم تظهر تنبيهات مريبة. ويوصي تنبيه NHS England المنشور في 28 أغسطس بتطبيق Release 2 في أسرع وقت، وإزالة التعرض العام أو حصر واجهات Application Server في عناوين IP موثوقة عندما يتعذر التصحيح فورًا.

1. الخادم مكشوف للإنترنت: احصر واجهاته بعناوين داخلية أو موثوقة عبر الجدار الناري أو ضوابط الشبكة، ثم ثبّت Release 2 وافحص الفترة السابقة للتحديث.
2. الخادم غير مكشوف مباشرة: راجع الوكلاء العكسيين وقواعد نشر الويب وتحويل المنافذ للتأكد من واقع التعرض، ثم طبّق Release 2. غياب واجهة عامة لا يخرج الإصدار من نطاق التأثر.
3. التصحيح الأول مثبت: استبدله بـRelease 2؛ فالحزمة الثانية تتضمن تحصينًا إضافيًا، ولا يُعد وجود الحزمة الأولى إغلاقًا للحادث.
4. الإصدار 24 أو 25 أو 26: استخدم حزمة المنتج ونظام التشغيل المطابقين. إذا كان الإصدار 23 أو أقدم، فاعزل الواجهات وخطط للترقية بدل انتظار حزمة مخصصة لذلك الفرع.

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

مؤشرات الاختراق المنشورة محدودة

تشمل المؤشرات الأولية تنبيهات كشف التسلل أو حماية النقاط الطرفية أو مراقبة الشبكة المرتبطة بـApplication Server، وخصوصًا نشاط ما بعد الاستغلال الصادر من العملية pc-app.exe. ويستحق ملف server.log فحصًا مستقلًا إذا اختفى أو حُذف أو أصبح أقصر بصورة غير متوقعة.

تتضمن رسائل السجل المحددة: “ERROR No suitable driver found for jdbc:no:x” و“ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST”. لكن غياب هذه العلامات لا يثبت سلامة الخادم؛ فالقائمة المنشورة أولية، ويجب مقارنتها بخط زمني للوصول إلى الواجهات وتنبيهات الشبكة والنقاط الطرفية وحالة السجلات والنسخ الاحتياطية.

عند وجود اشتباه معقول بالاختراق، يتمثل المسار المعلن في تأمين النسخ الاحتياطية الحالية، ومسح Application Server وإعادة بنائه بالكامل، ثم استعادة نسخة نظيفة تسبق السلوك المريب وتفعيل إجراءات الاستجابة للحوادث. لا تكفي إعادة تثبيت التصحيح فوق خادم يُحتمل أن المهاجم احتفظ بموطئ قدم داخله.

لماذا قد يتعطل SAML والبحث بالبطاقات؟

البلاغات المنشورة لا تعني أن SAML سيفشل في كل بيئة، ولا تثبت أن Release 2 هو السبب في كل عطل يظهر بعد التثبيت. المؤكد حتى تحديث 29 أغسطس هو وجود بلاغات من بعض العملاء عن خلل في SAML والبحث الخارجي بأرقام Card/ID بعد التصحيح، مع استمرار التحقيق ومن دون سحب توصية التحديث.

بعد التثبيت، ينبغي اختبار تسجيل الدخول عبر SAML من البداية إلى النهاية وفق ضوابط المؤسسة، بما يشمل حسابًا عاديًا وحسابًا إداريًا ومسار العودة من مزود الهوية. وفي المدارس والجامعات التي تعتمد البطاقات لتحرير مهام الطباعة، يلزم اختبار البحث الفعلي عن البطاقة؛ فبقاء الإعداد ظاهرًا في لوحة الإدارة لا يثبت أن عملية البحث تعمل.

أصبح البحث الخارجي برقم البطاقة متوقفًا افتراضيًا. تحتاج البيئات التي تستخدمه إلى إضافة security.card-number-lookup.enabled=Y إلى ملف server/security.properties، ثم إعادة تشغيل Application Server. وإذا كان اتصال SQL Server يستخدم برنامج تشغيل Sourceforge jTDS القديم، فالتوصية الأولية هي الانتقال إلى أحدث Microsoft SQL JDBC Driver مدعوم، مع بقاء احتمال ألا يحل ذلك جميع الحالات.

ما الذي يجب تأكيده قبل إعادة الخدمة؟

• وجود Release 2، وليس التصحيح الأول، على Application Server وكل Site Server وخادم ثانوي معني.
• بقاء واجهات الويب محصورة في عناوين موثوقة إلى أن تُراجع الحاجة الفعلية إلى أي وصول عام.
• فحص pc-app.exe وserver.log ورسائل الخطأ المنشورة، مع حفظ الأدلة قبل أي إعادة بناء.
• نجاح تسجيل الدخول عبر SAML للحسابات والمسارات التي تستخدمها المؤسسة فعليًا.
• نجاح البحث الخارجي بالبطاقات بعد مراجعة الخاصية وبرنامج تشغيل JDBC، إذا كانت الميزة مستخدمة.

حتى 30 أغسطس 2026، ظل Release 2 هو التصحيح الطارئ المطلوب للفروع 24 و25 و26، واستمر العمل على إصدار رسمي. كما بقي التحقيق في أعطال SAML والبحث بالبطاقات مفتوحًا؛ لذلك لا يبرر احتمال العطل تأجيل الاحتواء والتحديث، لكنه يجعل اختبار المصادقة والبطاقات وفحص آثار الاختراق شروطًا لإعادة الخدمة الطبيعية.