📄 الوصف (الإنجليزية)
WeKan before 8.35 contains a server-side request forgery vulnerability in webhook integration URL handling where the url schema field accepts any string without protocol restriction or destination validation. Attackers who can create or modify integrations can set webhook URLs to internal network addresses, causing the server to issue HTTP POST requests to attacker-controlled internal targets with full board event payloads, and can additionally exploit response handling to overwrite arbitrary comment text without authorization checks.
🤖 ملخص AI
WeKan before version 8.35 contains a critical server-side request forgery (SSRF) vulnerability in webhook URL handling that allows attackers with integration privileges to redirect internal HTTP requests to arbitrary network targets and manipulate board data without authorization. The vulnerability lacks protocol validation and destination filtering, enabling attackers to access internal services, exfiltrate sensitive board event data, and modify comments across the platform. This poses significant risk to organizations using WeKan for project management and collaboration, particularly in sensitive sectors handling confidential information.
📄 الوصف (العربية)
🤖 التحليل الذكي آخر تحليل: Apr 24, 2026 03:31
🇸🇦 التأثير على المملكة العربية السعودية
Saudi organizations using WeKan for project collaboration face significant risk, particularly in: (1) Government agencies and NCA-regulated entities managing sensitive policy documents and communications; (2) Banking sector (SAMA-regulated) using WeKan for internal project tracking with access to financial data; (3) Healthcare organizations (MOH-regulated) storing patient-related project information; (4) Energy sector (ARAMCO, SEC-regulated) managing critical infrastructure projects; (5) Telecommunications (STC, Mobily) coordinating network operations. The SSRF vulnerability enables attackers to access internal network resources, potentially reaching SCADA systems, internal databases, and administrative interfaces. The unauthorized comment modification capability could compromise audit trails and compliance documentation required by NCA ECC 2024 and SAMA CSF frameworks.
🏢 القطاعات السعودية المتأثرة
Government & Public Administration
Banking & Financial Services
Healthcare
Energy & Utilities
Telecommunications
Defense & Security
Education
Transportation
🎯 تقنيات MITRE ATT&CK
⚖️ درجة المخاطر السعودية (AI)
8.2
/ 10.0
🔧 Remediation Steps (English)
IMMEDIATE ACTIONS:
1. Disable webhook functionality in WeKan until patch is available
2. Audit all existing webhook integrations and remove any pointing to internal network addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x, localhost, 127.0.0.1)
3. Review access logs for suspicious webhook creation/modification activities
4. Restrict integration creation permissions to trusted administrators only
COMPENSATING CONTROLS (until patch available):
5. Implement network-level controls: block outbound HTTP/HTTPS from WeKan server to internal network ranges using firewall rules
6. Deploy WAF rules to detect and block webhook URL patterns containing internal IP addresses or localhost references
7. Implement egress filtering on WeKan server to prevent connections to RFC1918 addresses
8. Enable detailed logging of all webhook creation, modification, and execution events
9. Implement webhook URL validation at application level using regex to reject internal addresses
DETECTION RULES:
10. Monitor for webhook URLs containing: 127.0.0.1, localhost, 10., 172.16-31., 192.168., file://, gopher://, dict://, ldap://, tftp://
11. Alert on any comment modifications without corresponding user action in audit logs
12. Track outbound connections from WeKan process to internal network ranges
13. Monitor for unusual HTTP POST requests from WeKan server to internal services
PATCHING:
14. Subscribe to WeKan security advisories and upgrade to version 8.35 or later immediately upon release
15. Test patch in isolated environment before production deployment
🔧 خطوات المعالجة (العربية)
الإجراءات الفورية:
1. تعطيل وظيفة webhook في WeKan حتى يتوفر التصحيح
2. تدقيق جميع تكاملات webhook الموجودة وإزالة أي منها يشير إلى عناوين الشبكة الداخلية (10.x.x.x, 172.16-31.x.x, 192.168.x.x, localhost, 127.0.0.1)
3. مراجعة سجلات الوصول للأنشطة المريبة في إنشاء/تعديل webhook
4. تقييد أذونات إنشاء التكامل للمسؤولين الموثوقين فقط
الضوابط البديلة (حتى يتوفر التصحيح):
5. تنفيذ ضوابط على مستوى الشبكة: حظر الاتصالات الصادرة HTTP/HTTPS من خادم WeKan إلى نطاقات الشبكة الداخلية باستخدام قواعد جدار الحماية
6. نشر قواعد WAF للكشف عن أنماط عناوين URL للويب هوك التي تحتوي على عناوين IP داخلية أو مراجع localhost
7. تنفيذ تصفية الخروج على خادم WeKan لمنع الاتصالات بعناوين RFC1918
8. تفعيل تسجيل مفصل لجميع أحداث إنشاء وتعديل وتنفيذ webhook
9. تنفيذ التحقق من صحة عنوان URL للويب هوك على مستوى التطبيق باستخدام regex لرفض العناوين الداخلية
قواعد الكشف:
10. مراقبة عناوين URL للويب هوك التي تحتوي على: 127.0.0.1, localhost, 10., 172.16-31., 192.168., file://, gopher://, dict://, ldap://, tftp://
11. تنبيه عند أي تعديلات على التعليقات بدون إجراء مستخدم مقابل في سجلات التدقيق
12. تتبع الاتصالات الصادرة من عملية WeKan إلى نطاقات الشبكة الداخلية
13. مراقبة طلبات HTTP POST غير العادية من خادم WeKan إلى الخدمات الداخلية
التصحيح:
14. الاشتراك في تنبيهات أمان WeKan والترقية إلى الإصدار 8.35 أو أحدث فوراً عند توفره
15. اختبار التصحيح في بيئة معزولة قبل نشره في الإنتاج
📋 خريطة الامتثال التنظيمي
🟢 NCA ECC 2024
A.5.1.1 - Information security policies and procedures (webhook security controls)
A.5.2.1 - Access control and authorization (integration privilege management)
A.5.3.1 - Cryptography and secure communications (HTTPS enforcement for webhooks)
A.5.4.1 - Audit logging and monitoring (webhook activity logging)
A.5.5.1 - Incident management (SSRF exploitation detection and response)
🔵 SAMA CSF
Governance & Risk Management - Risk assessment of third-party tools like WeKan
Information & Cybersecurity - Network segmentation and access controls
Operational Resilience - Incident detection and response capabilities
Third-Party Risk Management - Vendor security assessment and patching requirements
🟡 ISO 27001:2022
A.5.1.1 - Policies for information security
A.5.2.1 - Information security roles and responsibilities
A.5.3.1 - Segregation of duties
A.6.1.1 - Cryptographic controls
A.6.2.1 - Physical and environmental security
A.7.1.1 - Access control
A.8.1.1 - User endpoint devices
A.8.2.1 - Privileged access rights
A.8.3.1 - Information access restriction
A.8.4.1 - Access to cryptographic keys
A.12.4.1 - Event logging
A.12.6.1 - Management of technical vulnerabilities
🟣 PCI DSS v4.0.1
Requirement 1.3 - Network segmentation (blocking internal network access)
Requirement 2.2.4 - Configure system security parameters
Requirement 6.2 - Ensure security patches are installed
Requirement 10.2 - Implement automated audit trails
Requirement 10.3 - Protect audit trail history