‏PostGREShell: باگ ۱۲ساله‌ی PostgreSQL

محقق‌های Cyera Research یه باگ امنیتی حساس به اسم PostGREShell (با شناسه CVE-2026-6471) رو تو PostgreSQL کشف کردن؛ همون دیتابیس متن‌بازی که بیش از ۳۹ هزار شرکت از جمله Netflix، اینستاگرام، اسپاتیفای و Uber از‌ش استفاده می‌کنن. به گفته‌ی نویسنده این باگ از نسخه ۹.۴ (یعنی از سال ۲۰۱۴) تا الان تو همه‌ی نسخه‌ها بوده و تازه وصله شده.

ماجرا از اکانت‌های «replication» شروع می‌شه؛ همون اکانت‌هایی که برای هماهنگ نگه‌داشتن نسخه‌ی بکاپ دیتابیس استفاده می‌شن. وقتی این اکانت‌ها یه «logical replication slot» می‌سازن، باید اسم یه output plugin (مثل pgoutput) بدن که PostgreSQL بارش می‌کنه. مشکل اینه که PostgreSQL برای مسیر معمولی (دستور LOAD) چک امنیتی داره که نمی‌گذاره پلاگین از هر مسیری لود شه، اما همین چک روی مسیر replication اصلاً صدا زده نمی‌شه؛ اسمی که کاربر می‌ده مستقیم می‌ره به dlopen() یا LoadLibrary()، بدون هیچ فیلتری.

روی ویندوز این باگ کاملاً از راه دور قابل استفاده‌ست: چون ویندوز مسیرهای UNC رو خودکار از روی شبکه (SMB) بار می‌کنه، مهاجم فقط با دادن یه آدرس شبکه‌ای می‌تونه سرور رو مجبور کنه فایل مخرب رو از سرور خودش دانلود و اجرا کنه، بدون اینکه چیزی روی سرور قربانی بذاره. روی لینوکس و مک هم اگه automount شبکه (NFS) فعال باشه همین اتفاق از راه دور ممکنه؛ در غیر این صورت مهاجم باید یه راه دیگه برای گذاشتن فایل روی دیسک سرور پیدا کرده باشه.

بعد از اجرای کد، مهاجم هنوز فقط همون اکانت بکاپ کم‌دسترسیه؛ ولی چون کد لود‌شده هیچ محدودیت امنیتی نداره، می‌تونه مستقیم تو جدول pg_authid بنویسه و خودش رو سوپریوزر کنه، بدون اینکه از چک‌های دسترسی معمول رد بشه. بعدش سه راه برای برگشت همیشگی می‌ذاره: تغییر pg_hba.conf برای اتصال بدون رمز، ثبت خودش تو shared_preload_libraries تا بعد از هر ری‌استارت دوباره بار شه، و برگرداندن دسترسی سوپریوزر اگه ادمین یکیش رو پیدا و پاک کنه.

نویسنده می‌گه این اولین‌بار نیست که همین الگو دیده می‌شه: Redis با دستور MODULE LOAD قبلاً قربانی بات‌نت‌هایی مثل HeadCrab شده و باگ مشابهش («RediShell») حدود ۱۳ سال روی ۳۳۰ هزار سرور باز بوده. OpenVPN، MySQL، MariaDB، Percona، MongoDB و SQLite JDBC هم قبلاً همین مشکل «لود کردن پلاگین بدون چک» رو داشتن. به گفته‌ی نویسنده، دلیلش اینه که تیم‌های مختلف، مسیر لود پلاگین رو جدا از مدل امنیتی اصلی می‌سازن.

Cyera از فوریه‌ی ۲۰۲۶ این باگ رو به تیم امنیتی PostgreSQL گزارش کرده بود و وصله‌ش شهریور امسال منتشر شد. توصیه می‌شه فوری آپدیت کنید، اکانت‌های replication رو چک کنید و attribute REPLICATION رو از هرکسی که لازم نداره بردارید، pg_hba.conf رو محدود به آی‌پی‌های شناخته‌شده کنید و پورت‌های SMB (۴۴۵) و NFS (۲۰۴۹) رو از سرور دیتابیس به بیرون ببندید.

نکات کلیدی:

• شناسه: CVE-2026-6471؛ از نسخه ۹.۴ (سال ۲۰۱۴) تا ۱۸.۲ همه‌ی نسخه‌های PostgreSQL رو درگیر می‌کنه
• مسیر حمله: اکانت replication ← لود output plugin بدون اعتبارسنجی ← dlopen()/LoadLibrary ← نوشتن مستقیم رو pg_authid برای سوپریوزر شدن
• روی ویندوز حمله کاملاً از راه دور با UNC/SMB ممکنه؛ روی لینوکس/مک به NFS automount یا دسترسی نوشتن فایل نیاز داره
• تو VirusTotal ۱۱۴ پلاگین مخرب PostgreSQL (تروجان، ماینر، ریورس‌شل) پیدا شده
• راه‌حل فوری: آپدیت به نسخه‌ی وصله‌شده، حذف اکانت‌های replication غیرضروری، محدودکردن pg_hba.conf و بستن SMB/NFS خروجی