- شناسه CVE-2025-32023 :CVE
- CWE-680 :CWE
- yes :Advisory
- منتشر شده: جولای 7, 2025
- به روز شده: جولای 7, 2025
- امتیاز: 7.0
- نوع حمله: Out-of-bounds write
- اثر گذاری: Remote code execution(RCE)
- حوزه: پایگاه‌های داده
- برند: Ruijie
- محصول: Student Information System
- وضعیتPublished :CVE
- Yes :POC
- وضعیت آسیب پذیری: patch شده
چکیده
آسیب‌پذیری به دلیل سرریز عدد صحیح در پایگاه داده Redis شناسایی شده است که منجر به سرریز بافر (out-of-bounds write) در عملیات HyperLogLog می‌شود. این ضعف به کاربران احراز هویت‌شده اجازه می‌دهد با استفاده از رشته‌های مخرب، حافظه پشته یا هیپ را دستکاری کرده و کد دلخواه را از راه دور اجرا کنند (RCE).
توضیحات
آسیب‌پذیری CVE-2025-32023 در پایگاه داده متن‌باز Redis شناسایی شده است. Redis به‌عنوان یک سامانه ذخیره‌سازی داده درون‌حافظه‌ای با قابلیت پایداری روی دیسک، به‌طور گسترده در زیرساخت‌های توزیع‌شده و سامانه‌های حساس مورد استفاده قرار می‌گیرد. این آسیب‌پذیری ناشی از سرریز عدد صحیح (Integer Overflow) است که منجر به سرریز بافر (Buffer Overflow- Out Of Bounds Writes) در پردازش عملیات HyperLogLog می شود و مطابق با CWE-680 طبقه‌بندی می گردد. در این شرایط، مهاجم می‌تواند با ارسال رشته‌های مخرب و بهره‌گیری از ضعف موجود در محاسبه طول کدگذاری‌های پراکنده، باعث دسترسی به آفست‌های خارج از محدوده و بازنویسی داده‌ها در حافظه، چه در پشته و چه در هیپ، شود. این آسیب پذیری در صورت بهره‌برداری موفق، امکان اجرای کد دلخواه (RCE) را در اختیار مهاجم احراز هویت‌شده قرار داده و محرمانگی، یکپارچگی و دسترس‌پذیری سامانه را تهدید می‌کند.
کد اثبات مفهومی (PoC) منتشر شده نشان می دهد که با استفاده از یک ورودی مخرب، ساختار HyperLogLog دستکاری شده و شرایط نوشتن خارج از محدوده در توابعی همچون hllMerge (پشته) یا hllSparseToDense (هیپ) ایجاد می‌گردد. نسخه‌های پیشرفته‌تر اکسپلویت از طریق تخریب طول یک آبجکت sds، افشای آدرس‌های حافظه و تزریق یک آبجکت ماژول جعلی در هیپ مدیریت‌شده توسط jemalloc، امکان دستیابی به اجرای کد از راه دور را فراهم می‌کنند. این فرآیند در نهایت با حذف آبجکت جعلی و فعال شدن destructor آن، به مهاجم اجازه می‌دهد کنترل کامل سرور Redis را در اختیار گیرد.
دامنه تأثیر این ضعف امنیتی کلیه نسخه‌های Redis از 2.8 تا پیش از انتشار نسخه‌های پچ شده 6.2.19، 7.2.10، 7.4.5 و 8.0.3 را در بر می‌گیرد. تیم توسعه Redis با انتشار این به‌روزرسانی‌ها، آسیب‌پذیری را برطرف نموده و به تمامی کاربران توصیه کرده است هرچه سریع‌تر نسبت به ارتقای نسخه اقدام کنند.
CVSS
| Score | Severity | Version | Vector String |
| 7.0 | HIGH | 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
لیست محصولات آسیب پذیر
| Versions | Product |
| affected at >= 8.0.0, < 8.0.3
affected at >= 7.4-rc1, < 7.4.5 affected at >= 7.0.0, < 7.2.10 affected at >= 2.8.0, < 6.2.19 |
redis |
لیست محصولات بروز شده
| Versions | Product |
| 8.0.3
7.4.5 7.2.10 6.2.19 |
redis |
استفاده محصول در ایران
در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که redis را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق نیست.
| Approx. Usage in .ir Domain via Google
(Total Pages) |
Product |
| 52690 | redis |
نتیجه گیری
با توجه به شدت بالای این آسیب‌پذیری در Redis و قابلیت بهره‌برداری آن برای اجرای کد دلخواه، این ضعف یک تهدید جدی برای زیرساخت‌های حیاتی محسوب می‌شود. وجود کد اثبات مفهومی و اکسپلویت‌های عملیاتی نشان می‌دهد که این آسیب‌پذیری نه‌تنها در سطح تحقیقاتی بلکه در شرایط واقعی نیز قابل استفاده است. هرگونه تأخیر در پچ کردن سیستم‌های آسیب‌پذیر، ریسک نفوذ، از دست رفتن داده‌های حساس، اختلال در سرویس و حتی تسلط کامل مهاجم بر سرور Redis را به‌شدت افزایش می‌دهد.
بنابراین اقدامات زیر به‌عنوان توصیه‌های فنی و عملیاتی ضروری پیشنهاد می‌شود:
- به‌روزرسانی فوری: تمامی سامانه‌های Redis باید در سریع‌ترین زمان ممکن به نسخه‌های امن 8.0.3، 7.4.5، 7.2.10 یا 6.2.19 به روزرسانی شوند شوند. نسخه‌های قدیمی‌تر باید از چرخه عملیاتی خارج گردند.
- محدودسازی دسترسی به دستورات HyperLogLog: در مواردی که به روزرسانی سریع امکان‌پذیر نیست، استفاده از ACL برای غیرفعال‌سازی یا محدود کردن دستورات مرتبط با HyperLogLog مانند PFADD، PFMERGE و PFCOUNT ضروری است.
- ایزوله سازی و محدودسازی محیط اجرا: اجرای Redis در محیط‌های ایزوله مانند کانتینر یا ماشین مجازی و محدودسازی دسترسی مستقیم کاربران به سرویس می‌تواند سطح حمله را کاهش دهد.
- کنترل دسترسی و تفکیک وظایف: Redis باید تنها برای کاربران و سرویس‌های مجاز قابل دسترسی باشد. استفاده از فایروال، VPN یا شبکه‌های خصوصی برای محدودسازی دسترسی خارجی توصیه می‌شود.
- نظارت و مانیتورینگ مداوم: ثبت و بررسی لاگ‌ها، شناسایی فعالیت‌های غیرعادی و استفاده از سامانه‌های تشخیص نفوذ (IDS/IPS) برای شناسایی الگوهای مخرب مرتبط با دستورات HyperLogLog اهمیت بالایی دارد.
- آزمایش امنیتی پس از پچ: پس از اعمال پچ یا اقدامات موقت باید ارزیابی امنیتی و آزمون نفوذ داخلی برای اطمینان از رفع کامل آسیب‌پذیری انجام گیرد.
اتخاذ اقدامات اصلاحی فوق نه‌تنها از بهره‌برداری موفقیت‌آمیز جلوگیری می‌کند، بلکه سطح تاب‌آوری امنیتی سازمان را در برابر حملات مشابه آتی افزایش خواهد داد.
امکان استفاده در تاکتیک های Mitre Attack
- Execution (TA0002)
T1203 – Exploitation for Client Execution
با بهره‌برداری از سرریز عدد صحیح و نوشتن خارج از محدوده (Out Of Bounds Write) در عملیات HyperLogLog، مهاجم می‌تواند کد دلخواه خود را روی سرور Redis اجرا کند. - Persistence (TA0003)
T1505 – Server Software Component
اجرای کد مخرب می‌تواند منجر به نصب یا ایجاد ماژول‌های جعلی در حافظه (Heap) شود که به مهاجم امکان حفظ دسترسی بلندمدت را می‌دهد. - Privilege Escalation (TA0004)
T1068 – Exploitation for Privilege Escalation
با کنترل کامل حافظه و استفاده از اکسپلویت‌های پیشرفته، مهاجم می‌تواند سطح دسترسی خود را در سیستم افزایش دهد و به بخش‌های حساس‌تر دسترسی پیدا کند.
T1083 – File and Directory Discovery
مهاجم با اجرای کد دلخواه می‌تواند ساختار فایل‌ها و داده‌های پایگاه داده را کشف کند و نقشه کلی سیستم را ترسیم نماید. - Lateral Movement (TA0008)
T1021 – Remote Services
پس از نفوذ موفق، مهاجم می‌تواند از طریق دسترسی به سرور Redis به سایر بخش‌های شبکه حرکت کند. - Impact (TA0040)
T1499 – Endpoint Denial of Service (DoS)
بهره‌برداری از این ضعف ممکن است باعث کرش شدن سرور Redis و ایجاد شرایط انکار سرویس شود.
منابع
- https://www.cve.org/CVERecord?id=CVE-2025-32023
- https://www.cvedetails.com/cve/CVE-2025-32023/
- https://github.com/redis/redis/security/advisories/GHSA-rp2m-q4j6-gr43
- https://vulmon.com/vulnerabilitydetails?qid=CVE-2025-32023
- https://vuldb.com/?id.315185
- https://github.com/redis/redis/commit/50188747cbfe43528d2719399a2a3c9599169445
- https://github.com/redis/redis/releases/tag/6.2.19
- https://github.com/redis/redis/releases/tag/7.2.10
- https://github.com/redis/redis/releases/tag/7.4.5
- https://github.com/redis/redis/releases/tag/8.0.3
- https://github.com/leesh3288/CVE-2025-32023
- https://nvd.nist.gov/vuln/detail/CVE-2025-32023
- https://cwe.mitre.org/data/definitions/680.html
گزارش فنی – اثبات آسیب‌پذیری ردیس (CVE-2025-32023)
معرفی آسیب‌پذیری
– نرم‌افزار آسیب‌پذیر: ردیس (Redis)
– نسخه‌های آسیب‌پذیر: از نسخه 2.8 تا قبل از نسخه‌های وصله‌شده (8.0.3، 7.4.5، 7.2.10، و 6.2.19)
– ماهیت مشکل: این آسیب‌پذیری ناشی از مدیریت ناقص داده‌های HyperLogLog (HLL) در عملیات‌هایی نظیر PFCOUNT و PFMERGE است. ارسال داده‌های دستکاری‌شده می‌تواند باعث نوشتن خارج از مرز (Out-of-Bounds Write) در حافظه (Heap یا Stack) شود. این موضوع منجر به کرش کردن ردیس و در برخی شرایط امکان اجرای کد از راه دور خواهد شد.
– شدت آسیب‌پذیری: بالا (High)
2. محیط آزمایش
برای بازتولید PoC شرایط زیر توصیه می‌شود:
– دسترسی به یک نمونه ردیس آسیب‌پذیر
– فعال بودن رمز عبور (Requirepass) یا دسترسی کاربری معتبر
– محیط آزمایشگاهی ایزوله برای جلوگیری از آسیب به سیستم‌های واقعی
3. اجرای POC
گام ۱: دریافت تصویر آسیب‌پذیر از نرم افزار ردیس
docker pull redis:7.4.2-alpine3.21@sha256:...
گام ۲: کلون کردن PoC
git clone https://github.com/leesh3288/CVE-2025-32023.git
cd CVE-2025-32023
گام ۳: اجرای یک کانتینر ردیس با رمز عبور
docker run -d --name redis-vuln -p 6379:6379 <IMAGE_ID> redis-server --requirepass vulnerableگام ۴: بررسی صحت اجرا
docker exec -it redis-vuln sh -c “redis-cli -a vulnerable ping” (خروجی: PONG)
گام ۵: اجرای PoC
python3 poc.py --host 127.0.0.1 --port 6379 --password vulnerable
گام ۶: در صورت موفقیت، خطای Connection Refused مشاهده می‌شود که نشان‌دهنده کرش ردیس است.
گام ۷: تأیید کرش با دستور
docker ps -a | grep redis-vuln
۴. نتیجه مورد انتظار
در محیط امن، ارسال داده‌های HLL مخرب نباید موجب کرش یا دسترسی غیرمجاز شود. سیستم باید ورودی‌ها را اعتبارسنجی کرده و از نوشتن خارج از مرز در حافظه جلوگیری کند.
۵. تحلیل فنی
آسیب‌پذیری CVE-2025-32023 به دلیل عدم اعتبارسنجی کامل داده‌های HyperLogLog در هنگام انجام عملیات‌های PFCOUNT و PFMERGE رخ می‌دهد. مهاجم می‌تواند داده‌های خاصی طراحی کرده و آن را در ردیس ذخیره کند. در زمان پردازش این داده‌ها، ساختار HLL به صورت نادرست در حافظه تفسیر شده و باعث نوشتن خارج از محدوده می‌شود.این نقص منجر به کرش سرور ردیس می‌شود و در برخی محیط‌ها امکان اجرای کد از راه دور (RCE) را برای مهاجم فراهم می‌کند. بهره‌برداری از آن نیازمند کاربر احراز هویت شده است، اما در بسیاری از موارد ردیس با تنظیمات نادرست در شبکه‌های داخلی یا حتی اینترنت بدون کنترل کافی در دسترس قرار دارد.
اسکریپت poc.py با هدف بازتولید آسیب‌پذیری CVE-2025-32023 طراحی شده است. در این کد ابتدا یک ساختار HyperLogLog غیرمعتبر ساخته می‌شود. برای این کار، توابعی مانند p8 و xzero مقادیر باینری تولید می‌کنند که باید نشان‌دهنده طول و داده‌های معتبر HLL باشند، اما در این PoC عمداً از مقادیر غیرعادی استفاده می‌شود. بخش اصلی این تقلب در خطی است که یک بخش بسیار بزرگ داده با طول محاسبه‌شده برابر -0x80000000 به ساختار اضافه می‌کند. این رفتار باعث می‌شود هنگام پردازش، حافظه Redis دچار نوشتن خارج از محدوده (Out-of-Bounds Write) شود.
پس از آماده‌سازی payload معیوب، داده در کلیدی به نام hll:exp ذخیره می‌شود و سپس با اجرای دستور pfcount روی همان کلید، Redis مجبور به انجام عملیات merge روی HLL خراب‌شده می‌شود. در همین نقطه آسیب‌پذیری خود را نشان می‌دهد؛ زیرا پردازشگر Redis قادر به مدیریت داده‌های معیوب نیست و به‌دلیل دستکاری طول و ساختار HLL، منجر به کرش پروسه Redis می‌شود. این کرش در محیط‌های واقعی می‌تواند به اختلال سرویس (DoS) منجر شود و در شرایط خاص، با توجه به چیدمان حافظه، امکان اجرای کد مخرب نیز فراهم گردد.
۶. رفع مشکل
– بروزرسانی ردیس به نسخه‌های امن: 8.0.3، 7.4.5، 7.2.10، یا 6.2.19
– محدود کردن دسترسی به ردیس (Bind به localhost یا شبکه داخلی)
– فعال‌سازی رمز عبور و استفاده از ACL برای کنترل دسترسی کاربران
– اجرای ردیس با کمترین سطح دسترسی و در محیط ایزوله (Container/VM)
– پایش لاگ‌ها و مانیتورینگ ردیس برای شناسایی کرش‌های غیرمنتظره
۷. زنجیره حمله پیشنهادی
زنجیره حمله مربوط به این آسیب پذیری در شکل زیر قابل مشاهده است
۹. منابع
- https://github.com/leesh3288/CVE-2025-32023.git
- https://github.com/shayantrix/POC-CVE-2025-32023
- https://nvd.nist.gov/vuln/detail/CVE-2025-32023
- https://redis.io
- https://cwe.mitre.org/data/definitions/787.html
CVE-2025-32023 – Redis HyperLogLog Out-of-Bounds Write (HLL) / Crash (PoC)
CVE ID: CVE-2025-32023
Severity: High (estimated — can lead to crash and has potential for remote code execution when exploited).
Affected Versions: Redis >= 2.8 up to (but before) 8.0.3, 7.4.5, 7.2.10, and 6.2.19
Tested On: redis:7.4.2-alpine3.21 (image sha256: 02419de7eddf55aa5bcf49efb74e88fa8d931b4d77c07eff8a6b2144472b6952)
Proof-of-Concept (PoC) Repositories:
Description
A specially crafted HyperLogLog (HLL) payload can trigger an out-of-bounds write during HLL merge operations, such as PFCOUNT or PFMERGE, in certain affected Redis versions. To exploit this issue, an authenticated user must provide the malformed HLL data. Successful exploitation corrupts Redis memory, which leads to process crashes and, depending on the environment and memory layout, may allow arbitrary code execution.
Prerequisites
- Access to a vulnerable Redis instance (authentication required if
requirepassor ACLs are in use). - A testing / isolated lab environment (do not run PoCs against production systems).
Proof of Concept (PoC) — reproduction steps (as tested)
- Pull vulnerable Redis docker image
Execute the PoC script
python3 poc.py --host 127.0.0.1 --port 6379 --password vulnerable
Expected PoC behavior (observed when successful)
During execution you may see output like:
- Setting malformed HLL payload…
- Triggering HLL merge with pfcount…
ConnectionRefusedError: Error 111 connecting to 127.0.0.1:6379. Connection refused.
A connection refused at this point indicates the Redis process crashed (the PoC corrupted memory and triggered a crash during PFCOUNT).
Confirm the Redis container crashed
docker ps -a | grep redis-vuln
container may show as exited/crashed
Expected Result
In a secure, patched Redis server, malformed HLL inputs should not corrupt memory or cause crashes. HLL merge operations must check and safely handle malformed or unexpected HLL payloads to prevent out-of-bounds writes.
Mitigation
- Upgrade Redis to the non-vulnerable versions listed by the Redis project or security advisories. Apply the official patches provided by Redis maintainers.
- Restrict access to Redis. Require authentication using requirepass or ACLs. Bind to localhost or internal networks, and use firewall rules to limit access to trusted hosts only.
- Run Redis with the least privileges and in isolated containers or virtual machines for untrusted workloads.
- Monitor Redis processes and logs for crashes and unusual behavior. Maintain regular backups and have safe restoration procedures.
- Apply common hardening practices, such as network segmentation and protections similar to fail2ban, while avoiding direct exposure of Redis to the internet.
References
PoC (repo): https://github.com/leesh3288/CVE-2025-32023.git
PoC (repo): https://github.com/shayantrix/POC-CVE-2025-32023
Note: The references above are the PoC repositories for reproduction and research. For official advisories, patched version numbers, and CVE metadata, check Redis security advisories, NVD, and vendor CVE pages.
Conclusion
This vulnerability needs an authenticated user to provide specially crafted HyperLogLog data. This data can create a stack or heap out-of-bounds write during HLL merge operations. It may lead to process crashes and poses a risk for remote code execution in certain environments. Consider vulnerable Redis instances as high-risk and fix them quickly in controlled environments.
Disclaimer
This PoC and instructions are for educational and research purposes only. Do not run this PoC on production systems or systems you do not own or do not have permission to test. The author takes no responsibility for misuse or unintended outcomes from following these instructions.
