ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-network version 5.0.1, when deserializing addr or addrv2 messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections. This vulnerability is fixed in zebrad version 4.3.0 and zebra-network version 5.0.1.
CVE-2026-40881 is a denial-of-service vulnerability in ZEBRA (Zcash node implementation) affecting versions prior to 4.3.0 and zebra-network before 5.0.1. The flaw allows attackers to cause out-of-memory aborts by sending specially crafted addr/addrv2 messages that trigger excessive memory allocation. While currently no public exploit exists, the vulnerability poses a risk to cryptocurrency infrastructure and blockchain nodes operating in Saudi Arabia.
Immediate Actions:
1. Identify all systems running ZEBRA/zebrad versions prior to 4.3.0 or zebra-network before 5.0.1 by conducting an inventory audit
2. Isolate affected nodes from public network access if possible, or implement network segmentation
3. Monitor system memory utilization and implement alerts for abnormal memory consumption patterns
Patching Guidance:
1. Upgrade ZEBRA to version 4.3.0 or later immediately
2. Upgrade zebra-network to version 5.0.1 or later
3. Test patches in non-production environments before deployment
4. Coordinate patching across all node infrastructure to minimize service disruption
Compensating Controls (if immediate patching not possible):
1. Implement rate limiting on addr/addrv2 message processing at the network layer
2. Deploy connection-level limits to restrict simultaneous connections from single sources
3. Configure memory limits at the OS level using cgroups or similar mechanisms
4. Implement network-based filtering to drop suspicious addr messages
Detection Rules:
1. Monitor for multiple addr/addrv2 messages from single source IPs
2. Alert on memory allocation spikes exceeding baseline by >50%
3. Track process termination due to out-of-memory conditions
4. Log and analyze connection patterns showing rapid addr message delivery
الإجراءات الفورية:
1. تحديد جميع الأنظمة التي تقوم بتشغيل إصدارات ZEBRA/zebrad السابقة للإصدار 4.3.0 أو zebra-network قبل 5.0.1 من خلال إجراء تدقيق الجرد
2. عزل العقد المتأثرة عن الوصول إلى الشبكة العامة إن أمكن، أو تطبيق تقسيم الشبكة
3. مراقبة استخدام ذاكرة النظام وتطبيق التنبيهات لأنماط استهلاك الذاكرة غير الطبيعية
إرشادات التصحيح:
1. ترقية ZEBRA إلى الإصدار 4.3.0 أو أحدث على الفور
2. ترقية zebra-network إلى الإصدار 5.0.1 أو أحدث
3. اختبار التصحيحات في بيئات غير الإنتاج قبل النشر
4. تنسيق التصحيح عبر جميع البنية التحتية للعقد لتقليل انقطاع الخدمة
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تطبيق تحديد معدل معالجة رسائل addr/addrv2 على مستوى الشبكة
2. نشر حدود على مستوى الاتصال لتقييد الاتصالات المتزامنة من مصادر واحدة
3. تكوين حدود الذاكرة على مستوى نظام التشغيل باستخدام cgroups أو آليات مماثلة
4. تطبيق التصفية القائمة على الشبكة لإسقاط رسائل addr المريبة
قواعد الكشف:
1. مراقبة رسائل addr/addrv2 المتعددة من عناوين IP مصدر واحدة
2. التنبيه على ارتفاعات تخصيص الذاكرة التي تتجاوز الخط الأساسي بنسبة >50%
3. تتبع إنهاء العملية بسبب ظروف نقص الذاكرة
4. تسجيل وتحليل أنماط الاتصال التي تظهر تسليم رسائل addr السريع