آخرین بررسی: ۷ سپتامبر ۲۰۲۶

اگر یک Router یا Firewall مبتنی بر MikroTik RouterOS مدیریت می‌کنید، این به‌روزرسانی امنیتی را نباید مانند یک Update معمولی به تعویق بیندازید.

CERT Polska شش آسیب‌پذیری امنیتی در RouterOS شناسایی کرده است و تأیید کرده که ترکیب دو آسیب‌پذیری بحرانی در قالب زنجیره‌ای با نام MikroTrick در حملات واقعی علیه تجهیزات MikroTik مورد سوءاستفاده قرار گرفته است.

دو آسیب‌پذیری اصلی این زنجیره عبارت‌اند از:

CVE-2026-67276
CVSS 9.2
SSH Authentication Bypass

+

CVE-2026-86060
CVSS 9.2
SSH Privilege Manipulation

=

MikroTrick

در سناریوی مورد تأیید CERT Polska، دستگاه‌هایی در معرض خطر بیشتری قرار دارند که سرویس SSH آن‌ها از شبکه عمومی اینترنت قابل دسترس است.

اقدام فوری: RouterOS را به نسخه دارای Fix ارتقا دهید. صرفاً بستن SSH یا محدودکردن Firewall یک راهکار موقت است و جای نصب Patch امنیتی را نمی‌گیرد.

MikroTrick چیست؟

MikroTrick نامی است که CERT Polska برای ترکیب دو آسیب‌پذیری SSH در MikroTik RouterOS انتخاب کرده است.

CVE-2026-67276
 ↓
SSH Authentication Weakness
 ↓
CVE-2026-86060
 ↓
Privilege Manipulation
 ↓
Full Administrative Access

اهمیت این زنجیره در این است که مهاجم در شرایط لازم می‌تواند بدون داشتن Authentication معتبر عادی به دسترسی مدیریتی بسیار بالا روی RouterOS برسد.

این مسئله برای Routerهایی که SSH آن‌ها مستقیماً روی Public IP قابل دسترس است جدی‌تر است.

CVE-2026-67276؛ ضعف بحرانی در احراز هویت SSH

این آسیب‌پذیری دارای امتیاز:

CVSS: 9.2

است.

مشکل به نحوه بررسی RSA Public Key در فرآیند Authentication مربوط می‌شود.

RouterOS در نسخه‌های آسیب‌پذیر تمام اجزای Public Key را هنگام مقایسه با Key مجاز User به‌شکل صحیح بررسی نمی‌کرد.

در نتیجه در شرایط مشخص، مهاجمی که اطلاعات لازم از Public Key یک User را داشته باشد می‌تواند Authentication مبتنی بر RSA را دور بزند؛ بدون اینکه Private Key واقعی آن User را در اختیار داشته باشد.

این ضعف به معنی شکسته‌شدن عمومی RSA نیست. مشکل در نحوه اعتبارسنجی Public Key توسط RouterOS قرار دارد.

CVE-2026-86060؛ دست‌کاری سطح دسترسی در SSH

دومین Vulnerability بحرانی نیز:

CVSS: 9.2

دارد.

این ضعف در پردازش Username در مسیر SSH Login قرار دارد.

یک Username دست‌کاری‌شده می‌تواند باعث تغییر Policy Mask مورد اعتماد RouterOS شود و Session را به سطح دسترسی بالاتری برساند.

در ترکیب با CVE-2026-67276، نتیجه می‌تواند بسیار خطرناک باشد:

Authentication Bypass
+
Privilege Escalation
=
Administrative Compromise

RouterOS فقط دو آسیب‌پذیری ندارد؛ شش CVE منتشر شده است

CERT Polska در مجموع شش آسیب‌پذیری را گزارش کرده است:

CVEبخشاثر اصلی
CVE-2026-67276SSH Authenticationدورزدن Authentication مبتنی بر RSA در شرایط مشخص
CVE-2026-86060SSH LoginPrivilege Escalation
CVE-2026-67277Bandwidth TestMemory Disclosure و Remote DoS
CVE-2026-67278X.509 / TLSضعف در اعتبارسنجی RSA Signature
CVE-2026-67279SSHانجام برخی عملیات File بدون Authentication کامل
CVE-2026-67281WebFigخواندن غیرمجاز فایل در شرایط آسیب‌پذیر

CVE-2026-67277؛ Bandwidth-Test نیز آسیب‌پذیر است

این Vulnerability امتیاز:

CVSS: 8.8

دارد.

مشکل باعث می‌شود یک Client بدون Authentication کامل بتواند Bandwidth-Test را وارد حالتی کند که نباید پیش از Login قابل دسترس باشد.

پیامدهای گزارش‌شده شامل:

  • Memory Disclosure
  • Kernel Memory Leakage
  • Remote Denial of Service
  • Restart شدن RouterOS

است.

اگر Bandwidth Test Server از اینترنت در دسترس است و استفاده‌ای از آن ندارید، این Exposure باید حذف شود.

CVE-2026-67278؛ مشکل X.509 و TLS

این Vulnerability به اعتبارسنجی Signatureهای RSA/PKCS#1 v1.5 در فرآیند X.509 مربوط است.

اهمیت آن زمانی بیشتر می‌شود که RouterOS خودش یک TLS Connection به مقصدی خارج از Router ایجاد کند.

در سناریوی مناسب برای مهاجم، ضعف اعتبارسنجی می‌تواند زمینه Impersonation سمت TLS Server را ایجاد کند.

CVE-2026-67279؛ SSH قبل از تکمیل Authentication

در این ضعف، SSH State Machine در شرایطی به مرحله‌ای می‌رسد که هنوز Authentication کامل نشده، اما Session قادر به انجام برخی عملیات می‌شود.

اثر گزارش‌شده می‌تواند شامل ایجاد یا تغییر File در فضای مدیریت‌شده RouterOS باشد.

CVE-2026-67281؛ آسیب‌پذیری WebFig

این مشکل در مسیر:

/jsproxy

در WebFig قرار دارد و در شرایط آسیب‌پذیر می‌تواند به خواندن File بدون Authentication منجر شود.

این مورد یک دلیل دیگر برای این Best Practice قدیمی است:

WebFig یا WWW/WWW-SSL را مستقیماً برای کل اینترنت باز نگذارید. مدیریت Router بهتر است فقط از Management Network یا VPN انجام شود.

کدام نسخه‌های RouterOS در معرض این آسیب‌پذیری‌ها هستند؟

CERT Polska محدوده آسیب‌پذیر را به‌صورت کلی چنین اعلام کرده است:

  • RouterOS 7.24 قبل از 7.24.2
  • RouterOS 7.x قدیمی‌تر از نسخه اصلاح‌شده شاخه مربوطه
  • RouterOS 6.x قبل از 6.49.21

روش ساده‌تر برای Administrator این است که به جای تفسیر نسخه‌های آسیب‌پذیر، مطمئن شود نسخه نصب‌شده حداقل یکی از Releaseهای اصلاح‌شده یا جدیدتر است.

نسخه‌های دارای Patch

Fix امنیتی در این Releaseها منتشر شده است:

RouterOS 7 Stable:
7.24.2 یا جدیدتر

RouterOS 7 Long-term:
7.23.4 یا جدیدتر

RouterOS 6 Long-term:
6.49.21

Development:
7.25beta3 یا جدیدتر

برای شبکه Production معمولاً Stable یا Long-term مناسب‌تر از Development/Beta است. هدف این نیست که فقط به 7.25beta3 بروید؛ کافی است Release اصلاح‌شده مناسب Channel خود را نصب کنید.

نسخه RouterOS را چگونه بررسی کنیم؟

/system resource print

یا:

/system package update check-for-updates

در WinBox نیز:

System
→ Packages
→ Check For Updates

قابل استفاده است.

قبل از Update چه کنیم؟

روی Router عملیاتی ابتدا Backup و Export بگیرید:

/system backup save name=before-security-update

/export file=before-security-update

فایل‌ها را از خود Router نیز خارج کرده و در Storage امن نگهداری کنید.

اگر همین الان به Compromise مشکوک هستید، Backup را فقط به‌عنوان Evidence نگه دارید و آن را بعداً بدون بررسی روی Router تمیز Restore نکنید.

آیا MikroTrick واقعاً در حملات استفاده شده است؟

بله.

CERT Polska اعلام کرده است که سوءاستفاده از ترکیب دو Vulnerability اصلی برای تصاحب RouterOSهایی که SSH آن‌ها از Public Network قابل دسترس بوده، در حملات واقعی تأیید شده است.

این موضوع تفاوت مهمی با یک CVE صرفاً آزمایشگاهی دارد.

Vulnerability Published
 +
Exploit Chain Known
 +
Real-World Exploitation Confirmed
 =
Immediate Patch Priority

نشانه‌های مشاهده‌شده در حملات

CERT Polska چند Indicator را در حملات بررسی‌شده گزارش کرده است.

یکی از Log Patternهای مهم:

login failure for user -2 from <ip> via ssh

user <name> added by ssh:-2@<ip>

همچنین User با نام:

ops

در برخی سیستم‌های Compromised مشاهده شده است.

نبود این Indicators ثابت نمی‌کند Router سالم است. این‌ها فقط نشانه‌های شناخته‌شده حملات مشاهده‌شده هستند.

IPهای گزارش‌شده در حملات مشاهده‌شده

CERT Polska این IPها را در فعالیت‌های مشاهده‌شده ذکر کرده است:

82.192.72.4

103.102.31.18

وجود Connection از این IPها باید بررسی شود؛ اما:

IOCهای IP می‌توانند در طول زمان تغییر کنند. Firewall کردن فقط همین دو Address یک راهکار امنیتی کافی نیست و جای Patch را نمی‌گیرد.

Flagged در RouterOS چیست؟

MikroTik در Releaseهای اصلاح‌شده از مکانیزم Flagged استفاده می‌کند.

RouterOS هنگام Startup Configuration را برای برخی نشانه‌های شناخته‌شده تغییر غیرمجاز بررسی می‌کند.

اگر نشانه مشکوکی پیدا شود:

  • بعضی Configurationهای مشکوک Disable می‌شوند.
  • یک Critical Log ثبت می‌شود.
  • پارامتر Flagged برابر yes قرار می‌گیرد.

وضعیت را بررسی کنید:

/system/device-mode/print

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

flagged: yes

اگر flagged=yes است، دستگاه را بالقوه Compromised در نظر بگیرید.

اما عکس آن صحیح نیست:

flagged=no

≠

Router قطعاً سالم است

مکانیزم Flagged فقط تعدادی از نشانه‌های شناخته‌شده Compromise را تشخیص می‌دهد.

بعد از Update چه چیزهایی را بررسی کنیم؟

۱. Userها

/user print detail

هر User ناشناس را بررسی کنید؛ به‌خصوص:

ops

۲. Scripts

/system script print detail

۳. Scheduler

/system scheduler print detail

۴. IP Services

/ip service print

۵. SOCKS

/ip socks print

۶. Web Proxy

/ip proxy print

۷. NAT

/ip firewall nat print detail

۸. Firewall

/ip firewall filter print detail

۹. Interfaceها و Tunnelها

/interface print detail

۱۰. Files

/file print detail

۱۱. Log

/log print

به موارد مربوط به:

  • SSH Login
  • User Creation
  • Configuration Changes
  • Critical Flagged Message

توجه کنید.

اگر فعلاً امکان Update نداریم چه کنیم؟

این اقدامات فقط Temporary Mitigation هستند.

SSH را از اینترنت ببندید

اگر SSH نیاز ندارید:

/ip service disable ssh

اگر SSH نیاز دارید، دسترسی آن را فقط به Management Subnet یا IPهای Trusted محدود کنید.

WWW را در صورت عدم نیاز Disable کنید

/ip service disable www

WWW-SSL را نیز بدون نیاز Public نکنید

Management Serviceها بهتر است از VPN در دسترس باشند.

Bandwidth Test Server را بررسی کنید

/tool bandwidth-server print

اگر نیاز ندارید:

/tool bandwidth-server set enabled=no

WinBox را از Internet Public حذف کنید

حتی اگر Vulnerability اصلی فعلی SSH باشد، Management Plane نباید بدون ضرورت از Internet برای همه Sourceها باز باشد.

برای مدیریت Remote، یک VPN مانند WireGuard انتخاب بسیار مناسب‌تری از Public SSH، WinBox یا WebFig است. راهنمای اتصال امن با WireGuard را می‌توانید مطالعه کنید.

بستن Service جای Update را نمی‌گیرد. CERT Polska صراحتاً این اقدامات را فقط راهکار موقت کاهش Attack Surface معرفی کرده است.

اگر Router احتمالاً Compromised شده است چه کنیم؟

اگر:

  • flagged=yes مشاهده کردید،
  • User ناشناس وجود دارد،
  • Script یا Scheduler غیرعادی پیدا کردید،
  • Log مشکوک مشاهده کردید،
  • Configuration بدون توضیح تغییر کرده است،

صرفاً User مشکوک را Delete نکنید و به کار ادامه ندهید.

مرحله ۱: Router را Isolate کنید

دسترسی مهاجم به Router و شبکه داخلی را محدود کنید.

مرحله ۲: Evidence را حفظ کنید

قبل از Factory Reset:

  • Logs
  • Configuration
  • User List
  • Scripts
  • Scheduler
  • Firewall
  • Files

را برای بررسی Incident ذخیره کنید.

مرحله ۳: دستگاه را از منبع قابل اعتماد Rebuild کنید

پس از ثبت Evidence، Router باید Reset و از Configuration قابل اعتماد بازسازی شود.

Full Backup یک Router مشکوک را بدون Audit روی Router تمیز Restore نکنید. ممکن است همان Configuration مخرب را دوباره وارد دستگاه کنید.

مرحله ۴: Credentialها را Rotate کنید

در صورت تأیید یا احتمال جدی Compromise این موارد را تغییر دهید:

  • RouterOS Passwords
  • SSH Keys
  • WireGuard Keys در صورت نیاز
  • IPsec Secrets
  • PPPoE Credentials
  • RADIUS Secrets
  • API Credentials
  • SNMP Credentials

فرض کنید Secretsی که روی Router قرار داشته‌اند ممکن است افشا شده باشند.

بعد از Patch چگونه MikroTik را Hardening کنیم؟

Management را از WAN عمومی حذف کنید

ساختار مناسب‌تر:

Administrator
 ↓
WireGuard VPN
 ↓
Management VLAN
 ↓
MikroTik

نه:

Internet
 ↓
Public SSH / WinBox
 ↓
Router

سرویس‌های غیرضروری را Disable کنید

/ip service print

FTP، Telnet، WWW، API یا SSH را فقط در صورت نیاز فعال نگه دارید.

Management VLAN ایجاد کنید

در شبکه‌های سازمانی Management Plane باید از User VLAN جدا باشد.

Input Firewall را جدی بگیرید

دسترسی مستقیم به خود Router را فقط برای منابع موردنیاز Allow کنید.

Logها را خارج از Router نگهداری کنید

Remote Syslog باعث می‌شود مهاجم نتواند با پاک‌کردن Logهای Router تمام Evidence را حذف کند.

Backup منظم داشته باشید

Backup و Export را خارج از Router نگهداری کنید.

RouterOS را به‌روز نگه دارید

Routerهای Edge جزو مهم‌ترین Assetهای امنیتی شبکه هستند و Patch Management آن‌ها باید بخشی از فرآیند نگهداری شبکه باشد.

برای Hardening بیشتر مقاله اشتباهات خطرناک در تنظیمات MikroTik را نیز مطالعه کنید.

کدام Routerها اولویت بالاتری برای بررسی دارند؟

اولویت فوری را به دستگاه‌هایی بدهید که:

  • Public IP دارند.
  • SSH آن‌ها از Internet قابل دسترس است.
  • WebFig یا WinBox Public دارند.
  • Bandwidth-Test Server فعال و Public دارند.
  • Gateway اصلی سازمان هستند.
  • VPN Concentrator هستند.
  • دسترسی به VLANهای حساس دارند.
  • RouterOS قدیمی اجرا می‌کنند.

اما Update فقط محدود به این دستگاه‌ها نباشد.

برنامه اقدام پیشنهادی برای مدیر شبکه

  1. Inventory تمام RouterOS Deviceها را تهیه کنید.
  2. Version هر Router را مشخص کنید.
  3. Public Exposure سرویس‌های Management را مشخص کنید.
  4. Routerهای دارای Public SSH را در اولویت اول قرار دهید.
  5. Backup و Export تهیه کنید.
  6. RouterOS را به Release اصلاح‌شده ارتقا دهید.
  7. Router را Reboot کنید.
  8. /system/device-mode/print را بررسی کنید.
  9. Log را برای Flagged و SSH Indicators بررسی کنید.
  10. Userها را Audit کنید.
  11. Scripts و Scheduler را Audit کنید.
  12. Proxy، SOCKS و Tunnelها را بررسی کنید.
  13. Firewall و NAT را با Baseline مقایسه کنید.
  14. Public Management Services را حذف کنید.
  15. Remote Management را پشت VPN قرار دهید.
  16. Remote Logging را فعال کنید.
  17. در صورت مشاهده Compromise، Incident Response کامل اجرا کنید.

بررسی امنیت RouterOS در شبکه‌های سازمانی

در شبکه‌های سازمانی صرفاً Upgrade کردن Router کافی نیست. بهتر است Management Plane، Firewall Policy، VPN، User Access و Log Management نیز بررسی شوند.

گروه فناوری ارتباطات پندار بیستون در حوزه طراحی، پیاده‌سازی و بررسی زیرساخت‌های MikroTik فعالیت می‌کند.

اگر MikroTik شما SSH یا Management Service عمومی داشته و درباره احتمال Compromise اطمینان ندارید، قبل از هر تغییر گسترده Evidence را حفظ کرده و Configuration را به‌صورت ساختاری بررسی کنید. برای بررسی فنی شبکه می‌توانید از مشاوره فنی بیستون استفاده کنید.

سؤالات متداول

MikroTrick چیست؟

نام زنجیره حمله‌ای است که CERT Polska برای ترکیب CVE-2026-67276 و CVE-2026-86060 در RouterOS انتخاب کرده است.

آیا MikroTrick واقعاً مورد سوءاستفاده قرار گرفته است؟

بله. CERT Polska سوءاستفاده واقعی از این زنجیره علیه دستگاه‌هایی با SSH قابل دسترس از شبکه عمومی را تأیید کرده است.

CVE-2026-67276 چقدر خطرناک است؟

CVSS آن 9.2 است و به ضعف در Authentication مبتنی بر RSA در SSH مربوط می‌شود.

CVE-2026-86060 چیست؟

یک ضعف در مسیر SSH Login است که می‌تواند در شرایط لازم باعث دست‌کاری سطح دسترسی و Privilege Escalation شود.

آیا فقط SSH آسیب‌پذیر است؟

خیر. شش CVE منتشر شده‌اند و Bandwidth-Test، X.509/TLS و WebFig نیز در میان Componentهای آسیب‌پذیر قرار دارند.

به کدام نسخه RouterOS ارتقا دهیم؟

Fix در 7.24.2 Stable، 7.23.4 Long-term، 6.49.21 و 7.25beta3 منتشر شده است. نسخه‌های جدیدتر همان شاخه نیز Fix را شامل می‌شوند.

آیا فقط بستن SSH کافی است؟

خیر. این اقدام Attack Surface را کاهش می‌دهد ولی جای Update امنیتی را نمی‌گیرد.

چگونه بفهمیم Router هک شده است؟

پس از Update، وضعیت flagged، Logها، Userها، Scripts، Scheduler، Proxy، SOCKS، Tunnelها و سایر Configurationها را بررسی کنید.

چگونه Flagged را بررسی کنیم؟

/system/device-mode/print

اگر flagged=no باشد Router سالم است؟

الزاماً خیر. نبود Flag فقط به معنی پیدا نشدن نشانه‌های شناخته‌شده توسط مکانیزم فعلی RouterOS است.

وجود flagged=yes چه معنایی دارد؟

باید آن را نشانه جدی Unauthorized Access در نظر گرفت و Router را وارد فرآیند Incident Response کرد.

User با نام ops چیست؟

CERT Polska در حملات بررسی‌شده وجود یک User بسیار پرقدرت با نام ops را به‌عنوان یکی از Indicators گزارش کرده است.

اگر ops وجود نداشته باشد Router سالم است؟

خیر. مهاجم می‌تواند Artifactهای متفاوتی ایجاد کند و نبود این User Compromise را رد نمی‌کند.

آیا RouterOS 6 نیز آسیب‌پذیر است؟

بله. برای شاخه v6 نسخه 6.49.21 شامل Fix منتشر شده است.

آیا بعد از هک می‌توان Full Backup قبلی را Restore کرد؟

اگر Backup از زمانی باشد که احتمال Compromise وجود داشته، نباید بدون Audit دوباره Restore شود.

بعد از Compromise باید Password را تغییر دهیم؟

فقط Password Router کافی نیست. همه Credentialها و Secretهای قابل دسترس از Router باید براساس Scope حادثه Rotate شوند.

بهترین روش Remote Management چیست؟

Management Serviceها را از Public Internet حذف کرده و از VPN مانند WireGuard و Management VLAN استفاده کنید.

جمع‌بندی؛ این Update را به تعویق نیندازید

موضوع MikroTrick فقط انتشار چند CVE جدید نیست.

سه عامل این Incident را مهم می‌کنند:

Critical CVSS
+
Authentication / Privilege Weakness
+
Confirmed Active Exploitation

اگر MikroTik مدیریت می‌کنید، ترتیب اقدام صحیح این است:

Update RouterOS
 ↓
Check Flagged
 ↓
Review Logs
 ↓
Audit Users / Scripts / Scheduler
 ↓
Check Firewall / Proxy / Tunnels
 ↓
Remove Public Management Access
 ↓
Use VPN for Administration

اگر Router نشانه‌ای از Compromise دارد، فقط Patch کردن کافی نیست؛ باید فرض کنید مهاجم قبلاً داخل دستگاه بوده و Incident Response کامل انجام دهید.