پستگرس‌کیوال ۵۲ نقص امنیتی را وصله کرد؛ از جمله یک باگ ۲۲ ساله که اجرای کد از راه دور با احراز هویت را ممکن می‌کرد
اخبار داغ فناوری اطلاعات و امنیت شبکهیک نقص از نوع اشتباه نوع (Type Confusion) در PostgreSQL به کاربر پایگاه داده‌ای که می‌تواند شیء (Object) بسازد، اجازه می‌دهد روی سرور کد اجرا کند. به‌روزرسانی‌های منتشرشده در روز گذشته آن را همراه با ۵۱ نقص امنیتی دیگر برطرف کرده‌اند. حفاظت کامل از این نقص، مستلزم بازسازی (Rebuild) هر افزونه نوشته‌شده به زبان C روی سرور نیز هست.
مشخصات آسیب‌پذیری
این نقص با شناسه CVE-2026-6460 و امتیاز ۸.۸ در مقیاس CVSS ردیابی می‌شود. هر کدی که از این راه اجرا شود، با مجوزهای کاربر سیستم‌عاملی که PostgreSQL را اجرا می‌کند اجرا خواهد شد. تمام نسخه‌های پیش از ۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ و ۱۴.۲۵ تحت تأثیر هستند.
گروه توسعه جهانی PostgreSQL، که انتشار این پایگاه داده را بر عهده دارد، گزارشی از حملات واقعی با این نقص نداده است. ارزیابی CISA در رکورد CVE نیز وضعیت بهره‌برداری را «هیچ» اعلام کرده است.
ریشه فنی: تغییر نوع فیلد در حالی که مقادیر قدیمی هنوز زنده‌اند
این نقص به انواع مرکب (Composite Types) مربوط می‌شود؛ انواعی که از چند فیلد نام‌دار ساخته شده‌اند و هر فیلد نوع داده خودش را دارد. نوع یک فیلد می‌تواند تغییر کند، در حالی که مقادیر قدیمی‌ای از همان نوع هنوز در بخش‌های دیگر سرور نگهداری می‌شوند.
در این حالت، سرور می‌توانست یک مقدار قدیمی را به‌گونه‌ای بخواند که گویی نوع جدید را دارد. وصله، طبق یادداشت‌های انتشار پروژه، بررسی نسخه اضافه می‌کند تا سرور بتواند مقداری را که دیگر با نوعش هم‌خوان نیست تشخیص دهد.
پژوهش Mehmet Ince: از یک «ابزار» ۲۲ ساله تا RCE
پژوهشگر امنیتی مهمت اینجه (Mehmet Ince) در یک تحلیل فنی منتشرشده در همین هفته، یک اکسپلویت کارکن برای این نقص را، با نمایش روی PostgreSQL 18.6، شرح داده است.
روش او به این شکل است: یک پرس‌وجو (Query) آماده می‌شود که یک مقدار را نگه می‌دارد، نوع یکی از فیلدهای آن مقدار تغییر می‌کند و سپس پرس‌وجو اجرا می‌شود. نوشته او شامل SQL مربوط به کرش کردن یک سرور وصله‌نشده و یک گام دوم برای نشت آدرس‌های حافظه است؛ اما SQL مرحله آخر — که سرور را وادار به اجرای دستور می‌کند — در آن گنجانده نشده است.
چه سطحی از دسترسی لازم است؟
اینجه نوشته توانسته این کرش را «به‌عنوان نقش ورود با کمترین سطح دسترسی» ایجاد کند. اما اطلاعیه امنیتی پروژه، مهاجم را فقط کسی توصیف می‌کند که می‌تواند شیء بسازد، بدون این‌که مشخص کند چه مجوزهایی لازم است. ارزیابی Red Hat نیز می‌گوید مهاجم به یک ورود پایگاه داده با توانایی ساختن یا تغییر اشیا نیاز دارد.
هیچ‌یک از این منابع مشخص نمی‌کند آیا حسابی که فقط مجوزهای پیش‌فرض دارد، می‌تواند فراتر از کرش برود و کد اجرا کند.
قدمت ۲۲ ساله
به گفته اینجه، ریشه این نقص به ۵ می ۲۰۰۴ بازمی‌گردد؛ زمانی که PostgreSQL امکان تغییر نوع یک ستون را به دست آورد. تکنیک او برای اجرای کد، به تغییری بعدی در ۱۴ می ۲۰۱۵ متکی است.
سرویس‌های مدیریت‌شده
او همچنین اکسپلویت را برای سرویس‌های مدیریت‌شده PostgreSQL تطبیق داده و در اوت، نمونه‌های اثبات مفهوم را به‌صورت خصوصی با تیم‌های امنیتی آن‌ها به اشتراک گذاشته است. ارائه‌دهندگانی که او با آن‌ها هماهنگ کرده شامل AWS (Aurora و RDS)، مایکروسافت (Azure PostgreSQL)، گوگل (AlloyDB)، Supabase، Databricks و Ubicloud هستند. تحلیل او وضعیت فعلی وصله هر سرویس را مشخص نمی‌کند.
پروژه بیش از یک دوجین گزارش‌دهنده را برای CVE-2026-6460 معرفی کرده، از جمله این پژوهشگر، و او را در پنج نقص دیگر همین انتشار نیز نام برده است.
۵۲ نقص در یک نگاه
پروژه ۳۲ نقص از ۵۲ نقص را با امتیاز ۸.۸ ارزیابی کرده که بالاترین امتیاز این انتشار است. بر اساس شاخص آسیب‌پذیری‌های پروژه، تنها یک نقص در سرور وجود دارد که نه به ورود نیاز دارد و نه به اقدام کاربر: CVE-2026-116322، که به یک کلاینت احراز هویت‌نشده اجازه می‌دهد سرورهای PostgreSQL 18 را وادار به ری‌استارت کند.
نقص‌های ابزارهای کلاینت
چند وصله دیگر مربوط به ابزارهای کلاینت است:
- یک آرشیو دستکاری‌شده می‌تواند باعث شود pg_restore کد را با مجوزهای کاربری که آن را اجرا می‌کند، اجرا کند.
- یک سرور مبدأ به‌خطرافتاده می‌تواند باعث شود psql از طریق اسکریپت بازیابی در خروجی tar ابزار pg_dump، کد اجرا کند.
مدیران سیستم چه باید بکنند؟
۱. سرور را به‌روزرسانی کنید به ۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ یا ۱۴.۲۵، متناسب با نسخه اصلی خود.
۲. هر افزونه زبان C را هم‌زمان با سرور بازسازی یا به‌روز کنید. افزونه‌های ساخته‌شده با نسخه‌های قدیمی‌تر هنوز بارگذاری می‌شوند، اما طبق یک اطلاعیه از نگهدارندگان بسته‌های RPM پروژه، ممکن است در برابر آسیب‌پذیری‌های رفع‌شده در این انتشار محافظت نشوند. برخی افزونه‌ها نیاز به تغییر در کد منبع نیز دارند.
۳. افزونه‌هایی که برای نسخه‌های جدید بازسازی شده‌اند، ممکن است روی سرورهای قدیمی‌تر بارگذاری نشوند. بسته‌های افزونه در مخازن RPM پروژه اکنون نسخه فرعی جدید را الزامی می‌کنند.
۴. اگر PostgreSQL خارج از واحد سرویس خود بسته اجرا می‌شود (مثلاً زیر Patroni)، بلافاصله پس از به‌روزرسانی آن را ری‌استارت کنید.
۵. ابزارهای کلاینت مانند pg_dump، pg_restore، reindexdb و vacuumdb را روی تمام ماشین‌هایی که آن‌ها را اجرا می‌کنند به‌روز کنید.
۶. از تنظیم تازه composite_type_mismatch برای خاموش کردن بررسی‌ها استفاده نکنید؛ پروژه می‌گوید این کار ریسک امنیتی دارد.
۷. اطلاعیه امنیتی و یادداشت‌های انتشار پروژه، هیچ راهکار موقتی برای سرورهایی که هنوز نمی‌توانند به‌روز شوند، ارائه نمی‌کنند.
۸. PostgreSQL 14 به پایان عمر رسیده و 14.25 آخرین نسخه آن است. نسخه‌های اصلی قدیمی‌تر نیز تحت تأثیرند و به‌روزرسانی دریافت نکرده‌اند.
۹. پس از به‌روزرسانی، مراحل بازنمایه‌سازی (Reindexing) را طبق اطلاعیه انتشار دنبال کنید. اگر از پشتیبان‌گیری افزایشی استفاده می‌کنید، یک نسخه پشتیبان کامل جدید بگیرید و پشتیبان‌های افزایشی بعدی را بر پایه آن بسازید.
چرا این گزارش اهمیت دارد؟
نخست، عمر نقص: ریشه‌ای که به سال ۲۰۰۴ برمی‌گردد و بیش از دو دهه در یکی از معتبرترین پایگاه‌های داده متن‌باز باقی مانده است، نشان می‌دهد تعامل پیچیده میان ویژگی‌های قدیمی و تغییرات بعدی (مثل تغییر ۲۰۱۵) می‌تواند مسیرهای بهره‌برداری غیرمنتظره بسازد.
دوم، پیچیدگی وصله‌کردن: در این مورد، به‌روزرسانی سرور به‌تنهایی کافی نیست؛ افزونه‌های C نیز باید بازسازی شوند و برخی ابزارهای کلاینت جداگانه به‌روز شوند. این چندلایه‌بودن، ریسک «وصله ناقص» را بالا می‌برد. سوم، ارتباط با سرویس‌های ابری: گستردگی ارائه‌دهندگانی که پژوهشگر با آن‌ها هماهنگ کرده، نشان می‌دهد پستگرس‌کیوال در بسیاری از زیرساخت‌های مدیریت‌شده به کار می‌رود.
نکته مهم دیگر، محدوده واقعی ریسک: بهره‌برداری، نیازمند حسابی است که بتواند شیء بسازد (و احتمالاً مجوزهای بیش از حداقل). بنابراین، تهدید اصلی برای محیط‌هایی است که حساب‌های کم‌اعتماد یا چندمستأجره (Multi-Tenant) روی همان سرور دارند. اما تا زمانی که روشن نشود حساب پیش‌فرض چه کارهایی می‌تواند بکند، احتیاط توصیه می‌شود. در عین حال، هیچ حمله شناخته‌شده‌ای گزارش نشده و مرحله پایانی اکسپلویت منتشر نشده است.
توصیه‌های امنیتی
- فوراً به نسخه‌های وصله‌شده (۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ یا ۱۴.۲۵) ارتقا دهید و افزونه‌های C را هم‌زمان بازسازی کنید.
- اگر از PostgreSQL 14 یا نسخه‌های قدیمی‌تر استفاده می‌کنید، برنامه مهاجرت به یک نسخه پشتیبانی‌شده را آغاز کنید؛ چون دیگر وصله نمی‌گیرند.
- مجوز ساخت و تغییر اشیا (CREATE و مشابه) را از حساب‌هایی که به آن نیاز ندارند بردارید، به‌ویژه در محیط‌های چندمستأجره؛ این کار سطح بهره‌برداری را کاهش می‌دهد (اما جایگزین وصله نیست).
- در سرویس‌های مدیریت‌شده، وضعیت وصله را از ارائه‌دهنده خود استعلام کنید؛ وضعیت فعلی هر سرویس در گزارش منتشرشده مشخص نیست.
- ابزارهای کلاینت (pg_dump، pg_restore، psql و...) را به‌روز کنید و از باز کردن آرشیوهای ناشناس با pg_restore خودداری نمایید.
- پس از به‌روزرسانی، مراحل بازنمایه‌سازی و در صورت لزوم گرفتن پشتیبان کامل جدید را انجام دهید.
- اگر PostgreSQL را زیر ابزارهایی مثل Patroni اجرا می‌کنید، بلافاصله پس از به‌روزرسانی سرویس را ری‌استارت کنید.
جمع‌بندی
CVE-2026-6460 نمونه‌ای از یک باگ بسیار قدیمی است که با یک اکسپلویت کارکن، مسیری از یک حساب با توانایی ساخت شیء به اجرای کد روی سرور باز می‌کند. هرچند شواهدی از بهره‌برداری فعال وجود ندارد و مرحله پایانی اکسپلویت منتشر نشده، اما وصله‌کردن این نقص به‌دلیل لزوم بازسازی افزونه‌های C و به‌روزرسانی ابزارهای کلاینت، پیچیده‌تر از یک ارتقای ساده است. مدیران باید سرور، افزونه‌ها و ابزارهای کلاینت را با هم به‌روز کنند و به پایان عمر نسخه ۱۴ توجه داشته باشند.
برچسب ها: امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, حمله سایبری, news, PostgreSQL