رخداد eMudhra تفاوت سرعت واکنش مرورگرها و محیط‌های Java را برجسته کرده است. طبق گزارش، پژوهشگری با امضای یک پیام، کنترل کلید خصوصی هشت intermediate CA متعلق به eMudhra را نشان داد. Mozilla ظرف حدود سه ساعت certificateهای مربوط را در Firefox مسدود کرد و Chrome هم همان روز واکنش نشان داد؛ اما این اقدام به‌معنای رفع خطر برای برنامه‌های Java نبود.
هر JDK یک trust store مستقل به نام cacerts دارد و هر container image شامل JDK نیز نسخه خودش را نگه می‌دارد. به‌روزرسانی سیستم‌عامل یا راه‌اندازی دوباره مرورگر، این مجموعه را تغییر نمی‌دهد. تا زمان به‌روزرسانی هر runtime، مهاجمی که میان سرویس و مقصد قرار بگیرد ممکن است بتواند سرویس را به پذیرش certificate جعلی در ارتباط TLS خروجی متقاعد کند.
نویسنده بر اساس گفت‌وگو با تیم‌های سازمانی Java می‌گوید انتقال به‌روزرسانی JDK به production اغلب هفته‌ها طول می‌کشد. یکی از دلایل، همراه‌شدن اصلاحات امنیتی با رفع bug و تغییرات رفتاری و عملکردی است که Regression Testing گسترده می‌طلبد. نبود فهرست دقیق JVMها و مسئول هرکدام، زمان‌بندی ماهانه یا فصلی تغییرات و بازسازی container image فقط هنگام انتشار قابلیت تازه نیز از موانع ذکرشده‌اند.
به‌گفته گزارش، اصلاح اولیه هم کافی نبود: در ۲۴ اکتبر، CVE-2026-114820 با امتیاز CVSS برابر ۹٫۱ نشان داد فهرست مسدودسازی قبلی مشکل را کامل برطرف نمی‌کند. اصلاح بعدی، root certificateهای مرتبط با eMudhra را کاملاً از trust store حذف می‌کند؛ بنابراین حتی runtimeهایی که به‌روزرسانی قبلی را گرفته بودند، دوباره به به‌روزرسانی نیاز داشتند.
راهکار پیشنهادی نویسنده، استفاده از به‌روزرسانی Security-only است: تغییری محدود به اصلاح امنیتی تا دامنه بررسی کوچک‌تر بماند. گزارش پنج آمادگی لازم را برمی‌شمارد: فهرست زنده JVMها و trust storeها، مسیر مشخص ارزیابی فوریت، دسترسی به اصلاحات خارج از برنامه، Regression Testing خودکار و pipeline انتشار runtime با امکان بازگشت.
نویسنده این رویکرد را به عملکرد Azul پیوند می‌دهد: اصلاح ۵۳ CVE در ۲۰ اکتبر، مسدودسازی هشت intermediate CA در ۲۱ اکتبر و ارائه اصلاح دوم در ۲۴ اکتبر. طبق ادعای گزارش، مرحله آخر از تصمیم به ساخت مجدد تا تحویل نسخه‌های Security-only به مشتریان حدود ۱۲ ساعت طول کشید.
