Wallos is an open-source, self-hostable personal subscription tracker. Versions 4.6.0 and below contain a Server-Side Request Forgery (SSRF) vulnerability in the subscription and payment logo/icon upload functionality. The application validates the IP address of the provided URL before making the request, but allows HTTP redirects (CURLOPT_FOLLOWLOCATION = true), enabling an attacker to bypass the IP validation and access internal resources, including cloud instance metadata endpoints. The getLogoFromUrl() function validates the URL by resolving the hostname and checking if the resulting IP is in a private or reserved range using FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE. However, the subsequent cURL request is configured with CURLOPT_FOLLOWLOCATION = true and CURLOPT_MAXREDIRS = 3, which means the request will follow HTTP redirects without re-validating the destination IP. This issue has been fixed in version 4.6.1.
Wallos subscription tracker versions 4.6.0 and below contain a critical Server-Side Request Forgery (SSRF) vulnerability in logo upload functionality. Attackers can bypass IP validation through HTTP redirects to access internal resources and cloud metadata endpoints. The vulnerability is actively exploitable and affects self-hosted instances commonly used by organizations for subscription management.
IMMEDIATE ACTIONS:
1. Identify all Wallos instances running versions 4.6.0 or below in your environment
2. Restrict network access to Wallos instances to trusted users only
3. Implement network segmentation to prevent Wallos from accessing internal resources
4. Review logs for suspicious logo/icon upload requests with redirect patterns
PATCHING:
1. Upgrade Wallos to version 4.6.1 or later immediately
2. Verify patch deployment across all instances
3. Restart Wallos services after patching
COMPENSATING CONTROLS (if immediate patching not possible):
1. Disable logo/icon upload functionality temporarily via application configuration
2. Implement WAF rules to block requests to logo upload endpoints
3. Configure firewall rules to prevent Wallos from reaching internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16)
4. Block access to cloud metadata endpoints (169.254.169.254, metadata.google.internal)
5. Implement egress filtering on network level
DETECTION:
1. Monitor for HTTP 3xx redirect responses in Wallos application logs
2. Alert on logo upload requests followed by internal IP access attempts
3. Track outbound connections to 169.254.169.254 or cloud metadata endpoints
4. Review application logs for multiple redirect chains (CURLOPT_MAXREDIRS = 3)
5. Implement IDS/IPS signatures for SSRF redirect patterns
الإجراءات الفورية:
1. حدد جميع حالات Wallos التي تعمل بالإصدارات 4.6.0 أو أقل في بيئتك
2. قيد الوصول إلى شبكة Wallos للمستخدمين الموثوقين فقط
3. طبق تقسيم الشبكة لمنع Wallos من الوصول إلى الموارد الداخلية
4. راجع السجلات للطلبات المريبة لتحميل الشعارات/الرموز مع أنماط إعادة التوجيه
التصحيح:
1. قم بترقية Wallos إلى الإصدار 4.6.1 أو أحدث على الفور
2. تحقق من نشر التصحيح عبر جميع الحالات
3. أعد تشغيل خدمات Wallos بعد التصحيح
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. عطل وظيفة تحميل الشعار/الرمز مؤقتاً عبر تكوين التطبيق
2. طبق قواعد WAF لحظر الطلبات إلى نقاط نهاية تحميل الشعار
3. قم بتكوين قواعد جدار الحماية لمنع Wallos من الوصول إلى نطاقات IP الداخلية
4. احظر الوصول إلى نقاط نهاية بيانات السحابة
5. طبق تصفية الخروج على مستوى الشبكة
الكشف:
1. راقب استجابات HTTP 3xx في سجلات تطبيق Wallos
2. أصدر تنبيهات لطلبات تحميل الشعار متبوعة بمحاولات الوصول إلى IP الداخلية
3. تتبع الاتصالات الصادرة إلى نقاط نهاية بيانات السحابة
4. راجع سجلات التطبيق للسلاسل المتعددة للإعادة
5. طبق توقيعات IDS/IPS لأنماط SSRF