الحديث عن تقييد تشغيل ADB من داخل جهاز Android نفسه لا يستند حتى الآن إلى إعلان رسمي من Google. مصدر القصة هو طلب عام في Google IssueTracker، ومقال نشره Kitsumed في 20 يوليو، ونقاش واسع على Hacker News. أهميته أنه يكشف توتراً حقيقياً بين تأمين منصة الهاتف وحق المطور أو المستخدم المتقدم في التحكم بأدواته.

هاتف Android يعرض ADB محلياً وتصحيحاً لاسلكياً وضوابط أمان

الفكرة الأصلية في الطلب منطقية: أن يستطيع adbd الاستماع على واجهة شبكة أو عنوان IP محدد، بدلاً من الظهور على كل الواجهات المتاحة. بعد CVE-2026-0073 يصبح هذا مطلباً أمنياً مفهوماً. يصف NVD الثغرة بأنها تجاوز محتمل للمصادقة المتبادلة في Wireless ADB، قد يسمح بتنفيذ كود كمستخدم shell من شبكة قريبة.

الخلاف يبدأ عند احتمال حصر adbd في واجهة Wi-Fi باسم wlan0. هذا قد يحمي من بعض المخاطر، لكنه قد يكسر الاتصال المحلي عبر 127.0.0.1. هذا الاتصال هو أساس on-device ADB: تشغيل عميل ADB على الهاتف نفسه، عبر Termux أو مكتبة داخل تطبيق، ثم الاتصال بخدمة ADB المحلية.

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

الحل الأفضل ليس قطع loopback بالكامل. النموذج الأنسب هو إعدادات افتراضية محافظة، وخيار واضح لاختيار الواجهة داخل Developer Options، وتحذير دائم عند تشغيل الوضع الخطر، وسياسات MDM للأجهزة المؤسسية، وسماح صريح لمن يحتاج إلى 127.0.0.1 أو tun0 أو eth0 على جهاز تطوير.

لا يوجد تغيير نهائي مؤكد في Android حتى الآن. لكن على الفرق التي تعتمد على Shizuku أو libadb-android أو adb connect 127.0.0.1 أو ADB عبر VPN و Ethernet أن توثق ذلك الآن وتختبر بدائلها. مسارات التصحيح التي كانت تبدو تفاصيل تقنية أصبحت جزءاً من سياسة الأمان والتحكم في المنصة.