خلاصهٔ مستند
نقص تزریق فرمان در Kestra OSS می‌تواند ایجاد و اجرای workflow دلخواه را از راه دور و بدون اطلاعات ورود ممکن کند.
شناسنامه و زمان‌بندی
- محصول: Kestra — Kestra OSS
- شناسه: CVE-2026-49869
- انتشار رکورد CVE: 2026-06-26
- افزوده‌شدن به CISA KEV: 2026-09-02
- امتیاز مرجع: 10 از ۱۰، CVSS 3.1؛ ارائه‌دهنده: GitHub_M
- ردهٔ ضعف: CWE-78, CWE-184, CWE-287, CWE-918
تاریخ ورود به KEV، تاریخ کشف آسیب‌پذیری نیست. امتیاز CVSS شدت فنی را بیان می‌کند؛ میزان درمعرض‌بودن و اهمیت دارایی شما نیز در اولویت اصلاح نقش دارند.
بررسی و اصلاح
برای Kestra Kestra OSS، نسخه و پیکربندی نصب‌شده را با اطلاعیهٔ فنی پیوندشده تطبیق دهید. از نسخهٔ اصلاح‌شدهٔ مورد تأیید سازنده یا راهکار موقت صریح همان اطلاعیه استفاده کنید؛ این پرونده شمارهٔ نسخهٔ اصلاحی را حدس نمی‌زند. پس از اصلاح، وضعیت وصله و رویدادهای مرتبط را بررسی کنید. اگر محصول دیگر پشتیبانی نمی‌شود، مهاجرت به نسخهٔ پشتیبانی‌شده را در برنامه قرار دهید.
حدود این پرونده
این متن برای آگاهی و اولویت‌بندی دفاعی است؛ آزمایش نفوذ یا تأیید آلوده‌بودن شبکهٔ شما نیست. حضور در KEV نشانهٔ شواهد بهره‌برداری واقعی از آسیب‌پذیری است. مهلت‌های الزام‌آور CISA به نهادهای مشمول همان دستورالعمل مربوط‌اند و مهلت قانونی عمومی برای همهٔ کاربران نیستند.
نسخه‌ها و پلتفرم‌های گزارش‌شده
جدول زیر حداکثر ده ردیف از دادهٔ ساختاریافتهٔ رکورد رسمی CVE-2026-49869 را نشان می‌دهد. فیلدهای version، lessThan و lessThanOrEqual عمداً با نام و مقدار اصلی آمده‌اند؛ این نمایش، تشخیص خودکار اثرپذیری یا فهرست کامل همهٔ شاخه‌ها نیست. برای تصمیم نهایی، رکورد کامل و اطلاعیهٔ سازنده را بررسی کنید.
| محصول در رکورد | پلتفرم | فیلدهای نسخه — عین مقادیر مرجع | وضعیت مرجع |
|---|---|---|---|
| kestra-io — kestra | — | version=< 1.0.45 | affected |
| kestra-io — kestra | — | version=>= 1.1.0, < 1.3.21 | affected |
چگونه این پرونده را به اقدام تبدیل کنیم؟
برای Kestra Kestra OSS، شناسهٔ دارایی، نسخهٔ نصب‌شده، قابلیت فعال و مسیر دسترسی را در یک یادداشت بررسی ثبت کنید. اگر دادهٔ مرجع با بسته یا شاخهٔ شما تطبیق روشن ندارد، وضعیت را «نامشخص» بگذارید و برای بررسی تکمیلی مالک تعیین کنید؛ حدس‌زدن وضعیت امن مناسب نیست.
بعد از اجرای اصلاحیه، فقط به موفقیت نصب اکتفا نکنید. نسخهٔ مؤثر سرویس، نتیجهٔ آزمون سلامت و زمان تغییر را ثبت کنید. در صورت وجود شواهد رخداد، رسیدگی به آن باید از مسیر مدیریت رخداد ادامه یابد؛ این صفحه آلوده‌بودن یا نبودن هیچ شبکه‌ای را تأیید نمی‌کند.
بردار امتیاز و حدود ارزیابی
بردار ثبت‌شده در مرجع: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS متعلق به FIRST است و با اجازه استفاده می‌شود. این امتیاز مرجع، جایگزین ارزیابی محیط سازمان نیست. دادهٔ نسخه‌ها از رکورد دریافت‌شده برای این بازبینی استخراج شده و با به‌روزرسانی منابع ممکن است تغییر کند.
یادداشت تحلیلی برای مسئول این دارایی
این بخش به خواندن عملی پروندهٔ CVE-2026-49869 اختصاص دارد. دادهٔ مرجع و امتیازِ گزارش‌شده در بخش‌های قبل آمده‌اند؛ پیشنهادهای این قسمت، برنامهٔ بررسی هستند و گزارش نفوذ به یک سازمان واقعی نیستند. برای Kestra Kestra OSS نخست باید معلوم باشد کدام تیم مالک سرویس است، کدام تیم تغییر را اجرا می‌کند و چه کسی نتیجه را می‌پذیرد. داشتن نام محصول در یک اسکن، با اثبات اثرپذیری همان نصب تفاوت دارد. نتیجهٔ معتبر باید به نسخه، قابلیت و مسیر دسترسی مشخص وصل شود.
در یک برگهٔ بررسی، نام قابل فهم سرویس را کنار شناسهٔ فنی دارایی بنویسید. سپس منبعی را که نسخه از آن خوانده شده ثبت کنید: پنل تجهیز، بستهٔ سیستم‌عامل، تصویر کانتینر یا خود پردازه. این منابع گاهی یکسان نیستند؛ نصب بستهٔ تازه لزوماً به معنی اجرای پردازهٔ تازه نیست. برای رفع اختلاف، به روش رسمی سازنده رجوع کنید و مقدار قبلی را بدون توضیح پاک نکنید. ردِ تصمیم‌ها در بررسی بعدی از یک وضعیت سبزِ بدون شواهد مفیدتر است.
مسیر رسیدن به مؤلفهٔ آسیب‌پذیر
در این بردار، مسیر حمله از نوع شبکه‌ای گزارش شده است. برای تحلیل محیط، فقط به داشتن یا نداشتن IP عمومی اکتفا نکنید. مسیرهای عبور از پراکسی، شبکهٔ خصوصی، تونل دسترسی و سرویس‌های همکار را روی نقشه بیاورید. سپس بررسی کنید درخواست نهایتاً به مؤلفهٔ آسیب‌پذیر می‌رسد یا در مرزی کنترل‌شده متوقف می‌شود. یک آزمایش اتصال مجاز می‌تواند دسترس‌پذیری را نشان دهد، اما به‌تنهایی امکان بهره‌برداری یا مصونیت را ثابت نمی‌کند.
در مورد Kestra Kestra OSS، خروجی پیشنهادی این مرحله یک نقشهٔ کوتاه است: مبدأ مجاز، مرز کنترل، سرویس مقصد و شاهدی که هر اتصال را تأیید می‌کند. مسیر مدیریت را از مسیر ارائهٔ خدمت جدا بنویسید. اگر محصول چند گره دارد، نتیجهٔ بررسی یک گره را به همهٔ گره‌ها تعمیم ندهید. هر مرزی که هنوز اندازه‌گیری نشده باید در گزارش علامت سؤال داشته باشد، نه علامت تأیید.
پیش‌شرط‌های دسترسی و نقش کاربر
مقدار PR:N یعنی در امتیازدهی مرجع، داشتن امتیاز دسترسی قبلی شرط حمله فرض نشده است. وجود صفحهٔ ورود در محصول را دلیل کافی برای ایمنی این پرونده ندانید؛ ممکن است بخش درگیر پیش از ورود پردازش شود. پرسش درست این است که کدام مسیر و مؤلفه در اطلاعیه مطرح است. قواعد دسترسی را بر اساس همان مسیر بررسی کنید و از تعمیم یک کنترل روی پنل مدیریت به تمام رابط‌های محصول بپرهیزید.
مقدار UI:N به این معناست که در شرایط امتیازدهی، مشارکت کاربر شرط محسوب نشده است. بنابراین توصیهٔ «روی لینک مشکوک کلیک نکنید» به‌تنهایی پاسخ عملی این پرونده نیست. راهکار اصلاح و کاهش دسترسی باید متناسب با مسیر فنی مسئله باشد.
چرا امتیاز، احتمال رخداد نیست؟
AC:L در بردار، پیچیدگی پایین‌تر شرایط حمله را نشان می‌دهد. این برچسب را به معنی وجود ابزار عمومی، موفقیت حتمی یا وقوع حمله در همین لحظه تفسیر نکنید؛ این ادعاها هر کدام به شواهد جدا نیاز دارند.
فیلد Scope در خانوادهٔ CVSS نسخهٔ سه به مرز اختیار امنیتی مربوط است؛ تغییر این مرز با تفاوت دو ماشین یا دو نشانی IP یکسان نیست. برای این پرونده مقدار S:C ثبت شده است. آن را در کنار شرح رسمی بخوانید و از ساختن زنجیرهٔ نفوذ جدید صرفاً بر اساس این حرف خودداری کنید.
برای CVE-2026-49869، یک تصمیم مناسب می‌تواند شامل اصلاح فوری، کاهش موقت دسترسی یا بررسی تکمیلی سریع باشد؛ انتخاب به شواهد محیط بستگی دارد. این صفحه یک فرمول ریسک سازمانی جدید پیشنهاد نمی‌کند. اهمیت سرویس، قابلیت بازیابی، وابستگی‌های کسب‌وکار و شواهد بهره‌برداری باید کنار امتیاز فنی دیده شوند. تصمیم پذیرفته‌شده را همراه مسئول و تاریخ بازبینی ثبت کنید تا «بعداً بررسی می‌کنیم» به وضعیت دائمی تبدیل نشود.
تبدیل اثر فنی به پرسش‌های قابل بررسی
در بُعد محرمانگی، مقدار C:H به اثر بالا اشاره دارد. دارایی‌های اطلاعاتی قابل دسترس سرویس را مشخص کنید؛ فهرست نام فایل به‌تنهایی نشان نمی‌دهد داده حساس است یا افشا شده. مرز دسترسی به داده و مدارک بررسی آن اهمیت دارند.
در بُعد یکپارچگی، مقدار I:H به اثر بالا اشاره دارد. راه تأیید تغییرهای مجاز را تعیین کنید. نسخهٔ فایل، تاریخ تغییر و ثبت عملیات باید با فرایند استقرار تطبیق داده شوند؛ هر تغییر غیرمنتظره لزوماً نتیجهٔ این آسیب‌پذیری نیست.
در بُعد دسترس‌پذیری، مقدار A:H به اثر بالا اشاره دارد. سرویس وابسته، زمان قابل تحمل توقف و مسیر بازیابی را بشناسید. سلامت صفحهٔ ورودی ممکن است اختلال یک قابلیت داخلی را پنهان کند؛ آزمون باید جریان واقعی کار را نیز بسنجد.
نمونهٔ تصمیم و معیار پایان بررسی
یک سناریوی آموزشی در نظر بگیرید: دو نصب از Kestra Kestra OSS پیدا شده‌اند. نصب نخست نسخهٔ مشخص، مالک شناخته‌شده و مسیر دسترسی مستند دارد؛ دربارهٔ نصب دوم تنها نام محصول در گزارش موجود است. درست نیست هر دو را با یک نتیجه ببندیم. برای اولی می‌توان انطباق با رکورد CVE-2026-49869 را بررسی کرد، اما دومی هنوز به شناسایی نیاز دارد. این سناریو شرح رخداد واقعی یا ادعای اثرپذیری یک نسخهٔ خاص نیست؛ هدف آن نشان‌دادن تفاوت کیفیت شواهد است.
معیار پایان کار را پیش از تغییر تعیین کنید: نسخهٔ مؤثر تأیید شده باشد، قابلیت‌های لازم سالم باشند، قواعد موقت ثبت شده باشند و مسئول سرویس نتیجه را پذیرفته باشد. اگر راهکار موقت اجرا شده، تاریخ پایان یا بازبینی آن را فراموش نکنید. کنترل موقت بدون مالک ممکن است باقی بماند و بعداً با تغییر معماری بی‌اثر شود. در برابر نشانهٔ رخداد، مسیر مدیریت رخداد را جدا ادامه دهید؛ بستن تیکت نصب وصله، مجوز اعلام پاک‌بودن محیط نیست.
برای مرور مبانی، راهنمای تفاوت CVE، CVSS و KEV را کنار این پرونده بخوانید. هدف، تبدیل دادهٔ جهانی به تصمیمی قابل توضیح دربارهٔ دارایی خودتان است. پرسش‌هایی که هنوز پاسخ ندارند باید در گزارش باقی بمانند. شفافیت دربارهٔ ندانسته‌ها، از اضافه‌کردن نسخهٔ اصلاحی، شاخص نفوذ یا تضمین امنیتیِ بدون منبع مفیدتر است.
