ملف jar واحد، بدون أي تبعيات وقت التشغيل، يعمل دون اتصال بالكامل، Java 17+.

لماذا يوجد هذا

1. Netty يصدر رقم إصدار واحد، لكن لكل وحدة "إصلاحها" الخاص

كل وحدة من وحدات Netty تُصدر تحت نفس رقم الإصدار، لذا تبدو الترقية كقرار واحد. ليست كذلك. على خط 4.1، إصدارات الإصلاح لهذه الأربع عشرة تقع على 125 / 129 / 132 / 133 / 135 / 136 / 137 — سبع قيم مختلفة. اتبع أي نشرة أمنية واحدة و ستظل داخل النطاق المتأثر للبقية.

2. إذا أصلحت ثغرات HTTP/2، فأنت على الأرجح ما زلت معرّضًا هنا

netty-codec-http2 يصرّح بأن netty-codec-http تبعية compile مع <version>${project.version}</version> — الإصداران مربوطان ببعضهما البعض.

لذا إذا قمت بالترقية إلى 4.1.136.Final لأن هذا هو الإصدار الذي يزيل ثغرات netty-codec-http2 السبع، فأنت الآن تشغّل netty-codec-http 4.1.136.Final أيضًا — و CVE-2026-59903 يغطي <= 4.1.136.Final. أنت بحاجة إلى 4.1.137.Final. نفس القصة على خط 4.2: إجابة HTTP/2 هي 4.2.16.Final، وهذا الجانب يحتاج 4.2.17.Final.

هذا ليس ادعاءً بأن نصيحة HTTP/2 كانت خاطئة — لقد أجابت عن وحدة مختلفة. إنه ادعاء بأن "رقم إصدار واحد" يخفي حقيقة أنك كنت تجيب عن وحدة واحدة فقط.

3. الحدود غير مكتوبة بشكل متسق، وإصدار واحد ينقلب عليها

عبر هذه النشرات الأربع عشرة، الحد الأعلى مكتوب <= 16 مرة و < 12 مرة. نفس 4.1.136.Final لذلك آمن لـ CVE-2026-56746 (< 4.1.136.Final) و متأثر لـ CVE-2026-59903 (<= 4.1.136.Final).

تطبيع العامل في أي اتجاه ينتج إجابة خاطئة — أحد الاتجاهين يبالغ في الإبلاغ، والآخر يقلل في الإبلاغ، والتقليل في الإبلاغ هو الخطأ المكلف لأداة مثل هذه. جدول القواعد يحافظ على كل عامل تمامًا كما كتبته النشرة، وتأكيد في tools/gen_rules.py يفشل البناء إذا توقفت حالة الحدود هذه عن التصرف بهذه الطريقة.

وهي لا تفحص pom.xml — عن قصد

إذا كنت تستخدم Spring WebFlux، فإن netty-codec-http تصل عبر

الـ artifactId لا يظهر أبدًا في pom.xml الخاص بك. الفحص القائم على pom يجيب "أنا لا أستخدمها"، وهذا خطأ. هذه الأداة تقرأ ملفات jar التي تُشحن فعليًا.

الاستخدام

رموز الخروج: 0 = غير متأثر · 1 = متأثر · 2 = تعذّر الحكم.

🔴 2 ليس 0 عمدًا. "لم يتم العثور على شيء" و"نظيف" يجب ألا يبدوا متشابهين لسكربت. الملف الذي ليس zip قابلًا للقراءة يُبلَّغ عنه كفشل قراءة، ولا يُعامل أبدًا بصمت كـ "لا يوجد netty هنا".

ما لا تخبرك به

• فقط هذه الـ 14 CVE، فقط netty-codec-http. وحدات Netty الأخرى لها ثغرات CVE خاصة بها؛ النتيجة النظيفة هنا لا تقول شيئًا عنها. إذا كنت تشغّل أيضًا netty-codec-http2، فإن الأداة تقول ذلك وتشير إلى مشكلة الوحدات المتقاطعة أعلاه، لكنها لا تحكم على تلك الوحدة.
• الخطورة تُبلَّغ كما نُشرت. اثنتان من الأربع عشرة لا تحملان درجة CVSS وواحدة منخفضة؛ تُطبع كما هي، ولا تُدمج في إجمالي مخيف.
• كل واحدة من هذه النشرات مُراجَعة مع بيانات حزمة كاملة، لذا فإن Dependabot وأمثاله ينبّهون عليها بالفعل. هذه الأداة ليست "الماسح لا يستطيع رؤيتها" — بل هي "التنبيه يخبرك برقم إصدار لكل نشرة، وما زلت بحاجة إلى معرفة أي إصدار واحد ينهيها."

كيف يُبنى جدول القواعد

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java مُولَّد، ولا يُحرَّر يدويًا أبدًا:

سبعة تأكيدات يجب أن تنجح أو لا يُكتب شيء — من بينها: كل نشرة ما زالت مُراجَعة؛ كلا خطي الإصدار موجودان لكل منها؛ التقاطع المحسوب ما زال 4.1.137.Final / 4.2.17.Final؛ تلك الإصدارات قابلة للجلب فعليًا من Maven Central (مع إصدار حارس يجب أن يعطي 404، حتى لا يمر فحص معطوب بصمت)؛ حالة الحدود في §3 ما زالت تنقلب؛ وإجابة HTTP/2 من §2 ما زالت تترك ثغرة على هذا الجانب.

فحوصات النهاية إلى النهاية بملفات jar حقيقية موجودة في tools/e2e_real_jars.py — وهي تنزّل ملفات jar فعلية من Maven Central بدلًا من النماذج، لأن "يعمل على zip مبني يدويًا، يفشل على jar الحقيقي" هو نمط فشل حقيقي.

الترخيص

MIT