CVE-2026-119618: نقص HTTP/2 در Apache، ارتقا به 2.4.71

CVE-2026-119618 چیست؟

CVE-2026-119618 آسیب‌پذیری بحرانی در mod_http2، ماژولی در Apache HTTP Server که ترافیک HTTP/2 را مدیریت می‌کند، است؛ این نقص می‌تواند به خرابی حافظه هیپ و اجرای کد از راه دور منجر شود ^[1].

Apache آن را چنین توصیف می‌کند: «آسیب‌پذیری اجرای هم‌زمان با منبع مشترک و همگام‌سازی نادرست در mod_http2 سرور Apache HTTP در assign_headers()» که «می‌تواند به RCE منجر شود» ^[1]. CIRCL، تیم ملی واکنش اضطراری رایانه‌ای لوکزامبورگ، توضیح می‌دهد که در پردازش هم‌زمان جریان‌های HTTP/2، یک کارگر (worker) می‌تواند جدول سرآیندی را که برای بافت اجرای دیگری تخصیص یافته تغییر دهد و این دسترسی ناامن به حافظه مشترک می‌تواند هیپ را خراب کند ^[2].

مهاجم موفق می‌تواند بدون ورود به سیستم، کد را با سطح دسترسی فرایند وب‌سرور Apache اجرا کند ^[2][4]. به گزارش BleepingComputer، تخمین زده می‌شود Apache HTTP Server تقریباً روی یک پنجم وب‌سایت‌ها اجرا شود ^[4].

وصله بالادستی یک عمل نوشتن در modules/http2/h2_request.c را از جدول سرآیند مشترک درخواست به سرآیندهای ورودی خود درخواست جاری تغییر می‌دهد ^[2].

کدام نسخه‌های Apache آسیب‌پذیرند؟

Apache HTTP Server از 2.4.55 تا 2.4.70 متأثر است، همراه با نسخه‌های mod_h2 مستقل از 2.0.8 تا 2.0.42 در GitHub؛ نسخه 2.4.71 آن را رفع می‌کند ^[1].

بسته‌های توزیع‌های لینوکس بررسی نسخه را پیچیده می‌کنند. CIRCL به سازمان‌هایی که از بسته‌های نگهداری‌شده توسط توزیع‌کننده استفاده می‌کنند توصیه می‌کند وصله امنیتی بک‌پورت‌شده را بررسی کنند و فقط به شماره نسخه بالادستی تکیه نکنند ^[2]. Red Hat، به نقل از خلاصه CIRCL، بسته‌های RHEL 9 و 10 خود را به‌جای بحرانی «مهم» ارزیابی می‌کند چون تخصیص‌دهنده حافظه‌اش بهره‌برداری را دشوارتر می‌کند، و RHEL 8 و پیش از آن را بدون تأثیر گزارش می‌دهد ^[2].

Red Hat امتیاز عمومی CVSS v3.1 برابر ۹٫۸ (بحرانی) را اعلام می‌کند ^[2][3]. ارزیابی خود Apache نیز بحرانی است ^[1].

آیا سرور Apache من آسیب‌پذیر است؟

فقط اگر نسخه متأثر را اجرا کند و واقعاً اتصال‌های HTTP/2 را بپذیرد: Red Hat می‌گوید سرورهایی که فقط برای HTTP/1.1 پیکربندی شده‌اند آسیب‌پذیر نیستند ^[3]. CIRCL تأکید می‌کند صرف نصب یا بارگذاری mod_http2 مسیر کد را در دسترس نمی‌کند ^[2].

• دستور Protocols HTTP/2 را کنترل می‌کند: «h2» آن را روی TLS و «h2c» روی متن ساده فعال می‌کند ^[2].
• پیش‌فرض هسته Apache http/1.1 است و بارگذاری mod_http2 به‌تنهایی آن را تغییر نمی‌دهد ^[2]. BleepingComputer یادآور می‌شود HTTP/2 به‌طور پیش‌فرض خاموش است ^[4].
• یک میزبان مجازی می‌تواند دستور Protocols مخصوص خود را داشته باشد، پس بررسی فقط پیکربندی سراسری ممکن است سایتی را که HTTP/2 دارد از قلم بیندازد ^[2].
• اگر یک پروکسی معکوس، متعادل‌کننده بار یا CDN، HTTP/2 را خاتمه دهد و فقط HTTP/1.1 را به Apache بفرستد، نشست HTTP/2 مشتری به‌خودی‌خود Apache را در دسترس نمی‌کند، اما باید پروتکل را در هر گام بررسی کنید ^[2].

CIRCL بررسی نسخه و ماژول‌های بارگذاری‌شده (apachectl -v و apachectl -M)، میزبان‌های مجازی پیکربندی‌شده (apachectl -S) و هر تنظیم صریح Protocols را پیشنهاد می‌کند ^[2]. آزمونی که نشان دهد یک نقطه پایانی HTTP/2 را می‌پذیرد ثابت نمی‌کند پس‌زمینه‌اش آسیب‌پذیر است، و آزمون منفی ثابت نمی‌کند هر درگاه یا میزبان مجازی HTTP/2 را رد می‌کند ^[2].

چگونه بررسی کنم سرورم HTTP/2 را می‌پذیرد؟

CIRCL دو بررسی پیشنهاد می‌کند: پیکربندی Apache را روی خود سرور مرور کنید، سپس پروتکل مذاکره‌شده را از شبکه آزمایش کنید، ترجیحاً با اتصال مستقیم به Apache و نه از راه پروکسی ^[2].

1. نسخه و ماژول‌ها را بررسی کنید. apachectl -v را برای دیدن نسخه و apachectl -M را، با فیلتر http2، برای دیدن اینکه ماژول بارگذاری شده است یا نه اجرا کنید ^[2].
2. میزبان‌های مجازی را فهرست کنید. apachectl -S همه میزبان‌های مجازی پیکربندی‌شده را نشان می‌دهد؛ این مهم است چون هر کدام می‌تواند خط Protocols خودش را داشته باشد ^[2].
3. همه دستورهای Protocols را پیدا کنید. CIRCL یک فرمان grep می‌دهد که /etc/apache2 و /etc/httpd را برای تنظیمات صریح Protocols، از جمله بازنویسی‌های میزبان مجازی، جست‌وجو می‌کند؛ مسیرها بسته به توزیع فرق می‌کنند ^[2].
4. روی TLS آزمایش کنید. درخواست curl با گزینه --http2 که نسخه HTTP را چاپ می‌کند نشان می‌دهد نقطه پایانی HTTPS با HTTP/2 مذاکره می‌کند یا نه ^[2].
5. متن ساده را آزمایش کنید. curl با --http2-prior-knowledge بررسی می‌کند نقطه پایانی HTTP ساده h2c را می‌پذیرد یا نه ^[2].

نتایج را با دقت بخوانید. پاسخی که HTTP/2 را گزارش می‌کند نشان می‌دهد نقطه پایانی آزمایش‌شده HTTP/2 را پذیرفته است اما تأیید نمی‌کند پس‌زمینه Apache آن آسیب‌پذیر است؛ نتیجه منفی ثابت نمی‌کند هر نشانی، درگاه یا میزبان مجازی آن را رد می‌کند ^[2]. توصیه CIRCL این است که پیکربندی مؤثر Apache و وضعیت بسته وصله‌شده فروشنده را با هم تأیید کنید ^[2]. در محیط‌های ابری، Wiz هشدار می‌دهد یک نمونه Apache نفوذشده می‌تواند نقطه ورودی برای حرکت جانبی به ریزسرویس‌های مجاور یا نقاط پایانی ابرداده ابری شود، که دلیل دیگری برای بررسی هر نمونه است، نه فقط وب‌سایت عمومی ^[5].

CVE-2026-119618 را چگونه رفع کنم؟

به Apache HTTP Server نسخه 2.4.71 یا بالاتر ارتقا دهید یا بسته وصله‌شده توزیع خود را نصب کنید، سپس Apache را راه‌اندازی مجدد کنید و تأیید کنید فرایندهای در حال اجرا از نسخه جدید استفاده می‌کنند ^[2][1].

1. Apache را به‌روز کنید. نسخه 2.4.71 یا ساخت فروشنده‌ای را که صریحاً برای CVE-2026-119618 وصله شده نصب کنید ^[2].
2. mod_h2 مستقل را به‌روز کنید اگر از آن استفاده می‌کنید، طبق دستور فروشنده‌اش؛ Wiz می‌گوید از 2.0.42 فراتر بروید، در حالی که CIRCL هشدار می‌دهد بدون بررسی فرض نکنید نسخه مستقل جدیدتری وجود دارد ^[5][2].
3. راه‌اندازی مجدد و تأیید کنید که فرایندهای در حال اجرا از ساخت اصلاح‌شده استفاده می‌کنند ^[2].
4. اگر هنوز نمی‌توانید وصله کنید، HTTP/2 را غیرفعال کنید: Protocols را روی http/1.1 بگذارید، h2 و h2c را از هر میزبان مجازی بازنویسی‌کننده حذف کنید، با apachectl -t آزمایش کنید و بارگذاری مجدد انجام دهید ^[2]. این کار مسیر این نقص را می‌بندد اما کد را اصلاح نمی‌کند ^[2].
5. دسترسی را محدود کنید به شبکه‌های مورد اعتماد، به‌عنوان اقدام موقت جایی که نه وصله ممکن است و نه تغییر پروتکل ^[2].

به گزارش BleepingComputer، پژوهشگران watchTowr آن را چنین جمع‌بندی کردند: «همین حالا وصله کنید یا تا زمان امکان h2 را کنار بگذارید» ^[4]. SecurityWeek گزارش می‌دهد Defiant هم هشدار داد به‌روزرسانی‌های امنیتی WordPress نمی‌توانند این مشکل را حل کنند چون وب‌سرور زیربنایی را تحت تأثیر قرار می‌دهد ^[3].

آیا از CVE-2026-119618 بهره‌برداری می‌شود؟

تا زمان پست Wiz در ۱۱ نوامبر ۲۰۲۶، هیچ اکسپلویتی در دسترس نبود و گزارشی از بهره‌برداری در دنیای واقعی وجود نداشت ^[5]. با این حال وضعیت به‌سرعت در حال تغییر است.

• Red Hat می‌گوید پژوهشی عمومی یک اکسپلویت قابل‌اعتماد علیه سروری که mod_http2 در آن فعال است نشان داده، اما اطلاعیه‌اش آن پژوهش را مشخص نمی‌کند ^[3]. CIRCL یادآور می‌شود این به‌تنهایی بهره‌برداری در دنیای واقعی را ثابت نمی‌کند ^[2].
• یک اثبات مفهوم عمومی در GitHub بازتولید خرابی حافظه و کرش Apache را گزارش می‌کند، اما اجرای کد از راه دور را نشان نمی‌دهد ^[3].
• داده‌های Wiz نشان می‌دهد ۶۴٪ محیط‌های ابری منابعی با نسخه‌های متأثر دارند و ۵۱٪ نمونه‌هایی در معرض دید عمومی؛ Wiz یادآور می‌شود این آمار پیکربندی را در نظر نمی‌گیرد، پس لزوماً سامانه‌های قابل بهره‌برداری نیستند ^[5][3].

CIRCL نشانه‌هایی را فهرست می‌کند که ارزش بررسی دارند: کرش غیرمنتظره کارگرها، راه‌اندازی‌های مجدد غیرعادی، فرایندهای فرزند مشکوک، تغییر فایل‌های غیرمجاز و اتصال‌های خروجی غیرمنتظره ^[2]. این‌ها سرنخ‌اند، نه شاخص‌های تأییدشده نفوذ، و وصله کردن ماندگاری‌ای را که پیش از به‌روزرسانی برقرار شده از بین نمی‌برد ^[2].

چه کسی نقص HTTP/2 در Apache را پیدا کرد؟

Apache از OSS Scanner شرکت Anthropic که نقص را در ۲۶ اکتبر ۲۰۲۶ گزارش کرد، و از Anthony Weems و Simon Scannell از Google Cloud Vulnerability Research که جداگانه در ۳ نوامبر آن را گزارش کردند، قدردانی می‌کند ^[1].

یافته Anthropic با شناسه داخلی ANT-2026-MAPKT6MZ ثبت شده است ^[1]. SecurityWeek این دو گزارش را کشف‌های مستقل توصیف می‌کند ^[3]. این نمونه‌ای دیگر از یافتن اشکالات جدی در نرم‌افزار متن‌باز پرکاربرد به‌دست ابزارهای خودکار و مبتنی بر هوش مصنوعی است؛ AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You بررسی می‌کند این روند چه معنایی دارد.

وصله ثبت و نسخه 2.4.71 در ۱۱ نوامبر منتشر شد، همان روزی که Apache موضوع را در فهرست پستی oss-security افشا کرد ^[1][2].

نسخه Apache 2.4.71 چه چیز دیگری را رفع می‌کند؟

Apache HTTP Server نسخه 2.4.71 در مجموع سه CVE را رفع می‌کند: یکی بحرانی، یکی مهم و یکی کم‌اهمیت ^[1].

• CVE-2026-106023 (مهم): ارجاع به اشاره‌گر NULL در mod_md هنگام پردازش درخواست که می‌تواند یک فرایند فرزند را از کار بیندازد؛ نسخه‌های 2.4.30 تا 2.4.70 را در بر می‌گیرد ^[1].
• CVE-2026-109163 (کم‌اهمیت): بازنویسی یک‌بایتی بافر پشته در mod_vhost_alias که Apache آن را «پس از CVE-2026-63292» برچسب می‌زند (آن نقص پیشین در 2.4.69 رفع شده بود)؛ نسخه‌های 2.4.69 و 2.4.70 را در بر می‌گیرد ^[1].

نسخه قبلی، 2.4.69 در اکتبر ۲۰۲۶، ۲۰ CVE را رفع کرد ^[1]. مدیرانی که آن را رد کرده‌اند با رفتن به 2.4.71 این رفع‌ها را هم می‌گیرند. برای نقص اخیر دیگری در سرورها، CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers را ببینید.

مدیران سیستم بعد چه چیزی را باید زیر نظر بگیرند؟

انتشار یک اکسپلویت عمومی اجرای کد از راه دور، بک‌پورت‌های فروشنده برای توزیع خودتان و هر گزارش از حملات در دنیای واقعی را دنبال کنید ^[3][5].

CIRCL توصیه می‌کند فهرست نمونه‌های دارای HTTP/2 تهیه شود، بررسی شود هر ساخت mod_http2 متأثر است یا نه و سامانه‌های در معرض دید بدون تأخیر وصله شوند، با اولویت برای وب‌سایت‌ها و APIهای متصل به اینترنت، میزبانی اشتراکی و سرورهای Apache پشت فرانت‌اندهایی که HTTP/2 را عبور می‌دهند ^[2]. سازمان‌هایی که فعالیت مشکوک می‌بینند باید از رویه‌های واکنش به رخداد خود پیروی و با CSIRT ملی‌شان تماس بگیرند ^[2].