ثغرات NGINX لأكتوبر 2026: كيف بتعرف من nginx.conf إذا سيرفرك متأثر؟

NGINX 1.30.6 و1.31.7 سكّروا خمس ثغرات بـ 14 أكتوبر 2026، وكل وحدة إلها إعداد بيفتحها. الأمر nginx -T مع grep بيلقط أنماط أغلبهن، والترقية بتسكّر الخمسة.

نُشر في 21 أكتوبر 202612 دقيقة قراءة#NGINX #تحديثات أمنية #Docker

إذا عندك NGINX قدّام موقعك على VPS أو جوّا كونتينر Docker، الخبر وصلك غالباً هيك: خمس ثغرات، وتلاتة منهن درجتهن 9.2. أغلب هالثغرات ما بتنفتح إلا مع إعداد معيّن، فقبل ما تقرر إذا الموضوع بيخصك، شغّل nginx -v وnginx -T وقارن النتيجة بالجدول تحت.

شو سكّرت NGINX 1.30.6 و1.31.7؟

NGINX 1.30.6 على خط الـ stable و1.31.7 على خط الـ mainline طلعوا بـ 14 أكتوبر 2026، وسكّروا خمس ثغرات: تلاتة بإدارة الذاكرة، ووحدة بالـ TLS، ووحدة بالـ HTTP/3. أي نسخة من 0.1.29 لحد 1.30.5 على الـ stable، أو لحد 1.31.6 على الـ mainline، بتوقع بمدى وحدة منهن على الأقل.

الإصدار مكتوب بـ أخبار nginx.org بنفس اليوم، ومعه njs 1.0.2 بإصلاحين لقراءة الـ XML. واليوم، 21 أكتوبر، طلعت 1.31.8 على الـ mainline، وسجل تغييراتها ما فيه إصلاحات أمنية جديدة. نشرة الأمان كاتبة «1.31.7+» تحت «Not vulnerable»، فـ 1.31.8 كمان مش متأثرة.

وإذا كنت مأجّل الترقية من الصيف، 1.30.6 بتسكّر كمان ثغرات أقدم. منها CVE-2026-42533، صنّفتها NGINX «major» وانسكّرت بـ 1.30.4 و1.31.3 بـ 15 يوليو 2026.

أي إعداد بيشغّل كل ثغرة؟

كل ثغرة من الخمسة بتنفتح مع تركيبة إعدادات محددة. بس CVE-2026-93479 إلها كمان طريق تاني ما شرحت F5 شروطه، فهي الوحيدة يلي الإعدادات لحالها ما بتبرّيك منها.

F5 هي الجهة يلي بتصدر أرقام الـ CVE لـ NGINX، ونشرت الشروط والحلول المؤقتة بـ 14 أكتوبر. مدى النسخ من نشرة أمان nginx.org:

الثغرة	الإعداد يلي بيشغّلها	النسخ المتأثرة	الحل المؤقت لحد ما ترقّي
<span dir="ltr">CVE-2026-15176</span>: <span dir="ltr">heap overflow</span>	`location` فيها `alias`، و`rewrite` بيغيّر الـ <span dir="ltr">URI</span>، وشي بيقرا `$request_filename` (`return` أو `set` أو `if` أو `add_header` أو `log_format`)	0.1.29 لـ 1.31.6	شيل `alias` من هالـ `location`، أو ما تستعمل `$request_filename`
<span dir="ltr">CVE-2026-93479</span>: <span dir="ltr">heap overflow</span>	`map` فيها <span dir="ltr">regex</span>، والـ `root` أو `log_format` بيقرا الـ <span dir="ltr">captures</span> تبعها قبل متغير ناتج الـ `map`	1.30.0 لـ 1.30.5، و1.31.2 لـ 1.31.6	<span dir="ltr">named captures</span> بدل المرقّمة، وبس جوّا البلوك يلي فيه الـ <span dir="ltr">regex</span>
<span dir="ltr">CVE-2026-97205</span>: <span dir="ltr">use-after-free</span>	`aio` مفعّل، وصفحات <span dir="ltr">SSI</span> فيها `include virtual`، ببعض الإعدادات	0.8.11 لـ 1.31.6	طفّي `aio`، أو وقّف تخديم صفحات <span dir="ltr">SSI</span>
<span dir="ltr">CVE-2026-97629</span>: تزوير جلسة <span dir="ltr">TLS</span>	`ssl_session_cache shared:…` بلا `ssl_session_ticket_key`	1.23.2 لـ 1.31.6	شيل سطر `ssl_session_cache shared:…` كله، أو حمّل مفاتيح ثابتة من ملف بـ `ssl_session_ticket_key`. ومع `ssl_session_tickets off` السيرفر مش متأثر
<span dir="ltr">CVE-2026-95101</span>: بايتات زيادة بالطلب للـ <span dir="ltr">backend</span>، وتجاوز `client_max_body_size`	<span dir="ltr">HTTP/3</span> مع <span dir="ltr">proxy</span> و`proxy_request_buffering on`، وهي القيمة الافتراضية	1.25.0 لـ 1.31.6	`proxy_request_buffering off`

الـ commit يلي سكّر ثغرة الـ alias فيه هالمثال، والطلب /foo/1 كان بيعمل buffer overflow:

location /foo/ {
    alias /bar/;
    rewrite ^/foo/.*$ /x;
    return 200 $request_filename;
}

الـ rewrite غيّر الـ URI لـ /x، وNGINX لسا ما اختار location جديدة. بهالفترة، تحويل الـ URI لمسار ملف ممكن يكتب برّا الذاكرة المحجوزة إذا بادئة الـ location (هون /foo/) أطول من الـ URI الجديد.

بثغرة الـ TLS، كل worker عنده تلات خانات لمفاتيح الـ session tickets، بس تدوير المفاتيح كان بينسخ خانتين، فالتالتة بتضل ذاكرة مش مهيّأة (الـ commit تبع الإصلاح). F5 بتقول إنو المهاجم ممكن يستعملها ليتجاوز التحقق من شهادة العميل، والتزوير بيصير بطريقة عشوائية ما بيتحكم فيها. فإذا سيرفرك بيطلب شهادة عميل بـ ssl_verify_client، رقّي هالسيرفر أول واحد.

ليش NGINX بتقول «medium» وF5 بتعطي 9.2؟

التقييمين من نظامين مختلفين. نشرة nginx.org بتعطي كل ثغرة كلمة، والخمسة «medium». وF5 بتحسب درجة CVSS: التلاتة يلي بالذاكرة أخدوا 9.2 على CVSS v4.0 و8.1 على v3.1.

الـ CVSS مقياس من 0 لـ 10 بيوصف الثغرة حسب طريقة الهجوم وأثره، والـ 9.0 وفوق اسمها Critical. مواصفة CVSS v4.0 بتقول إنو الدرجة الأساسية بتفترض أسوأ أثر معقول بين بيئات التشغيل المختلفة، مش بيئتك إنت، وفيها مقاييس بيئة (Environmental) لحتى كل حدا يعدّل الدرجة على وضعه.

حسب الـ vector تبع F5 للتلاتة، الهجوم من الشبكة، بلا تسجيل دخول ولا تفاعل من حدا، بس تعقيده عالي (AC:H). بالمواصفة، هالقيمة معناها إنو الهجوم بيحتاج يتجاوز حماية متل الـ ASLR. ووصف F5 إلهن بيقول إنو الـ worker ممكن يوقع أو يعيد تشغيله، وتنفيذ الكود ممكن إذا الـ ASLR مطفي أو المهاجم قدر يتجاوزه. ثغرة الـ TLS أخدت 8.3 وثغرة الـ HTTP/3 أخدت 6.9، الاتنين على v4.0.

نشرة nginx.org ما بتشرح كيف بتختار الكلمة، بس نفس الصفحة بتعطي «major» لثغرات تانية، متل CVE-2026-42533.

عملياً، نسختك والنمط بإعداداتك هني يلي بيحددوا وضعك. إذا النمط موجود والنسخة بالمدى، رقّي اليوم أو طبّق الحل المؤقت هلق. وإذا النمط مش موجود، رقّي بأقرب صيانة، لأنو الإعدادات بتتغيّر والـ grep ما بيلقط كل شي.

كيف بتفحص سيرفرك بـ nginx -v وnginx -T؟

الأمر nginx -v بيطبع النسخة، وnginx -T بيفحص الإعدادات وبيطبعها كلها مع كل ملف داخل بـ include، فبتفتّش عن الأنماط الخمسة بملف واحد.

شغّل nginx -v. إذا طلع 1.30.6 أو أحدث على الـ stable، أو 1.31.7 أو أحدث على الـ mainline، الخمسة متسكّرين عندك. إذا النسخة من حزمة توزيعتك، الرقم لحاله ما بيكفي، والسبب بقسم الترقية تحت.
اطبع الإعدادات كلها لملف بـ sudo nginx -T > ~/nginx-full.conf. بـ Docker: docker exec <container> nginx -T > ~/nginx-full.conf، أو docker compose exec <service> nginx -T > ~/nginx-full.conf. حسب توثيق أوامر NGINX، الـ -T بيعمل متل -t وبيطبع ملفات الإعدادات كمان.
شغّل الأوامر تحت على الملف، وكل سطر بيطلع اقراه ضمن الـ server أو الـ location يلي هو فيها.

# CVE-2026-15176
grep -nwE 'alias|rewrite' ~/nginx-full.conf
grep -n 'request_filename' ~/nginx-full.conf

# CVE-2026-93479
grep -nw 'map' ~/nginx-full.conf
grep -nE '\$[1-9]' ~/nginx-full.conf

# CVE-2026-97205
grep -nwE 'aio|ssi' ~/nginx-full.conf

# CVE-2026-97629
grep -nE 'ssl_session_(cache|ticket_key|tickets)' ~/nginx-full.conf

# CVE-2026-95101
grep -nE 'quic|proxy_pass|proxy_request_buffering' ~/nginx-full.conf

# njs
grep -nE 'js_(import|content|set)' ~/nginx-full.conf

كيف تقرا النتيجة

إذا alias وrewrite بنفس الـ location، ومعهن $request_filename بنفس الـ location أو بـ log_format، هاد نمط CVE-2026-15176.
الـ $1 لحالها عادية، لأنها بتطلع بكتير أسطر rewrite. يلي بيهمك $1 جوّا root أو log_format بإعدادات فيها map بـ ~. حسب الـ commit تبع إصلاحها، أثر مسار الـ log محدود ببايت فاضي واحد بينكتب برّا الحد، والمسار الأخطر هو حساب الـ root من متغيرات. وإذا ما لقيت شي، الطريق التاني يلي ما انشرح بيضل، فالـ grep هون ما بيبرّيك.
aio on أو aio threads مع ssi on شغّالين على نفس الـ location، حتى لو واحد منهن مكتوب بالـ http أو الـ server والـ location ورثته: دوّر بالصفحات يلي بتمرق منها عن include virtual.
ssl_session_cache shared: بلا ssl_session_ticket_key وبلا ssl_session_tickets off هو نمط CVE-2026-97629. إذا شهادتك من Let's Encrypt عن طريق certbot، الملف options-ssl-nginx.conf بنسخته الحالية بمستودع certbot فيه ssl_session_cache shared:le_nginx_SSL:10m ومعه ssl_session_tickets off. تأكد إنو السطر التاني طالع عندك.
quic بسطر listen، ومعه proxy_pass بنفس الـ server، وما في proxy_request_buffering off: هاد نمط CVE-2026-95101. موديول الـ HTTP/3 ما بينبنى افتراضياً لما تبني من المصدر، وnginx -V بيقلك إذا نسختك فيها --with-http_v3_module.
إذا طلع js_import أو js_content أو js_set، إنت بتستعمل njs، وإلها تحديث لحالها هو njs 1.0.2.

إذا عندك كذا سيرفر وإعداداتهن بمستودع git، فيك تعطي نفس الأوامر لوكيل برمجة متل Claude Code يمرق عليهن ويجمعلك النتيجة بجدول. وقسم مهارات AI بالمتجر فيه مهارات لـ Claude Code ووكلاء البرمجة.

كيف بترقّي حسب طريقة التثبيت؟

الترقية لـ 1.30.6 أو 1.31.7 أو أحدث بتسكّر الخمسة كلهن، والطريق بيختلف حسب من وين جاي NGINX عندك: مستودع nginx.org، أو حزمة التوزيعة، أو صورة Docker.

من مستودع nginx.org

إذا ركّبت من مستودعات nginx.org، الترقية حزمة عادية. المستودع فيه حزم لـ Debian 12 و13 وUbuntu 22.04 و24.04 و26.04 وRHEL 8 لـ 10 وغيرهن، والـ mainline إلو مسار mainline/ بالرابط. على Debian وUbuntu:

sudo apt update && sudo apt install --only-upgrade nginx
nginx -v
sudo systemctl restart nginx

بعد الترقية اعمل restart مش reload. حسب توثيق التحكم بـ NGINX، الـ reload بيقرا الإعدادات من جديد وبيشغّل workers جداد بنفس الملف التنفيذي، والملف الجديد بيحتاج إشارة USR2 أو تشغيل من جديد.

من حزمة التوزيعة

Debian بينقل الإصلاح للنسخة يلي عنده بدل ما يرفع الرقم، ومتتبّعه معلّم الخمسة «fixed» بـ forky بالنسخة 1.30.4-8، وهي أقل من 1.30.6. لهيك رقم nginx -v من حزمة توزيعة ما بينقارن بجدول nginx.org، والمرجع متتبّع الأمان تبع توزيعتك.

وبالعكس، حزمة رقمها برّا المدى ممكن تكون متأثرة. حسب تحديث الأمان DSA-6575-1 يلي نشره Debian بـ 21 أكتوبر 2026، الكود المتأثر بـ CVE-2026-93479 دخل حزمة trixie (Debian 13) لما نقلوا إصلاح أمني أقدم، مع إنو مداها بنشرة nginx.org بيبلّش من 1.30.0. ونفس التحديث بيسكّر الخمسة بـ trixie بالنسخة 1.26.3-3+deb13u10، فعلى Debian 13، apt upgrade من مستودع الأمان بيجيبلك الإصلاح.

على bookworm (Debian 12، النسخة 1.22.1)، متتبّع Debian لسا كاتب «vulnerable» للخمسة لحد 21 أكتوبر. حسب نشرة nginx.org، 1.22.1 برّا مدى تلاتة منهن (CVE-2026-93479 وCVE-2026-95101 وCVE-2026-97629)، بس بعد يلي صار بـ trixie، اعتمد على المتتبّع. ومتتبّع Ubuntu كاتب «Needs evaluation» للخمسة على كل نسخه. على هالنسخ، apt upgrade لحاله ما رح يجيبلك الإصلاح هلق، وعندك خيارين: تنقل لمستودع nginx.org، أو تطبّق الحل المؤقت من الجدول لكل نمط لقيته وتراقب المتتبّع.

بـ Docker

الصور الرسمية على Docker Hub صار فيها الإصلاح. لحد 21 أكتوبر 2026، الوسمين nginx:stable وnginx:1.30 عندهم نفس الـ digest تبع nginx:1.30.6، والوسوم nginx:mainline وnginx:latest وnginx:1.31 نفس nginx:1.31.7، ونسخ الـ alpine كمان. بس الصورة يلي بنيتها قبل هيك بتضل على النسخة القديمة لحد ما تبنيها من جديد:

# image: nginx:... used directly
docker compose pull
docker compose up -d

# Dockerfile with FROM nginx:...
docker compose build --pull
docker compose up -d

docker compose exec <service> nginx -v

انتبه للوسوم المثبّتة على خط قديم. الوسم nginx:1.28 آخر مرة انرفع بـ 7 أبريل 2026، قبل أسبوع من 1.30.0 (14 أبريل)، ونسخة 1.28 بتوقع بمدى أربعة من الخمسة. هون إعادة البناء ما بتجيب شي جديد: غيّر الوسم لـ nginx:1.30 أو أحدث.

إذا بتستعمل njs

الـ njs هو موديول JavaScript تبع NGINX، بيشتغل بـ js_import وjs_content. njs 1.0.2 طلعت بـ 14 أكتوبر وسكّرت ثغرتين بقراءة الـ XML، والنسخ المتأثرة 0.7.10 لـ 1.0.1 حسب نشرة أمان njs:

CVE-2026-101025: كل مرة بيفشل فيها xml.parse() مع XML مكسور، بتضل ذاكرة محجوزة بالـ worker، فالذاكرة بتكبر بلا حد. بتصيب المحرك المدمج بس، والحل المؤقت حسب F5 هو js_engine qjs.
CVE-2026-101019: بالـ XML الموقّع، قيمة attribute ممكن تطلع غايبة أو مقطوعة والتوقيع بيضل صحيح. بتصيب المحركين، njs وQuickJS، فـ js_engine qjs ما بيحلها، والحل هو njs 1.0.2. F5 بتقول إنو nginx-saml مع المحرك المدمج متأثر أكيد.

شو لسا مش معروف عن ثغرات NGINX هدول؟

لحد 21 أكتوبر 2026 ما في استغلال منشور لأي وحدة من ثغرات NGINX الخمسة. والمعلومات الناقصة لحد اليوم هي الشروط الكاملة لتنتين منهن، ومدى النسخ القديمة بسجلات F5، وموعد الإصلاح على Ubuntu وDebian 12.

سجل CVE-2026-93479 بيقول إنو نفس الـ overflow ممكن يصير كمان من متغير ما بتنحفظ قيمته (بلغة NGINX: non-cacheable) جوّا تعبير نصي، «under certain conditions»، والسجل ما بيسمّي هالشروط. حسب دليل مطوّري NGINX، هيك متغير بتنحسب قيمته من جديد كل مرة بينقرا، متل $time_local. وسجل CVE-2026-97205 بيقول إنو الـ aio بيفتحها «in certain configurations» بس، وما بيعدّد هالإعدادات. يعني إذا الـ grep لقى aio وssi سوا، سيرفرك ممكن يكون متأثر والسجل ما بيحسمها؛ وإذا ما لقى نمط CVE-2026-93479، هاد ما بيبرّيك منها. بالحالتين، الترقية بتسكّر الثغرة.

سجلات F5 للخمسة فيها ملاحظة إنها ما بتقيّم النسخ يلي خلص دعمها التقني (End of Technical Support). وبعض المدى فيها أضيق من نشرة nginx.org: سجل CVE-2026-97205 بيبلّش من 1.30.0 والنشرة من 0.8.11، وسجل CVE-2026-97629 من 1.23.3 والنشرة من 1.23.2. إذا أداة فحص أو موقع ثغرات قلّك إنو نسخة قديمة برّا المدى، قارنها بنشرة nginx.org، لأنها نشرة المشروع نفسه للنسخة المفتوحة المصدر.

على Ubuntu، صفحة كل ثغرة من الخمسة كاتبة «Needs evaluation» على كل النسخ، وآخر تحديث إلها بالمتتبّع كان بـ 15 أكتوبر. حسب صفحة شرح الحالات عند Ubuntu، هالحالة معناها إنو لسا ما معروف إذا الحزمة متأثرة على هالنسخة أو لأ.

من وين تبلّش هلق؟

بلّش بـ nginx -v على كل سيرفر وكل كونتينر عندك، لأنو النسخة، إذا جاية من nginx.org أو Docker، بتحسم إذا الخمسة متسكّرين قبل أي grep؛ ومن حزمة توزيعة، المرجع متتبّع توزيعتك.

سجّل النسخة لكل سيرفر وكونتينر، ومن وين جاي: nginx.org أو التوزيعة أو Docker.
شغّل nginx -T والأوامر فوق، وعلّم كل نمط من الجدول لقيته.
رقّي لـ 1.30.6 أو 1.31.7 أو أحدث، أو لحزمة التوزيعة يلي متتبّعها كاتب «fixed». إذا الترقية مش ممكنة اليوم، طبّق الحل المؤقت للنمط يلي لقيته، وبعدها sudo nginx -t && sudo systemctl reload nginx.
ابني صورك من جديد بـ --pull، وتأكد بـ nginx -v جوّا الكونتينر الشغّال.

الإعدادات طبقة وحدة من السيرفر. كود التطبيق ورا NGINX إلو ثغراته بالصلاحيات وIDOR، وحزمة المهارات الأمنية بتراجع هالكود قبل النشر، وهي لسا قيد التحضير.

وإذا منصتك فيها دفع أو بيانات مستخدمين، وبدك حدا يفحص الإعدادات والتطبيق متل ما بيجرّبهم مهاجم ويسلّمك خطة إصلاح، هاد شغل مُحَصَّن. شو طلع معك بالـ grep: أي نمط من الخمسة موجود بإعداداتك؟

أسئلة شائعة

هل في هجمات معروفة على ثغرات NGINX هدول؟

لحد 21 أكتوبر 2026 ما في شي منشور. كتالوج CISA للثغرات المستغلة (KEV) ما فيه ولا وحدة من الخمسة، وتقييم CISA بسجلاتهن بـ 15 أكتوبر كاتب إنو ما في استغلال معروف. وحسب The Hacker News، لا NGINX ولا F5 بلّغوا عن هجمات.

ركّبت NGINX من مستودع Ubuntu أو Debian، بيكفيني apt upgrade؟

إي، إذا عندك Debian 13 (trixie): تحديث Debian الأمني DSA-6575-1 بـ 21 أكتوبر 2026 بيجيب النسخة 1.26.3-3+deb13u10، وفيها إصلاح الخمسة. على Debian 12 (bookworm) وUbuntu لسا لأ: متتبّع Debian كاتب vulnerable على bookworm، ومتتبّع Ubuntu كاتب Needs evaluation للخمسة على كل النسخ. لحد ما يوصل الإصلاح، انقل لمستودع nginx.org أو طبّق الحل المؤقت لكل نمط لقيته بإعداداتك.

صورتي مبنية على nginx:1.28، بيكفي أبنيها من جديد؟

لأ. وسم nginx:1.28 على Docker Hub آخر مرة انرفع بـ 7 أبريل 2026، ونسخة 1.28 بتوقع بمدى أربعة من الخمسة حسب نشرة nginx.org. غيّر الوسم لـ nginx:1.30 أو nginx:stable، وبعدها ابني الصورة.

كيف بعرف إذا NGINX عندي شغّال بـ HTTP/3؟

دوّر على سطر listen فيه quic بإعداداتك، والأمر nginx -V بيقلك إذا نسختك مبنية مع --with-http_v3_module. الموديول ما بينبنى افتراضياً لما تبني NGINX من المصدر، وإذا ما في quic بأي listen، الثغرة CVE-2026-95101 ما بتلمسك.

بعد ما رقّيت، بيكفي nginx -s reload؟

لأ. الـ reload بيقرا الإعدادات من جديد بس بنفس الملف التنفيذي، فالنسخة القديمة بتضل شغّالة. اعمل restart للخدمة، مثلاً systemctl restart nginx، أو بدّل الملف التنفيذي بإشارة USR2 متل ما بيشرح توثيق NGINX.

ثغرات NGINX لأكتوبر 2026: كيف بتعرف من nginx.conf إذا سيرفرك متأثر؟

شو سكّرت <span dir="ltr">NGINX 1.30.6</span> و<span dir="ltr">1.31.7</span>؟

أي إعداد بيشغّل كل ثغرة؟

ليش <span dir="ltr">NGINX</span> بتقول «<span dir="ltr">medium</span>» و<span dir="ltr">F5</span> بتعطي 9.2؟

كيف بتفحص سيرفرك بـ <span dir="ltr">nginx -v</span> و<span dir="ltr">nginx -T</span>؟

كيف تقرا النتيجة

كيف بترقّي حسب طريقة التثبيت؟

من مستودع <span dir="ltr">nginx.org</span>

من حزمة التوزيعة

بـ <span dir="ltr">Docker</span>

إذا بتستعمل <span dir="ltr">njs</span>

شو لسا مش معروف عن ثغرات <span dir="ltr">NGINX</span> هدول؟

من وين تبلّش هلق؟

أسئلة شائعة

نزّلت LiteLLM 1.107.0 أو سحبت صورة latest؟ شو لازم تعمل هلق

PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك

تحديثات أمان Node.js لأكتوبر 2026: شو بتسكّر، وأي نسخة بعد 28 أكتوبر

شو سكّرت <span dir="ltr">NGINX 1.30.6</span> و<span dir="ltr">1.31.7</span>؟

أي إعداد بيشغّل كل ثغرة؟

ليش <span dir="ltr">NGINX</span> بتقول «<span dir="ltr">medium</span>» و<span dir="ltr">F5</span> بتعطي 9.2؟

كيف بتفحص سيرفرك بـ <span dir="ltr">nginx -v</span> و<span dir="ltr">nginx -T</span>؟

كيف تقرا النتيجة

كيف بترقّي حسب طريقة التثبيت؟

من مستودع <span dir="ltr">nginx.org</span>

من حزمة التوزيعة

بـ <span dir="ltr">Docker</span>

إذا بتستعمل <span dir="ltr">njs</span>

شو لسا مش معروف عن ثغرات <span dir="ltr">NGINX</span> هدول؟

من وين تبلّش هلق؟

أسئلة شائعة

مقالات أخرى

نزّلت LiteLLM 1.107.0 أو سحبت صورة latest؟ شو لازم تعمل هلق

PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك

تحديثات أمان Node.js لأكتوبر 2026: شو بتسكّر، وأي نسخة بعد 28 أكتوبر