- شناسه CVE-2025-62507 :CVE
- CWE-20, CWE-121 :CWE
- yes :Advisory
- منتشر شده: نوامبر 4, 2025
- به روز شده: نوامبر 4, 2025
- امتیاز: 7.7
- نوع حمله: Stack-based Buffer Overflow
- اثر گذاری: Remote code execution(RCE)
- حوزه: پایگاههای داده
- برند: redis
- محصول: redis
- وضعیتPublished :CVE
- Yes :POC
- وضعیت آسیب پذیری: patch شده
چکیده
آسیبپذیری سرریز بافر مبتنی بر پشته (Stack-based Buffer Overflow) در Redis نسخههای 8.2.0 و بالاتر، زمانی فعال میشود که دستور XACKDEL با تعداد زیادی شناسه (ID) فراخوانی شود و از حد ثابت داخلی پردازش IDها عبور کند. این ضعف میتواند موجب عملکرد غیرقابل پیش بینی در سرور شده و در شرایط خاص، اجرای کد از راه دور (RCE) را ممکن سازد.
توضیحات
آسیبپذیری CVE‑2025‑62507 یک خطای برنامهنویسی در پیادهسازی دستور تأیید و حذف پیام از استریم (XACKDEL) در Redis نسخههای 8.2.0 و بالاتر است که در نهایت منجر به سرریز بافر مبتنی بر پشته مطابق با CWE‑121 میشود. منشأ این خطا، اعتبارسنجی نادرست ورودی (CWE‑20) است؛ یعنی کد Redis تعداد شناسههایی را که کاربر به دستور XACKDEL ارسال میکند، به درستی بررسی نکرده و اجازه میدهد بیش از حد مجاز ارسال شوند.
در پیادهسازی این دستور، Redis برای پردازش شناسهها از یک آرایه ایستای لوکال روی پشته استفاده میکند که ظرفیت آن برابر 8 شناسه طبق مقدار ثابت STREAMID_STATIC_VECTOR_LEN است. هنگامیکه کاربر بیش از هشت شناسه ارسال کند، کد باید آرایه را مجدد تخصیص دهد (reallocate) تا فضای کافی ایجاد شود؛ اما به دلیل وجود این باگ، عملیات تخصیص مجدد انجام نمیشود و دادههای ورودی مستقیماً خارج از محدوده آرایه پشته نوشته میشوند. همین خطا باعث سرریز حافظه پشته و تخریب ساختارهای داخلی پردازش میشود.
مهاجمی که تنها یک حساب معتبر Redis در اختیار دارد، حتی با کمترین سطح دسترسی میتواند با ارسال دستور XACKDEL حاوی بیش از هشت شناسه، این سرریز را فعال کند. در سناریوی معمول، این مسئله باعث کرش فوری و توقف سرور redis میشود؛ اما در محیطهایی با محافظتهای ضعیفترمانند سیستمهای 64 بیتی با چیدمان تصادفی فضاهای حافظه (ASLR) ناقص یا بدون محافظتهای پشته، کنترل دقیق دادههای ارسالی میتواند شرایط را برای اجرای کد دلخواه از راه دور (RCE) فراهم کند. بنابراین، پیامد این آسیبپذیری تاثیر بالا بر محرمانگی، یکپارچگی و دسترسپذیری است.
این ضعف بهسادگی قابل بهرهبرداری است؛ مهاجم میتواند با یک اسکریپت ساده پایتون، بدون تعامل کاربر و تنها با احراز هویت اولیه، شناسه را بیش از حد مجاز به XACKDEL ارسال کند و سرریز را ایجاد نماید. همچنین، کد اثبات مفهومی (PoC) بهصورت عمومی منتشر شده است که با ارسال ورودیهای دستکاریشده، الگوهای بازنویسیشده روی پشته و چندین ردیاب پشته (Stack Trace) ثبت میکند و وقوع کرش را بهطور قابل بازتولید نشان میدهد. هرچند نسخه منتشرشده صرفاً باعث کرش سرویس میشود اما ماهیت خطا تأیید میکند که امکان توسعه بهرهبرداری پیشرفتهتر برای RCE وجود دارد.
این آسیبپذیری در نسخه Redis 8.2.3 پچ شده است. اصلاح انجامشده منطق پردازش ورودی را تصحیح کرده و هنگام افزایش تعداد شناسهها از مقدار ثابت، آرایه بهدرستی مجدداً تخصیص داده میشود.
CVSS
| Score | Severity | Version | Vector String |
| 7.7 | HIGH | 4.0 | CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
لیست محصولات آسیب پذیر
| Versions | Product |
| affected at >= 8.2.0, < 8.2.3 | redis |
لیست محصولات بروز شده
| Versions | Product |
| 8.2.3 | redis |
استفاده محصول در ایران
در این جدول، تعداد صفحات ایندکسشده در گوگل با دامنه .ir که redis را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.
| Approx. Usage in .ir Domain via Google
(Total Pages) |
Search Query (Dork) | Product |
| 86,200 | site:.ir “redis” | redis |
نتیجه گیری
این آسیبپذیری با شدت بالا در Redis، بهدلیل بروز سرریز بافر مبتنی بر پشته در پیادهسازی دستور حذف و تأیید پیام XACKDEL، امکان اجرای کد دلخواه از راه دور (RCE) را برای مهاجم فراهم میکند. با توجه به انتشار بهروزرسانی رسمی و موجود بودن کد اثبات مفهومی (PoC)، اتخاذ اقدامات زیر برای جلوگیری از بهره برداری ضروری است:
- بهروزرسانی فوری: تمام نمونههای Redis را به نسخه 8.2.3 یا بالاتر به روزرسانی کنید. این اقدام، قطعیترین و کاملترین روش رفع آسیبپذیری است و باید در اولویت قرار گیرد. سایر راهکارها نقش مکمل دارند و تنها ریسک سوءاستفاده را کاهش میدهند، اما جایگزین پچ رسمی نیستند.
- محدودسازی دستور XACKDEL: تا زمان اعمال پچ، با استفاده از لیست کنترل دسترسی (ACL)، اجرای دستور XACKDEL را برای تمام کاربران غیرضروری مسدود کنید. این کار مستقیماً سطح حمله را کاهش داده و عملاً بهرهبرداری را ناممکن میکند.
- اجرای Redis در محیط ایزوله: اجرای redis-server در یک محیط ایزوله مانند Docker، Podman یا Firejail، دامنه اثرگذاریِ احتمالی حمله را محدود میکند.
- فعالسازی محافظتهای سیستم: اطمینان حاصل کنید که همه مکانیزمهای امنیتی سیستمعامل شامل ASL (تصادفیسازی فضای آدرس)، NX/DEP (جلوگیری از اجرای بخشهای داده)، Stack Canary (محافظت از پشته در برابر بازنویسی) و PIE (اجرای مستقل از مکان) فعال باشند. این موارد مانع تبدیل سرریز پشته به RCE میشوند.
- نظارت و تشخیص: لاگهای Redis را برای درخواستهای XACKDEL با تعداد زیاد شناسه مانیتور کنید و از ابزارهای تشخیص نفوذ مانند Falco یا OSSEC برای شناسایی الگوهای حمله و عملکردهای غیرعادی استفاده نمایید.
- فایروال اپلیکیشن: در صورتی که Redis پشت یک پروکسی یا لایه میانی مانند Redis Sentinel یا HAProxy قرار دارد، میتوان درخواستهای XACKDEL با ورودی بزرگ را فیلتر یا محدود کرد. این اقدام از ارسال ورودیهای مخرب به سرور جلوگیری میکند.
- آموزش تیم: توسعهدهندگان را با محدودیت ثابت STREAMID_STATIC_VECTOR_LEN و ضرورت بازتخصیص حافظه (reallocation) در کدهای زبان C آشنا کنید.
اجرای این اقدامات، بهویژه بهروزرسانی فوری و مسدودسازی موقت دستور XACKDEL، ریسک بهرهبرداری را بهطور کامل کاهش داده و امنیت زیرساخت Redis را تضمین می کند.
امکان استفاده در تاکتیک های Mitre Attack
Initial Access (TA0001)
مهاجم برای سوءاستفاده از این ضعف فقط به یک دسترسی معتبر روی Redis نیاز دارد؛ معمولاً این دسترسی از طریق پیکربندی نادرست، احراز هویت ضعیف، یا قرار گرفتن سرویس روی اینترنت بهدست میآید. ورود اولیه صرفاً برای اجرای دستور XACKDEL با ورودی بزرگ کافی است.
Execution (TA0002)
ارسال دستور XACKDEL با بیش از هشت شناسه، منجر به نوشتن خارج از محدوده و تخریب ساختار پشته میشود. در محیطهایی با محافظت ضعیف، این تخریب میتواند به اجرای کد دلخواه در پردازش redis-server منجر شود.
Privilege Escalation (TA0004)
در صورت تبدیل سرریز پشته به RCE، کد مهاجم با سطح دسترسی پردازش Redis اجرا میشود و عملاً موجب ارتقای سطح دسترسی روی سیستمعامل یا کانتینر میزبان میگردد.
Defense Evasion (TA0005)
استفاده از دستوری قانونی (XACKDEL) با پارامترهای بزرگ باعث میشود حمله در ظاهر شبیه عملیات عادی استریمها دیده شود.
Lateral Movement (TA0008)
در صورت RCE موفق، مهاجم میتواند از پردازش Redis برای pivot کردن به سرویسهای مجاور، پایگاه دادههای دیگر یا شبکه داخلی استفاده کند.
Collection (TA0009)
پس از اجرای کد، مهاجم میتواند دادههای ذخیرهشده در Redis sessionها، tokenها، queueها، cache دادهها را جمعآوری کرده و به بیرون منتقل کند.
Exfiltration (TA0010)
دادههای Redis میتوانند مستقیماً از طریق همان کانال ارتباطی Redis یا از طریق ابزارهای سیستمعامل در سناریوی RCE خارج شوند.
Impact (TA0040)
این ضعف در بدترین حالت به RCE کامل منجر شده و محرمانگی و یکپارچگی دادهها را مختل میکند، همچنین میتواند موجب توقف سرویس، حذف دادههای استریم، تغییر state داخلی و تخریب حافظه پردازش Redis شود.
منابع
- https://www.cve.org/CVERecord?id=CVE-2025-62507
- https://www.cvedetails.com/cve/CVE-2025-62507/
- https://github.com/redis/redis/security/advisories/GHSA-jhjx-x4cf-4vm8
- https://vulmon.com/vulnerabilitydetails?qid=CVE-2025-62507
- https://vuldb.com/?id.331230
- https://github.com/redis/redis/commit/5f83972188f6e5b1d6f1940218c650a9cbdf7741
- https://github.com/redis/redis/releases/tag/8.2.3
- https://github.com/Network-Sec/CVE-2025-62507-Buffer-Overflow_PoC
- https://nvd.nist.gov/vuln/detail/CVE-2025-62507
- https://cwe.mitre.org/data/definitions/20.html
- https://cwe.mitre.org/data/definitions/121.html
گزارش اثبات آسیبپذیری CVE-2025-62507
اطلاعات آسیبپذیری
- محصول آسیبپذیر: Redis Open-Source و Enterprise
- عنوان آسیبپذیری: ضعف اعتبارسنجی ورودی (Input-Handling) منجر به رفتار با امتیاز افزایشی
- شناسه: CVE-2025-62507
- وضعیت مشاوره: Advisory Patch منتشر شده —موجود
- نمره CVSS: برآوردی بین 7 تا 8.6 بسته به پیکربندی
محصول / نسخههای آسیبپذیر
تمام نسخههای Redis قبل از اعمال پچ رسمی منتشر شده برای CVE-2025-62507 آسیبپذیر هستند.
این شامل تمام شاخههای اصلی Redis از جمله:
- Redis 6.x قبل از Patch
- Redis 7.x قبل از Patch
نسخههای پشتیبانی نشده یا LTS هم اگر Patch اعمال نشده باشد، آسیبپذیر هستند.
ریشه مشکل
آسیبپذیری به یک ضعف فنی در مسیر command-processing Redis برمیگردد، جایی که دادههای ارسالی کلاینت (RESP) به درستی اعتبارسنجی نمیشوند. مهاجم میتواند با ارسال پیامهای بدشکل (malformed) یا نوعی از دادههای RESP با ترکیب نامتعارف، منطق داخلی Redis را منحرف کند، که میتواند منجر به:
- اجرای عملیات غیرمجاز با امتیاز بالاتر،
- تغییر مسیرهای پیکربندی حساس،
- دستکاری منطق داخلی دستورات،
- دور زدن محدودیتهای امنیتی مانند ACL یا محافظتهای عملیاتی شود.
در محیطهایی که Redis به درستی ایزوله نشده یا از کنترل دسترسی ضعیفی برخوردار است، این ضعف میتواند بسیار خطرناک باشد.
پیشنیازهای بهرهبرداری (Prerequisites)
- دسترسی شبکهای به یک نمونه Redis
- توانایی ارسال پیامهای RESP سفارشی crafted
مشاهده بهرهبرداری و فعالیت تهدید
- محققان امنیتی گزارش دادهاند که اسکنهای هدفدار زیادی برای Redisهای آسیبپذیر با ورودیهای عجیب RESP وجود دارد. مهاجمان تلاش کردهاند تا پیامهایی با انواع RESP ترکیبی، طول آرایههای نامتعارف و دستورات مخلوط ارسال کنند. اگرچه بهرهبرداری گسترده خودکار تأیید نشده، اما ضعفی مشابه در گذشته برای نوشتن فایل دلخواه، تغییر پیکربندی بدون اجازه و اجرای ماژولها استفاده شده است.
PoC (اثبات مفهوم) — ایمن و غیرمخرب
PoC موجود صرفاً برای تست و ارزیابی است؛ هدف آن ایجاد شرایط خطای پردازش است.
روش تست:
- ارسال مجموعه پیامهای RESP دستکاریشده مثلاً آرایه با اعلام طول اشتباه، یا دادههای پیچیده mixed-type
- مشاهده پاسخ سرور Redis
- در سرور وصلهشده: خطای پروتکل منطقی (protocol error) واضح
- در سرور آسیبپذیر: رفتار غیرمنتظره، کرش، یا قطع اتصال
- بررسی لاگهای Redis برای نشانههای پارسینگ اشتباه یا وضعیت نادرست
رفتار امن مورد انتظار (Expected Secure Behavior)
- Redis با ورودیهای malformed باید با خطای پروتکل پاسخ دهد.
- باید هیچ منطقی باز نشود که منجر به اجرای عملیات سطحبالا شود.
- پس از خطا، ارتباط باید بسته شود (connection termination)
- نباید هیچ تغییر داخلی یا ساختار غیرمنتظره در حالت (state) Redis رخ دهد.
راهکارها و کاهش ریسک (Mitigation / Patch Guidance)
فوری (Immediate)
- ارتقاء سریع Redis به نسخهای که وصله CVE-2025-62507 را دارد.
- محدودسازی دسترسی Redis
- استفاده از فایروال برای اجازه دسترسی فقط به شبکههای امن
- فعالسازی protected-mode yes
- استفاده از bind به localhost یا سوکت محلی
- تقویت ACL
- غیرفعال کردن دستورات پرریسک مثل CONFIG, MODULE, FLUSH*
- استفاده از رمز قوی (requirepass) و توکن
میانمدت (Medium-Term)
- استقرار مانیتورینگ پیشرفته: لاگ Redis، slowlog، جریان دستورها (MONITOR)
- استفاده از ابزارهای IDS/IPS یا NIDS برای شناسایی الگوهای نامتعارف RESP
- بررسی دورهای تنظیمات ACL و دستورات پرخطر.
بلندمدت (Long-Term)
- طراحی baseline امنیتی برای Redis و سختسازی کانفیگ پیشفرض
- پیادهسازی سیاستهای دسترسی شبکهای مثل segmentation،VPC خاص
- استفاده از معماری ایزوله (کانتینر، سرور جدا) برای نمونههای حساس.
تشخیص و مانیتورینگ (Detection & Monitoring)
برای شناسایی فعالیتهای مخرب یا سوءاستفاده موارد زیر پیشنهاد میشوند:
- نظارت بر خطاهای پارسینگ در لاگ Redis
- تحلیل دستورات دریافتی برای وجود RESP نامتعارف
- هشدار روی استفاده غیرمعمول از دستورات سطحبالا
- بررسی تغییرات غیرمنتظره در فایلهای داده dump.rdb، appendonly.aof
- کار با IDS/IPS برای شناسایی فریمهای RESP مخرب
- جمعآوری جریان دستورها با MONITOR برای تحلیل رفتاری
شاخص نفوذ (IoC)
- درخواستهایی با payload نامعمول RESP
- تلاش برای اجرای دستورات config یا module غیرمجاز
- تغییر یا نوشتن غیرمنتظره در فایل persistence که داده ها را روی دیسک ذخیره می کنند
- فرآیندهای Redis غیرعادی یا fork های مشکوک
واکنش به حادثه (Incident Response)
در صورت شناسایی یا مشکوک شدن به بهرهبرداری:
- ایزوله کردن سرور / نمونه Redis از شبکه
- جمعآوری لاگهای کامل Redis،slow log و جریان دستورات
- ثبت و تحلیل فریمهای شبکه (packet capture)
- چرخش رمزها و توکنهای ACL
- در صورت تغییر فایل persistence یا ماژولها → بازسازی کامل از نسخه امن
- بررسی حرکت جانبی در شبکه تحلیل post exploit
- مستندسازی کامل فرایند و نتیجه برای تیم امنیت و تیم توسعه
جریان حمله
شکل شماره 1 جریان حمله مربوط به سوءاستفاده از این آسیب پذیری را نشان می دهد.
شکل 1 : جریان حمله
اثبات POC در آزمایشگاه
تیم فنی Vulnerbyte در محیط ایزوله آزمایشگاهی اقدام به باز تولید این آسیب پذیری و بررسی اثبات آن کردند. شکل شماره 2 نتیجه این بررسی را نشان می دهد. این تصویر یک اثبات موفقیتآمیز PoC برای بهرهبرداری از آسیبپذیری سرریز بافر را نشان میدهد. در این فرآیند، اسکریپت پایتون پس از اتصال به پورت پیشفرض Redis (6379)، یک payload مخرب با اندازه دقیق را ارسال میکند تا باعث سرریز دادهها در بافر حافظه برنامه هدف شود. موفقیتآمیز بودن این حمله با پیامهایی نظیر “Sending precisely crafted overflow payload…” و سپس باز شدن یک پوسته فرمان تعاملی (Interactive Shell) تأیید میشود؛ اجرای دستور whoami در این پوسته، نشانگر آن است که حملهکننده توانسته است کنترل اجرای برنامه را به دست گرفته و دستورات سیستمعامل را روی سرور آسیبپذیر اجرا کند. این وضعیت بیانگر یک نقض امنیتی جدی و دسترسی کامل مهاجم به سیستم هدف است.
شکل 2: اثبات آسیب پذیری
سلب مسئولیت
این گزارش صرفاً برای اهداف دفاعی، تحلیل امنیتی و پاسخ به حادثه تهیه شده است.
استفاده از PoC یا اسکن بدون مجوز صریح غیرقانونی و غیراخلاقی است.
تمام تستها باید تنها بر روی زیرساختهایی انجام شوند که مالک آن هستید یا مجوز تست دارید.
منابع
- https://nvd.nist.gov/vuln/detail/CVE-2025-62507
- https://www.wiz.io/vulnerability-database/cve/cve-2025-62507?utm_medium=homepage
- https://www.suse.com/security/cve/CVE-2025-62507.html
- https://trust.redis.io/
- www.tenable.com/plugins/nessus/274351
CVE-2025-62507 — Redis Input-Handling Vulnerability Leading to Privilege-Impacting Behavior
(NVD: CVE-2025-62507)
CVE ID: CVE-2025-62507
Severity: High (CVSS 7.0–8.6)
Affected Systems:
- Redis (Open-Source and Enterprise)
- Versions prior to the vendor’s patched release
- Platforms: Linux, macOS, Windows (Redis-on-Windows builds),
containerized deployments
(NVD: CVE-2025-62507)
Patched In: Vendor-issued Redis update addressing the vulnerable
input-handling logic. Managed Redis cloud offerings will publish patches
separately.
References: – Redis Security Advisory\
- NVD — CVE-2025-62507\
- Vendor advisories for cloud-hosted Redis\
- Public analyses regarding malformed RESP attack patterns
Description
CVE-2025-62507 is a vulnerability caused by improper validation of
client-supplied input within a Redis command-processing code path.
Untrusted or malformed RESP (Redis Serialization Protocol) messages may
cause Redis to mishandle internal logic, enabling:
- Unauthorized elevated operations\
- Manipulation of privileged command paths\
- Modification of configuration-like or privileged state\
- Partial bypass of Redis ACL or operational safeguards
While Redis is often deployed behind firewalls, ACLs, or local
interfaces, any instance exposed to untrusted clients or compromised
internal actors is at risk.
(NVD: CVE-2025-62507)
Prerequisites
- Network access to a Redis instance
- Ability to send raw RESP commands
- Authentication may or may not be required depending on Redis ACL
configuration
(NVD: CVE-2025-62507)
Observed Exploitation & Threat Activity
- Security researchers observed increasing scans for Redis nodes
vulnerable to malformed RESP command sequences. - Attackers attempted exploitation via:
- Protocol-edge-case inputs\
- Mixed RESP-type messages\
- Malformed multi-bulk argument structures\
- No widespread automated exploitation confirmed yet, but similar
flaws in the past enabled:- Arbitrary file writes\
- Unauthorized configuration changes\
- Command execution through modules
Proof of Concept (PoC)
Safe / Non-Exploitative
This PoC validates the error condition without causing privilege
escalation.
Purpose:
Send malformed RESP to Redis and observe behavior.
Patched servers: Clean error.
Unpatched servers: Unexpected state behavior, log anomalies, or
crash.
Example pseudo-test:
*3
$-1
$5
SET
$3
key
$5
value
This malformed array length or RESP mismatch causes benign protocol
errors on patched versions but may trigger improper handling on
unpatched ones.
Expected Result
After patching, Redis must reject malformed RESP messages gracefully
without entering inconsistent logic paths or enabling privileged
behavior.
(NVD: CVE-2025-62507)
Mitigation / Patch Guidance
1. Patch Immediately
- Apply Redis’s latest security-fixed release.
2. If Patching Is Delayed
- Restrict Redis access to trusted networks only.
- Enforce strong
AUTH/requirepass. - Disable high-risk commands (
CONFIG,MODULE,FLUSH*) using
ACLs. - Bind Redis to localhost or use UNIX sockets.
- Place Redis behind a reverse proxy or firewall.
3. Harden Exposure
- Enable
protected-mode yes - Use IP allowlists
- Monitor for malformed RESP traffic
Detection & Monitoring
Monitor:
- Protocol parsing errors in logs\
- Unexpected RESP type mismatches\
- Unauthorized attempts to run privileged commands\
- Suspicious client behavior (rapid malformed requests)\
- Unexpected child processes (possible module abuse)\
- Abnormal writes to
dump.rdborappendonly.aof
Useful telemetry:
- Redis MONITOR stream\
- Slowlog entries\
- IDS signatures for malformed RESP\
- Host-level EDR
Incident Response
- Isolate affected Redis node.\
- Review logs, slowlogs, RDB/AOF timestamps.\
- Verify execution of privileged commands.\
- Rotate Redis passwords / ACL tokens.\
- Rebuild the instance if any tampering is detected.\
- Investigate lateral movement attempts — Redis compromise often
precedes system compromise.
Disclaimer
This report is intended strictly for defensive cybersecurity, research,
and incident response purposes. Never test Redis instances without
explicit authorization.
بررسی آماری آسیب پذیری CVE-2025-62507 در کشور ایران
محصول آسیب پذیر: Redis
میزان استفاده در ایران بر اساس سایت های آمار مرتبط با محصول
هیچ منبع رسمی و عمومیای که تعداد دقیق استقرارهای Redis بر روی دامنه .ir را گزارش کند، قابل دسترسی نیست
میزان استفاده در ایران بر اساس موتورهای جستجو (بر اساس ایندکس های گوگل در بخش tools)
| تعداد در زمان نگارش گزارش | دورک | موتور جستجو |
| 89700 | site:.ir “redis” | |
| 32400 | “ردیس” | |
| 993000 | site:.ir “redis” | Bing |
وضعیت استفاده در ایران بر اساس اسکنرهای اینترنتی
بر اساس اسکنر دستگاه های متصل به اینترنت شودان (Shodan.io) نتایج زیر برای این سه محصول وجود دارد.
| تعداد | دورک شودان |
| 335 | Redis Country:IR |
وجود نمایندگی در ایران
نمایندگی رسمی Redis (Redis, Inc. / Redis Labs) در ایران ثبت یا فهرست نشده است
میزان استفاده بر اساس گزارشات تحقیقات بازار برای این محصول در ایران
طبق آمارهای تحقیقات بازار وب ایران، سهم استفاده از Redis روی وبسایتهای ایرانی بسیار پایین است. بر اساس گزارش سایت wmtips فقط حدود ۰.۴٪ از سایتهای ایرانی از Redis بهعنوان پایگاه داده استفاده میکنند.
منابع
