شناسه CVE-2026-25769 :CVE
CWE-502 :CWE
yes :Advisory
منتشر شده: مارس 17, 2026
به روز شده: مارس 17, 2026
امتیاز: 9.1
نوع حمله: Security Feature Bypass

اثر گذاری: Remote code execution(RCE)
حوزه: نرم افزارهای شبکه و امنیت
برند: wazuh
محصول: wazuh
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch شده

چکیده

آسیب‌پذیری موجود در Wazuh Cluster ناشی از سریال‌زدایی ناامن داده‌ها (Insecure Deserialization) است و مهاجم را قادر می‌سازد تا کد دلخواه خود را از راه دور (RCE) روی master node اجرا کند. این ضعف امنیتی تنها زمانی فعال می‌شود که Wazuh در حالت cluster mode اجرا شود و هر مهاجمی که به یک worker node دسترسی پیدا کند، می‌تواند با دسترسی root تمامی دستورات دلخواه خود را روی master node اجرا کرده و کنترل کامل سیستم مانیتورینگ را به دست آورد.

توضیحات

آسیب‌پذیری CVE-2026-25769 از نوع سریال‌زدایی ناامن داده‌ها مطابق با CWE-502 است و در مکانیزم پردازش پیام‌های Cluster در Wazuh رخ می‌دهد. Wazuh یک پلتفرم متن‌باز و رایگان برای پیشگیری، شناسایی و پاسخ به تهدیدات امنیتی است. این ضعف در پیاده‌سازی فرآیند سریال‌زدایی داده‌های JSON در معماری Master/Worker ایجاد شده است؛ معماری‌ای که در آن master node مسئول هماهنگی، مدیریت سیاست‌ها، ذخیره‌سازی لاگ‌ها و پردازش رویدادهای امنیتی بوده و Workerها وظیفه اجرای عملیات توزیع‌شده را بر عهده دارند.

ریشه فنی آسیب‌پذیری در تابع as_wazuh_object() واقع در فایل framework/wazuh/core/cluster/common.py قرار دارد. این تابع به‌عنوان پارامتر object_hook در فراخوانی json.loads() استفاده می‌شود؛ به این معنا که هنگام تبدیل داده JSON دریافتی به object پایتون، این تابع روی ساختار ورودی اعمال می‌گردد. مسئله از آنجا آغاز می‌شود که این تابع بدون اعمال هیچ‌گونه اعتبارسنجی یا محدودسازی، مقادیر خاصی از جمله کلید __module__ و مشخصه‌های مرتبط با callable object (object قابل فراخوانی) را مستقیماً از ورودی دریافتی استخراج می‌کند.

در این فرآیند، مقدار __module__ که کاملاً تحت کنترل مهاجم است، به تابع import_module() ارسال شده و ماژول مشخص‌شده بدون بررسی لیست سفید (Whitelist) یا محدودیت امنیتی بارگذاری می‌شود. سپس با استفاده از getattr()، هر تابع دلخواه از آن ماژول استخراج شده و یک callable object تولید می‌گردد. این object در ادامه مسیر پردازش پیام Cluster، در فایل framework/wazuh/core/cluster/dapi/dapi.py و مشخصاً در بخش اجرای دستور(`data = f(**f_kwargs)`) مستقیماً فراخوانی می‌شود. بدین ترتیب، داده‌ای که در ظاهر یک پیام داخلی Cluster است، عملاً به مکانیزم اجرای کد (RCE) تبدیل می‌شود.

در سناریوی بهره‌برداری، مهاجم ابتدا باید به یک worker node دسترسی پیدا کند؛ این دسترسی می‌تواند از طریق آسیب‌پذیری دیگر، دسترسی غیرمجاز، تهدید داخلی یا حملات زنجیره تأمین (supply chain attack) حاصل شود. مهاجم پس از در اختیار گرفتن worker node، قادر خواهد بود پیام‌های Distributed API (DAPI) را که میان nodeها مبادله می‌شود، تولید کند. این پیام‌ها با استفاده از کلید متقارن Fernet رمزگذاری شده و از طریق پورت TCP 1516 به master node ارسال می‌شوند. از آنجا که master node به Workerها اعتماد ذاتی دارد و پیام‌های رمزگشایی‌شده را معتبر فرض می‌کند، هیچ کنترل ثانویه‌ای برای بررسی صحت ماژول یا تابع درخواست‌شده اعمال نمی‌شود. در نتیجه، مهاجم می‌تواند به‌سادگی توابع سیستمی مانند subprocess.getoutput را فراخوانی کرده و هر فرمان دلخواه سیستم‌عامل را با دسترسی root اجرا کند.

این آسیب‌پذیری قابل خودکارسازی است؛ مهاجم می‌تواند با استفاده از اسکریپت‌های پایتون یا ابزارهای آماده اکسپلویت، پیام JSON مخرب را تولید کرده و در قالب پیام خوشه‌ای ارسال کند. کد اثبات مفهومی (PoC) منتشر شده نشان می‌دهد که اجرای فرمان‌هایی مانند id، whoami یا ایجاد فایل‌هایی مانند /tmp/RCE_PROOF روی master node امکان‌پذیر است. از آنجا که سرویس Wazuh معمولاً با دسترسی root اجرا می‌شود، تمامی دستورات تزریق‌شده نیز با همان سطح دسترسی اجرا شده و کنترل کامل سیستم در اختیار مهاجم قرار می‌گیرد.

این آسیب‌پذیری هر سه مؤلفه اصلی امنیت را تحت تأثیر قرار می‌دهد. از نظر محرمانگی (Confidentiality)، مهاجم می‌تواند به داده‌ها و لاگ‌های حساس دسترسی یابد؛ از نظر یکپارچگی (Integrity)، می‌تواند سیاست‌ها، تنظیمات و هشدارهای امنیتی را تغییر دهد و از نظر دسترس‌پذیری (Availability)، امکان توقف سرویس‌ها، حذف فایل‌ها یا اختلال در عملکرد Cluster را دارد. علاوه بر این، با توجه به نقش مرکزی master node در مدیریت Agentها، مهاجم می‌تواند حمله خود را به سایر سامانه‌های متصل گسترش دهد و کنترل کامل محیط مانیتورینگ امنیتی را به دست آورد.

در مجموع، این آسیب‌پذیری نمونه‌ای کلاسیک از اعتماد بیش از حد به داده‌های داخلی سیستم توزیع‌شده است؛ جایی که توسعه‌دهندگان فرض کرده‌اند تمامی پیام‌های دریافتی از Worker قابل اعتماد هستند، در حالی که نفوذ به یک node می‌تواند کل ساختار امنیتی Cluster را در معرض ریسک قرار دهد. این ضعف در نسخه 4.14.3 با اصلاح منطق سریال‌زدایی و اعمال محدودیت‌های امنیتی بر ماژول‌ها و توابع قابل بارگذاری کاملاً پچ شده است.

CVSS

Score	Severity	Version	Vector String
9.1	CRITICAL	3.1	CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

تفسیر جدول CVSS

لیست محصولات آسیب پذیر

Versions	Product
node می‌تواند کل ساختار امنیتی Cluster را در معرض ریسک قرار دهد. این ضعف در نسخه 4.14.3 با اصلاح منطق سریال‌زدایی و اعمال محدودیت‌های امنیتی بر ماژول‌ها و توابع قابل بارگذاری کاملاً پچ شده است.affected at >= 4.0.0, < 4.14.3	wazuh

لیست محصولات بروز شده

Versions	Product
>= 4.14.3	wazuh

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که wazuh را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Search Query (Dork)	Product
864	site:.ir “wazuh”	wazuh

نتیجه گیری

این آسیب‌پذیری با شدت بحرانی در Wazuh Cluster امکان اجرای کد دلخواه از راه دور (RCE) روی Master Node را فراهم می‌کند و در بسیاری از استقرارها می‌تواند منجر به اجرای دستورات با سطح دسترسی root شود. در صورت بهره‌برداری موفق، مهاجم قادر خواهد بود به داده‌های حساس دسترسی پیدا کند، قوانین و پیکربندی‌های امنیتی را تغییر دهد و حتی عملکرد سامانه مانیتورینگ و تحلیل امنیتی را مختل کند. برای کاهش ریسک و جلوگیری از سوءاستفاده از این آسیب‌پذیری، اجرای اقدامات زیر توصیه می‌شود:

به‌روزرسانی فوری: تمامی سامانه‌های Wazuh را در اسرع وقت به نسخه 14.3 یا بالاتر ارتقا دهید. این نسخه شامل اصلاح منطق سریال‌زدایی ناامن داده‌ها است و تنها راهکار قطعی برای رفع این آسیب‌پذیری محسوب می‌شود. سایر اقدامات صرفاً نقش تکمیلی در کاهش سطح ریسک دارند.
محدودسازی دسترسی شبکه به Cluster: ارتباطات داخلی Cluster را تنها به nodeهای مورد اعتماد محدود کرده و دسترسی به پورت‌های مربوط به ارتباطات خوشه‌ای (مانند پورت 1516) را از طریق فایروال شبکه یا جداسازی (segmentation) شبکه کنترل کنید تا از دسترسی غیرمجاز به زیرساخت خوشه جلوگیری شود.
ایزوله‌سازی محیط اجرا: در صورت امکان، nodeهای Wazuh را در محیط‌های ایزوله مانند Docker یا Kubernetes اجرا کنید و اصل حداقل سطح دسترسی را برای سرویس‌ها اعمال نمایید تا در صورت بهره‌برداری، دامنه تأثیر حمله محدود شود.
نظارت و تحلیل لاگ‌ها: ثبت لاگ‌های دقیق Wazuh را فعال کرده و مسائل مربوط به ارتباطات cluster و پیام‌های DAPI را با سطح DEBUG بررسی کنید تا عملکردهای غیرعادی یا تلاش‌های احتمالی برای سوءاستفاده شناسایی شوند.
کنترل و اعتبارسنجی پیام‌های Cluster: در محیط‌های توسعه یا استقرارهای سفارشی، مکانیزم‌های اضافی برای اعتبارسنجی پیام‌های cluster، محدودسازی ماژول‌ها و توابع قابل فراخوانی پیاده‌سازی کنید تا از بارگذاری ماژول‌های غیرمجاز جلوگیری شود.
انجام تست‌های امنیتی دوره‌ای: زیرساخت Wazuh را به‌صورت منظم با استفاده از ابزارهای تست امنیتی مانند OWASP ZAP، روش‌های Fuzzing و سایر ابزارهای تحلیل امنیتی ارزیابی کنید تا نقاط ضعف احتمالی پیش از بهره‌برداری مهاجمان شناسایی شوند.

اجرای این اقدامات، به‌ویژه به‌روزرسانی سریع سامانه به نسخه پچ‌شده و کنترل ارتباطات cluster، می‌تواند احتمال بهره‌برداری از این آسیب‌پذیری را به میزان قابل توجهی کاهش داده و سطح امنیت زیرساخت مانیتورینگ Wazuh را بهبود دهد.

امکان استفاده در تاکتیک‌های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)
مهاجم نیاز به دسترسی اولیه به نود Worker دارد. این دسترسی می‌تواند از طریق بهره‌برداری از یک آسیب‌پذیری دیگر در سطح شبکه، حمله به پنل مدیریتی Wazuh، نفوذ به یک سرور مجازی یا فیزیکی در لبه شبکه، آشنایی با کارکنان داخلی (Insider Threat) یا از طریق حمله به زنجیره تامین (Supply Chain Attack) حاصل شود.

Execution (TA0002)
پس از نفوذ به نود Worker، مهاجم با ارسال یک درخواست DAPI حاوی JSON مخرب (که شامل subprocess.getoutput است) از طریق پورت 1516 (پروتکل خوشه) به نود اصلی، باعث اجرای کد دلخواه (مثلاً دستور id) بر روی نود اصلی می‌شود. این عمل معادل اجرای کد از راه دور با دسترسی ریشه است.

Privilege Escalation (TA0004)
با توجه به اینکه سرویس Wazuh روی نود اصلی معمولاً با بالاترین سطح دسترسی (root) اجرا می‌شود، هدف اصلی این آسیب‌پذیری عملاً دستیابی مستقیم به سطح دسترسی root است. مهاجم پس از اجرای موفق حمله، قادر به هرگونه عملیاتی از جمله تغییر تنظیمات کرنل، دستکاری فرآیندها و خواندن تمام فایل‌های سیستم است.

Defense Evasion (TA0005)
از آنجا که ارتباطات خوشه Wazuh رمزنگاری شده‌اند (با استفاده از Fernet symmetric encryption)، و مهاجم از کلید معتبر و داخل شبکه معتبر استفاده می‌کند، این حمله باعث تولید هشدارهای امنیتی سطح پایین در ارتباطات اولیه شبکه نمی‌شود و از دید مکانیزم‌های تشخیص نفوذ (IDS) سنتی که عمدتاً به دنبال ترافیک رمزگذاری نشده هستند، مخفی می‌ماند.

Credential Access (TA0006)
پس از دستیابی به دسترسی root بر روی نود اصلی، مهاجم می‌تواند به تمام فایل‌ها از جمله فایل‌های رمزنگاری خوشه (cluster.key) و تمام بانک‌های اطلاعاتی داخلی Wazuh دسترسی پیدا کرده و هش رمزهای عبور کاربران، کلیدهای API، اطلاعات لاگین سیستم‌های متصل و سایر اعتبارنامه‌های حیاتی را استخراج کند.

Collection (TA0009)
نود اصلی Wazuh یک مخزن مرکزی از تمامی داده‌های امنیتی سازمان است. مهاجم می‌تواند حجم عظیمی از اطلاعات حساس (شامل رویدادهای لاگ، اطلاعات احراز هویت، اسرار تجاری و اطلاعات حریم خصوصی) را از دیتابیس داخلی و ایندکس‌های Elasticsearch جمع‌آوری کند.

Lateral Movement (TA0008)
کل زیرساخت امنیتی سازمان تحت کنترل مهاجم قرار می‌گیرد. مهاجم می‌تواند با صدور فرمان به gent های نصب شده روی سرورهای حیاتی سازمان، به طور خودکار و نفوذی کنترل شده به تمام نقاط زیرساخت دسترسی پیدا کند و به صورت افقی در شبکه جابجا شود.

Impact (TA0040)
بهره‌برداری موفق از این آسیب‌پذیری یک نقض کامل امنیت زیرساخت SIEM است. مهاجم با دسترسی کامل root به مغز متفکر سامانه امنیتی، قادر به خاموش کردن کلیه هشدارها، نابود کردن و دستکاری لاگ‌های امنیتی، پاک کردن ردپای خود، و تبدیل پلتفرم امنیتی به ابزاری برای جاسوسی و حمله به سایر سازمان‌های متصل می‌باشد. این رویداد می‌تواند منجر به خاموشی کامل سیستم دفاعی سازمان، سرقت یا نابودی اطلاعات حیاتی، نقض قوانین حریم خصوصی (GDPR/HIPAA) و در نهایت از دست رفتن کامل اعتماد کاربران و ذی‌نفعان گردد.

منابع

گزارش اثبات آسیب‌پذیری CVE-2026-25769

اطلاعات آسیب‌پذیری

عنوان: اجرای کد از راه دور از طریقDeserialization ناامن در پروتکل کلاستر Wazuh
شناسه: CVE-2026-25769
وضعیت مشاوره: Advisory / Patch Available
امتیاز CVSS v3.1: 9.1 (Critical)
محصول/سیستم تحت تأثیر: Wazuh Manager

محصول / نسخه‌های آسیب‌پذیر

در نسخه‌های زیر (پیش از اعمال پچ امنیتی):
• Wazuh Manager (نرم‌افزار مدیریت خوشه) نسخه‌های 4.0.0 تا 4.14.2
• کلیه استقرارهای خوشه‌ای Wazuh با معماری Master/Worker که در آن نودهای Worker احراز هویت می‌شوند
• سیستم‌هایی که سرویس wazuh-clusterd را روی پورت‌های شبکه (به طور پیش‌فرض TCP/1516) اجرا می‌کنند
• کلیه محیط‌های عملیاتی (Production) که قابلیت خوشه‌بندی Wazuh در آن‌ها فعال است
• نسخه‌های پایین‌تر از 3.9.0 نیز در برخی سناریوها (مانند هر نسخه حاوی کد آسیب‌پذیر) ممکن است تحت تأثیر قرار گیرند

محیط‌های درگیر

سازمان‌هایی که از Wazuh به عنوان پلتفرم مدیریت اطلاعات امنیتی و رویدادها (SIEM)، نظارت بر یکپارچگی فایل (FIM) و تشخیص تهدید استفاده می‌کنند
• مراکز داده، سازمان‌های دولتی، مؤسسات مالی و ارائه‌دهندگان خدمات مدیریت شده (MSSP)
• محیط‌های ابری و مجازی‌سازی که از معماری خوشه‌ای Wazuh بهره می‌برند
• هر محیط عملیاتی که در آن یک نود (Worker Node) Wazuh به خطر افتاده یا کلید خوشه به روشی افشا شده باشد
• صنایع حیاتی (نظیر انرژی، بهداشت و درمان، مخابرات، حمل و نقل) که از Wazuh برای تشخیص تهدید استفاده می‌کنند

کامپوننت‌های آسیب‌پذیر

سرویس wazuh-clusterd (مدیریت پروتکل خوشه‌بندی Wazuh، به طور پیش‌فرض روی پورت TCP/1516)
• تابع as_wazuh_object در فایل framework/wazuh/core/cluster/common.py (یک object_hook سفارشی در فرآیند بارگذاری JSON)
• تابع receive_file در همان فایل common.py (که برای همگام‌سازی فایل بین نودها استفاده می‌شود)
• فرآیند wazuh-logcollector (که با سطح دسترسی root اجرا شده و فایل پیکربندی اصلی /var/ossec/etc/ossec.conf را پردازش می‌کند)
• مکانیسم احراز هویت و همگام‌سازی در پروتکل کلاستر Wazuh

ریشه مشکل (Root Cause Analysis)

ریشه اصلی این آسیب‌پذیری به دو نقص اساسی در پیاده‌سازی پروتکل کلاستر Wazuh بازمی‌گردد: یکی از نوع نقض اعتبارسنجی داده‌های (Deserialization) ناامن (CWE-502) و دیگری از نوع آسیب‌پذیری پیمایش مسیر (Path Traversal) به همراه مجوزهای پیش‌فرض ناایمن که اجرای کد از راه دور را با سطح دسترسی root امکان‌پذیر می‌سازد.

اولین نقص در تابع as_wazuh_object (در فایل framework/wazuh/core/cluster/common.py) نهفته است. این تابع به عنوان یک object_hook سفارشی در فرآیند بارگذاری JSON عمل می‌کند و برای پردازش داده‌های دریافتی از نودهای خوشه طراحی شده است. در هنگام رویارویی با یک شیء JSON حاوی کلید __callable__، تابع بدون هیچ‌گونه اعتبارسنجی و لیست سفید (whitelist):

مسیر ماژول (__module__) را از ورودی کاربر می‌خواند.
ماژول مورد نظر را از طریق import_module بارگذاری می‌کند.
تابع یا متد دلخواه را از طریق getattr واکشی می‌کند.

سپس، این تابع که توسط مهاجم مشخص شده، بعداً در فرآیند اجرا می‌شود و سرویس wazuh-clusterd به طور مؤثر به مهاجمی که نود worker را در اختیار دارد اجازه می‌دهد تا توابع و ماژول‌های دلخواه پایتون را روی نود مستر (Master) اجرا کند. این نقص به مهاجم اجازه می‌دهد که کد دلخواه خود را در دستگاه قربانی، با سطح دسترسی کاربر سیستمی wazuh (که یک کاربر ممتاز در سطح فایل سیستم Wazuh است) اجرا کند.

نقص دوم در متد receive_file (در همان فایل) است که مسیر فایل دریافتی از نود فرستنده را مستقیماً با مسیر نصب Wazuh (common.WAZUH_PATH) ادغام می‌کند. در این متد هیچ بررسی بر روی کاراکترهای مسیرگردی (.. /) وجود ندارد و فایل در مسیر مقصد با مجوزهای کاربر wazuh ذخیره می‌شود. از آنجایی که مجوزهای پیش‌فرض فایل پیکربندی اصلی Wazuh (/var/ossec/etc/ossec.conf) به گونه‌ای است که کاربر wazuh به آن دسترسی نوشتن دارد (مالکیت root:wazuh و مجوز 640-)، مهاجمی که قبلاً از طریق نقص deserialization به سطح دسترسی کاربر wazuh رسیده است (و یا از طریق روش دیگری به کلید خوشه دسترسی پیدا کرده) می‌تواند فایل ossec.conf را بازنویسی کند.

به طور خاص، مهاجم با استفاده از اولین بردار حمله (deserialization ناامن) قادر است کدی را با دسترسی کاربر wazuh اجرا کند. سپس با استفاده از بردار دوم، فایل ossec.conf را با محتوایی مخرب جایگزین می‌کند. در نهایت، فرآیند wazuh-logcollector که با سطح دسترسی root در حال اجرا است، پیکربندی جدید را بارگذاری کرده و فرمان مخرب تزریق‌شده (مانند ایجاد یک شل معکوس با دسترسی root) را اجرا می‌کند. این زنجیره از ضعف‌ها به مهاجم اجازه می‌دهد تا کنترل کامل سرور Master Wazuh (که «مغز متفکر» کل سیستم امنیتی سازمان است) را به دست گیرد. این روش برخلاف مدل امنیتی Wazuh که فرض می‌کند پیکربندی اصلی فقط توسط مدیران معتبر قابل تغییر است، اثبات می‌کند که یک مهاجم شبکه می‌تواند این پیکربندی را بدون هیچ‌گونه تعامل مدیریتی تغییر دهد.

بخش آسیب‌پذیر

رفتار ناامن سیستم:

عدم اعتبارسنجی در Deserialization: پذیرش و اجرای فراخوانی‌های تابع دلخواه پایتون (با استفاده از کلید __callable__) از payloadهای JSONارسالی توسط نودهای خوشه، بدون هیچ‌گونه محدودیتی (بررسی whitelistیا اعتبارسنجی ماژول). این رفتار درگاه مخربی را برای اجرای مستقیم کد مهاجم باز می‌کند.
پیمایش مسیر و نبود مدیریت محدوده (chroot) در نوشتن فایل: پذیرش مسیر فایل با مسیر نسبی از کاربر و ادغام مستقیم آن با مسیر اصلی Wazuh، بدون اعتبارسنجی ورودی و بدون محدود کردن عملیات فایل به یک دایرکتوری امن. این امکان را به مهاجم می‌دهد که هر فایلی را که کاربر wazuhبه آن دسترسی داشته باشد، بازنویسی کند.

نحوه سوء استفاده مهاجم:
• مهاجم از طریق به خطر انداختن یک نود worker (ایمنی پایین‌تر، داده‌های پشتیبان یا حمله به زنجیره تامین) به کلید خوشه (Cluster Key) و دسترسی شبکه به نود مستر دسترسی پیدا می‌کند
• مهاجم یک payload JSON مخرب حاوی کلید __callable__ و ماژول دلخواه مانند os.system یا یک ماژول سفارشی برای اجرای فرمان می‌سازد
• مهاجم این payload را به سرویس wazuh-clusterd روی پورت TCP/1516 نود مستر ارسال می‌کند
• payload در سمت سرور بدون اعتبارسنجی deserialize شده و تابع مخرب پایتون اجرا می‌شود
• مهاجم با اجرای تابع os.system و دستورات Bash، یک فایل ossec.conf مخرب (شامل بلوک <localfile> با دستور شل معکوس) ایجاد کرده و در دایرکتوری /var/ossec/etc/ ذخیره می‌کند
• مهاجم یک (Listener) Netcat را روی پورت دلخواه خود راه‌اندازی می‌کند
• مهاجم با استفاده از پیام file_upd یا دستکاری مستقیم فایل از طریق فرمان قبلی، فایل ossec.conf اصلی را بازنویسی می‌کند یا منتظر می‌ماند تا wazuh-logcollector به طور دوره‌ای پیکربندی را بازخوانی کند
• فرآیند wazuh-logcollector (که با دسترسی root اجرا می‌شود) فایل پیکربندی آلوده را پردازش کرده و فرمان مخرب را اجرا می‌کند
• مهاجم یک شل معکوس با دسترسی ریشه (root) دریافت کرده و کنترل کامل نود مستر را به دست می‌گیرد

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری یک نقطه افزایش سطح دسترسی (Privilege Escalation) و یک نقطه اجرای کد اولیه (Initial Code Execution) در زنجیره حمله محسوب می‌شود. از یک سو، بهره‌برداری از تابع as_wazuh_object به مهاجمی که فقط نود worker ضعیف شده را در اختیار دارد اجازه می‌دهد تا با کاربر wazuh بر روی نود مستر کد اجرا کند. مهاجم با اجرای کد روی نود مستر می‌تواند از آسیب‌پذیری پیمایش مسیر برای بدست آوردن کنترل کامل نود مستر با دسترسی ریشه (root) سو استفاده کند. Wazuh Manager (نود مستر) به عنوان «مغز متفکر» پلتفرم امنیتی سازمان عمل می‌کند و تمامی لاگ‌های میزبانی شده، پیکربندیagent ها، داده‌های مربوط به تشخیص تهدید و رویدادهای امنیتی کل سازمان در آن متمرکز شده است. موفقیت در بهره‌برداری از این آسیب‌پذیری عملاً به معنای نقض کامل محرمانگی (Confidentiality)، یکپارچگی (Integrity) و در دسترس‌بودن (Availability) داده‌های امنیتی سازمان است. مهاجم می‌تواند:

قوانین تشخیص تهدید را تغییر داده و حمله خود را از دید سیستم پنهان کند.
تمام لاگ‌های امنیتی سازمان را پاک یا سرقت کند.
از Wazuh Manager به عنوان سکوی پرشی برای حرکت جانبی (Lateral Movement) در شبکه سازمانی استفاده نماید.
با کنترل عوامل (agents)، در Agentها نیز کد اجرا کند و نفوذ را در سطح شبکه گسترش دهد.
کل پلتفرم یکپارچه SIEM را مختل کرده و دید سازمان نسبت به حوادث امنیتی را به طور کامل از بین ببرد.

این آسیب‌پذیری مدل امنیتی Wazuh را که بر مبنای اعتماد به نودهای خوشه است، به طور کامل نقض کرده و اصل کمترین دسترسی (Least Privilege) را دور می‌زند.

پیش‌نیازهای بهره‌برداری (Prerequisites)

دسترسی شبکه مهاجم به سرویس wazuh-clusterd روی نود مستر Wazuh (پورت پیش‌فرض TCP/1516)
• در اختیار داشتن کلید خوشه (Cluster Key) معتبر برای احراز هویت در پروتکل خوشه‌بندی (از طریق به خطر افتادن نود worker، دسترسی به فایل پشتیبان، یا تهدید داخلی)
• استفاده از نسخه آسیب‌پذیر Wazuh Manager (نسخه‌های 4.0.0 تا 4.14.2 یا سایر نسخه‌های حاوی کد آسیب‌پذیر)
• فعال بودن قابلیت خوشه‌بندی (Cluster) در پیکربندی Wazuh Manager
• عدم اعمال پچ امنیتی (ارتقا به نسخه 4.14.3 یا بالاتر) روی سیستم هدف
• (برای سناریوی افزایش سطح دسترسی با بازنویسی ossec.conf) وجود مجوزهای پیش‌فرض ناایمن روی فایل /var/ossec/etc/ossec.conf (-rw-rw—- root:wazuh) که به کاربر wazuh اجازه نوشتن می‌دهد
• (برای سناریوی افزایش سطح دسترسی با بازنویسی ossec.conf) فرآیند wazuh-logcollector با دسترسی root در حال اجرا باشد (این حالت پیش‌فرض است)

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

در فرآیند deserialization، باید یک لیست سفید (whitelist) سخت‌گیرانه از ماژول‌ها و توابع مجاز برای فراخوانی توسط نودهای خوشه پیاده‌سازی شود تا از اجرای کد دلخواه جلوگیری شود
• پروتکل خوشه‌بندی Wazuh باید نوشتن فایل را تنها به یک دایرکتوری مشخص و ایمن (مانند /var/ossec/var/cluster/incoming) محدود کند (مکانیزم chroot)
• تمامی مسیرهای فایل ارسالی از سوی نودها باید قبل از هرگونه عملیات فایل، به دقت اعتبارسنجی شوند تا از پیمایش مسیر (Path Traversal) جلوگیری شود
• فایل پیکربندی اصلی /var/ossec/etc/ossec.conf نباید توسط کاربر سیستمی wazuh قابل نوشتن باشد؛ مالکیت آن باید root:wazuh و مجوز آن 644 (فقط ریشه قابل نوشتن) باشد
• سرویس wazuh-clusterd که با کاربر wazuh اجرا می‌شود، هرگز نباید بتواند فایل‌هایی با اهمیت امنیتی مانند ossec.conf را تغییر دهد
• اصل کمترین دسترسی (Least Privilege) به طور کامل در طراحی و پیاده‌سازی سرویس‌ها رعایت شود، به طوری که نفوذ به یک نود worker منجر به نفوذ به نود مستر نشود

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک:

به‌روزرسانی فوری Wazuh Manager به نسخه 4.14.3 یا بالاتر که هر دو آسیب‌پذیری (deserialization ناامن و پیمایش مسیر) در آن پچ شده است.
• در صورت عدم امکان به‌روزرسانی فوری، غیرفعال کردن قابلیت خوشه‌بندی در محیط‌های حساس تا رفع کامل آسیب‌پذیری
• محدود کردن دسترسی شبکه به پورت 1516 تنها به آدرس‌های IP معتبر (نودهای خوشه) با استفاده از فایروال
• تغییر دسترسی فایل /var/ossec/etc/ossec.conf به root:wazuh و مجوز 640 (خواندنی برای گروه) به عنوان یک اقدام موقت:
chown root:wazuh /var/ossec/etc/ossec.conf && chmod 640 /var/ossec/etc/ossec.conf
• قطع دسترسی اینترنت به سرویس خوشه‌بندی در صورت عدم نیاز به ارتباط خارج از شبکه داخلی
• بازنشانی فوری کلیدهای خوشه (Cluster Keys) در صورت مشکوک بودن به افشای آن‌ها
• پایش مداوم فایل ossec.conf برای شناسایی تغییرات غیرمجاز با استفاده از سیستم‌های نظارت بر یکپارچگی فایل (FIM) موجود در خود Wazuh

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک:

انجام اسکن کامل شبکه برای شناسایی تمام نمونه‌های Wazuh Manager در حال اجرا و بررسی نسخه آن‌ها
• پیاده‌سازی مکانیزم‌های تشخیص نفوذ (IDS/IPS) با قوانین اختصاصی برای شناسایی بسته‌های مخرب پروتکل خوشه Wazuh • فعال‌سازی و تقویت لاگ‌برداری تفصیلی از رفتارهای سرویس‌های wazuh-clusterd و wazuh-logcollector و ارسال آن‌ها به سیستم SIEM
• آموزش تیم‌های عملیاتی (Operations) در خصوص خطرات پیکربندی پیش‌فرض Wazuh و نحوه هاردنینگ آن
• اجرای بازبینی امنیتی بر روی پیکربندی خوشه Wazuh و اطمینان از اعمال اصل کمترین دسترسی در سطح فایل‌ها و سرویس‌ها
• استقرار سیستم‌های هشداردهنده برای شناسایی تلاش‌های مکرر برای احراز هویت ناموفق در سرویس خوشه

اقدامات بلندمدت برای کاهش ریسک:

بازطراحی معماری خوشه Wazuh به گونه‌ای که فرآیند همگام‌سازی فایل‌ها در یک محیط محصور (Sandbox) با کمترین دسترسی انجام شود
• استقرار راهکارهای خودکار به‌روزرسانی امنیتی (Patch Management) برای اعمال سریع وصله‌های امنیتی Wazuh
• افزایش سطح آگاهی تیم‌های توسعه و عملیات در خصوص خطرات Deserialization ناامن (CWE-502) و پیمایش مسیر (CWE-22)
• پیاده‌سازی فرآیندهای منظم تست نفوذ (Penetration Testing) و ارزیابی امنیتی برای کشف زودهنگام آسیب‌پذیری‌های مشابه در زیرساخت
• تدوین و اجرای سیاست‌های هاردنینگ برای تمام مؤلفه‌های Wazuh بر اساس راهنمای امنیتی رسمی
• تجزیه تحلیل و بررسی از نظر نفوذ و تداوم حضور مهاجم در شبکه پس از یک حادثه مشکوک

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوء استفاده:

وجود درخواست‌های غیرعادی به سرویس خوشه Wazuh (پورت 1516) حاوی payloadهای JSON با کلید __callable__ و مقادیر ناآشنا (مانند {“__callable__”: {“__module__”: “os”, “__name__”: “system”}})
• مشاهده خطاهایی مربوط به بارگذاری ماژول در فایل common.py در لاگ‌های wazuh-clusterd
• تغییرات ناگهانی و غیرمنتظره در فایل /var/ossec/etc/ossec.conf (مانند افزوده شدن بلوک‌های <localfile> جدید با فرمان‌های شل مانند bash -i, nc, sh -i)
• ثبت خطاهای مرتبط با باز کردن فایل در فرآیند همگام‌سازی در لاگ‌های wazuh-clusterd
• افزایش ناگهانی ترافیک خروجی شبکه از سمت سرور Wazuh Manager به سمت آدرس‌های IP ناشناس (که حاکی از تلاش برای اتصال مجدد – Reverse Shell است)
• وجود لاگ‌های احراز هویت موفق در سرویس خوشه از آدرس‌های IP غیرمنتظره (مربوط به نود worker)
• اجرا شدن فرآیندهای جدید با کاربر ریشه (root) که ارتباط واضحی با فرآیندهای عادی Wazuh ندارند

منابع پیشنهادی برای مانیتورینگ و پایش:

لاگ‌های سرویس Wazuh Manager (معمولاً در /var/ossec/logs/ossec.log)
• لاگ‌های سیستمی (syslog) برای ردیابی رویدادهای سطح هسته و برنامه
• سیستم‌های SIEM برای جمع‌آوری و تحلیل مرکزی لاگ‌های Wazuh و سایر تجهیزات
• راهکارهای NDR (Network Detection and Response) برای شناسایی ترافیک مشکوک به سمت پورت 1516
• سیستم‌های نظارت بر یکپارچگی فایل (FIM) خود Wazuh برای پایش تغییرات فایل ossec.conf و سایر فایل‌های حساس
• ابزارهای اسکن آسیب‌پذیری (مانند Nessus) برای شناسایی نمونه‌های آسیب‌پذیر Wazuh

واکنش به حادثه (Incident Response)

ایزوله‌سازی فوری سرور Wazuh Manager آسیب‌دیده از شبکه جهت جلوگیری از حرکت جانبی مهاجم و پاک کردن رد پا
• جمع‌آوری و حفظ لاگ‌های Wazuh Manager، لاگ‌های سیستمی و ترافیک شبکه مرتبط برای تحلیل فارنزیک
• بازبینی فایل /var/ossec/etc/ossec.conf برای شناسایی بلوک‌های <localfile> مخرب و حذف آن‌ها
• تغییر تمام کلیدهای خوشه (Cluster Keys) و رمزهای عبور مرتبط با Wazuh
• اعمال پچ امنیتی (ارتقا به نسخه 4.14.3 یا بالاتر) و اصلاح مجوزهای فایل‌های پیکربندی
• اسکن کامل شبکه برای شناسایی سایر سیستم‌هایی که ممکن است مهاجم از Wazuh Manager به آن‌ها دسترسی یافته باشد (به ویژه Agent ها)
• تغییر رمزهای عبور و توکن‌های همه Agent های متصل
• مستندسازی کامل حادثه (زمان وقوع، نشانه‌ها، اقدامات انجام‌شده، درس‌آموخته‌ها) و گزارش به مدیریت ارشد و تیم واکنش سریع (CSIRT)

جریان حمله (Attack Flow)

در نمودار زیر (شکل ۱)، جریان کلی بهره‌برداری از این آسیب‌پذیری نشان داده شده است. مهاجم با دسترسی به نود worker (یا کلید خوشه) از طریق پورت‌های خوشه، اجرای کد از راه دور را با دسترسی root روی نود مستر انجام می‌دهد. این حمله بر اساس عدم اعتبارسنجی در دو بخش به طور مجزا قابل انجام است و در ادامه جریان کلی حمله با استفاده از آسیب‌پذیری پیمایش مسیر نمایش داده شده است.

شکل 1: جریان اجرای آسیب پذیری

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte، این آسیب‌پذیری را در محیط ایزوله و کنترل‌شده با استفاده از نسخه آسیب‌پذیر بررسی و اجرا کرده است

یک نمونه کلاستر Wazuh با یک نود Master و یک نود Worker راه‌اندازی شده است
این اثبات مفهوم صرفاً توصیفی و آموزشی بوده و شامل تغییرات مخرب نمی‌شود
نتایج نشان می‌دهد که چگونه ورودی JSON بدون اعتبارسنجی دسریالایز می شود می‌تواند منجر به اجرای دستورات سیستم از راه دور شود (شکل ۲)

شکل 2: اثبات اجرای آسیب پذیری (POC)

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی از محتوای آن ممنوع است.

منابع

https://www.cve.org/CVERecord?id=CVE-2026-25769

https://nvd.nist.gov/vuln/detail/CVE-2026-25769

https://cwe.mitre.org/data/definitions/502.html

https://cwe.mitre.org/data/definitions/22.html

https://github.com/wazuh/wazuh/security/advisories/GHSA-3gm7-962f-fxw5

https://github.com/wazuh/wazuh/security/advisories/GHSA-r4f7-v3p6-79jm

https://github.com/hakaioffsec/CVE-2026-25769

https://hakaisecurity.io/cve-2026-25769-rce-via-insecure-deserialization-in-wazuh-cluster-remote-command-execution-through-cluster-protocol/research-blog/

https://www.tenable.com/plugins/nessus/303595

https://www.checkpoint.com/defense/advisories/public/2026/cpai-2026-2331.html

#Wazuh Cluster

CVE-2026-25769 – Remote Code Execution via Insecure Deserialization in Wazuh Cluster

Affects

Wazuh Cluster (Master‑Worker Architecture)
Versions:
- Wazuh 4.0.0 up to 4.14.2 (including all intermediate versions)
Components:
- Cluster communication protocol (DAPI)
- Distributed API Handler
Files:
- framework/wazuh/core/cluster/common.py
- framework/wazuh/core/cluster/dapi/dapi.py
Functions:
- as_wazuh_object(dct)
- json.loads(..., object_hook=as_wazuh_object)

Description

CVE-2026-25769 is a critical pre‑authentication (within the cluster) insecure deserialization vulnerability in Wazuh Cluster.

The Wazuh master node uses a custom deserialization function as_wazuh_object() as an object_hook for json.loads() when processing messages received from worker nodes. This function is designed to reconstruct Python objects from JSON data.

The vulnerability arises because:

The as_wazuh_object() function implicitly trusts any worker that has authenticated using the pre‑shared cluster key.
When a JSON object contains the special key __callable__, the function blindly imports any Python module specified in the "__module__" field and retrieves any callable named in the "__name__" field.
No whitelist or validation is applied to the module or function name.
After reconstruction, the callable is executed directly in the master’s context via the DAPI handler.

A malicious actor who has compromised a single worker node (or can intercept/modify cluster traffic) can craft a DAPI message that:

Specifies a dangerous module (e.g. subprocess or os),
Specifies a dangerous function (e.g. getoutput, system),
Supplies arbitrary arguments (e.g. a system command).

This results in insecure deserialization leading to remote code execution (RCE) on the master node.

Attack Vector

Primary Attack Vector:
Remote (via Compromised Worker Node / Cluster Network)

Attack Scenario:

An attacker gains initial access to any worker node in the Wazuh cluster (via other vulnerabilities, weak credentials, insider threat, or supply‑chain compromise).
On the compromised worker, the attacker extracts the pre‑shared cluster key (stored in ossec.conf).

The attacker crafts a malicious JSON payload containing:

{
  "__callable__": {
    "__module__": "subprocess",
    "__name__": "getoutput",
    "__args__": ["id > /tmp/pwned"]
  }
}

Using the cluster key, the attacker sends the payload to the master node on the cluster communication port (1516/TCP).
The master node receives the message, deserializes it with as_wazuh_object(), and automatically imports subprocess , retrieves getoutput, and executes the command.
The attacker’s command runs with root privileges on the master node.

Key Characteristics:

No authentication bypass needed – the worker is already trusted by the cluster key.
No additional user interaction required.
Exploitable from any compromised worker node (lateral movement).
RCE achieved without ever sending a command to the master’s REST API.

Conditions Increasing Risk:

Wazuh running in cluster mode (not standalone).
At least one worker node exposed to potential compromise.
Use of default cluster key (not rotated).
Lack of network segmentation between worker and master nodes.
No proper egress filtering on worker nodes.

Impact

Successful exploitation allows:

Full remote code execution with root privileges on the master node,
Complete compromise of the central security management platform,
Disabling or manipulation of detection rules,
Extraction of all agent keys and credentials,
Deletion of forensic logs to cover traces,
Lateral movement from the master to other internal systems,
Subversion of active response actions (e.g. blocking IP addresses).

This represents a complete security infrastructure takeover and effectively blinds the organization’s SIEM/XDR capabilities.

Observed Exploitation & Threat Activity

Multiple public PoC exploits available since March 2026 (e.g. hakaioffsec/CVE-2026-25769).
Active scanning and exploitation attempts reported in the wild.
High likelihood of rapid adoption by threat actors due to:
- trivial exploitation with ready‑to‑use scripts,
- high impact (root RCE on the master),
- presence in many enterprise security stacks.

Severity & Metrics

CVSS v3.1: Critical (9.1)
Attack Vector: Network
Privileges Required: High (needs a compromised worker or valid cluster credentials)
User Interaction: None

Relevant CWE:

CWE-502 – Deserialization of Untrusted Data
CWE-94 – Improper Control of Code Generation (Code Injection)
CWE-20 – Improper Input Validation

Patch & Vendor Status

Fixed in Wazuh version 4.14.3.
Patch introduces a whitelist of allowed modules/functions and replaces dangerous eval() logic with safe alternatives (ast.literal_eval).
No official workaround provided by the vendor – upgrading is the only fully effective solution.

Mitigation & Remediation

Immediate Actions

Upgrade Wazuh to version 4.14.3 or later on all cluster nodes (master and workers).
If immediate upgrade is impossible:
- Block port 1516/TCP on the master node from all IPs except those of legitimate worker nodes:
```
iptables -A INPUT -p tcp --dport 1516 -s <WORKER_IP> -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -j DROP
```
- Restrict network access to the cluster communication channel.

Defensive Measures

Rotate the cluster key regularly (stored in ossec.conf).
Harden worker nodes – treat them as sensitive resources.
Segment network: place worker and master nodes in isolated VLANs.
Monitor for anomalous cluster messages (e.g. unexpected __callable__ keys).
Use TLS instead of pre‑shared keys where possible (requires architectural changes).
Disable unused DAPI functionality if custom compilation is possible.

Detection & Hunting

Indicators of Exploitation:

Log errors related to as_wazuh_object, __callable__, or unhandled_exc in /var/ossec/logs/ossec.log.
Unusual child processes spawned from the wazuh-manager process (e.g. bash, sh, python3, curl, wget).
Unexpected outbound connections from the master node (reverse shells, data exfiltration).
Sudden changes in detection rules, active response commands, or agent keys.
Cluster traffic spikes or anomalous DAPI messages.

Log Sources to Monitor:

Wazuh main log: /var/ossec/logs/ossec.log
Wazuh cluster log: /var/ossec/logs/cluster.log
System process auditing (auditd, EDR)
NetFlow / firewall logs for port 1516/TCP

Sample Sigma Rule (Concept):

title: Wazuh Suspicious Child Process from wazuh-manager
id: 8c4f2a1b-3e5d-4c7e-9a2b-1d3e5f7a8b9c
status: experimental
description: Detects suspicious child processes spawned by wazuh-manager
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    ParentImage: '/var/ossec/bin/wazuh-manager'
    Image:
      - '/bin/bash'
      - '/bin/sh'
      - '/usr/bin/python*'
      - '/usr/bin/curl'
      - '/usr/bin/wget'
  condition: selection
level: critical

Post‑Incident Response

If exploitation is suspected:

Isolate the affected master node immediately – disconnect it from the network.
Preserve forensic evidence:
- Full disk image or at least /var/ossec/logs/
- Memory capture
- Network traffic capture from the master
Rotate all credentials and keys stored on or managed by Wazuh:
- Agent keys
- Cluster key
- API credentials (e.g. wazuh-wui)
- Any secrets stored in custom rules or active responses
Audit the entire Wazuh infrastructure for backdoors:
- Modified rules or decoders
- Extra active response commands
- Unauthorised changes to ossec.conf
- New cron jobs, SSH keys, systemd services
Assume full compromise of the master – do not simply roll back configurations.
Rebuild master node from a trusted clean installation and restore only verified data from backups.
Review all worker nodes – they may have been used as entry points.

References

Wazuh Security Advisory: GHSA-3gm7-962f-fxw5 (GitHub)
NVD – CVE-2026-25769
GitHub – hakaioffsec/CVE-2026-25769 (PoC exploit)
CWE-502 – Deserialization of Untrusted Data

CVE-2026-25769

Wazuh Cluster vulnerable to Remote Code Execution via Insecure Deserialization