- شناسه CVE-2026-0073 :CVE
- CWE-303 :CWE
- yes :Advisory
- منتشر شده: می 4, 2026
- به روز شده: می 4, 2026
- امتیاز: 8.8
- نوع حمله: Authorization Bypass
- اثر گذاری: Remote code execution(RCE)
- حوزه: تلفن همراه
- برند: Google
- محصول: Android
- وضعیتPublished :CVE
- Yes :POC
- وضعیت آسیب پذیری: patch شده
چکیده
آسیبپذیری در مکانیزم احراز هویت Wireless ADB در سیستمعامل اندروید ناشی از یک خطای منطقی در فرآیند اعتبارسنجی گواهی TLS در کامپوننت adbd است. این ضعف به مهاجم در همان شبکه یا در مجاورت شبکهای دستگاه اجازه میدهد بدون نیاز به تعامل کاربر و بدون نیاز به سطح دسترسی اولیه، فرآیند احراز هویت Wireless Debugging را دور زده و به ADB shell دستگاه دسترسی پیدا کند. مهاجم در صورت اکسپلویت موفق میتواند دستورات دلخواه را از راه دور اجرا کرده، به اطلاعات دستگاه دسترسی پیدا کند و در برخی سناریوها سطح دسترسی خود را افزایش دهد.
توضیحات
آسیبپذیری CVE-2026-0073 در کامپوننت adbd (Android Debug Bridge Daemon) و مشخصاً در تابع adbd_tls_verify_cert در فایل auth.cpp رخ میدهد و ناشی از پیادهسازی نادرست مکانیزم احراز هویت مطابق با CWE-303 است. این ضعف در فرآیند اعتبارسنجی گواهیهای TLS (پروتکل رمزنگاری برای احراز هویت و ارتباط امن) در قابلیت Wireless ADB وجود دارد و باعث میشود مکانیزم احراز هویت متقابل (Mutual Authentication) میان کلاینت ADB و دستگاه اندروید بهدرستی عمل نکند.
در حالت عادی، Wireless ADB تنها به سیستمهایی اجازه اتصال میدهد که قبلاً Pair شده یا توسط کاربر تأیید شده باشند؛ اما وجود خطای منطقی در فرآیند بررسی گواهیها باعث میشود مهاجم بتواند احراز هویت را دور زده و بدون نیاز به تأیید کاربر به سرویس ADB متصل شود. بررسیها و PoCهای منتشرشده نشان میدهد این ضعف با نحوه مقایسه کلیدهای رمزنگاری در تابع EVP_PKEY_cmp() مرتبط است؛ بهطوریکه در برخی شرایط، adbd هنگام مقایسه نوع کلیدها دچار Type Confusion شده و گواهیهایی با الگوریتمهایی مانند EC P-256 یا Ed25519 را در برابر کلیدهای RSA معتبر تلقی میکند.
این ضعف امنیتی بهسادگی قابل خودکارسازی است. مهاجم تنها کافی است در همان شبکه Wi-Fi قربانی قرار داشته باشد و قابلیت Wireless Debugging روی دستگاه فعال باشد. در چنین شرایطی، مهاجم میتواند با استفاده از کلاینتهای اصلاحشده ADB یا ابزارهای سفارشی، به پورت Wireless ADB متصل شده و بدون نیاز به تعامل کاربر، ADB shell دریافت کند. این حمله از نوع Zero-Click محسوب میشود زیرا قربانی نیازی به پذیرش اتصال یا انجام هیچ اقدام اضافی ندارد.
پس از موفقیت در حمله، مهاجم به سطح دسترسی shell user دست پیدا میکند. اگرچه این سطح دسترسی معادل root نیست اما امکان اجرای طیف گستردهای از عملیات را فراهم میسازد؛ از جمله اجرای دستورات سیستمی، نصب برنامه، دسترسی به بخشی از دادهها، استخراج فایلها، تغییر برخی تنظیمات و تعامل مستقیم با سرویسهای دستگاه. همچنین در صورت وجود آسیبپذیریهای تکمیلی، این دسترسی میتواند برای افزایش سطح دسترسی (Privilege Escalation) و تصاحب کامل دستگاه مورد استفاده قرار گیرد.
این ضعف بهویژه در محیطهای توسعه، آزمایشگاههای تست، زیرساختهای سازمانی و سناریوهای خودکارسازی خطرناک است؛ زیرا در بسیاری از این محیطها قابلیت Wireless Debugging بهصورت دائم فعال باقی میماند. مهاجم میتواند با اسکن پورتهای پویا Wireless ADB، دستگاههای آسیبپذیر را شناسایی کرده و اتصال غیرمجاز برقرار کند. برخی کدهای اثبات مفهومی (PoC) منتشرشده حتی قابلیت اسکن شبکه، شناسایی خودکار پورت، اجرای دستورات از راه دور و ایجاد shell تعاملی را نیز پیادهسازی کردهاند که این موضوع ریسک سوءاستفاده عملیاتی از آسیبپذیری را بهطور قابلتوجهی افزایش میدهد.
طبق بردار CVSS، این حمله از طریق شبکه مجاور (Adjacent Network) انجام میشود، مهاجم به سطح دسترسی اولیهای نیاز ندارد و اکسپلویت بدون تعامل کاربر امکانپذیر است. همچنین تأثیر آسیبپذیری بر محرمانگی (Confidentiality)، یکپارچگی (Integrity) و دسترسپذیری (Availability) در سطح بالا ارزیابی شده است. این آسیبپذیری نسخههای Android 14، 15، 16 و 16-qpr2 را تحت تأثیر قرار میدهد و در بولتن امنیتی Android با Patch Level برابر 2026-05-01 برطرف شده است.
CVSS
| Score | Severity | Version | Vector String |
| 8.8 | HIGH | 3.1 | CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
شکل 1: تفسیر جدول CVSS
لیست محصولات آسیب پذیر
| Versions | Product |
| affected at 16-qpr2
affected at 16 affected at 15 affected at 14 |
Android |
لیست محصولات بروز شده
| Versions | Product |
| Security Patch Level 2026-05-01 and later | Android |
استفاده محصول در ایران
در این جدول، تعداد صفحات ایندکسشده در گوگل با دامنه .ir که Android را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.
| Approx. Usage in .ir Domain via Google (Total Pages) | Search Query (Dork) | Product |
| 5,480,000 | site:.ir “Android” | Android |
نتیجه گیری
این آسیبپذیری در مکانیزم احراز هویت Wireless ADB اندروید، امکان دورزدن کامل فرآیند احراز هویت و دستیابی به محیط ADB shell را بدون هیچگونه تعامل کاربری فراهم میکند. با توجه به انتشار PoCهای عمومی، احتمال سوءاستفاده گسترده از این ضعف، بهویژه در شبکههای سازمانی، محیطهای توسعه و آزمایشگاههای تست بسیار بالا است. برای کاهش ریسک و جلوگیری از نفوذ، اجرای اقدامات زیر ضروری است:
- بهروزرسانی فوری: تمامی دستگاههای اندروید باید با Patch Level مورخ 2026-05-01 یا نسخههای جدیدتر بهروزرسانی شوند. این اقدام اصلیترین و مؤثرترین راهکار مقابله با آسیبپذیری است.
- غیرفعالسازی Wireless Debugging: قابلیت Wireless Debugging را در صورت عدم نیاز بهطور کامل غیرفعال کنید تا سطح حمله کاهش یابد. فعال بودن دائم Wireless ADB ریسک نفوذ را بهشدت افزایش میدهد.
- محدودسازی دسترسی شبکه: دستگاههایی که Wireless ADB روی آنها فعال است نباید به شبکههای عمومی یا غیرقابل اعتماد متصل شوند. استفاده از شبکههای ایزوله و تفکیکشده (Network Segmentation) توصیه میشود.
- استفاده از ADB مبتنی بر USB: در محیطهای توسعه و تست، ترجیحاً از ADB مبتنی بر USB استفاده شود تا وابستگی به ارتباطات بیسیم و ریسک حملات مبتنی بر شبکه کاهش یابد.
- مانیتورینگ ترافیک شبکه: ارتباطات ADB و پورتهای پویا مرتبط با Wireless Debugging باید توسط سامانههای تشخیص نفوذ (IDS) و فایروالها مانیتور شوند تا تلاشهای مشکوک برای اتصال یا Pairing شناسایی گردد. همچنین بررسی مستمر لاگهای adbd میتواند در تشخیص فعالیتهای غیرعادی مؤثر باشد.
- محدودسازی دسترسی توسعهدهندگان: فعالسازی Developer Options و Wireless Debugging باید صرفاً برای کاربران مجاز، در بازههای زمانی محدود و بر اساس نیاز عملیاتی انجام شود.
- استفاده از سامانه مدیریت دستگاه همراه (MDM): در محیطهای سازمانی، سیاستهای امنیتی مبتنی بر MDM میتوانند فعالسازی Wireless Debugging را کنترل، محدود یا بهطور کامل غیرفعال کنند.
- تست امنیتی مستمر: دستگاهها و محیطهای اندروید باید بهصورت دورهای با ابزارهای ارزیابی امنیتی و اسکنرهای ADB مورد آزمایش قرار گیرند تا وجود پیکربندیهای ناامن یا سرویسهای Wireless Debugging فعال مشخص شود.
اجرای این اقدامات، بهویژه نصب فوری پچهای امنیتی و غیرفعالسازی Wireless ADB در محیطهای غیرضروری، میتواند احتمال سوءاستفاده از این آسیبپذیری و نفوذ به دستگاههای اندروید را بهطور قابلتوجهی کاهش دهد.
امکان استفاده در تاکتیکهای Mitre Attack (در زمان اجرای حمله)
Initial Access (TA0001)
مهاجم با قرار گرفتن در همان شبکه محلی (Wi-Fi) دستگاه هدف و اجرای یک اسکریپت (مانند adb_tls_exploit.py)، مستقیماً و بدون نیاز به احراز هویت، به دستگاه دسترسی پیدا میکند. این دسترسی از طریق پروتکل mDNS برای کشف پورت و سپس بهرهبرداری از نقص TLS حاصل میشود.
Execution (TA0002)
پس از موفقیت در bypass احراز هویت، مهاجم با ارسال فرمان OPEN “shell:” از طریق پروتکل ADB، یک شل (shell) با دسترسی کاربر «shell» (UID 2000) باز میکند و میتواند هر دستوری (مانند id, whoami, ls, cat) را روی دستگاه اجرا کند.
Persistence (TA0003)
پس از دسترسی، مهاجم میتواند با نصب یک برنامه مخرب (از طریق دستور pm install)، اضافه کردن یک کلید SSH به authorized_keys کاربر shell، و یا فعالسازی مجدد Wireless Debugging از راه دور (در صورت غیرفعال شدن)، دسترسی دائمی خود را در دستگاه فراهم کند.
Privilege Escalation (TA0004)
اگرچه دسترسی اولیه به سطح کاربر «shell» است، اما مهاجم میتواند از این دسترسی برای اجرای سایر اکسپلویتهای افزایش دسترسی محلی (LPE) به منظور دستیابی به سطح دسترسی ریشه (root) استفاده کند. وجود آسیبپذیریهای LPE در هسته لینوکس یا درایورهای دستگاه میتواند این امکان را فراهم کند.
Credential Access (TA0006)
پس از دسترسی به شل، مهاجم میتواند به پایگاه داده برنامهها (مانند فایلهای /data/data/)، کوکیهای مرورگر، رمزهای عبور ذخیره شده، و اطلاعات احراز هویت ذخیره شده در دستگاه دسترسی پیدا کند. همچنین میتواند پیامهای SMS، مخاطبین، و تماسها را استخراج کند.
Impact (TA0040)
بهرهبرداری موفق از این آسیبپذیری یک نقض کامل حریم خصوصی و امنیت دستگاه است. مهاجم با دسترسی به شل، قادر به نابودی محرمانگی، یکپارچگی و در دسترس بودن دادههای دستگاه است. این دسترسی میتواند منجر به سرقت اطلاعات حساس (نظیر پیامهای خصوصی، عکسهای شخصی، اسناد کاری، اطلاعات کارت بانکی، رمزهای عبور)، نصب بدافزار (مانند جاسوسافزار، باجافزار، و باتنت)، شنود مکالمات و پیامها، ردیابی موقعیت مکانی، و در نهایت از کار افتادن کامل دستگاه شود. در یک محیط سازمانی، این دسترسی میتواند منجر به نقض دادههای شرکتی، جاسوسی صنعتی، و دسترسی به شبکه داخلی شرکت گردد. اعتماد کاربران از بین رفته و سازمان با هزینههای سنگین ناشی از نقض دادهها، جریمههای قانونی (مانند GDPR) و خسارت به اعتبار خود مواجه خواهد شد.
منابع
- https://www.cve.org/CVERecord?id=CVE-2026-0073
- https://www.cvedetails.com/cve/CVE-2026-0073/
- https://source.android.com/docs/security/bulletin/2026/2026-05-01
- https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-0073
- https://vuldb.com/vuln/361009
- https://github.com/CryptReaper12/CVE-2026-0073
- https://github.com/0xBlackash/CVE-2026-0073
- https://github.com/tc4dy/CVE-2026-0073-PoC-Exploit
- https://nvd.nist.gov/vuln/detail/CVE-2026-0073
- https://cwe.mitre.org/data/definitions/303.html
گزارش اثبات آسیبپذیری CVE-2026-0073
اطلاعات آسیبپذیری
عنوان: نقص در احراز هویت TLS بیسیم ADB اندروید منجر به اجرای کد از راه دور
شناسه: CVE-2026-0073
وضعیت مشاوره: Advisory / Patch Available
امتیاز: CVSS: 8.8 (High)
محصول: Google Android Debug Bridge – adbd
محصول / نسخههای آسیبپذیر
در نسخههای زیر:
- Android نسخه 14
- Android نسخه 15
- Android نسخه 16
- تمام دستگاههایی که قابلیت Wireless Debugging روی آنها فعال است (Android 11+)
محیطهای درگیر
- تمام کاربرانی که گزینه Wireless Debugging را در تنظیمات فعال کردهاند
- سازمانهایی که از دستگاههای اندروید در شبکههای داخلی استفاده میکنند
- محیطهای عمومی مانند فرودگاهها، کافهها، دفاتر اشتراکی با Wi-Fi مشترک
- مراکز درمانی که از تبلتهای اندرویدی برای امور حساس استفاده میکنند
کامپوننتهای آسیبپذیر
- adbd (Android Debug Bridge Daemon)
- فایل auth.cpp، حاوی تابع adbd_tls_verify_cert با نقص منطقی در تأیید گواهی TLS
- تابع EVP_PKEY_cmp از OpenSSL، بازگرداندن مقدار -1 در صورت عدم تطابق نوع کلید (RSA در مقابل EC)
- پروتکل STLS (Start TLS)، مسیر ارتباط بیسیم ADB در Android 11+
- پورت پویا (30000-50000)، پورت تصادفی که Wireless Debugging روی آن Listen میکند
ریشه مشکل (Root Cause Analysis)
ریشه اصلی این آسیبپذیری به نقص منطقی در تابع adbd_tls_verify_cert در فایل daemon/auth.cpp بازمیگردد.
این تابع مسئول تأیید گواهی کلاینت (client certificate) در فرآیند احراز هویت متقابل (Mutual TLS) هنگام اتصال از طریق Wireless Debugging است. سرور adbd کلید عمومی دستگاههای مجاز را در حافظه خود ذخیره کرده و در زمان اتصال، کلید ارائهشده توسط کلاینت را با آن مقایسه میکند.
تابع EVP_PKEY_cmp در صورت موفقیت (مطابقت کلیدها) مقدار 1، در صورت عدم مطابقت مقدار 0، و در صورت عدم تطابق نوع کلید(مثلاً مقایسه کلید RSA با کلید EC) مقدار -1 بازمیگرداند
در زبان C/C++، هر مقدار غیر از صفر در شرط if به عنوان true در نظر گرفته میشود. بنابراین:
- اگر کلیدها مطابقت داشته باشند → بازگشت 1 → true → احراز هویت موفق
- اگر کلیدها مطابقت نداشته باشند → بازگشت 0 → false → احراز هویت ناموفق
- اگر نوع کلیدها متفاوت باشد → بازگشت -1 → true → احراز هویت موفق (با وجود عدم تطابق کامل!)
مهاجم با ارائه یک گواهی EC P-256 (یا Ed25519) در مقابل دستگاهی که کلید مجاز آن از نوع RSA است، میتواند بدون داشتن هیچ کلید مجازی، احراز هویت را با موفقیت پشت سر بگذارد و در همان شبکه محلی (Wi-Fi مشترک) میتواند بدون نیاز به تعامل کاربر، دسترسی شل به دستگاه پیدا کند
بخش آسیبپذیر
رفتار ناامن سیستم:
تابع adbd_tls_verify_cert هنگام مقایسه کلید عمومی مهاجم با کلیدهای مجاز ذخیرهشده، از EVP_PKEY_cmp استفاده میکند. این تابع در صورت عدم تطابق نوع کلید (RSA در مقابل EC) مقدار -1 بازمیگرداند که در شرط if به عنوان true ارزیابی شده و منجر به پذیرش نادرست احراز هویت میشود. در نتیجه، مهاجم بدون داشتن هیچ کلید مجازی، اتصال TLS را با موفقیت برقرار کرده و به شل دستگاه دسترسی پیدا میکند.
نحوه سوءاستفاده مهاجم:
- مهاجم در شبکه محلی (Wi-Fi) دستگاه هدف قرار دارد
- مهاجم پورت تصادفی Wireless Debugging را شناسایی میکند
- مهاجم یک اتصال TCP به آن پورت برقرار کرده و پیام CNXN (Connection Negotiation) ارسال میکند
- دستگاه هدف با پیام STLS (Start TLS) پاسخ داده و درخواست ارتقا به TLS 1.3 میکند
- مهاجم یک گواهی TLS با کلید عمومی از نوع EC P-256 (یا Ed25519) ارائه میکند
- تابع adbd_tls_verify_cert کلید EC مهاجم را با کلیدهای ذخیرهشده (معمولاً RSA) مقایسه میکند
- به دلیل عدم تطابق نوع، مقدار -1 بازمیگرداند که در شرط if به معنای «مطابقت» تفسیر میشود
- دستگاه احراز هویت را تأیید کرده و یک شل (shell) در اختیار مهاجم قرار میدهد
- مهاجم میتواند دستورات دلخواه اجرا کند، فایلها را استخراج کند، یا بکدور دائمی نصب نماید
نقش این آسیبپذیری در زنجیره حمله
این آسیبپذیری یک نقطه ورود اولیه (Initial Access) بسیار خطرناک در زنجیره حمله محسوب میشود. با توجه به نمره CVSS 8.8 (بالا)، ماهیت بدون نیاز به احراز هویت (Zero-Click)، و نیاز صرف به حضور در همان شبکه محلی، مهاجم میتواند بدون هیچ تعامل کاربری، کنترل کامل دستگاه اندرویدی را در دست گیرد. دسترسی به adbd با سطح دسترسی شل کاربر (shell user) و در عمل با دسترسی ریشه (root) از طریق دستور su یا دسترسی مستقیم به دستورات سیستمی، عملاً به معنای نقض کامل محرمانگی (Confidentiality) و یکپارچگی (Integrity) دستگاه است.
پیشنیازهای بهرهبرداری (Prerequisites)
- مهاجم باید در همان شبکه محلی دستگاه هدف قرار داشته باشد (Wi-Fi مشترک)
- قابلیت Wireless Debugging باید در دستگاه هدف فعال باشد
- مهاجم باید پورت که دستگاه روی آن Listen است را بداند
- دستگاه باید از نسخههای آسیبپذیر Android (14، 15، 16، یا 16-QPR2) استفاده کند
رفتار مورد انتظار در حالت امن (Expected Secure Behavior)
- تابع adbd_tls_verify_cert باید به جای تکیه بر مقدار بازگشتی EVP_PKEY_cmp در شرط if، مقدار بازگشتی را به صورت صریح با 1 مقایسه کند
- کلیدهای عمومی از نوعهای مختلف (RSA در مقابل EC) هرگز نباید به عنوان “مطابقت” پذیرفته شوند
- احراز هویت باید تنها در صورت تطابق کامل کلیدها (نوع و مقدار) موفق باشد
- در صورت بروز خطا یا شرایط غیرمنتظره، اتصال باید به طور پیشفرض رد شود
راهکارها و کاهش ریسک (Mitigation / Patch Guidance)
اقدامات فوری برای کاهش ریسک:
- نصب فوری به روزرسانی امنیتی
- غیرفعال کردن Wireless Debugging در تنظیمات، هنگام عدم استفاده
- محدود کردن دسترسی به شبکههای Wi-Fi عمومی برای دستگاههای حساس
- پایش مداوم لاگهای دستگاه برای شناسایی اتصالات ADB غیرمجاز
اقدامات کوتاهمدت / میانمدت برای کاهش ریسک:
- پیادهسازی Network Segmentation برای جداسازی دستگاههای اندرویدی از شبکههای داخلی حساس
- آموزش کاربران در خصوص خطرات فعال نگه داشتن Wireless Debugging
- استفاده از راهکارهای MDM (Mobile Device Management) برای اعمال سیاستهای امنیتی و اجباری کردن بهروزرسانیها
- انجام اسکن دورهای شبکه برای شناسایی دستگاههای آسیبپذیر و پورتهای ADB باز
اقدامات بلندمدت برای کاهش ریسک:
- پیادهسازی فرآیندهای خودکار بهروزرسانی امنیتی در سازمان
- بازبینی و سختگیری در سیاستهای فعالسازی قابلیتهای توسعهدهنده روی دستگاههای سازمانی
- استفاده از راهکارهای Zero Trust برای دسترسی به منابع سازمانی از دستگاههای موبایل
تشخیص و مانیتورینگ (Detection & Monitoring)
نشانههای تلاش برای سوءاستفاده:
- وجود اتصالات ADB غیرمنتظره از آدرسهای IP ناشناس در لاگهای شبکه
- ثبت رویدادهای مرتبط با adbd در لاگهای سیستم (Logcat)
- اجرای ناگهانی فرمانهای su یا shell بدون حضور کاربر فیزیکی
- تغییرات غیرمجاز در فایل /data/misc/adb/adb_keys (کلیدهای مجاز ADB)
- افزایش ترافیک شبکه خروجی از دستگاه
- نصب نرمافزارهای ناشناس یا تغییر تنظیمات امنیتی دستگاه
منابع پیشنهادی برای مانیتورینگ و پایش:
- لاگهای سیستم Android (Logcat) با فیلتر adbd و auth
- راهکارهای MDM با قابلیت پایش اتصالات ADB
- سیستمهای SIEM برای جمعآوری و تحلیل مرکزی لاگهای امنیتی دستگاههای موبایل
- راهکارهای NDR (Network Detection and Response) برای شناسایی ترافیک ADB در شبکه
- ابزارهای اسکن آسیبپذیری
واکنش به حادثه (Incident Response)
- ایزولهسازی فوری دستگاه آلوده از شبکه (قطع Wi-Fi و داده همراه)
- بازبینی کلیدهای مجاز ADB در /data/misc/adb/adb_keys و حذف کلیدهای ناشناس
- بازنشانی تنظیمات توسعهدهنده (Revoke USB debugging authorizations)
- بررسی لاگها برای شناسایی دستورات اجراشده و اطلاعات استخراجشده
- تغییر رمزهای عبور تمام حسابهایی که روی دستگاه استفاده میشدند
- اعمال پچ امنیتی و راهاندازی مجدد دستگاه
- مستندسازی کامل حادثه (زمان وقوع، نشانهها، اقدامات انجامشده، درسآموختهها) و گزارش به مدیریت ارشد و تیم واکنش سریع (CSIRT)
جریان حمله (Attack Flow)
در نمودار زیر (شکل ۱)، مهاجم در همان شبکه Wi-Fi دستگاه هدف قرار دارد و قابلیت Wireless Debugging روی دستگاه فعال است. مهاجم با ارائه یک گواهی TLS از نوع EC P-256 (در حالی که دستگاه منتظر کلید RSA است)، باعث میشود تابع EVP_PKEY_cmp مقدار -1 بازگرداند که در شرط if به اشتباه به معنای “مطابقت” تفسیر میشود. در نتیجه احراز هویت دور زده شده و مهاجم به شل (shell) دسترسی پیدا میکند.
شکل 1: جریان اجرای آسیب پذیری
اثبات مفهوم (PoC) — کاملاً غیرمخرب
آزمایشگاه تخصصی Vulnerbyte، این آسیبپذیری را در محیط ایزوله و کنترلشده با استفاده از نسخه آسیبپذیر بررسی و اجرا کرده است
- این آزمایشگاه شامل دستگاه اندروید به همراه نسخه آسیبپذیر است راه اندازی شده است
- اجرای اسکریپت پایتون poc-cve-2026-0073.py به همراه آدرس ip دستگاه تلفن و یک دستور شل
- بدون تعامل کاربر دستور شل مربوطه روی دستگاه اجرا می شود
- این اثبات مفهوم صرفاً توصیفی و آموزشی بوده و شامل تغییرات مخرب نمیشود
رفع مسئولیت
این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوبهای قانونی از محتوای آن ممنوع است.
منابع
https://www.cve.org/CVERecord?id=CVE-2026-0073
https://nvd.nist.gov/vuln/detail/CVE-2026-0073
https://cwe.mitre.org/data/definitions/303.html
https://source.android.com/docs/security/bulletin/2026/2026-05-01
https://github.com/adityatelange/Poc-CVE-2026-0073
Android Debug Bridge (ADB)
CVE-2026-0073 – Authentication Bypass in Wireless ADB Leading to Remote Code Execution
Affects
- Android Debug Bridge (ADB) – Wireless Debugging Component
- Versions:
- Android 14
- Android 15
- Android 16
- Android 16-QPR2
- Components:
adbd(ADB daemon) in Wireless Debugging Modeauth.cpp– TLS certificate verification logic
- Files:
daemon/auth.cpp
- Functions:
adbd_tls_verify_cert()
Description
CVE-2026-0073 is a critical authentication bypass vulnerability in Android’s Wireless ADB (Android Debug Bridge) implementation.
When a client connects via Wireless ADB (STLS path) , the device initiates a mutual TLS 1.3 handshake. The adbd_tls_verify_cert() function in auth.cpp compares the client’s public key against stored authorized keys using OpenSSL’s EVP_PKEY_cmp() function .
The vulnerability arises because:
EVP_PKEY_cmp()returns 1 if keys match, 0 if they don’t, but -1 if key types are different (e.g., RSA vs EC)- -1 evaluates to
truein C/C++ conditional statements - The code incorrectly treats a type mismatch as a successful authentication
This logic error allows an attacker to bypass mutual authentication entirely, gaining unauthorized access to the device’s ADB shell.
Attack Vector
Primary Attack Vector:
Remote / Unauthenticated (Adjacent Network – requires Wi-Fi connectivity)
Attack Scenario:
- An attacker identifies an Android device with Wireless Debugging enabled on the same local network
- The attacker connects to the device’s randomized Wireless Debugging port (displayed in Developer Options, range 30000–50000)
- The attacker initiates the STLS (Start TLS) handshake using an EC P-256 key
- The device’s
adbd_tls_verify_cert()function compares the client’s EC key against the stored RSA keys EVP_PKEY_cmp()returns-1(type mismatch), which the code interprets as a successful match- The device grants the attacker a
rootshell without any user interaction or screen wake
Key Characteristics:
- No authentication required (pre-auth).
- No user interaction required (zero-click) .
- Exploitable over adjacent network (same Wi-Fi) .
- Relies on incorrect implementation of an authentication algorithm .
Conditions Increasing Risk:
- Wireless Debugging enabled on the target Android device.
- Device not patched with May 2026 Android Security Bulletin .
- Device on same network as attacker.
Impact
Successful exploitation allows:
- Full remote code execution with root privileges (
uid=0) , - Complete device compromise,
- Backdoor installation for persistence (injecting rogue RSA keys) ,
- Lateral movement to internal networks (via device routing tables),
- Extraction of sensitive system files (
/data/misc/adb/adb_keys,/system/build.prop) .
This represents a complete device takeover risk.
Observed Exploitation & Threat Activity
- Published: May 4, 2026
- Patches available: May 2026 Android Security Bulletin (2026-05-01)
- Public PoC: Multiple weaponized exploits available on GitHub
- CVSS Score: 8.8 (High) / 8.3 (depending on source)
- Exploitation in the wild: No confirmed widespread exploitation as of May 2026, but PoC availability makes exploitation likely .
Severity & Metrics
- CVSS v3.1 (NVD): High (8.8)
- Attack Vector: Adjacent Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Confidentiality: High
- Integrity: High
- Availability: High
Relevant CWE:
- CWE-303 – Incorrect Implementation of Authentication Algorithm
Patch & Vendor Status
- Official patch available: Yes – included in May 2026 Android Security Bulletin (2026-05-01)
- GitHub Security Advisory: Published May 4, 2026
Mitigation & Remediation
Immediate Actions
- Apply available security patches immediately from the May 2026 Android Security Bulletin .
- Disable Wireless Debugging on all Android devices not actively requiring it for development .
- Restrict wireless ADB access to trusted networks only .
- Implement network segmentation to limit adjacent network access to Android devices running vulnerable versions .
Defensive Measures
- Regularly “Revoke USB debugging authorizations” in Developer Options to purge legacy RSA keys from the device keystore .
- Monitor for unauthorized ADB connections to devices on your network.
- Use Mobile Device Management (MDM) solutions to enforce developer options policies.
Detection & Hunting
Indicators:
- Unexpected
adbdprocesses consuming CPU or network resources. - Connections to randomized ports (30000–50000) on Android devices from unknown MAC addresses.
- Log entries in
logcatindicatingadbd_tls_verify_certfunction execution with mismatched key types. - Presence of unauthorized RSA keys in
/data/misc/adb/adb_keys. - Successful shell connections (
uid=0(root)) originating from unexpected sources.
Log analysis:
- Check
adb logcatfor authentication-related entries from theadbddaemon.
Post-Incident Response
If exploitation is suspected:
- Isolate affected device from the network immediately (disable Wi-Fi/Cellular).
- Preserve forensic evidence (ADB logs, network captures, filesystem image).
- Rotate all credentials and keys stored on the compromised device.
- Audit device for backdoors (check
/data/misc/adb/adb_keysfor rogue keys, review installed apps, check for modified system files) . - Assume full compromise – do not simply change passwords.
- Factory reset the device or reflash the firmware from a trusted source.
References
- https://source.android.com/docs/security/bulletin/2026/2026-05-01
- https://nvd.nist.gov/vuln/detail/CVE-2026-0073
- https://github.com/novaek/CVE-2026-0073-Research
- https://github.com/devtint/CVE-2026-0073
- https://github.com/adityatelange/poc-CVE-2026-0073
- https://cwe.mitre.org/data/definitions/303.html
بررسی آماری آسیب پذیری CVE-2026-0073 در کشور ایران
محصول آسیب پذیر: نرم افزار adbd شرکت Google (نسخههای 14، 15، 16 و 16- QPR2 سیستم عامل اندروید)
میزان استفاده در ایران بر اساس سایت های آمار مرتبط با محصول
بستر غالب اجرای این نرمافزار در کشور طبق دادههای StatCounter در می 2026، سیستمعامل اندروید با سهم بیش از 85% از بازار موبایل در ایران دارد. این سهم بالا به این معناست که از هر ده گوشی هوشمند در ایران، بیش از هشت دستگاه اندرویدی است
نکته بسیار نگرانکننده اینکه این آسیبپذیری بدون نیاز به هیچ تعاملی از سوی کاربر (zero-click) و صرفاً با قرار گرفتن مهاجم در همان شبکه محلی (Wi-Fi) قابل بهرهبرداری است
میزان استفاده در ایران بر اساس موتورهای جستجو (بر اساس ایندکس های گوگل در بخش tools)
تعداد در زمان نگارش گزارش
|
موتور جستجو |
Dork |
تعداد |
|
|
site:.ir “android” |
5,390,000 |
وجود نمایندگی در ایران
سیستمعامل اندروید توسط شرکت Google توسعه داده میشود. این شرکت دفتر رسمی یا نمایندگی در ایران ندارد. کاربران ایرانی برای دریافت بهروزرسانیهای امنیتی عمدتاً به سازندگان دستگاههای خود (مانند سامسونگ، شیائومی، هواوی، نوکیا و برندهای مونتاژی داخلی) وابسته هستند. اما هیچ گونه پشتیبانی رسمی از طرف شرکت سازنده در کشور وجود ندارد.
میزان استفاده بر اساس گزارشات تحقیقات بازار برای این محصول در ایران
اگرچه آمار رسمی و دقیقی از تعداد سیستمهای آسیبپذیر در ایران وجود ندارد، اما شواهد زیر نشاندهنده سطح قابل توجه ریسک است.
- کاربران اندروید در ایران: طبق آمار، اندروید با سهم بیش از ۸۵٪ از بازار موبایل ایران، غالبترین سیستمعامل همراه در کشور است. این یعنی دهها میلیون دستگاه اندرویدی به طور بالقوه در معرض این آسیبپذیری قرار دارند.
- فعال بودن Wireless Debugging: با توجه به اینکه جامعه برنامهنویسان و توسعهدهندگان اپلیکیشن در ایران بسیار فعال است و بسیاری از آنها برای تست و دیباگ برنامههای خود از Wireless ADB استفاده میکنند، تعداد قابل توجهی از دستگاههای اندرویدی در ایران این ویژگی را فعال نگه میدارند. همچنین مقالات و ویدیوهای آموزشی متعددی به زبان فارسی در وبسایتها و کانالهای آپارات و یوتیوب برای فعالسازی Wireless Debugging منتشر شده است.
- تخمین میزان استفاده: با توجه به تعداد برنامهنویسان و توسعهدهندگان اپلیکیشن در ایران و همچنین کاربران حرفهای و تسترهای امنیتی، میتوان تخمین زد که تعداد زیادی از دستگاه اندرویدی در ایران به طور بالقوه در معرض این آسیبپذیری قرار دارند. این موضوع به ویژه با توجه به اینکه این آسیبپذیری بدون نیاز به هیچ تعامل کاربری (zero-click) قابل بهرهبرداری است و مهاجم صرفاً با اتصال به همان شبکه Wi-Fi میتواند به دستگاه قربانی دسترسی پیدا کند، فوقالعاده نگرانکننده است.
منابع
https://gs.statcounter.com/os-market-share/mobile/iran
https://source.android.com/docs/security/bulletin/2026/2026-05-01
