ثغرات NativePHP Mobile: حدّث إلى 4.6.1 وأعد بناء تطبيقك

نشر فريق NativePHP سبعة تحذيرات أمنية لحزمة nativephp/mobile وإضافة mobile-file. إليك ما تعنيه الثغرات وكيف تحدّث وتعيد بناء تطبيقك قبل نشره من جديد.

إذا كنت تبني تطبيقات iOS وAndroid بـ Laravel عبر NativePHP، فهذا التحذير يخصك مباشرة. الإصلاح لا يصل المستخدمين بتحديث composer وحده: بعض الإصلاحات في الكود الأصلي (native) وتحتاج إلى إعادة بناء التطبيق ورفع نسخة جديدة إلى المتجرين. في هذا المقال نشرح الثغرات، ومن يتأثر بها، وخطوات الترقية، وما تغيّر في السلوك.

ما الذي حدث؟

في 26 أكتوبر 2026 نشر NativePHP سبعة تحذيرات (advisories) تخص حزمة nativephp/mobile وإضافة nativephp/mobile-file، حسب تقرير Laravel News. خمسة منها بدرجة High واثنان بدرجة Moderate. وبحسب التقرير، النسخ 1.x و2.x انتهى دعمها ولن تُرقَّع.

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

ثغرات NativePHP Mobile السبع باختصار

كيف تعمل أخطر ثغرة؟

بحسب نص التحذير الأول على GitHub، يتأثر الإصدار من 4.5.0 حتى ما قبل 4.6.1. ملف routes/api.php كان بلا middleware، فأي JavaScript يعمل على أصل التطبيق نفسه (بسبب XSS أو سكربت مخترق) يستطيع إرسال POST إلى /_native/api/call والوصول إلى أي دالة مسجّلة في الجسر.

ثم إن الـ task ID كان يُدرج داخل نص PHP تقيّمه قناة المهام غير المتزامنة، فإذا لم يكن UUID أمكن حقن كود. وكان بالإمكان أيضًا إرسال اسم حدث وحمولة اعتباطية إلى حلقة الشاشة الأصلية، مثل حدث تنقّل.

الإصلاح يفرض أن يكون الـ task ID بصيغة UUID في طبقات Swift وKotlin وC، ويرفض الجسر أي استدعاء يبدأ بالبادئة AsyncTask.. الفحص الأخير موجود في حزمة Composer، أما الفحوص الأصلية فتحتاج إلى إعادة بناء.

الحل المؤقت الذي يذكره التحذير: لا تضمّن JavaScript غير موثوق أو من طرف ثالث في الـ web view إلى أن تحدّث.

تحديثات PHP المرافقة

أعاد NativePHP بناء كل ملفات PHP الثنائية بعد إصدارات PHP الأمنية في 21 أكتوبر (الثغرتان CVE-2026-109618 وCVE-2026-109619 بدرجة 9.2، والإصلاح في PHP 8.5.12 و8.4.27 و8.3.36) وسحب النسخ المعرّضة. وأصبحت الملفات الثنائية تُنشر مع hashes وتواقيع تتحقق منها الأدوات عند التنزيل. هذا التحقق موجود في nativephp/desktop 2.4.0 وnativephp/mobile 3.3.11، وسيصل إلى nativephp/mobile 4.7.0 خلال أيام بحسب التقرير. لتفاصيل ثغرتي PHP نفسهما راجع مقالنا السابق عن تحديث PHP الأمني.

هل تطبيقك متأثر؟

اسأل نفسك ثلاثة أسئلة عملية:

1. أي إصدار تستخدم؟ نص التحذير الأول يحدد المتأثر بنطاق 4.5.0 وما قبل 4.6.1. أما بقية التحذيرات فلم يذكر التقرير نطاقات إصداراتها المتأثرة بدقة، لذلك الأسلم أن تعدّ أي إصدار أقدم من 4.6.1 (أو 3.3.11 على فرع 3.x) غير مرقّع، وأن تراجع صفحة كل تحذير على GitHub.
2. هل يعمل في الـ web view كود لا تتحكم به؟ مكتبات إعلانات أو تحليلات أو سكربتات تُحمَّل من CDN أو محتوى مستخدمين يُعرض دون تعقيم، كلها طرق محتملة لتنفيذ JavaScript على أصل التطبيق.
3. هل تستخدم mobile-file؟ إن كنت على فرع 4.x فأزلها بعد الترقية، وإن كنت على 3.x فحدّثها إلى 1.0.3.

وإن كنت تبني نسخ Android release فتذكّر أن تسريب session cookie وXSRF token إلى logcat يعني أن النسخ المنشورة سابقًا قد سرّبت هذه القيم إلى سجلات الجهاز، فالتحديث وإعادة البناء يوقفان ذلك لكنهما لا يعالجان ما سُجّل بالفعل.

خطوات الترقية

1. حدّث nativephp/mobile إلى 4.6.1، أو إلى 3.3.11 إن كنت على فرع 3.x.
2. على فرع 4.x: أزل nativephp/mobile-file لأن الحزمة الأساسية صارت توفّر File.Move وFile.Copy. على فرع 3.x حدّث الإضافة إلى 1.0.3.
3. شغّل php artisan native:install --force ثم أعد بناء التطبيق.
4. ارفع النسخة الجديدة إلى App Store وGoogle Play.
5. لتطبيقات سطح المكتب: حدّث إلى nativephp/desktop 2.4.0 ثم نفّذ composer remove nativephp/php-bin لأنها حزمة متقادمة.

composer require nativephp/mobile:^4.6.1
php artisan native:install --force

تغييرات في السلوك قد تكسر كودك

• الأحداث المرسلة عبر /_native/api/events يجب أن تطبّق الواجهة Native\Mobile\Events\Contracts\DispatchableFromNative. إن كنت تكتب إضافات فأضف هذه الواجهة إلى أصناف أحداثك.
• حمولات المهام غير المتزامنة صارت مشفّرة وموثّقة بمفتاح التطبيق (app key). التطبيقات بلا app key لن تستطيع إطلاق مهام غير متزامنة.

ماذا نتعلم من هذه الحادثة؟

• لا تثق بالـ web view: عامله كأي صفحة ويب معرّضة لـ XSS. أي مسار API داخلي يجب أن يتحقق من مصدر الطلب وصيغة مدخلاته.
• قلّل سكربتات الطرف الثالث داخل تطبيقاتك الهجينة، فهي شرط الاستغلال في أغلب هذه الثغرات.
• لا تستخدم unserialize() على بيانات غير موثقة. الحل هنا كان تشفير الحمولة وتوثيقها بمفتاح التطبيق.
• التحديث ليس تحديث Composer فقط في التطبيقات الأصلية: خطط لإعادة البناء والنشر على المتجرين، وتذكّر أن مراجعة المتجر قد تستغرق وقتًا.

الخلاصة

إن كان تطبيقك يعتمد على NativePHP Mobile فحدّث اليوم إلى 4.6.1 (أو 3.3.11)، وأعد البناء، وارفع نسخة جديدة، وراجع الواجهة DispatchableFromNative وإعداد app key. وإن كنت على 1.x أو 2.x فلا ترقيع لك: انتقل إلى نسخة مدعومة.

المصادر

• NativePHP Mobile Security Advisories – Laravel News
• GHSA-9884-fw9c-mq85 – GitHub Security Advisory