«روز صفر» (zero-day) پرمصرف‌ترین و بدفهم‌ترین اصطلاح امنیت است. در دقیق‌ترین معنا، آسیبپذیری روز صفر آسیبپذیریای است که وصلهای برایش وجود ندارد — و همین یک جمله، بخش بزرگی از آنچه در فارسی «روز صفر» نامیده میشود را از این دسته بیرون می‌کند. اگر وصله منتشر شده و شما نصب نکرده‌اید، آن آسیبپذیری N-day است. این مقاله سه اصطلاح روز صفر را از هم جدا می‌کند، نشان می‌دهد شناسهی CVE در چه لحظه‌ای تخصیص می‌یابد، فهرست CISA KEV چه سیگنالی می‌دهد، و مدافع در برابر چیزی که وصله ندارد واقعاً چه کاری میتواند بکند.
در یک نگاه
- سه اصطلاح جدا: آسیبپذیری روز صفر (وصله ندارد)، اکسپلویت روز صفر (کدی که از آن بهره می‌برد)، و حمله‌ی روز صفر (استفاده‌ی واقعی از آن علیه هدف).
- آسیبپذیری وصله‌نشده‌ای که وصله‌اش موجود است، روز صفر نیست — N-day است؛ و N-dayها عامل رخنه‌های واقعی بیشتری هستند.
- شناسهی CVE نشانه‌ی وجود وصله نیست و ثبت CVE با غنی‌سازی کامل رکورد در NVD هم‌زمان نیست.
- فهرست CISA KEV سیگنال «واقعاً در حال بهرهبرداری است» را می‌دهد و باید بالاتر از امتیاز خام CVSS در اولویتبندی بنشیند.
- وصلهی مجازی (قاعدهی WAF) زمان می‌خرد و هیچ‌گاه رفع محسوب نمی‌شود؛ به‌ویژه در برابر کنترل دسترسی، منطق کسبوکار و SSRF ساختاراً بیاثر است.
روز صفر چیست؟ سه اصطلاحی که یکی نیستند
در گفت‌وگوی روزمره هر سه با یک نام خوانده می‌شوند و همین باعث بی‌دقتی میشود:
- آسیبپذیری روز صفر (Zero-day vulnerability): ضعفی در نرمافزار که وصلهای برایش منتشر نشده است. تولیدکننده ممکن است هیچ اطلاعی نداشته باشد، یا مطلع باشد و در حال کار روی اصلاح.
- اکسپلویت روز صفر (Zero-day exploit): کد یا روال مشخصی که از آن آسیبپذیری بهرهبرداری می‌کند. وجود آسیبپذیری به‌معنی وجود اکسپلویت نیست؛ فاصله‌ی بین این دو میتواند از چند ساعت تا هرگز باشد.
- حمله‌ی روز صفر (Zero-day attack): استفاده‌ی واقعی از آن اکسپلویت علیه یک هدف مشخص. این پایین‌ترین فراوانی را در بین سه مفهوم دارد.
عدد «صفر» به روزهای فرصت مدافع اشاره دارد: در لحظهی شروع بهرهبرداری، صفر روز برای نصب وصله وجود داشته، چون وصلهای نبوده.
آسیبپذیری میتواند برای تولیدکننده ناشناخته باشد اما برای یک بازیگر خاص شناخته‌شده. همچنین میتواند عمومی افشا شده باشد و همچنان وصله نداشته باشد — این حالت را گاهی «0-day منتشرشده» می‌نامند و خطرناک‌ترین وضعیت عملیاتی است، چون جزئیات عمومی است و راه‌حل رسمی نیست.
مکانیزم فنی و نمونه‌های تاریخی این دسته در دانشنامه‌ی zero-day آمده است؛ این مقاله روی تفکیک مفاهیم و تصمیم عملیاتی تمرکز دارد.
باور غلط بزرگ: «هر آسیبپذیری وصله‌نشده روز صفر است»
«روی سرور ما یک آسیبپذیری وصله‌نشده هست، پس در معرض یک روز صفر هستیم.» اگر تولیدکننده وصله را منتشر کرده و شما نصب نکرده‌اید، آن آسیبپذیری N-day است، نه روز صفر. این تفکیک لفظی نیست: در برابر روز صفر واقعاً کار مشخصی برای «رفع» وجود ندارد و تنها دفاع در عمق و تشخیص می‌ماند؛ در برابر N-day کار مشخصی وجود دارد که انجام نشده است. برچسب اشتباه «روز صفر» در واقع مسئولیت را جابه‌جا می‌کند.
حرف N در N-day به تعداد روزهای سپری‌شده از انتشار وصله اشاره دارد. و نکته‌ی مهم اینجاست که انتشار وصله ریسک را در کوتاه‌مدت بالا می‌برد: با انتشار اصلاح، جزئیات فنی عملاً عمومی میشود و مهاجمان با مقایسه‌ی نسخه‌ی وصله‌شده و قبلی اکسپلویت می‌سازند. برای دارنده‌ی سامانه‌ی وصله‌نشده، لحظهی انتشار وصله آغاز شمارش معکوس است، نه پایان ماجرا.
دو نمونه‌ی مشهور که OWASP هم در سناریوهای دسته‌ی A03:2025 نقص‌های زنجیره‌ی تأمین نرمافزار به آنها نام می‌برد، بهترین گواه‌اند:
- Log4Shell —
CVE-2021-44228در کتابخانه‌ی Log4j. در روزهای اول یک وضعیت اضطراری واقعی بود، اما سال‌ها پس از انتشار وصله همچنان در سامانه‌های وصله‌نشده مورد بهرهبرداری قرار می‌گرفت. یعنی عمر آسیبپذیری به‌عنوان «روز صفر» چند روز بود و به‌عنوان N-day سال‌ها. - RCE در Struts 2 —
CVE-2017-5638. سال‌ها پس از انتشار وصله همچنان یکی از پرکاربردترین مسیرهای ورود در اسکن انبوه اینترنت بود.
پیامد مدیریتی روشن است: اگر فرایند وصلهی شما ضعیف است، هزینه‌کردن برای «دفاع در برابر روز صفر» سرمایه‌گذاری در جای اشتباه است. تفکیک کامل واژگان (ضعف، آسیبپذیری، تهدید، ریسک) در آسیبپذیری چیست آمده است.
خط زمانی: از کشف تا وصله
یک آسیبپذیری در طول عمرش برچسبش عوض میشود، و دانستن اینکه الان کجای این خط ایستاده‌اید تعیین می‌کند چه کاری معنا دارد:
| مرحله | وضعیت وصله | برچسب درست | کار مؤثر مدافع |
|---|---|---|---|
| ایجاد در کد | — | ضعف نهفته | بازبینی کد، مدل‌سازی تهدید |
| کشف توسط مهاجم، ناشناخته برای تولیدکننده | ندارد | روز صفر | دفاع در عمق، تشخیص رفتاری، کاهش سطح حمله |
| افشای عمومی پیش از وصله | ندارد | روز صفر منتشرشده | کنترل جبرانی موقت، پایش شدید، آماده‌باش پاسخ به رخداد |
| انتشار وصله | دارد | روز اول N-day | وصلهی اضطراری با اولویت |
| مدت‌ها پس از وصله | دارد | N-day | وصله؛ و بررسی اینکه چرا فرایند وصله کار نکرد |
در مسیر سالم، انتقال از مرحله‌ی دوم به چهارم از راه افشای هماهنگ رخ می‌دهد: پژوهشگر به تولیدکننده گزارش می‌دهد، مهلت معقولی برای رفع داده میشود و سپس جزئیات عمومی میشود. چارچوب و انتظارات دو طرف در افشای مسئولانه توضیح داده شده و اگر خودتان چیزی در سامانه‌ی دیگری یافتید، همان سند مسیر درست را نشان می‌دهد.
CVE و NVD: شناسه از چه لحظه‌ای هست و چه چیزی را تضمین نمی‌کند
سه گزاره‌ای که مرتب اشتباه فهمیده می‌شوند:
- وجود شناسهی CVE به‌معنی وجود وصله نیست. شناسه فقط یک نام یکتا برای ارجاع به یک آسیبپذیری مشخص در یک محصول مشخص است. CVE میتواند پیش از انتشار وصله رزرو و منتشر شود.
- نبود CVE به‌معنی نبود آسیبپذیری نیست. آسیب‌پذیری‌های کد اختصاصی شما هرگز CVE نمی‌گیرند؛ برچسب درست‌شان شناسهی CWE است. اکثر یافته‌های یک تست نفوذ وب در همین دسته‌اند.
- ثبت CVE با غنی‌سازی کامل رکورد یکی نیست. رکورد CVE ابتدا با اطلاعات پایه منتشر میشود و افزودن داده‌های تحلیلی — امتیاز CVSS، فهرست نسخه‌های متأثر (CPE)، نگاشت CWE — گام جداگانه‌ای در NVD است. تأخیر در این غنی‌سازی در سال‌های اخیر موضوع شناخته‌شده‌ای بوده و پیامد عملی‌اش برای شما این است که نمی‌توانید فرایند وصلهی خود را فقط به «آمدن امتیاز CVSS در NVD» گره بزنید؛ گاهی باید بر پایه‌ی توصیه‌نامه‌ی خود تولیدکننده تصمیم بگیرید.
یک واقعیت مقیاس هم بگوییم: در مجموعه‌داده‌ای که OWASP برای Top 10:2025 استفاده کرد، از حدود ۲۲۰٬۰۰۰ رکورد CVE، ۱۵۶ هزار امتیاز CVSS v3 داشتند و فقط ۶ هزار امتیاز v4 — یعنی حتی در پذیرش نسخه‌ی امتیازدهی هم اکوسیستم یکدست نیست. جزئیات در دانشنامه‌ی CVE و دانشنامه‌ی CVSS.
CISA KEV: سیگنال «واقعاً در حال بهرهبرداری»
مشکل اولویتبندی این است که تعداد CVEها از توان هر تیمی بیشتر است و امتیاز CVSS به‌تنهایی نمی‌گوید کدام‌یک همین حالا در حال بهرهبرداری است. فهرست KEV (Known Exploited Vulnerabilities) که CISA منتشر می‌کند، دقیقاً این شکاف را پر می‌کند: فهرستی از آسیبپذیریهایی که برای بهرهبرداری فعال آنها شواهد قابل اعتماد وجود دارد و اقدام اصلاحی روشنی دارند.
کاربرد عملی برای یک تیم فنی ایرانی، فارغ از الزامات دولتی آمریکا، سه چیز است:
- قاعدهی اولویت: اگر CVE مربوط به یکی از اجزای شما در KEV هست، آن مورد بالاتر از یک CVE با امتیاز بالاتر که در KEV نیست می‌نشیند. «امتیاز ۹٫۸ ولی هیچ اکسپلویتی در میدان نیست» با «امتیاز ۷٫۵ و بهرهبرداری فعال» یکی نیست.
- ورودی برای متریک Exploit Maturity در CVSS v4.0، که همان سازوکار رسمی وارد کردن این سیگنال در امتیاز است (نام‌گذاری CVSS-BT).
- ابزار گفت‌وگو با مدیریت: «این مورد در فهرست رسمی آسیب‌پذیری‌های تحت بهرهبرداری فعال است» جمله‌ی مؤثرتری از «امتیازش بالاست» است.
در همین راستا، MITRE کنار فهرست ۲۵ ضعف خطرناک سال ۲۰۲۵، فهرست جداگانه‌ای هم با نام «۱۰ ضعف برتر KEV» منتشر کرده — یعنی ضعف‌هایی که بیشترین حضور را در آسیب‌پذیری‌های واقعاً بهره‌برداری‌شده دارند. این دو فهرست را با هم بخوانید: یکی می‌گوید چه ضعف‌هایی پرتکرار و پرخطرند، دیگری می‌گوید مهاجمان عملاً از کدام‌ها استفاده می‌کنند.
چرا میدان اصلی روز صفرِ وب، زنجیره‌ی تأمین است
برای یک برنامه‌ی وب، احتمال اینکه یک آسیبپذیری روز صفر در کد اختصاصی شما هدف یک بهرهبرداری انبوه شود پایین است — مهاجم برای یک هدف واحد چنین هزینه‌ای نمی‌کند. آنچه واقعاً اتفاق می‌افتد این است که آسیبپذیری در چیزی پیدا میشود که هزاران سایت از آن استفاده می‌کنند: فریم‌ورک، کتابخانه، افزونه، وب‌سرور، پنل مدیریت پایگاه‌داده، یا خودِ خط لوله‌ی ساخت.
به همین دلیل OWASP در نسخه‌ی ۲۰۲۵ دسته‌ی A03 نقص‌های زنجیره‌ی تأمین نرمافزار را از رتبه‌ی ششِ ۲۰۲۱ به رتبه‌ی سه آورد و دامنه‌اش را گسترش داد تا «همه‌ی نقص‌های زنجیره‌ی تأمین را پوشش دهد، نه فقط مواردی که به آسیبپذیری شناخته‌شده مربوط‌اند». نمونه‌های رسمی این دسته دقیقاً همین الگو را نشان می‌دهند: SolarWinds با آلوده شدن حدود ۱۸٬۰۰۰ سازمان از راه به‌روزرسانی یک تأمین‌کننده‌ی مورد اعتماد، و Shai-Hulud (۲۰۲۵)، کرم خودتکثیر npm که بیش از ۵۰۰ نسخه‌ی بسته را آلوده کرد و با توکن‌های سرقتی خودش را گسترش داد.
سه اقدام که آمادگی شما را در برابر روز صفرِ بعدی تعیین می‌کند:
- SBOM و موجودی پیوسته. در ساعت اول یک Log4Shell بعدی، سؤال حیاتی این است: «آیا ما از این کتابخانه استفاده می‌کنیم و کجا؟» تیمی که نمی‌تواند در چند دقیقه پاسخ دهد، روزها را صرف جست‌وجو می‌کند.
- دریافت اجزا از منابع رسمی با راستی‌آزمایی امضا، و MFA و تفکیک وظایف روی کل زیرساخت توسعه.
- توان انتشار سریع. اگر استقرار یک نسخه‌ی جدید در سازمان شما دو هفته طول می‌کشد، آن دو هفته پنجره‌ی بهرهبرداری شماست. توان وصلهی سریع خودش یک کنترل امنیتی است.
مدافع در برابر چیزی که وصله ندارد چه می‌کند؟
پاسخ صادقانه: نمی‌توانید از آسیبپذیریای که وجودش را نمی‌دانید پیشگیری کنید. اما می‌توانید احتمال موفقیت و اثر آن را کم کنید و زمان کشف را کوتاه کنید. سه لایه:
۱) کاهش سطح حمله
هر جزئی که نصب نیست، آسیب‌پذیری‌اش هم به شما مربوط نیست. حذف افزونه‌ها و ماژول‌های بلااستفاده، بستن پنل‌های مدیریتی از دسترس عمومی، حذف محیط‌های دمو و زیردامنه‌های فراموش‌شده، و کمینه‌سازی مجوزهای کاربر پایگاه‌داده و حساب‌های سرویس. این ارزان‌ترین دفاع در برابر روز صفر است و ربطی به دانستن آسیبپذیری ندارد.
۲) دفاع در عمق و محدودسازی اثر
تفکیک شبکه و جداسازی محیط‌ها؛ کنترل خروجی (Egress) از لایه‌ی برنامه، که یکی از مؤثرترین کنترل‌ها در برابر SSRF و برقراری کانال کنترل پس از بهرهبرداری است؛ اجرای سرویس با حداقل امتیاز؛ و پرچم‌های کوکی و CSP برای محدود کردن اثر آسیب‌پذیری‌های سمت کلاینت.
۳) تشخیص و پاسخ
این همان دسته‌ی A09:2025 نقص ثبت رخداد و هشداردهی است، و تغییر نام آن از «پایش» به «هشداردهی» دقیقاً به این معناست که لاگِ بی‌هشدار کافی نیست. حداقل‌ها: ثبت رخدادهای امنیتی با زمینه‌ی کافی، مسیر ممیزی فقط-افزودنی با حفاظت یکپارچگی، هشدار برای الگوهای غیرعادی (شکست‌های مجوزدهی، حجم غیرمعمول خروج داده، ساخت کاربر جدید با نقش بالا)، و کتابچه‌ی پاسخ به رخداد که پیش از رخداد نوشته شده باشد. استقرار Honeytoken هم توصیه‌ی صریح OWASP در همین دسته است.
وصلهی مجازی: چه می‌کند و چه نمی‌کند
«یک قاعده روی WAF گذاشتیم، پس آسیبپذیری رفع شد.» وصلهی مجازی هرگز رفع نیست. ارزش واقعی آن یک چیز است: خریدن زمان بین افشای یک آسیبپذیری و لحظه‌ای که می‌توانید نسخه‌ی اصلاح‌شده را منتشر کنید — و این کاربرد کاملاً موجهی است. اما محدودیت‌هایش را باید بدانید: قاعدهی امضامحور با کدگذاری چندلایه، تغییر Content-Type، بدنه‌ی بزرگ‌تر از حد بازرسی و درخواست‌های HTTP/2 دور زده میشود؛ در برابر کنترل دسترسی، منطق کسبوکار، شرایط مسابقه و SSRF ساختاراً بیاثر است؛ DOM XSS را نمی‌بیند چون بدنه در قطعه‌ی URL هرگز به سرور نمی‌رسد؛ و اگر مهاجم IP اصلی سرور را پیدا کند، کل لایه دور زده میشود. جزئیات در دانشنامه‌ی WAF.
اگر گمان می‌کنید هدف قرار گرفته‌اید
ترتیب کار در ساعت‌های اول اهمیت دارد و اشتباه رایج، پاک کردن سریع شواهد است:
- پیش از پاک‌سازی، شواهد را نگه دارید. تصویر سیستم، لاگ وب‌سرور و برنامه، فایل‌های تغییریافته با زمان تغییر. اگر لاگ‌ها را بازنویسی کنید، تشخیص مسیر ورود غیرممکن میشود و همان مسیر بعد از بازیابی باز می‌ماند.
- محدودسازی. جداسازی سرویس متأثر، ابطال نشست‌ها و توکن‌ها، چرخش اعتبارنامه‌ها و کلیدهای API.
- تعیین مسیر ورود. نه فقط «چه چیزی خراب شد»، بلکه «از کجا آمد». بدون این گام، بازیابی موقتی است.
- پاک‌سازی و بازگردانی از نسخه‌ی پشتیبان سالم، با فرض اینکه ماندگاری مهاجم — کاربر ادمین جدید، وب‌شل، کار زمان‌بندی‌شده، کلید SSH — ممکن است در پشتیبان هم باشد.
- راستی‌آزمایی و آزمون مجدد پیش از بازگشت به سرویس.
نشانه‌هایی که باید جدی گرفت در نشانه‌های هک شدن سایت فهرست شده و روال کامل در بازیابی سایت هک‌شده و پاک‌سازی بدافزار آمده است. اگر سایت شما در فهرست سیاه موتور جست‌وجو قرار گرفته، بلک‌لیست گوگل مسیر رفع را توضیح می‌دهد.
و در سطح پیشگیرانه: بخش عمده‌ی چیزی که در گزارش‌های عمومی «حمله‌ی روز صفر» نامیده میشود، در واقع بهرهبرداری از N-day یا یک نقص کنترل دسترسی است. سنجش وضعیت واقعی با تست نفوذ وب و برقراری فرایند پیوسته با مدیریت آسیبپذیری، بازده بیشتری از هر ابزار ضدروزصفری دارد.
پرسش‌های متداول
آسیبپذیری روز صفر چیست به زبان ساده؟
آسیبپذیریای که تولیدکنندهی نرمافزار وصلهای برایش منتشر نکرده است — چون یا از آن بیخبر است یا در حال کار روی اصلاح. عدد صفر به روزهای فرصت مدافع اشاره دارد: در لحظهی بهرهبرداری، صفر روز برای نصب وصله وجود داشته.
تفاوت zero-day و N-day چیست؟
روز صفر یعنی وصله وجود ندارد. N-day یعنی وصله منتشر شده اما روی سامانه‌ی هدف نصب نشده است؛ N به تعداد روزهای گذشته از انتشار وصله اشاره دارد. اگر روی سرور شما کتابخانه‌ای با وصلهی شش‌ماهه‌ی نصب‌نشده هست، آن روز صفر نیست. در عمل هم N-dayها عامل رخنه‌های بیشتری هستند.
آیا هر CVE یک روز صفر است؟
خیر. CVE فقط یک شناسهی یکتا برای ارجاع به آسیبپذیری مشخص در محصول مشخص است و میتواند پیش یا پس از انتشار وصله منتشر شود. اکثر CVEها در لحظهی انتشار عمومی وصلهی موجود دارند — یعنی از همان روز اول N-day هستند، نه روز صفر.
چطور از حمله‌ی روز صفر جلوگیری کنیم؟
پیشگیری کامل از چیزی که وجودش معلوم نیست ممکن نیست؛ کاری که میشود کرد کاهش احتمال موفقیت، کاهش اثر و کوتاه کردن زمان کشف است: حذف اجزای بلااستفاده، بستن پنل‌های مدیریتی از دسترس عمومی، کنترل خروجی از لایه‌ی برنامه، اجرا با حداقل امتیاز، ثبت لاگ به‌همراه هشدار، و توان انتشار سریع وصله.
آیا WAF جلوی روز صفر را میگیرد؟
میتواند برای بخشی از موارد زمان بخرد — و همین «وصلهی مجازی» بهترین کاربرد یک WAF است — اما رفع نیست. قاعدهی امضامحور با کدگذاری چندلایه و تغییر قالب درخواست دور زده میشود، در برابر کنترل دسترسی و منطق کسبوکار و SSRF ساختاراً بیاثر است، و با پیدا شدن IP اصلی سرور کل لایه دور زده میشود.
فهرست CISA KEV چیست و چرا مهم است؟
فهرستی از آسیبپذیریهایی که شواهد قابل اعتماد از بهرهبرداری فعال آنها وجود دارد. اهمیتش در اولویتبندی است: یک CVE با امتیاز متوسط که در KEV هست، معمولاً فوریتر از CVE با امتیاز بالاتری است که هیچ اکسپلویتی در میدان ندارد. در CVSS v4.0 هم این سیگنال از راه متریک Exploit Maturity رسماً وارد امتیاز میشود.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.