سال‌ها پیش، در یک پروژهٔ پاکسازی سایت هک‌شده، بعد از این‌که بدافزار را پیدا و پاک کردیم، سؤال کلیدی این بود: چرا سایت هک شد؟ همه فکر می‌کردند هاست ضعیف بوده یا رمز لو رفته. اما وقتی لاگ‌ها را دیدیم، الگویی روشن بود: چهار ماه قبل از هک، یک آسیب‌پذیری در افزونهٔ فرم تماس سایت منتشر شده بود. پچ هم موجود بود. فقط کسی آن آپدیت را نصب نکرده بود. آن روز برای اولین بار متوجه شدم آن شناسه عجیب و غریب که در بوق و کرنای خبری می‌بینم، همان چیزی است که می‌توانست جلوی این حادثه را بگیرد. آن شناسه، CVE بود.

CVE یا Common Vulnerabilities and Exposures (آسیب‌پذیری‌ها و نقاط ضعف شناخته‌شده)، یک سیستم استاندارد جهانی برای شناسایی و نام‌گذاری آسیب‌پذیری‌های امنیتی نرم‌افزار است. هر آسیب‌پذیری که کشف و تأیید می‌شود، یک شناسهٔ یکتا می‌گیرد تا در سراسر جهان به‌یک شکل شناخته شود. اگر می‌خواهید در نقشهٔ امنیت سایت خودتان جای درست را ببینید، CVE ابزار اصلی شماست. مقدمهٔ مفهومی آسیب‌پذیری را در آسیب‌پذیری وب چیست و چگونه شناسایی می‌شود؟ آورده‌ام؛ این مقاله، لایهٔ عملیاتی و تصمیم‌گیری بر پایه CVE است.

CVE دقیقاً چیست و چه چیزی را استاندارد می‌کند؟

CVE در سال ۱۹۹۹ توسط موسسهٔ MITRE با حمایت مالی از سازمان امنیت داخلی آمریکا راه‌اندازی شد. مشکل اصلی که CVE حل کرد، نبود یک زبان مشترک بود. قبل از CVE، هر شرکت امنیتی و هر محقق، آسیب‌پذیری‌ها را با اسم‌های متفاوتی می‌شناخت و هماهنگی بین‌المللی برای پچ کردن تقریباً غیرممکن بود.

امروز CVE یک استاندارد جهانی است. هر آسیب‌پذیری که کشف می‌شود، از یک برنامهٔ رسمی به نام CVE Numbering Authority (CNA) یک شناسهٔ یکتا می‌گیرد و این شناسه در پایگاه داده‌های جهانی ثبت می‌شود. این شناسه، در تمام مقالات، ابزارهای اسکن، توصیه‌های امنیتی و پایگاه داده‌های سراسری، به‌عنوان شناسهٔ آن آسیب‌پذیری شناخته می‌شود.

نکته‌ای که در تجربهٔ کاری‌ام برای مدیران سایت توضیح می‌دهم: CVE یک سیستم هشدار است، نه یک پایگاه دادهٔ کامل. CVE فقط شناسه و توضیح مختصر آسیب‌پذیری را می‌دهد. تحلیل عمیق‌تر و امتیاز خطر، در پایگاه‌های دیگری مثل NVD (National Vulnerability Database) انجام می‌شود که در ادامه به آن می‌رسیم.

CVE یک دفتر اسناد رسمی برای آسیب‌پذیری‌های نرم‌افزاری است. اگر یک آسیب‌پذیری در آن دفتر ثبت نشده باشد، در عمل در گفت‌وگوی جهانی وجود خارجی ندارد.

ساختار کد CVE و نحوه خواندن آن

هر CVE یک ساختار مشخص دارد که خواندنش چند ثانیه می‌برد. فرمت کلی:

CVE-YYYY-NNNNN

سه بخش این ساختار:

  • CVE: پیشوند ثابت که نشان می‌دهد این یک شناسهٔ استاندارد آسیب‌پذیری است.
  • YYYY: سالی که CVE صادر شده. دقت کنید این سالِ انتشار CVE است، نه سال کشف یا وقوع آسیب‌پذیری.
  • NNNNN: عددی که به‌صورت ترتیبی یا تصادفی در همان سال صادر می‌شود. طول آن امروز معمولاً چهار یا پنج رقم است، اما در سال‌های پرحادثه، ممکن است به بیشتر هم برسد.

مثال واقعی: CVE-2024-12345. یعنی یک آسیب‌پذیری که در سال ۲۰۲۴ در سیستم CVE ثبت شده و شماره‌اش ۱۲۳۴۵ است. صرفاً از روی این شماره نمی‌توانید بفهمید که این آسیب‌پذیری در چه نرم‌افزاری است یا چه شدتی دارد؛ برای آن، به پایگاه دادهٔ CVE یا به NVD مراجعه کنید.

چرا CVE برای امنیت نرم‌افزار حیاتی است؟

سه نقش کلیدی که CVE در اکوسیستم امنیت ایفا می‌کند:

نقش اول: زبان مشترک جهانی

وقتی یک محقق امنیتی در ایران آسیب‌پذیری‌ای را کشف می‌کند، با ثبت آن به‌عنوان یک CVE، این اطلاعات به‌طور مستقیم به دست تیم‌های توسعه در آمریکا، اروپا و آسیا می‌رسد، بدون نیاز به ترجمه یا توصیف مکرر. این زبان مشترک، سرعت واکنش به آسیب‌پذیری‌ها را چند برابر کرده است.

نقش دوم: مبنای هشدار و پچ

ابزارهای اسکن امنیتی، سیستم‌های مدیریت وصله، و حتی افزونه‌های امنیتی وردپرس، همگی بر پایهٔ CVE کار می‌کنند. وقتی یک ابزار اسکن می‌گوید سایت شما یک آسیب‌پذیری شناخته‌شده دارد، معمولاً به CVE مربوطه استناد می‌کند. این لینک مستقیم بین کشف و پچ را ممکن می‌سازد.

نقش سوم: مبنای رتبه‌بندی خطر

سیستم‌های امتیازدهی مثل CVSS (Common Vulnerability Scoring System) بر پایهٔ CVE کار می‌کنند. هر CVE، یک امتیاز شدت می‌گیرد و این امتیاز، تصمیم می‌گیرد که یک آسیب‌پذیری چقدر فوری باید پچ شود. در بخش اکوسیستم، این مکانیزم را کامل‌تر باز می‌کنم.

در تجربهٔ پروژه‌هایی که با هک مواجه شده‌ام، تقریباً همیشه یک الگوی تکراری وجود دارد: آسیب‌پذیری هفته‌ها یا ماه‌ها قبل از هک، در قالب CVE منتشر شده بود و پچش هم موجود بود. تنها دلیل هک، این بود که مدیر سایت CVE را جدی نگرفته یا نمی‌دانسته چطور آن را رصد کند. راهنمای پاکسازی سایت هک‌شده در راهنمای پاک‌سازی سایت وردپرسی هک‌شده آمده است؛ اما پیشگیری همیشه ارزان‌تر از پاکسازی است.

اکوسیستم CVE: NVD، CVSS و MITRE

برای استفادهٔ عملی از CVE، باید چهار بازیگر اصلی این اکوسیستم را بشناسید:

MITRE

سازمان غیرانتفاعی که CVE را اداره می‌کند. کارش تخصیص شناسه‌های CVE و نگهداری فهرست رسمی است. وظیفهٔ تحلیل عمیق یا امتیازدهی را ندارد.

NVD

NVD یا National Vulnerability Database (پایگاه دادهٔ ملی آسیب‌پذیری‌ها)، توسط NIST (موسسهٔ ملی استاندارد و فناوری آمریکا) اداره می‌شود. این پایگاه داده، هر CVE را با امتیاز CVSS، تحلیل عمیق، و ارجاع به منابع اضافه منتشر می‌کند. اگر می‌خواهید یک CVE را کامل بشناسید، NVD نقطهٔ شروع اصلی است.

CVSS

CVSS یا Common Vulnerability Scoring System، یک سیستم امتیازدهی از ۰ تا ۱۰ است که شدت یک آسیب‌پذیری را می‌سنجد. امتیاز بر اساس چند معیار مشخص می‌شود: بهره‌برداری‌پذیری، تأثیر بر محرمانگی، یکپارچگی و دسترس‌پذیری. تفسیر امتیاز:

امتیاز CVSSسطح شدتواکنش پیشنهادی
۰/۱ – ۳/۹کمدر بازهٔ معمول آپدیت
۴/۰ – ۶/۹متوسططی روزهای آینده
۷/۰ – ۸/۹بالاطی ۲۴ تا ۴۸ ساعت
۹/۰ – ۱۰/۰بحرانیفوری، حتی در ساعات شبانه

CNA

CNA یا CVE Numbering Authority، سازمان‌هایی هستند که مجوز تخصیص CVE را دارند. امروز بیش از ۲۰۰ سازمان در سراسر جهان CNA هستند، از جمله مایکروسافت، گوگل، اوراکل، و شرکت‌های امنیتی بزرگ. وجود شبکهٔ CNAها، سرعت ثبت CVEها را به‌شدت افزایش داده است.

تفاوت CVE با CWE، CVSS و Zero-Day

این اصطلاحات اغلب با هم اشتباه گرفته می‌شوند. تفاوت‌شان را در یک جمله:

  • CVE: یک آسیب‌پذیری مشخص در یک نسخهٔ مشخص از یک نرم‌افزار مشخص. مثل شمارهٔ پرونده در دادگاه.
  • CWE (Common Weakness Enumeration): یک نوع ضعف عمومی. مثل طبقهٔ بندی پرونده — مثلاً نقص ورودی‌های نامعتبر یا نشت اطلاعات.
  • CVSS: امتیاز شدت یک آسیب‌پذیری. مثل درجهٔ جرم.
  • Zero-Day: آسیب‌پذیری که هنوز پچی برایش منتشر نشده یا هنوز عمومی نشده است. Zero-Day می‌تواند یک CVE داشته باشد یا نداشته باشد؛ چون Zero-Day به وضعیت پچ اشاره می‌کند نه به شناسه. مفهوم دقیق Zero-Day را در آسیب‌پذیری Zero Day چیست؟ باز کرده‌ام.

یک مثال عینی برای روشن شدن تفاوت: فرض کنید یک افزونهٔ وردپرس در فرآیند بررسی ورودی کاربر ضعف دارد (این CWE است: نوع ضعف). یک محقق این ضعف را در نسخهٔ ۲/۳ همان افزونه کشف می‌کند و بعد از گزارش، یک شناسهٔ CVE-2024-12345 برای آن صادر می‌شود (این CVE است: آسیب‌پذیری مشخص). NVD به این CVE امتیاز ۸/۵ می‌دهد (این CVSS است: شدت). تا زمانیکه پچ منتشر نشود، این آسیب‌پذیری Zero-Day محسوب می‌شود.

CVE در وردپرس و افزونه‌ها

وردپرس و اکوسیستم افزونه‌هایش، یکی از بزرگ‌ترین منابع CVE در جهان است. سه دلیل:

دلیل اول: تعداد بالا

بیش از ۶۰ هزار افزونه در مخزن رسمی وردپرس وجود دارد و بیش از ۴۰ درصد کل سایت‌های جهان با وردپرس ساخته شده‌اند. این حجم عظیم، سطح حملهٔ گسترده‌ای ایجاد می‌کند و به همان نسبت، تعداد CVEها بالا می‌رود.

دلیل دوم: کیفیت متغیر افزونه‌ها

هر توسعه‌دهنده‌ای می‌تواند افزونه در مخزن وردپرس منتشر کند و همه‌شان سطح بالایی از رعایت استاندارد امنیتی ندارند. این تنوع در کیفیت، خودش منبع آسیب‌پذیری‌هاست. روش تشخیص افزونه‌های مسئولیت‌پذیر در آسیب‌پذیری افزونه‌های وردپرس چه خطراتی دارد؟ آمده است.

دلیل سوم: دیر آپدیت کردن کاربران

حتی وقتی CVE منتشر و پچ ارائه می‌شود، بسیاری از کاربران وردپرس آپدیت را دیر نصب می‌کنند. این پنجرهٔ زمانی بین انتشار CVE و نصب پچ، طلایی‌ترین زمان برای مهاجمان است.

چهار افزونهٔ وردپرسی که در تجربهٔ من بیشترین سابقهٔ CVE بحرانی دارند: افزونه‌های فرم‌ساز (به‌خاطر پردازش ورودی کاربر)، افزونه‌های صفحه‌ساز، افزونه‌های فروشگاهی (ووکامرس و الحاقی‌هایش) و افزونه‌های آپلود فایل. با این چهار دسته باید سختگیرترین سیاست‌ها را در پیش بگیرید. راهنمای فنی برای پیگیری CVEهای افزونه در چگونه امنیت قالب و افزونه وردپرس را بررسی کنیم؟ آمده است.

چطور یک گزارش CVE را درست بخوانیم؟

هر CVE در NVD یک ساختار مشخص دارد و یاد گرفتن خواندن درست آن، در تصمیم‌گیری سریع حیاتی است. پنج بخش اصلی که باید ببینید:

  1. Description: توضیح مختصر آسیب‌پذیری. معمولاً شامل نام نرم‌افزار، نسخه‌های آسیب‌پذیر و نوع ضعف است.
  2. CVSS Score: امتیاز شدت. این عدد، اولویت شما را تعیین می‌کند.
  3. Affected Versions: نسخه‌هایی که در معرض آسیب‌پذیری هستند. اگر نسخهٔ شما در این بازه نیست، معمولاً امن هستید — اما شرایط را دوباره بررسی کنید.
  4. References: منابع اصلاح، معمولاً شامل لینک به پچ یا نسخهٔ اصلاح‌شده.
  5. CWE ID: نوع ضعف. این به شما می‌گوید آسیب‌پذیری از چه جنسی است و چه سطحی از دانش برای سوءاستفاده لازم است.

در تجربهٔ خواندن صدها CVE، الگویی که به‌کارم آمده: اگر CVSS بالای ۷ و نسخهٔ شما در بازهٔ آسیب‌پذیر است، پچ را فوراً نصب کنید. اگر CVSS بین ۴ تا ۷ و آسیب‌پذیری نیاز به دسترسی فیزیکی یا شرط خاص دارد، برنامه‌ریزی روزهای آینده کافی است. اگر CVSS زیر ۴ و آسیب‌پذیری عملاً غیرقابل بهره‌برداری است، در بازهٔ معمول آپدیت انجام دهید.

CVE به شما نمی‌گوید چه کاری انجام دهید؛ شرایط را توصیف می‌کند و شرایط به شما می‌گوید چقدر فوری باید واکنش نشان دهید. تفاوت تیم حرفه‌ای و آماتور در سرعت این تفسیر است.

CVE به‌عنوان ابزار تصمیم: کدام آسیب‌پذیری را اول پچ کنیم؟

در دنیای واقعی، هیچ سایتی هر CVE جدید را نمی‌تواند فوراً پچ کند. باید اولویت‌بندی کنید. چارچوبی که در پروژه‌ها استفاده می‌کنم، سه سؤال است:

سؤال اول: آیا این آسیب‌پذیری، نرم‌افزاری را هدف می‌گیرد که در سایت من نصب است؟

اولین فیلتر. اگر CVE برای نرم‌افزاری است که در سایت شما نصب نیست، در اولویت اول قرار نمی‌گیرد (اما برای پایش آینده ثبت شود).

سؤال دوم: امتیاز CVSS چیست؟

امتیاز بالای ۹ یعنی فوری، حتی اگر نیمه‌شب باشد. امتیاز بین ۷ تا ۹ یعنی حداکثر دو روز. امتیاز بین ۴ تا ۷ یعنی یک هفته. امتیاز زیر ۴ یعنی در بازهٔ معمول آپدیت.

سؤال سوم: آیا این آسیب‌پذیری به‌طور فعال در حال بهره‌برداری است؟

این مهم‌ترین فیلتر است که اکثر سایت‌ها به آن توجه نمی‌کنند. بعضی آسیب‌پذیری‌ها حتی با CVSS بالا، در عمل کسی سراغشان نمی‌رود. برعکس، بعضی آسیب‌پذیری‌ها با CVSS متوسط، در حملات فعال استفاده می‌شوند. برای دیدن بهره‌برداری فعال، منابعی مثل KEV (Known Exploited Vulnerabilities) از CISA وجود دارد. اگر CVE در KEV هست، بدون توجه به CVSS، فوراً پچ کنید.

یک توصیهٔ عملی که در پروژه‌های تیمی جا افتاده: یک پایگاه دادهٔ داخلی از CVEهای مرتبط با نرم‌افزارهای نصب‌شده در سایت‌های مشتریان نگه دارید. این کار، واکنش را از روز به ساعت کاهش می‌دهد. فهرست ابزارهای خودکار برای این کار در بهترین ابزارهای اسکن بدافزار کدامند؟ و اسکنرهای آسیب‌پذیری وب کدامند؟ آمده است.

پاسخ به پرسش‌های پرتکرار درباره CVE

CVE چیست به زبان ساده؟

CVE یک شناسهٔ استاندارد جهانی برای آسیب‌پذیری‌های امنیتی نرم‌افزار است. هر آسیب‌پذیری که کشف می‌شود، از طرف موسسهٔ MITRE یک شمارهٔ یکتا مثل CVE-2024-12345 می‌گیرد تا در سراسر جهان به‌یک شکل شناخته شود. این استاندارد باعث می‌شود هماهنگی بین محققان، ابزارهای امنیتی و توسعه‌دهندگان سریع‌تر انجام شود.

تفاوت CVE و CVSS چیست؟

CVE شناسهٔ یک آسیب‌پذیری است (مثل شمارهٔ پرونده)، در حالی که CVSS امتیاز شدت همان آسیب‌پذیری است (مثل درجهٔ جرم). هر آسیب‌پذیری یک CVE و یک امتیاز CVSS دارد. CVE می‌گوید چه آسیب‌پذیری است، CVSS می‌گوید چقدر خطرناک است.

چطور از وجود CVEهای جدید مطلع شوم؟

چند مسیر رسمی وجود دارد: دنبال کردن پایگاه NVD، عضویت در خبرنامه‌های امنیتی مثل WPScan برای وردپرس، و فعال‌سازی هشدارهای امنیتی در افزونه‌های امنیتی سایت. بهترین ترکیب، پایگاه دادهٔ NVD برای دیدن همه‌چیز و WPScan برای تمرکز روی اکوسیستم وردپرس است. ابزارها در بهترین افزونه‌های امنیتی وردپرس هم به‌طور غیرمستقیم این هشدارها را پوشش می‌دهند.

آیا هر آسیب‌پذیری CVE می‌گیرد؟

خیر. فقط آسیب‌پذیری‌هایی که توسط یک CNA معتبر تأیید و به MITRE گزارش شوند، CVE می‌گیرند. آسیب‌پذیری‌های کوچک، آسیب‌پذیری‌های نرم‌افزارهای کاملاً داخلی، و آسیب‌پذیری‌های ناشناس، معمولاً CVE نمی‌گیرند. همچنین بعضی آسیب‌پذیری‌ها عمداً CVE نمی‌گیرند چون ممکن است افشای زودهنگام به کاربران آسیب بزند.

آیا CVE فقط برای نرم‌افزارهای بزرگ است؟

خیر. هر نرم‌افزاری، از یک افزونهٔ کوچک وردپرس تا سامانه‌های بزرگ سازمانی، می‌تواند CVE بگیرد. در حقیقت، بعضی از خطرناک‌ترین CVEها مربوط به نرم‌افزارهای کوچک اما پرکاربرد هستند. اگر یک افزونهٔ کوچک با ۱۰۰ هزار نصب فعال CVE بحرانی بگیرد، اثرش می‌تواند از یک سامانهٔ سازمانی که فقط ۱۰ مشتری دارد بیشتر باشد.

آیا CVE برای آسیب‌پذیری که پچ شده هم می‌ماند؟

بله. CVE یک ثبت تاریخی است و پس از انتشار، حذف نمی‌شود. حتی اگر پچ منتشر شود، CVE مربوطه در NVD باقی می‌ماند اما با علامت پچ‌شده. این برای تاریخچه و برای سایت‌هایی که هنوز نسخهٔ قدیمی را دارند، حیاتی است. اگر سایتی نسخهٔ قدیمی را داشته باشد، CVE همچنان معتبر و مرتبط است.

پنج گام عملی: از شناخت CVE تا پچ سریع

اگر امروز می‌خواهید CVE را در کار خودتان جدی بگیرید، این پنج گام را اجرا کنید:

  1. فهرست نرم‌افزارهای سایت را بسازید: وردپرس، قالب، افزونه‌ها با نسخه‌های فعلی. این فهرست، پایهٔ همهٔ اقدامات بعدی است.
  2. عضویت در هشدارهای امنیتی: خبرنامهٔ WPScan برای وردپرس، و دنبال کردن NVD برای بقیه. یک ایمیل روزانه یا هفتگی که فقط CVEها را گزارش می‌دهد، کافی است.
  3. آپدیت خودکار افزونه‌های بحرانی را فعال کنید: برای افزونه‌های امنیتی، فرم‌ساز، و فروشگاهی، آپدیت خودکار می‌تواند پنجرهٔ حمله را به‌شدت کوچک کند. روشش در خطای بروزرسانی خودکار وردپرس آمده است.
  4. یک تیم یا فرد مسئول تعیین کنید: پایش CVE نباید به شانس سپرده شود. در تیم، یک نفر مسئول هفتگی پایش هشدارها باشد و در صورت CVE بحرانی، در کمتر از ۲۴ ساعت اقدام کند.
  5. یک گزارش پس از هر پچ بنویسید: چه CVE پچ شد، چه نسخه‌ای به چه نسخه‌ای رفت، چه تغییری در رفتار سایت دیده شد. این گزارش‌ها بعداً برای بازبینی و آموزش تیم ارزشمندند.

در تجربهٔ پروژه‌هایی که روی CVE کار کرده‌ام، تیم‌هایی که این پنج گام را جدی می‌گیرند، تقریباً هیچ‌وقت هک نمی‌شوند — نه چون امنیت‌شان کامل است، بلکه چون پنجرهٔ حمله را به‌قدری کوچک می‌کنند که مهاجمان سراغشان نمی‌روند. امنیت همیشه یک نبرد مستمر است، نه یک وضعیت ثابت. مفاهیم پایه‌ای این نبرد را در راهنمای امنیت وردپرس برای مبتدیان و در مقیاس بزرگ‌تر در اشتباهات امنیتی رایج در وردپرس آورده‌ام.

اگر تجربه‌ای از مواجهه با CVE بحرانی در پروژهٔ خودتان دارید — به‌خصوص اگر شرایطی پیش آمده که در این مقاله نگنجیده — برایم بنویسید. همین جزئیات میدانی، به خوانندگان بعدی کمک می‌کند که واکنش سریع‌تری داشته باشند و از هزینه‌های سنگین هک پیشگیری کنند. 🛡️