PostgreSQL نسخه‌های ۱۸.۶ تا ۱۴.۲۴ و بتای ۱۹ منتشر شد؛ ۲۸ اصلاح امنیتی در یک روز

سیزدهم اوت ۲۰۲۶ برای مدیران پایگاه‌داده روز شلوغی بود. گروه توسعه جهانی PostgreSQL به‌طور هم‌زمان نسخه‌های اصلاحی 18.6، 17.11، 16.15، 15.19 و 14.24 را منتشر کرد و PostgreSQL 19 Beta 3 نیز در دسترس قرار گرفت. محور اصلی این انتشار، رفع ۲۸ آسیب‌پذیری امنیتی در کنار ده‌ها رفع باگ است — ترکیبی که این به‌روزرسانی را از جنس «الزامی» می‌کند، نه اختیاری.

#چه اتفاقی افتاده است؟

چرخه انتشار نقطه‌ای (minor release) PostgreSQL معمولاً فصلی است، اما وقتی شمار اصلاحات امنیتی به ۲۸ مورد می‌رسد و همه شاخه‌های پشتیبانی‌شده را در بر می‌گیرد، پیام روشن است: حداقل بخشی از این آسیب‌پذیری‌ها روی نسخه‌های قدیمی‌تر نیز وجود داشته و پنجره سوءاستفاده برای سرورهای وصله‌نشده باز است. هم‌زمان، انتشار PostgreSQL 19 Beta 3 آخرین ایستگاه آزمایشی مهم پیش از نسخه نهایی است که طبق برنامه در سپتامبر ۲۰۲۶ عرضه می‌شود. نکته زمانی دیگر: پایان عمر (EOL) نسخه ۱۴ در ۱۲ نوامبر ۲۰۲۶ خواهد بود؛ یعنی کاربران این شاخه کمتر از سه ماه فرصت دارند برنامه مهاجرت را نهایی کنند.

PostgreSQL 19 در سپتامبر ۲۰۲۶ نهایی می‌شود؛ نسخه ۱۴ در نوامبر بازنشسته خواهد شد. — PostgreSQL Global Development Group

#جزئیات فنی

در مدل پشتیبانی PostgreSQL، هر نسخه اصلی پنج سال پشتیبانی می‌شود و نسخه‌های نقطه‌ای صرفاً اصلاحی‌اند — یعنی ارتقای مثلاً 17.10 به 17.11 نیازی به dump/restore ندارد و با تعویض باینری و راه‌اندازی مجدد انجام می‌شود. همین سادگی، ارتقای فوری را برای بیشتر استقرارها شدنی می‌کند. در مقابل، ارتقای میان نسخه‌های اصلی (مثلاً ۱۴ به ۱۷) نیازمند pg_upgrade یا تکثیر منطقی است و باید از قبل برنامه‌ریزی شود. برای تیم‌هایی که Beta 3 نسخه ۱۹ را تست می‌کنند، این مرحله فرصت آزمون سازگاری اکستنشن‌ها (مانند PostGIS یا pg_stat_statements)، ابزارهای پشتیبان‌گیری و کوئری‌های حساس به تغییرات planner است؛ چون پس از GA، گزارش رگرسیون عملاً دیر خواهد بود.

از منظر کلان، این موج انتشار یادآور نقطه قوت تاریخی PostgreSQL است: فرایند انتشار منظم، شفاف و پیش‌بینی‌پذیر که به سازمان‌ها اجازه می‌دهد وصله‌ها را برنامه‌ریزی کنند. اما همان شفافیت یک تکلیف هم ایجاد می‌کند: با انتشار عمومی ۲۸ CVE، مهاجمان نیز فهرست اهداف را دریافت کرده‌اند و فاصله میان انتشار وصله و اکسپلویت عمومی در سال‌های اخیر به‌طرز محسوسی کوتاه شده است. سازمان‌هایی که PostgreSQL را در معرض اینترنت قرار داده‌اند، باید این موج را در اولویت بالاتری از به‌روزرسانی‌های معمول قرار دهند.

#چرا مهم است؟

نکته‌ای که در اخبار کوتاه گم می‌شود، اقتصاد «اصلاحات انباشته» است. ۲۸ CVE در یک موج، برای تیم‌هایی که چرخه وصله ماهانه دارند یعنی حداقل یک چرخه اضطراری خارج از نوبت؛ و برای سازمان‌هایی که PostgreSQL را در قالب سرویس مدیریت‌شده (RDS، Cloud SQL، Azure Database) مصرف می‌کنند، یعنی وابستگی به زمان‌بندی وصله ارائه‌دهنده. توصیه تحریریه ما: همین هفته موجودی نسخه‌های ۱۴ را استخراج کنید. با EOL در ۱۲ نوامبر، هر روز تأخیر، شما را به پنجره‌ای نزدیک‌تر می‌کند که در آن هم باید مهاجرت نسخه اصلی انجام دهید و هم اصلاحات امنیتی را تعقیب کنید — دو پروژه پرریسک که هم‌زمان‌شدنشان ایده بدی است. در مقابل، کسانی که روی ۱۷ یا ۱۸ هستند، با یک نگهداری کوتاه می‌توانند این موج را پشت سر بگذارند.

#اعداد و ارقام

• ۵ انتشار اصلاحی: 18.6 / 17.11 / 16.15 / 15.19 / 14.24
• ۲۸ آسیب‌پذیری امنیتی رفع‌شده
• PostgreSQL 19 Beta 3 منتشر شد؛ نسخه نهایی: سپتامبر ۲۰۲۶
• پایان پشتیبانی PostgreSQL 14: ۱۲ نوامبر ۲۰۲۶

در جمع‌بندی، توصیه عملی برای سه گروه متفاوت است: استقرارهای روی نسخه‌های ۱۷ و ۱۸ باید همین هفته وصله شوند؛ کاربران نسخه ۱۴ باید هم‌اکنون برنامه مهاجرت به ۱۷ یا ۱۸ را پیش از پایان پشتیبانی در نوامبر نهایی کنند؛ و تیم‌هایی که چشم به نسخه ۱۹ دارند، Beta 3 را آخرین فرصت جدی برای تست سازگاری اکستنشن‌ها و بارگذاری‌های واقعی بدانند. چرخه انتشار PostgreSQL نشان داده که قابل اعتماد است؛ بخش سخت ماجرا، به‌روز نگه‌داشتن سرورهای واقعی در برابر تقویم انتشار است.

#منابع

• postgresql.org — اخبار
• یادداشت‌های انتشار PostgreSQL