في سبتمبر 2025 كشفت شركة Koi Security عن حزمة npm غير رسمية تحمل اسم postmark-mcp كانت تقلّد خادم MCP الخاص بخدمة Postmark. عملت الإصدارات الأولى بصورة طبيعية، ثم أضاف الإصدار 1.0.16 تعديلًا خبيثًا يجعل الرسائل المرسلة عبر الأداة تتضمن عنوان BCC مخفيًا يرسل نسخة من البريد إلى جهة خارجية.
الحادثة مهمة لأنها لم تكن اختراقًا لخوادم Postmark ولا ثغرة CVE في واجهة Postmark API. كانت هجوم Software Supply Chain يعتمد على تثبيت مكوّن غير رسمي ومنحه صلاحية التعامل مع البريد. وأكدت Postmark في تنبيهها الأمني الرسمي أن الحزمة الخبيثة لم تكن تابعة لها وأن خدماتها وواجهاتها الشرعية لم تتعرض للاختراق.
كما تغيرت نقطة مهمة منذ نشر الخبر الأصلي: في 2025 كان خادم Postmark MCP الرسمي متاحًا من مستودع GitHub الرسمي ولم تكن الشركة قد نشرت الحزمة المقلدة الموجودة على npm. أما في 2026 فأصبح لدى Postmark بالفعل حزمة npm رسمية، ولكن تحت الاسم المحدد بنطاق المؤسسة @activecampaign/postmark-mcp، وهو اختلاف يجب الانتباه إليه عند التثبيت.
ماذا حدث في هجوم postmark-mcp؟
أطلقت Postmark في يونيو 2025 خادم MCP تجريبيًا يتيح لمساعدات الذكاء الاصطناعي التفاعل مع خدمة البريد. يسمح هذا النوع من التكامل للـAI Assistant باستخدام أدوات حقيقية بدل الاكتفاء بشرح كيفية تنفيذ المهمة، مثل إرسال رسالة أو التعامل مع قوالب البريد.
ظهر لاحقًا على npm مشروع غير رسمي باسم postmark-mcp يقلّد المشروع الحقيقي. بحسب تحليل Koi Security الأصلي، عملت الإصدارات من 1.0.0 إلى 1.0.15 بصورة طبيعية، وهو ما ساعد الحزمة على اكتساب الثقة. بعد ذلك تغير سلوكها في الإصدار 1.0.16.
لم يحتج المهاجم إلى استغلال Zero-Day أو تجاوز آلية حماية داخل Postmark. التغيير الخبيث كان بسيطًا: إضافة مستلم BCC غير ظاهر إلى الرسالة قبل تمريرها إلى خدمة البريد. ونتيجة لذلك كان المستلم المقصود يحصل على الرسالة بصورة طبيعية، بينما تُرسل نسخة إضافية بصمت إلى العنوان المرتبط بالنطاق giftshop[.]club.
لماذا كان تسريب البريد صعب الملاحظة؟
خطورة هذا الأسلوب تأتي من أن الوظيفة الأساسية لم تتوقف. لم تظهر للمستخدم بالضرورة رسالة خطأ، ولم يفشل إرسال البريد، ولم يكن هناك سلوك تخريبي واضح يجذب الانتباه.
كان سير العمل يبدو طبيعيًا تقريبًا:
- يطلب المستخدم أو AI Agent إرسال رسالة.
- يمر المحتوى إلى خادم MCP المثبت محليًا.
- تضيف الحزمة الخبيثة مستلم BCC إضافيًا.
- تُرسل الرسالة عبر Postmark إلى المستلم الصحيح.
- تصل نسخة أخرى إلى العنوان الذي حدده مطور الحزمة الخبيثة.
وهذا يوضح مشكلة أوسع في أدوات AI Agents: نجاح Tool Call لا يعني أن الأداة تصرفت بأمان. قد تنفذ الأداة الوظيفة المطلوبة وتنفذ في الوقت نفسه إجراءً إضافيًا لم يطلبه المستخدم.
هل سُرقت فعلًا آلاف الرسائل يوميًا؟
يجب التفريق هنا بين ما أثبته التحليل وبين التقديرات. أثبت باحثو Koi وجود كود BCC الخبيث في postmark-mcp ابتداءً من الإصدار 1.0.16، وذكروا أن الحزمة كانت تحقق نحو 1,500 تنزيل أسبوعيًا وقت الكشف.
أما الرقم الذي تراوح بين 3,000 و15,000 رسالة يوميًا فكان تقديرًا وضعه الباحثون بناءً على افتراضات حول نسبة التثبيتات المستخدمة فعليًا وعدد الرسائل التي قد ترسلها كل جهة. لا يمثل هذا الرقم إحصاءً مؤكدًا لعدد الرسائل التي ثبت تسريبها.
لذلك الأدق القول إن الحزمة كانت قادرة على نسخ الرسائل التي تمر عبر الوظيفة المتأثرة، وليس أن هناك رقمًا موثقًا نهائيًا لجميع الرسائل المسروقة.
ما نوع البيانات التي كان يمكن أن تتسرب؟
تعتمد الأضرار على طبيعة البريد الذي مر عبر الخادم خلال فترة استخدام الإصدار الخبيث. البريد التشغيلي قد يحتوي على بيانات أكثر حساسية من مجرد عنوان المرسل والمستلم، مثل:
- روابط إعادة تعيين كلمات المرور.
- رموز تحقق أو معلومات مصادقة مؤقتة.
- فواتير وبيانات مالية أو تعاقدية.
- مراسلات العملاء والدعم الفني.
- معلومات داخلية للشركة.
- مفاتيح API أو Credentials أُرسلت بطريقة غير آمنة عبر البريد.
لهذا أوصت Postmark الجهات التي استخدمت الحزمة المزورة بمراجعة سجلات البريد والنظر في تدوير أي Credentials يحتمل أنها ظهرت في الرسائل المتأثرة.
لماذا تعد هذه الحادثة هجوم Supply Chain وليس ثغرة في Postmark؟
في الثغرة التقليدية قد يستغل المهاجم خللًا برمجيًا للوصول إلى النظام دون الصلاحيات المطلوبة. هذا ليس ما حدث هنا.
الحزمة نفسها كانت المكوّن الخبيث. المستخدم قام بتثبيتها ومنحها Postmark Server Token لأنها قدمت نفسها كأداة تؤدي وظيفة مشروعة. لذلك يصنفها Snyk كـMalicious Package ويربطها بـCWE-506 الخاص بإدخال كود خبيث، بدل التعامل معها كثغرة CVE في منتج Postmark.
الحادثة مثال مباشر على المخاطر التي يناقشها أيضًا دليل CyberOPlus حول أمان npm وهجمات Software Supply Chain: التحقق من هوية الناشر ومصدر الحزمة وسلوك تحديثاتها مهم بقدر فحص الثغرات الموجودة في Dependencies نفسها.
ما علاقة MCP بزيادة أثر الحادثة؟
Model Context Protocol أو MCP هو بروتوكول يتيح لتطبيقات الذكاء الاصطناعي الاتصال بأدوات ومصادر بيانات خارجية بطريقة موحدة. المشكلة ليست أن MCP بروتوكول خبيث، بل أن MCP Server قد يصبح جسرًا بين النموذج وبين أنظمة شديدة الحساسية.
عندما يكون الخادم قادرًا على إرسال البريد أو قراءة قاعدة بيانات أو تنفيذ عمليات على خدمة سحابية، تصبح صلاحياته جزءًا من Attack Surface للتطبيق. ولهذا يجب التعامل مع MCP Server باعتباره كودًا ذا امتيازات فعلية، لا كإضافة بسيطة للواجهة.
توضح مواصفات MCP مبادئ مثل موافقة المستخدم على الوصول إلى البيانات والعمليات، وحماية البيانات، والتعامل بحذر مع Tools، وعدم اعتبار وصف الأداة نفسه مصدرًا موثوقًا بصورة تلقائية.
ويتقاطع ذلك مع المبادئ الأوسع الموضحة في دليل أمن تطبيقات LLM وRAG وAI Agents، حيث يجب أن تطبق الصلاحيات والقيود خارج النموذج نفسه، وأن يحصل كل Tool على أقل Scope يحتاج إليه.
ما الذي تغير منذ حادثة 2025؟
أحد أهم أسباب تحديث هذه الصفحة هو أن المشهد الحالي لم يعد مطابقًا لما كان عليه وقت الكشف.
1. الحزمة الخبيثة القديمة لم تعد هي حزمة Postmark الرسمية
أكدت Postmark في سبتمبر 2025 أن الحزمة غير المحددة بنطاق postmark-mcp الموجودة آنذاك على npm لم تكن تابعة لها. وتم حذف الحزمة الخبيثة بعد الكشف، لكن حذف Package من registry لا يزيل النسخ الموجودة بالفعل من أجهزة من ثبّتها.
2. يوجد الآن Package رسمي على npm
في 2026 أصبح خادم Postmark الرسمي متاحًا أيضًا عبر npm تحت الاسم:
@activecampaign/postmark-mcp
وتربطه Postmark مباشرة بمستودع ActiveCampaign/postmark-mcp الرسمي على GitHub. كما تعرض صفحة npm الرسمية ActiveCampaign بصفتها الجهة الناشرة.
| العنصر | الحزمة الخبيثة في 2025 | الخادم الرسمي في 2026 |
|---|---|---|
| اسم npm | postmark-mcp |
@activecampaign/postmark-mcp |
| الجهة الرسمية | لا | ActiveCampaign / Postmark |
| المستودع المعتمد | حزمة تقلد المشروع الحقيقي | github.com/ActiveCampaign/postmark-mcp |
| الوضع | حزمة خبيثة تم كشفها وحذفها | مشروع رسمي نشط |
3. خادم Postmark MCP أصبح أوسع صلاحية
في يوليو 2026 أعلنت Postmark إصدار v2.0 الذي وسّع الخادم إلى 24 أداة تشمل إرسال البريد الفردي والدُفعات، وإدارة Templates، والبحث في الرسائل، وإدارة Bounces وSuppressions وWebhooks، إضافة إلى إحصاءات التسليم والتشخيص.
هذا التطور مفيد وظيفيًا، لكنه يجعل تطبيق Principle of Least Privilege أكثر أهمية. توضح الوثائق الحالية أن الخادم يعمل بصلاحيات POSTMARK_SERVER_TOKEN كاملة على Postmark Server المرتبط به، ولا يوفر Server Token نفسه Scopes دقيقة لكل Tool.
كيف حسّنت Postmark أمان خادم MCP الرسمي؟
توثق النسخة الحالية من المشروع عدة ضوابط لم تكن جزءًا من قصة الحزمة المقلدة في 2025، من بينها:
- Tool Annotations لتمييز العمليات Read-only عن العمليات التي تغير البيانات أو تحذفها.
- إخفاء أجزاء من عناوين البريد افتراضيًا داخل Structured Logs.
- اشتراط HTTPS عند إنشاء Webhooks.
- إمكانية تحديد
WEBHOOK_URL_ALLOWLISTلمنع تسجيل Webhook على نطاقات غير معتمدة. - توصية بعدم تفعيل Auto-approval لعمليات الإرسال أو الأدوات التدميرية في البيئات غير الموثوقة.
- استخدام Postmark Server مخصص لحركة MCP لتقليل Blast Radius في حال إساءة استخدام Token.
وفي 27 أغسطس 2026 أضافت Postmark أيضًا ميزة IP Allowlisting لطلبات الإرسال عبر API. تسمح الميزة بتحديد نطاقات IPv4 CIDR موثوقة على مستوى الحساب أو Postmark Server، بحيث تُرفض طلبات API القادمة من خارجها. هذه الحماية لا تشمل SMTP ولا تغني عن مراجعة أمان MCP Server نفسه، لكنها يمكن أن تضيف طبقة مفيدة للبيئات ذات عناوين الخروج الثابتة.
كيف تعرف إن كانت بيئتك استخدمت الحزمة الخبيثة؟
إذا كانت المؤسسة استخدمت MCP مع Postmark خلال 2025، فلا يكفي التحقق من وجود كلمة Postmark في الإعدادات. يجب التحقق من اسم الحزمة ومصدرها والإصدار الذي كان مثبتًا فعليًا.
مؤشرات الحادثة التي نشرها Koi تضمنت:
- اسم الحزمة القديمة:
postmark-mcp. - الإصدار الخبيث المعروف:
1.0.16وما بعده ضمن تلك الحزمة. - عنوان BCC المبلغ عنه:
phan@giftshop[.]club. - النطاق المرتبط بالتسريب:
giftshop[.]club.
وجود أحد هذه المؤشرات في Logs أو Lockfiles أو نسخ Dependency القديمة يستحق التحقيق، لكنه لا يثبت وحده حجم البيانات التي تم تسريبها.
ماذا تفعل إذا استخدمت postmark-mcp الخبيثة؟
- أزل الحزمة القديمة: تأكد من عدم وجود
postmark-mcpالخبيثة في المشروع أو إعداد MCP أو Images وبيئات CI القديمة. - افحص Lockfiles وArtifacts: راجع
package-lock.jsonوyarn.lockونسخ Container السابقة لتحديد الإصدار الذي كان مستخدمًا. - راجع سجلات البريد: ابحث عن BCC أو مستلمين غير متوقعين مرتبطين بالنطاق المبلغ عنه.
- حدد البيانات التي مرت عبر الأداة: لا تفترض أن كل البريد متساوي الحساسية. حدد الرسائل التي قد تحتوي Credentials أو Tokens أو بيانات عملاء.
- دوّر الأسرار المتأثرة: غيّر كلمات المرور والمفاتيح والرموز التي يحتمل أنها ظهرت داخل الرسائل خلال فترة التعرض.
- أصدر Postmark Server Token جديدًا عند الحاجة: خصوصًا إذا كان هناك احتمال أن تكون بيئة التشغيل أو ملفات الإعداد نفسها قد تعرضت.
- افحص العمليات اللاحقة: إذا تسرب رابط Password Reset أو API Key، راجع سجلات النظام المرتبط به بحثًا عن استخدام غير معتاد.
كيف تقلل مخاطر MCP Supply Chain مستقبلًا؟
تحقق من المصدر قبل اسم الحزمة
اسم Package مطابق لاسم منتج معروف لا يثبت ملكيته. ابدأ دائمًا من موقع المزود أو Documentation الرسمية ثم اتبع رابط التثبيت المنشور هناك.
بالنسبة إلى Postmark، تشير الوثائق الحالية إلى مستودع ActiveCampaign الرسمي وحزمة @activecampaign/postmark-mcp، وليس إلى الحزمة القديمة غير المحددة بنطاق.
لا تمنح MCP Server صلاحيات أكبر من حاجته
إذا كان Agent يحتاج إلى التعامل مع نظام بريد واحد، فاستخدام Postmark Server منفصل مخصص له يقلل نطاق الضرر مقارنة باستخدام Credential تمنحه الوصول إلى بيئة أوسع.
لا تجعل Tool Approval إجراءً شكليًا
العمليات التي ترسل بريدًا أو تعدل Templates أو تنشئ Webhooks أو تحذف بيانات يجب ألا تعمل تلقائيًا في كل سياق. وجود Human Approval أو Policy خارج النموذج يقلل إمكانية تحويل Prompt Injection أو Tool Misuse إلى إجراء حقيقي.
راقب السلوك بعد التحديثات وليس اسم الإصدار فقط
أهم درس من postmark-mcp أن الحزمة يمكن أن تكون سليمة في عدة إصدارات ثم يتغير سلوكها في تحديث لاحق. لذلك لا يكفي فحص Dependency مرة واحدة عند إدخالها إلى المشروع.
راجع تغيرات المصدر، وLockfiles، والناشر، وProvenance عند توفرها، وطبّق سياسة واضحة للموافقة على تحديثات الأدوات التي تتعامل مع البريد أو قواعد البيانات أو Credentials.
عامل MCP Servers كجزء من Asset Inventory
يجب أن تعرف المؤسسة ما MCP Servers المثبتة، ومن يملكها، وما Credentials التي تستخدمها، وما الأنظمة التي تستطيع الوصول إليها. MCP Server غير مسجل داخل Inventory قد يصبح قناة غير مرئية لتسريب البيانات حتى لو كانت بقية البنية التحتية تخضع لضوابط قوية.
ما الدرس الأهم من حادثة postmark-mcp؟
لم تكشف الحادثة عن ضعف خاص في بروتوكول البريد أو اختراق لخوادم Postmark، بل كشفت مشكلة ثقة في طبقة الأدوات المحيطة بـAI Agents.
المستخدم لم يكن مضطرًا إلى منح المهاجم صلاحية صريحة لسرقة البريد؛ كان يكفي أن يثق بأداة تبدو شرعية ويمنحها الصلاحيات اللازمة لأداء وظيفتها الحقيقية. عندما تغير الكود، تحولت هذه الصلاحيات نفسها إلى قناة تسريب.
وفي 2026 لم تعد النصيحة الصحيحة هي تجنب Postmark MCP لمجرد حادثة 2025. توجد اليوم نسخة رسمية ونشطة من ActiveCampaign/Postmark، مع ضوابط أمنية أوضح وحزمة npm رسمية منفصلة عن الحزمة التي استُخدمت في الهجوم. لكن المبدأ لا يتغير: تحقق من المصدر، قلل الصلاحيات، راقب التحديثات، ولا تعامل أي MCP Server على أنه مجرد Plugin منخفض المخاطر.