سبع ثغرات تحت الاستغلال الفعلي:

لم تعد البنية التحتية المرتبطة بالذكاء الاصطناعي مجرد طبقة تقنية جانبية داخل المؤسسات. بوابات النماذج، خوادم MCP، منصات الأتمتة، ومحركات تدفقات العمل أصبحت اليوم نقاط تحكم عالية القيمة؛ لأنها تقع في المنتصف بين المستخدمين، النماذج، قواعد البيانات، مفاتيح مزودي الخدمات، والأنظمة الخلفية.

ولهذا السبب، فإن إدراج سبع ثغرات جديدة في كتالوج الثغرات المستغلة فعليًا لدى وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية CISA KEV ليس مجرد تحديث دوري لقائمة ثغرات. الصورة الأهم هي أن المهاجمين بدأوا بالفعل في تحويل هذه الثغرات إلى سلاسل هجوم متكاملة تشمل تنفيذ الأوامر، إنشاء جلسات غير مصرح بها، سرقة المفاتيح، تثبيت الوصول، نشر أدوات تعدين العملات الرقمية، والوصول إلى طبقات البيانات الحساسة خلف منصات الذكاء الاصطناعي.

اللافت كذلك أن بعض هذه الهجمات لا تستهدف تطبيقات تقليدية فحسب، بل مكونات أصبحت جزءًا مباشرًا من البنية الحديثة للذكاء الاصطناعي المؤسسي، مثل:

LiteLLM
MCP Servers
Kestra
RAGFlow
Flowise
LangChain
Langflow
ChromaDB
Ollama
Marimo

هذا التحول يفرض على فرق الأمن وإدارة المخاطر إعادة النظر في طريقة تصنيف هذه الأنظمة: ليست مجرد أدوات تطوير أو طبقات وسيطة، بل أصول حساسة قد تمنح المهاجم وصولًا إلى مفاتيح مزودي النماذج، بيانات الاعتماد، قواعد البيانات، بيئات الحاويات، وأنظمة التشغيل نفسها.

#ما الذي أضافته CISA إلى كتالوج KEV؟

أضافت CISA سبع ثغرات إلى كتالوج:

Known Exploited Vulnerabilities (KEV)

وذلك بعد وجود أدلة على استغلالها في هجمات فعلية.

القاسم المشترك هنا ليس شدة CVSS فقط، بل حقيقة أن جميع هذه الثغرات انتقلت من مستوى "إمكانية الاستغلال" إلى مستوى "الاستغلال الفعلي".

وهنا تكمن أهمية كتالوج KEV: وجود ثغرة فيه يعني أن قرار المعالجة لم يعد قائمًا فقط على التقييم النظري للمخاطر، بل على نشاط هجومي مثبت في الواقع.

#SonicWall SMA 1000: من SSRF إلى تنفيذ أوامر النظام

تضم القائمة ثغرتين في أجهزة:

SonicWall SMA 1000

الأولى:

CVE-2026-83548
CVSS: 10.0

وهي ثغرة:

Server-Side Request Forgery (SSRF)

وتسمح لمهاجم غير مصادق عليه بإجبار النظام على إجراء طلبات من جانب الخادم إلى موارد أو وظائف داخلية قد لا تكون متاحة له مباشرة.

الخطورة هنا أن SSRF في الأجهزة الطرفية والبوابات الآمنة قد يفتح للمهاجم مسارًا نحو مكونات داخلية حساسة.

الثغرة الثانية:

CVE-2026-83549
CVSS: 7.8

وهي:

Operating System Command Injection

وتتطلب حسابًا إداريًا مصادقًا عليه، لكنها تسمح بعد ذلك بتنفيذ أوامر على نظام التشغيل، بما يقود إلى:

Remote Code Execution

من منظور سلسلة الهجوم، وجود ثغرة وصول أولي بجانب ثغرة لتنفيذ أوامر يرفع حساسية المنتج بشكل كبير، لأن المهاجم قد يحاول دمج أكثر من ضعف ضمن مسار واحد بدل الاعتماد على ثغرة منفردة.

#Sangoma Switchvox: استعلام SQL واحد قد يتجاوز حدود قاعدة البيانات

الثغرة:

CVE-2026-9586
CVSS: 9.3

تؤثر على:

Sangoma Switchvox

وتندرج تحت:

SQL Injection

الخطورة أن المهاجم لا يحتاج إلى مصادقة، ويمكنه إرسال طلب مصمم خصيصًا لتنفيذ استعلامات تعسفية على قاعدة بيانات:

PostgreSQL

وهذا قد يتيح له تنفيذ عمليات على قاعدة البيانات، وقد يتطور الأثر في بيئات معينة إلى:

Remote Code Execution

تقارير الرصد أشارت إلى أن مهاجمين مجهولين استغلوا الثغرة فعليًا لنشر:

Reverse Shell

والـ Reverse Shell يغيّر طبيعة الاختراق تمامًا؛ فبدل تنفيذ طلب منفرد، يحصل المهاجم على قناة تفاعلية مستمرة تسمح له بالاستطلاع وتنفيذ الأوامر والتحرك داخل البيئة.

#JFrog Artifactory: الوصول الإداري دون مصادقة

الثغرة:

CVE-2026-82329
CVSS: 9.8

تؤثر على:

JFrog Artifactory

وهي من نوع:

Improper Authentication

وفي الإعداد الافتراضي قد تسمح لمهاجم لديه وصول شبكي إلى الخدمة بالحصول على صلاحيات إدارية دون امتلاك بيانات اعتماد صحيحة.

هذه الفئة من الثغرات شديدة الحساسية في منصات إدارة المستودعات البرمجية، لأن حساب الإدارة لا يمنح فقط إمكانية رؤية البيانات، بل قد يوفر وصولًا إلى:

Repositories
Packages
Build Artifacts
Tokens
Credentials
CI/CD Integrations
Federated Access

وبحسب تقارير الرصد، استُخدمت الثغرة لإنشاء رموز إدارية ومن ثم تنفيذ استطلاع لاحق على:

Users
Groups
Credential Sets
Federated Access Topologies

أي أن الهدف لم يكن مجرد الدخول إلى المنصة، بل فهم البنية المرتبطة بها تمهيدًا للتوسع داخل البيئة.

#Starlette: تهريب الطلبات كجزء من سلسلة تجاوز مصادقة

الثغرة:

CVE-2026-48710
CVSS: 6.5

تؤثر على:

Starlette

وهي مرتبطة بسلوك:

HTTP Request/Response Smuggling

الفكرة الأساسية أن المهاجم قد يتمكن من التأثير على طريقة إعادة بناء الرابط أو تفسير المسار بحيث يتم حقن جزء من المسار داخل جزء المضيف:

Host

ما قد يؤدي إلى اختلاف بين الطريقة التي يفسر بها مكون أمامي الطلب والطريقة التي يفسره بها التطبيق الخلفي.

في السيناريوهات التي تعتمد فيها آلية المصادقة أو التفويض على المسار المعاد بناؤه، قد يؤدي ذلك إلى:

Authentication Bypass

الخطورة الأكبر ظهرت عندما أمكن ربط هذه الثغرة بثغرة أخرى في:

LiteLLM

وهي:

CVE-2026-42271
CVSS: 8.7

السلسلة تسمح بتجاوز المصادقة ثم الوصول إلى تنفيذ أوامر عن بعد ضد بعض البيئات الضعيفة.

#LiteLLM: بوابة النماذج تتحول إلى نقطة ارتكاز للمهاجم

تضم القائمة أيضًا:

CVE-2026-59822
CVSS: 8.8

في:

Berri LiteLLM

وتحديدًا في نقطة نهاية:

Model Context Protocol (MCP) Streamable HTTP

الثغرة من نوع:

Improper Authentication

ويمكن أن تسمح لمهاجم غير مصادق بإنشاء جلسة MCP تبدو مصادقًا عليها باستخدام:

Arbitrary Bearer Token

هذه النقطة حساسة لأن بوابات مثل LiteLLM قد تعمل كطبقة وسيطة تربط المستخدمين أو التطبيقات بمزودي النماذج.

وقد تحتوي البيئة على بيانات مثل:

Provider API Keys
Model Configuration
Provider Endpoints
Virtual Keys
Routing Rules
Usage Metadata

عمليًا، مهاجم يصل إلى هذه الطبقة قد لا يكتفي بالتحكم في خدمة واحدة، بل قد يحصل على بيانات تسمح له بالوصول إلى أنظمة خارجية أو استهلاك خدمات مدفوعة أو استغلال مفاتيح مزودي الذكاء الاصطناعي.

#ماذا فعل المهاجمون داخل LiteLLM؟

رصدت حملات استغلال تستخدم سلسلة مرتبطة بـ:

CVE-2026-42271
CVE-2026-48710

للوصول إلى بوابات LiteLLM الضعيفة.

بعد الوصول، استُخدمت البرمجيات الخبيثة لنشر:

XMRig

وهو برنامج معروف بتعدين العملات الرقمية.

لكن النشاط لم يتوقف عند التعدين.

قبل نشر عامل التعدين، نفذ المهاجمون خطوات استطلاع للبيئة، شملت بصمة النظام ومحاولة إيقاف عمليات التعدين المنافسة.

كما استخدموا معلومات قواعد بيانات تم الحصول عليها سابقًا للوصول إلى:

PostgreSQL

والبحث داخل جداول حساسة في LiteLLM مثل:

LiteLLM_ProxyModelTable
LiteLLM_VerificationToken

والهدف من ذلك جمع معلومات مرتبطة بـ:

Model Configuration
Upstream Provider Keys
Provider Endpoints
Proxy-Issued Virtual Keys

وهنا يتضح أن القيمة الحقيقية للاختراق ليست قوة المعالجة فقط، بل الوصول إلى طبقة الهوية والاعتماد الخاصة بالنماذج والخدمات السحابية.

#الاستمرارية: تعديل authorized_keys

من آليات الاستمرارية التي ظهرت في سلسلة الهجوم تعديل الملف:

~/.ssh/authorized_keys

هذه الخطوة تسمح للمهاجم بإضافة مفتاح SSH خاص به، وبالتالي الاحتفاظ بإمكانية العودة إلى الخادم لاحقًا حتى لو تم إغلاق جلسة الاستغلال الأصلية.

هذه التقنية تمثل تحولًا مهمًا من:

Initial Access

إلى:

Persistence

وهو فارق يجب أن تنتبه له فرق الاستجابة للحوادث؛ لأن إصلاح الثغرة فقط بعد الاختراق لا يعني أن المهاجم فقد الوصول.

إذا كان قد أضاف:

SSH Keys
New Accounts
Tokens
Scheduled Tasks
Containers
Modified Workflows

فقد يبقى الوصول قائمًا بعد تطبيق التصحيح.

#Kestra OSS: تنفيذ Workflow تعسفي دون بيانات اعتماد

الثغرة:

CVE-2026-49869
CVSS: 10.0

تؤثر على:

Kestra OSS

وتسمح لمهاجم غير مصادق بإنشاء وتنفيذ:

Arbitrary Workflows

مما يقود إلى تنفيذ أوامر على نظام التشغيل.

بحسب التحليل المنشور للحملة، استُغلت الثغرة على الأرجح في أواخر يونيو 2026 لإنشاء:

Reverse Shell

ثم تنفيذ استطلاع لبيئة:

Docker

وبعد ذلك نشر عامل تعدين للعملات الرقمية وجمع بيانات إضافية من البيئة.

الاختراق كشف أربعة مسارات تأثير رئيسية:

Shell execution through the workflow engine
Container environment exposure through Docker socket access
Host resource hijacking through crypto-miner deployment
Follow-on collection through workflow task execution

هذه المسارات توضح خطورة منصات الأتمتة: الـ Workflow Engine لا يعمل كتطبيق عادي فقط، بل غالبًا يمتلك أصلًا صلاحيات واسعة لتنفيذ أوامر والتفاعل مع الخدمات والملفات والحاويات.

#لماذا يمثل Docker Socket مخاطرة مضاعفة؟

إذا كانت منصة مثل Kestra قادرة على الوصول إلى:

/var/run/docker.sock

فإن اختراق المنصة قد يمنح المهاجم قدرة غير مباشرة على التحكم في بيئة Docker.

في كثير من البيئات، الوصول إلى Docker Socket يعادل فعليًا امتلاك صلاحيات واسعة جدًا على المضيف، لأنه يمكن استخدامه لإنشاء حاويات جديدة وربط مسارات من النظام المضيف داخل الحاوية.

بالتالي فإن مسار الهجوم قد يتحول من:

Compromised Application

إلى:

Container Control

ثم إلى:

Host-Level Impact

ولهذا لا ينبغي تقييم ثغرات منصات الأتمتة بمعزل عن الصلاحيات والموارد التي تملكها تلك المنصات داخل البيئة.

#إخفاء الآثار باستخدام وظائف المنصة نفسها

من السلوك المثير للاهتمام أن المهاجمين استخدموا أمرًا من نمط:

curl | sh

ثم قاموا بترميز النتائج التي جمعوها وحفظها باستخدام واجهة:

Key-Value

الخاصة بـ Kestra.

هذه التقنية تقلل اعتماد المهاجم على ملفات مستقلة داخل النظام.

وبالتالي، إذا كان فريق الاستجابة يبحث فقط عن:

Dropped Files
Temporary Scripts
Suspicious Archives

فقد يفوته جزء من النشاط، لأن بعض البيانات الخبيثة أو النتائج المسروقة قد تكون مخزنة داخل منصة العمل نفسها.

#من التعدين إلى سرقة مفاتيح الذكاء الاصطناعي

الصورة العامة للحملات المرصودة تتضمن عدة أهداف:

Credential Theft
Persistence
Resource Hijacking
API Key Theft
Backend Access
Database Enumeration
Cryptocurrency Mining
AI-Native Post-Exploitation

وهذا يوضح أن تعدين العملات الرقمية ليس سوى أحد مسارات الاستفادة من المضيف المخترق.

القيمة الأعلى قد تكون في مفاتيح مثل:

OpenAI API Key
Azure OpenAI Credentials
Anthropic API Key
AWS Bedrock Credentials
Google Vertex AI Credentials
Internal Proxy Tokens
MCP Session Tokens

في بيئة مؤسسية، سرقة هذه المفاتيح قد تؤدي إلى مخاطر تتجاوز تكلفة الاستخدام.

فقد توفر وصولًا إلى:

Internal Models
Sensitive Prompts
RAG Data Sources
Internal APIs
Enterprise Knowledge Bases
Backend Tools
Agent Actions

#خوادم MCP أصبحت سطح هجوم جديدًا

مع انتشار:

Model Context Protocol (MCP)

أصبحت خوادم MCP بمثابة طبقة ربط بين نماذج الذكاء الاصطناعي والأدوات الخارجية.

قد يملك خادم MCP صلاحية الوصول إلى:

Files
Databases
APIs
Source Code
Cloud Services
Tickets
Email
Internal Systems

لذلك فإن اختراق المصادقة على خادم MCP لا ينبغي تصنيفه كاختراق خدمة ويب تقليدية فقط.

اعتمادًا على الأدوات المتاحة للخادم، قد يتحول إلى اختراق لـ:

AI Control Plane

أي الطبقة التي تسمح للنموذج أو الوكيل بتنفيذ أفعال في أنظمة أخرى.

#استهداف RAGFlow ومزودي النماذج

في حملة أخرى، رُصد نشاط يُعتقد أنه يستهدف أنظمة:

RAGFlow

المكشوفة للإنترنت باستخدام مجموعة من الثغرات، من بينها:

CVE-2026-45312
CVE-2026-28797
CVE-2026-24770
CVE-2025-68700
CVE-2025-69286

الهدف من هذه الحملات كان متشابهًا:

Credential Collection
Durable Access
Resource Monetization
LLM Provider Key Theft
Metadata Collection

حتى عندما اختلفت طريقة الاستغلال من منتج إلى آخر، بقي الهدف النهائي ثابتًا: الوصول المستمر، جمع بيانات الاعتماد، والاستفادة من الموارد.

#لماذا أصبحت بنية الذكاء الاصطناعي هدفًا جذابًا؟

المهاجم يبحث عادة عن أصل يجمع أكثر من قيمة في نقطة واحدة.

بوابات ومنصات الذكاء الاصطناعي تحقق ذلك بشكل مثالي.

فقد تحتوي الخدمة الواحدة على:

API Keys
Database Credentials
Cloud Tokens
Model Endpoints
User Sessions
Internal Network Access
Docker Permissions
Workflow Execution Rights
RAG Data
MCP Tool Access

هذا يعني أن اختراق خادم واحد قد يفتح مسارات متعددة في وقت واحد.

على سبيل المثال:

Exploit
   ↓
Gateway Access
   ↓
Credential Harvesting
   ↓
Database Access
   ↓
Provider API Keys
   ↓
Backend / Cloud Access
   ↓
Persistence

من هذا المنظور، أصبح من الخطأ التعامل مع منصة الذكاء الاصطناعي باعتبارها مجرد "واجهة أمامية لنموذج".

#أين يظهر البعد الخاص بالحوكمة والمخاطر والالتزام؟

من منظور:

Governance, Risk and Compliance (GRC)

القضية هنا تتجاوز تطبيق التصحيحات.

المشكلة الأساسية تبدأ من تصنيف الأصول.

إذا كانت منصة LiteLLM أو خادم MCP مسجلة في سجل الأصول كأداة تطوير منخفضة الأهمية، بينما تمتلك فعليًا مفاتيح وصول إلى خدمات سحابية وقواعد بيانات وأدوات داخلية، فإن نموذج المخاطر نفسه يصبح غير دقيق.

ينبغي أن يأخذ التصنيف في الحسبان:

إذا كانت الإجابات تشير إلى صلاحيات عالية، فإن الأصل يجب أن يدخل ضمن نطاق:

Critical or High-Risk Assets

حتى لو كان المنتج نفسه حديثًا أو لم يكن مصنفًا تاريخيًا كمنصة حساسة.

#KEV أهم من CVSS في تحديد الأولوية

الاعتماد على:

CVSS

وحده قد يؤدي إلى ترتيب غير مثالي للمعالجة.

على سبيل المثال، ثغرة بدرجة:

6.5

قد تبدو أقل أهمية من ثغرة بدرجة:

9.8

لكن إذا كانت الأولى:

Actively Exploited

وتستخدم كجزء من سلسلة تؤدي إلى:

Authentication Bypass + RCE

فقد تكون أولويتها التشغيلية أعلى من ثغرة حرجة نظريًا لم يظهر لها استغلال فعلي.

يمكن التعبير عن ذلك بشكل مبسط:

Patch Priority
=
CVSS
+
KEV Status
+
Internet Exposure
+
Asset Criticality
+
Exploitability
+
Business Impact

وهذه هي النقطة التي يصبح فيها دمج Threat Intelligence مع إدارة الثغرات أمرًا ضروريًا.

#مهلة المعالجة التي حددتها CISA

وفق التوجيه:

Binding Operational Directive (BOD) 26-04

فإن الجهات الفيدرالية المدنية الأمريكية مطالبة بإعطاء أولوية عالية لمعالجة الثغرات الموجودة في KEV.

الموعد المستهدف لمعظم الثغرات الواردة في هذه المجموعة هو:

September 5, 2026

بينما تم منح مهلة حتى:

September 16, 2026

للثغرتين:

CVE-2026-48710
CVE-2026-59822

المغزى هنا ليس أن هذه التواريخ تنطبق تنظيميًا على جميع المؤسسات حول العالم، بل أن CISA تعتبر الثغرات خطرة بما يكفي لإلزام الجهات الواقعة تحت نطاق التوجيه بمعالجتها ضمن نافذة زمنية قصيرة.

#ما الذي يجب أن تبحث عنه فرق الدفاع؟

في هذه الحملات، مؤشرات الاختراق لا تقتصر على وجود ملف خبيث واحد.

يجب الربط بين عدة سلوكيات.

من أمثلة الأنشطة ذات الحساسية العالية:

Unexpected Workflow Creation
New Administrative Tokens
Unauthorized MCP Sessions
Provider API Key Access
Suspicious PostgreSQL Queries
SSH authorized_keys Modification
Unknown Reverse Shell Connections
Unexpected Docker Socket Access
XMRig Execution
Competing Miner Termination
curl-pipe-shell Activity
Unusual Key-Value Writes

كما ينبغي مراقبة الاتصالات الخارجة من بوابات الذكاء الاصطناعي إلى وجهات غير معتادة، خصوصًا إذا كانت الخدمة لا تحتاج بطبيعتها إلى فتح اتصالات خارجية عشوائية.

#التعامل مع منصات الذكاء الاصطناعي كـ Control Plane

أهم استنتاج من الهجمات الأخيرة هو أن الدفاع عن بنية الذكاء الاصطناعي لا يجب أن يتم على أساس أن كل منتج "تطبيق منفصل".

منصة مثل:

LiteLLM

قد تتحكم في مسارات النماذج والمفاتيح.

منصة مثل:

Kestra

قد تنفذ أوامر وتدفقات عمل.

خادم:

MCP

قد يربط النموذج بأدوات داخلية.

منصة:

RAGFlow

قد ترتبط بمصادر معرفة حساسة ومفاتيح مزودي النماذج.

لهذا فإن التصنيف الأدق لهذه المكونات هو:

Control Points

أو:

AI Control Plane Components

وليس مجرد تطبيقات ويب.

#الخلاصة

إضافة سبع ثغرات جديدة إلى كتالوج CISA KEV تكشف اتجاهًا أكثر أهمية من الأرقام نفسها.

المهاجمون لا يستهدفون فقط التطبيقات التقليدية، بل ينتقلون بسرعة إلى البنية التي تشغّل أنظمة الذكاء الاصطناعي المؤسسية: بوابات النماذج، خوادم MCP، منصات الأتمتة، أنظمة RAG، ومحركات تدفقات العمل.

الاستغلالات المرصودة وصلت بالفعل إلى:

Reverse Shells
Administrative Token Creation
Authentication Bypass
Remote Code Execution
Credential Harvesting
SSH Persistence
Docker Discovery
Crypto Mining
API Key Theft
Database Enumeration
AI-Native Post-Exploitation

وبالنسبة لفرق الأمن، فإن الدرس الأهم ليس فقط "حدّث هذه المنتجات"، بل إعادة تصنيف هذه المكونات أمنيًا.

أي خدمة تربط النموذج بقاعدة بيانات أو واجهة برمجية أو مزود سحابي أو محرك تنفيذ يجب التعامل معها على أنها أصل عالي الحساسية، لأن اختراقها قد يمنح المهاجم أكثر بكثير من مجرد السيطرة على تطبيق واحد.

في بيئات الذكاء الاصطناعي الحديثة، البوابة التي تمر عبرها النماذج قد تكون في الوقت نفسه بوابة إلى بقية المؤسسة.