NGINX ਕਮਜ਼ੋਰੀਆਂ: ਕਾਰਨ, ਫਿਕਸ ਅਤੇ ਉਤਪਾਦਨ ਤਸਦੀਕ

ਇਤਿਹਾਸਕ ਲੇਖ ਦੀ ਮਿਤੀ: 2026-10-14 (ਖੁਲਾਸਾ ਅਤੇ ਸੁਰੱਖਿਆ ਰਿਲੀਜ਼ ਮਿਤੀ)। 2026-10-27 ਦੁਆਰਾ ਜਾਂਚੇ ਗਏ ਸਰੋਤ ਅਤੇ ਜਾਣਕਾਰੀ ਪੂਰਕ।

ਇਹ ਲੇਖ ਘਟਨਾ ਦੀ ਮਿਤੀ ਦੁਆਰਾ ਪੁਰਾਲੇਖ ਹੈ; 14 ਅਕਤੂਬਰ ਤੋਂ ਬਾਅਦ ਜਾਰੀ ਕੀਤੇ ਸੰਸਕਰਣ ਅਤੇ ਰੀਲੀਜ਼ ਅੱਪਡੇਟ ਹੇਠਾਂ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ। ਦਰਸ਼ਕ: NGINX Open Source / NGINX Plus ਵੈਬਸਾਈਟ ਅਤੇ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਸੰਚਾਲਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਮਚਾਰੀ, ਸੁਰੱਖਿਆ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਮਚਾਰੀ, ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਮੇਨਟੇਨਰ, ਅਤੇ ਨਾਲ ਹੀ ਇੰਜਨੀਅਰ ਜੋ NGINX ਸਵੈ-ਕੰਪਾਈਲ ਕਰਦੇ ਹਨ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਮੋਡੀਊਲ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹਨ।

ਇਹ ਲੇਖ ਪੰਜ NGINX ਕੋਰ ਕਮਜ਼ੋਰੀਆਂ ‘ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦਾ ਹੈ ਜੋ 14 ਅਕਤੂਬਰ, 2026 ਨੂੰ ਪ੍ਰਗਟ ਕੀਤੇ ਗਏ ਸਨ ਅਤੇ ਤੀਬਰਤਾ ਨਾਲ ਹੱਲ ਕੀਤੇ ਗਏ ਸਨ, ਅਤੇ ਮਈ ਤੋਂ ਸਤੰਬਰ 2026 ਤੱਕ ਪ੍ਰਤੀਨਿਧ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਅਤੇ ਬੇਨਤੀ ਦੀ ਇਕਸਾਰਤਾ ਕਮਜ਼ੋਰੀਆਂ ‘ਤੇ ਵੀ ਨਜ਼ਰ ਮਾਰਦਾ ਹੈ। ਸਮੱਗਰੀ ਟਰਿੱਗਰ ਸਥਿਤੀਆਂ, ਕੋਡ-ਪੱਧਰ ਦੇ ਪ੍ਰਭਾਵ, ਸ਼ੌਰਟ-ਮੀਡੀਆ ਪ੍ਰਭਾਵ ਦੇ ਕਾਰਨਾਂ, ਕੋਡ-ਪੱਧਰ ‘ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਕਾਰਨਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ। ਉਪਾਅ, ਅਧਿਕਾਰਤ ਪੈਚ ਲਾਗੂ ਕਰਨਾ, ਪੁਰਾਣੀਆਂ ਸ਼ਾਖਾਵਾਂ ਲਈ ਬੈਕਪੋਰਟ ਅਤੇ ਉਤਪਾਦਨ ਦੀ ਤਸਦੀਕ। ਹਵਾਲੇ ਜਿਵੇਂ ਕਿ S1 ਸਰੋਤ ਅੰਤਿਕਾ ਨਾਲ ਲਿੰਕ। ਉਦਾਹਰਨ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਸਿਰਫ਼ ਤੈਨਾਤੀ ਅਤੇ ਆਡਿਟਿੰਗ ਵਿਚਾਰਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਸੰਸਕਰਣ, ਸੰਰਚਨਾ ਵਿਰਾਸਤ, ਨਿਰਭਰਤਾ, ਅਤੇ ਵਪਾਰਕ ਸਮਰੱਥਾ ਦੇ ਆਧਾਰ ‘ਤੇ ਤਸਦੀਕ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

TL; DR: ਤਰਜੀਹੀ ਕਾਰਵਾਈਆਂ

1. ਸੁਰੱਖਿਆ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਲਈ nginx.org ਓਪਨ ਸੋਰਸ ਪੈਕੇਜ, ਅੱਪਡੇਟ ਕਰੋ Stable 1.30 ਘੱਟੋ-ਘੱਟ ਤੱਕ ਸ਼ਾਖਾ 1.30.6 ਅਤੇ Mainline 1.31 ਘੱਟੋ-ਘੱਟ ਤੱਕ ਸ਼ਾਖਾ 1.31.7. ਤਸਦੀਕ ਦੀ ਮਿਤੀ ‘ਤੇ, 1.31.8 ਨਵੀਨਤਮ ਹੈ Mainline ਰਿਲੀਜ਼ ਇਹ ਵੱਖਰੀਆਂ ਬ੍ਰਾਂਚ ਬੇਸਲਾਈਨ ਹਨ; ਬ੍ਰਾਂਚਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਸੰਖਿਆ ਦੀ ਤੁਲਨਾ ਨਾ ਕਰੋ। S1 S2
2. ਪੂਰੇ ਪੈਕੇਜ ਸੰਸਕਰਣ ਦੁਆਰਾ ਵੰਡ ਸਥਾਪਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। Ubuntu 22.04 / 24.04 / 26.04 / 26.10 ਕੋਲ ਵਿਕਰੇਤਾ ਬੈਕਪੋਰਟ ਹਨ; Debian 13 (trixie) ਲਈ ਘੱਟੋ-ਘੱਟ 1.26.3-3+deb13u10 ਦੀ ਲੋੜ ਹੈ। ਪੁਸ਼ਟੀਕਰਨ ‘ਤੇ, Debian 12 (bookworm) ਪੈਕੇਜ 1.22.1-9+deb12u10 ਅਜੇ ਵੀ ਪ੍ਰਭਾਵਿਤ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਹਰੇਕ CVE ਦੀ ਜਾਂਚ ਕਰੋ; Debian 13 ਸਲਾਹਕਾਰ ਇਹ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ Debian 12 ਸਥਿਰ ਹੈ। S13S14S15
3. ਪੰਜ ਸੰਰਚਨਾ ਸੰਜੋਗਾਂ ਦਾ ਆਡਿਟ ਕਰੋ: alias + rewrite + $request_filename , map + regex + ਵੇਰੀਏਬਲ ਮੁਲਾਂਕਣ, aio + ssi + include virtual , HTTP/3 ਨਾਲ proxy_request_buffering on , ਅਤੇ ssl_session_cache shared:... ਆਟੋਮੈਟਿਕ ਨਾਲ TLS ਸੈਸ਼ਨ ਟਿਕਟ ਕੁੰਜੀ ਰੋਟੇਸ਼ਨ। ਇਕੱਲੇ ਨਿਰਦੇਸ਼ ਦੀ ਮੌਜੂਦਗੀ ਸ਼ੋਸ਼ਣ ਦੀ ਸਥਾਪਨਾ ਨਹੀਂ ਕਰਦੀ; ਬੇਨਤੀ ਮਾਰਗ ਅਤੇ ਸੰਰਚਨਾ ਦਾਇਰੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। S1 S3 S4
4. ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਬਦਲੋ. nginx -t ਚਲਾਓ, ਫਿਰ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ ਜਾਂ ਉੱਚ-ਉਪਲਬਧਤਾ ਰੋਲਿੰਗ ਤੈਨਾਤੀ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੁਰਾਣੀ master/worker ਪ੍ਰਕਿਰਿਆਵਾਂ ਬੰਦ ਹੋ ਗਈਆਂ ਹਨ; nginx -s reload ਇਕੱਲਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਚੱਲ ਰਹੀ ਬਾਈਨਰੀ ਬਦਲ ਗਈ ਹੈ।
5. ਅਸਲ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: HTTP/1.1 , HTTP/2 , HTTP/3 ਜੇਕਰ ਸਮਰੱਥ ਹੈ, ਪ੍ਰੌਕਸੀਡ ਅੱਪਲੋਡ ਅਤੇ API ਬੇਨਤੀ ਸੰਸਥਾਵਾਂ, mTLS ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ, SSI ਪੰਨੇ ਅਤੇ ਪਹੁੰਚ ਲੌਗ। ਹਰੇਕ ਅੰਤਮ ਬਿੰਦੂ ਲਈ ਪੈਕੇਜ ਪ੍ਰੋਵੇਨੈਂਸ, ਸੰਸਕਰਣ, ਚਿੱਤਰ ਡਾਇਜੈਸਟ, ਚੱਲ ਰਹੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਨਤੀਜੇ ਰਿਕਾਰਡ ਕਰੋ।
6. ਜੇਕਰ ਤੁਰੰਤ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਅਸੰਭਵ ਹੈ, ਤਾਂ ਲਾਗੂ ਟਰਿੱਗਰ ਸ਼ਰਤਾਂ ਨੂੰ ਹਟਾਓ: ਬੇਲੋੜੀ ਨੂੰ ਅਸਮਰੱਥ ਕਰੋ SSI / AIO ਜਾਂ HTTP/3 , ਕਮਜ਼ੋਰ ਸਮੀਖਿਆ alias / rewrite / map ਵੇਰੀਏਬਲ ਹਵਾਲੇ, ਅਤੇ ਅਸਥਾਈ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ ssl_session_tickets off; ਪ੍ਰਭਾਵਿਤ ਲਈ mTLS ਸੇਵਾਵਾਂ। WAF , ASLR , ਦਰ ਸੀਮਾਵਾਂ ਅਤੇ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਸਿਰਫ਼ ਕੁਝ ਸ਼ਰਤਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਅਧਿਕਾਰਤ ਪੈਚਾਂ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦੀਆਂ। S3 S4 S8 S12

1. ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਅਤੇ ਜੋਖਮ ਨਿਰਣਾ

NGINX ਨੇ 14 ਅਕਤੂਬਰ, 2026 ਨੂੰ 1.30.6 (Stable) ਅਤੇ 1.31.7 (Mainline) ਨੂੰ ਪੰਜ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹੋਏ ਜਾਰੀ ਕੀਤਾ। ਤਿੰਨ ਵਿੱਚ ਹੀਪ ਓਵਰਫਲੋ ਜਾਂ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ-ਮੁਕਤ ਅਤੇ F5 CVSS v4.0 ਦੇ 9.2 / ਕ੍ਰਿਟੀਕਲ ਸਕੋਰ ਸ਼ਾਮਲ ਹਨ। ਹੋਰ ਦੋ HTTP/3 ਬੇਨਤੀ ਦੀ ਇਕਸਾਰਤਾ ਅਤੇ TLS ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। S1S2S3

ਰੇਟਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਵੱਖਰਾ ਕਰੋ: nginx.org ਸਾਰੇ ਪੰਜ ਮੁੱਦਿਆਂ ਨੂੰ medium ਵਜੋਂ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ F5 CVSS v4.0 ਅਤੇ ਕੁਝ ਰਾਸ਼ਟਰੀ ਸੁਰੱਖਿਆ ਏਜੰਸੀਆਂ ਤਿੰਨ ਮੈਮੋਰੀ ਮੁੱਦਿਆਂ ਨੂੰ ਨਾਜ਼ੁਕ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਸਾਰੇ ਪੰਜ ਬਿਨਾਂ ਸ਼ਰਤ ਰਿਮੋਟ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਸੰਰਚਨਾ, ਟ੍ਰੈਫਿਕ ਪਹੁੰਚਯੋਗਤਾ ਅਤੇ ਹਮਲਾਵਰ ਦੇ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਸਥਿਤੀਆਂ। ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਅਤੇ ਭਰੋਸੇਯੋਗ RCE ਸਬੂਤ ਦੇ ਵੱਖ-ਵੱਖ ਪੱਧਰ ਹਨ। S1S3S4

ਸੀ.ਵੀ.ਈ	ਤਕਨੀਕੀ ਮੁੱਦੇ ਅਤੇ ਖਾਸ ਟਰਿੱਗਰ ਹਾਲਾਤ	ਕੋਰ ਪ੍ਰਭਾਵ	ਮੁਲਾਂਕਣ ਅਤੇ ਨਿਪਟਾਰੇ
CVE-2026-15176	alias ਮਾਰਗ ਮੈਪਿੰਗ + rewrite ਤਬਦੀਲੀ URI + ਮੁਲਾਂਕਣ $request_filename	ਹੀਪ ਬਫਰ ਓਵਰਫਲੋ, Worker ਕਰੈਸ਼; ਸੰਭਾਵੀ RCE ਕੁਝ ਸ਼ਰਤਾਂ ਅਧੀਨ	F5 CVSS v4.0 9.2; ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਨੂੰ ਤਰਜੀਹ ਦਿਓ
CVE-2026-93479	HTTP/Stream ਸਕ੍ਰਿਪਟ ਮੁਲਾਂਕਣ, ਖਾਸ ਤੌਰ ‘ਤੇ map regex ਕੈਪਚਰ ਅਤੇ root ਡਾਇਰੈਕਟਰੀ, ਲੌਗ ਵੇਰੀਏਬਲ ਕਰਾਸ-ਰੈਫਰੈਂਸ	ਰਾਖਵੇਂ ਬਫਰ ਨੂੰ ਓਵਰਰਾਈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੀਪ ਓਵਰਫਲੋ ਹੁੰਦਾ ਹੈ; ਸੰਭਾਵੀ RCE ਕੁਝ ਸ਼ਰਤਾਂ ਅਧੀਨ	F5 CVSS v4.0 9.2; ਪਿਛਲੀ ਮੁਰੰਮਤ ਤੋਂ ਬਾਅਦ ਰਿਗਰੈਸ਼ਨ ਜੋਖਮ ਹੈ
CVE-2026-97205	SSI ਵਰਚੁਅਲ ਸ਼ਾਮਲ ਹਨ ਅਤੇ AIO/ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ; ਬਕਾਇਆ ਕਾਰਵਾਈ ਗਿਣਤੀ ਓਵਰਫਲੋ	ਵਰਤੋਂ-ਬਾਅਦ-ਮੁਫ਼ਤ, Worker ਕਰੈਸ਼, ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ; ਸੰਭਾਵੀ RCE	F5 CVSS v4.0 9.2; ਗੈਰ-ਡਿਫਾਲਟ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੈ
CVE-2026-95101	HTTP/3 ਅਗਿਆਤ ਫ੍ਰੇਮ ਬਫਰਾਂ ਵਿੱਚ ਖੰਡਿਤ ਹੈ, ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਬਾਡੀ ਬਫਰਿੰਗ ਸਮਰਥਿਤ ਹੈ	ਅਪਸਟ੍ਰੀਮ ਬੇਨਤੀ ਬਾਡੀ ਵਿੱਚ ਗੈਰ-DATA ਬਾਈਟਾਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਇੰਜੈਕਟ ਕਰਨਾ, ਸੰਭਵ ਤੌਰ ‘ਤੇ ਬੇਨਤੀ ਬਾਡੀ ਆਕਾਰ ਸੀਮਾ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ	ਇਹ ਕਮਜ਼ੋਰੀ ਬੇਨਤੀ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਇਹ ਖੁਦ ਰਿਮੋਟ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (RCE) ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ।
CVE-2026-97629	ਸ਼ੇਅਰਡ TLS ਸੈਸ਼ਨ ਕੈਸ਼, ਆਟੋਮੈਟਿਕ ਕੁੰਜੀ ਰੋਟੇਸ਼ਨ ਅਤੇ Worker ਕੁੰਜੀ ਮਿਰਰਿੰਗ	ਸੈਸ਼ਨ ਟਿਕਟ ਜਾਅਲੀ; ਪ੍ਰਭਾਵਿਤ mTLS ਸੇਵਾ ਲਈ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣੀਕਰਨ ਬਾਈਪਾਸ ਹੋ ਸਕਦਾ ਹੈ	ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣੀਕਰਨ ਕਿਸਮ API ਦੇ ਕਾਰੋਬਾਰੀ ਪ੍ਰਭਾਵ ਵੱਲ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ

ਉਪਰੋਕਤ CVSS ਸਕੋਰ F5 ਦੁਆਰਾ v4.0 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਿੱਤਾ ਗਿਆ ਹੈ; ਉਹੀ ਕਮਜ਼ੋਰੀ CVSS 3.1, nginx.org ਆਪਣੇ ਗ੍ਰੇਡਾਂ ਅਤੇ ਵੰਡ ਤੀਬਰਤਾ ਰੇਟਿੰਗਾਂ ਵਿੱਚ ਵੱਖਰੀ ਗੰਭੀਰਤਾ ਦਿਖਾ ਸਕਦੀ ਹੈ। S1S3S4

1.1 ਇਕੱਲੇ CVE ਸਕੋਰਾਂ ਦੀ ਬਜਾਏ ਤੈਨਾਤੀ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਤਰਜੀਹ ਦਿਓ

ਤੈਨਾਤੀ ਫਾਰਮ	ਜਾਂਚ ਦੇ ਮੁੱਖ ਨੁਕਤੇ	ਨਿਪਟਾਰੇ ਲਈ ਤਰਜੀਹੀ ਸਿਫ਼ਾਰਸ਼ਾਂ
ਜਨਤਕ ਨੈੱਟਵਰਕ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ, ਕਸਟਮਾਈਜ਼ਡ rewrite, alias, ਅਤੇ ਕੰਪਲੈਕਸ map ਸਮੇਤ	CVE-2026-15176, CVE-2026-93479 ਅਤੇ ਮਈ ਤੋਂ ਜੁਲਾਈ ਤੱਕ ਮੁੜ ਲਿਖਣ/ਨਕਸ਼ੇ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ	P0: ਆਡਿਟ ਅਤੇ ਤੁਰੰਤ ਅਪਡੇਟ ਕਰੋ
API / ਸਿਰਫ਼ ਜਾਂ ਮੁੱਖ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਪ੍ਰਮਾਣਿਕਤਾ ਵਜੋਂ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪ੍ਰਬੰਧਨ ਜਹਾਜ਼	ਸੈਸ਼ਨ ਟਿਕਟ ਅਤੇ CVE-2026-97629 ਦੀ ਸਾਂਝੀ ਕੈਸ਼ ਕੌਂਫਿਗਰੇਸ਼ਨ	P0: ਪ੍ਰਮਾਣਿਕਤਾ ਸੀਮਾ ਅਤੇ ਅੱਪਡੇਟ ਦੀ ਤੁਰੰਤ ਪੁਸ਼ਟੀ ਕਰੋ
ਬਾਹਰੀ HTTP/3 ਅੱਪਲੋਡ, ਸਥਿਤੀ ਤਬਦੀਲੀ ਇੰਟਰਫੇਸ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕਲਾਸ API ਪ੍ਰਦਾਨ ਕਰੋ	CVE-2026-95101, ਖਾਸ ਕਰਕੇ ਬੇਨਤੀ ਬਾਡੀ ਬੈਕਐਂਡ ਨਾਲ ਪ੍ਰੌਕਸੀਡ ਹੈ	P0/P1: ਕਾਰੋਬਾਰੀ ਮਹੱਤਤਾ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰਬੰਧ ਕਰੋ
SSI ਡਾਇਨਾਮਿਕ ਪੇਜ ਜਾਂ ਅਸਿੰਕ੍ਰੋਨਸ ਫਾਈਲ I/O	CVE-2026-97205	P1: ਸੁਮੇਲ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਮੁਰੰਮਤ ਕਰੋ
ਸਿਰਫ਼ ਸਥਿਰ ਪੰਨੇ + ਸਧਾਰਨ HTTP/1.1/2 ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ	ਸੰਰਚਨਾ ਅਤੇ ਸੰਸਕਰਣ ਨੂੰ ਅਜੇ ਵੀ ਆਡਿਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਕੁਝ CVE ਸ਼ਰਤਾਂ ਗੁੰਮ ਹੋ ਸਕਦੀਆਂ ਹਨ	P1: ਸੰਕਟਕਾਲੀਨ ਸੁਰੱਖਿਆ ਅੱਪਗਰੇਡ ਵਿੰਡੋ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ
ਸੇਵਾਮੁਕਤ Kubernetes ਕਮਿਊਨਿਟੀ ingress-nginx ਦੀ ਵਰਤੋਂ ਕਰੋ	ਪ੍ਰੋਜੈਕਟ ਸੁਰੱਖਿਆ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਜੋਖਮ ਇਹਨਾਂ ਪੰਜ CVE ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹਨ	ਇੱਕ ਵਿਅਕਤੀਗਤ ਕੰਟਰੋਲਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਬਣਾਓ

P0/P1 ਜਨਤਕ ਨੈੱਟਵਰਕ ਐਕਸਪੋਜ਼ਰ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਣ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਲਈ ਇਸ ਲੇਖ ਵਿੱਚ ਦਿੱਤੇ ਗਏ ਸੰਚਾਲਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਨਿਪਟਾਰੇ ਦੇ ਸੁਝਾਅ ਹਨ। ਇਹ ਇੱਕ ਅਧਿਕਾਰਤ CVSS ਵਰਗੀਕਰਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਸਨੂੰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦੀ ਅੰਦਰੂਨੀ ਸੰਪਤੀ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜੋਖਮ ਮੁਲਾਂਕਣ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।

1.2 ਪ੍ਰਭਾਵ ਸੀਮਾ ਅਤੇ ਹਮਲੇ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ

ਇਸ ਬੈਚ ਦੀਆਂ ਮੁੱਖ ਕਮਜ਼ੋਰੀਆਂ ਮੁੱਖ ਤੌਰ ‘ਤੇ NGINX ਡੇਟਾ ਪਲੇਨ ਵਿੱਚ ਸਥਿਤ ਹਨ: ਹਮਲਾ ਐਂਟਰੀ ਪੁਆਇੰਟ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨ ਅਤੇ ਬੇਨਤੀ ਹੈ, ਅਤੇ ਅਸਲ ਪ੍ਰਭਾਵ ਆਮ ਤੌਰ ‘ਤੇ Worker ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਲਈ ਸ਼ੋਸ਼ਣਯੋਗ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਅਨੁਮਤੀ ਆਮ ਤੌਰ ‘ਤੇ ਚੱਲ ਰਹੇ ਉਪਭੋਗਤਾ, ਕੰਟੇਨਰ ਪਾਬੰਦੀਆਂ, ਲੀਨਕਸ ਸਮਰੱਥਾ, ਮਾਊਂਟਿੰਗ ਅਤੇ Worker ਦੇ ਨੈੱਟਵਰਕ ਅਨੁਮਤੀਆਂ ਦੁਆਰਾ ਪ੍ਰਤਿਬੰਧਿਤ ਹੁੰਦੀ ਹੈ; ਸੰਭਾਵੀ RCE ਸਵੈਚਲਿਤ ਤੌਰ ‘ਤੇ root ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਜਾਂ ਹੋਸਟ ਸਮਝੌਤਾ ਨੂੰ ਸੰਕੇਤ ਨਹੀਂ ਕਰਦਾ ਹੈ। S4

ਪਰ ਭਾਵੇਂ ਇਹ ਪ੍ਰਕਿਰਿਆ ਗੈਰ-ਅਧਿਕਾਰਤ ਹੈ, ਇਸ ਵਿੱਚ ਅਜੇ ਵੀ ਪ੍ਰੌਕਸੀ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀਆਂ ਵਾਲੀਆਂ ਪੜ੍ਹਨਯੋਗ ਫਾਈਲਾਂ, ਅਪਸਟ੍ਰੀਮ ਸਰਵਿਸ ਟੋਕਨ, ਅਸਥਾਈ ਫਾਈਲਾਂ, ਅੰਦਰੂਨੀ API, ਅਤੇ ਪਹੁੰਚਯੋਗ ਨੈਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਹੋ ਸਕਦੀ ਹੈ। mTLS ਲਈ, ਪ੍ਰਮਾਣੀਕਰਨ ਬਾਈਪਾਸ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਗੰਭੀਰ ਵਪਾਰਕ ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਨਾਲ ਹੋਵੇ।

2. ਕਾਰਨ ਵਿਸ਼ਲੇਸ਼ਣ

2.1 NGINX ਵਿੱਚ ਤਿੰਨ ਗਲਤੀ-ਸੰਭਾਵੀ ਸੀਮਾਵਾਂ ਨੂੰ ਸਮਝੋ

ਇੱਕ NGINX worker ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀ, ਇਵੈਂਟ-ਸੰਚਾਲਿਤ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਬੇਨਤੀ ਸਥਿਤੀ, ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਪਾਰਸਰਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਇਹ ਕਮਜ਼ੋਰੀ ਤਿੰਨ ਇੰਜੀਨੀਅਰਿੰਗ ਪੱਧਰਾਂ ‘ਤੇ ਰੁਕਾਵਟਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ:

1. ਵੇਰੀਏਬਲ ਮੁਲਾਂਕਣ ਅਤੇ ਮੈਮੋਰੀ ਦਾ ਆਕਾਰ ਇਕਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: rewrite ਬੇਨਤੀ URI ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਪਾਥ ਮੈਪਿੰਗ ਮੌਜੂਦਾ ਪ੍ਰਭਾਵੀ location ਨਾਲ ਇਕਸਾਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ; ਜਦੋਂ ਸਕ੍ਰਿਪਟ ਦੁਭਾਸ਼ੀਏ ਵੇਰੀਏਬਲ ਲੰਬਾਈ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਲਿਖਣ ਵਾਲੀ ਥਾਂ ਨੂੰ ਅਸਲ ਆਉਟਪੁੱਟ ਅਤੇ ਰਾਖਵੇਂ ਖੇਤਰਾਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
2. ਅਸਿੰਕਰੋਨਸ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਬੇਨਤੀ ਕੀਤੀ ਮੈਮੋਰੀ ਦੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਜਦੋਂ ਅਧੂਰੀ ਫਾਈਲ ਰੀਡਿੰਗ ਅਤੇ ਰਾਈਟਿੰਗ, ਕੈਚ ਵੇਟਿੰਗ ਜਾਂ ਥ੍ਰੈਡ ਟਾਸਕ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸੰਬੰਧਿਤ ਬੇਨਤੀ ਮੈਮੋਰੀ ਪੂਲ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
3. ਪ੍ਰੋਟੋਕੋਲ ਸਥਿਤੀ ਅਤੇ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਨੂੰ ਮਿਲਾਇਆ ਜਾਂ ਛੱਡਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ: HTTP/3 ਅਗਿਆਤ ਫ੍ਰੇਮ ਛੱਡਣ ਦੀ ਲੰਬਾਈ ਨੂੰ DATA ਬੇਨਤੀ ਸਰੀਰ ਦੀ ਲੰਬਾਈ ਵਜੋਂ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ; TLS ਦਸਤਖਤ ਤਸਦੀਕ ਵਿੱਚ ਭਾਗ ਲੈਣ ਵਾਲੇ ਸਾਰੇ ਮੁੱਖ ਸਲਾਟ ਸੈਸ਼ਨ ਟਿਕਟ ਰੋਟੇਸ਼ਨ ਦੌਰਾਨ ਸਹੀ ਢੰਗ ਨਾਲ ਅਰੰਭ ਅਤੇ ਸਮਕਾਲੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਨਿਮਨਲਿਖਤ ਸਮੱਗਰੀ NGINX ਅਪਸਟ੍ਰੀਮ ਫਿਕਸ ਕਮਿਟ ਅਤੇ ਵਿਕਰੇਤਾ ਘੋਸ਼ਣਾ ‘ਤੇ ਅਧਾਰਤ ਹੈ ਜੋ ਅਸਫਲਤਾ ਵਿਧੀ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਹੈ ਜਿਸ ਨੂੰ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਉਦਾਹਰਣ ਦਾ ਟੁਕੜਾ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਹੈ, ਇਹ ਪੂਰਾ ਕੋਡ ਨਹੀਂ ਹੈ ਜੋ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਦੀ ਮੁਰੰਮਤ ਕਰਨ ਲਈ ਸਿੱਧਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। S5S6S7S8S9

2.2 CVE-2026-15176: alias ਅਤੇ ਦੁਬਾਰਾ ਲਿਖੇ URI ਵਿਚਕਾਰ ਮਾਰਗ ਮੈਪਿੰਗ ਅਵੈਧ ਹੈ।

NGINX ਵਿੱਚ, ਮੇਲ ਖਾਂਦਾ location ਅਤੇ ਇਸਦੇ alias ਫਾਈਲ ਮਾਰਗ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ; rewrite ਮੌਜੂਦਾ ਬੇਨਤੀ URI ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਮੁੜ ਲਿਖਣ ਤੋਂ ਬਾਅਦ, ਮੂਲ location ਮੈਪਿੰਗ ਦੁਆਰਾ ਵਰਤੀਆਂ ਗਈਆਂ ਧਾਰਨਾਵਾਂ ਹੁਣ ਨਹੀਂ ਰੱਖ ਸਕਦੀਆਂ ਹਨ।

ngx_http_map_uri_to_path() ਵਿੱਚ alias ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਪ੍ਰਭਾਵਿਤ ਪ੍ਰੋਸੈਸਿੰਗ ਮਾਰਗ ਨੇ ਸਹੀ ਢੰਗ ਨਾਲ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਕਿ ਕੀ ਬੇਨਤੀ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ ਜਾਂ ਨਹੀਂ। ਜਦੋਂ ਸੰਰਚਨਾ ਮੁੜ-ਲਿਖਣ ਤੋਂ ਬਾਅਦ $request_filename ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਮਾਰਗ ਨੂੰ ਉਹਨਾਂ ਧਾਰਨਾਵਾਂ ਨਾਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਮੌਜੂਦਾ URI ਸਥਿਤੀ ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹਨ, ਅੰਤ ਵਿੱਚ ਹੀਪ ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਆਊਟ-ਆਫ-ਬਾਉਂਡ ਰਾਈਟ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ। S5

ਆਮ ਸੁਮੇਲ (ਸਿਰਫ਼ ਸੰਰਚਨਾ ਆਡਿਟ ਲਈ ਇੱਕ ਵਿਰੋਧੀ ਉਦਾਹਰਨ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤੈਨਾਤੀ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

ਖ਼ਤਰਾ return ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ: set, if, add_header, log_format, ਆਦਿ ਨੂੰ ਵੀ ਆਡਿਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜੇਕਰ $request_filename ਮੁਲਾਂਕਣ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਉਸੇ ਬੇਨਤੀ ਨੂੰ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਿੱਚ return ਸਿਰਫ ਇਸ ਰਾਜ ਮਾਰਗ ਨੂੰ ਦੇਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਇਸਦੀ ਵਰਤੋਂ ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲਈ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਕਿ ਸਾਰੀਆਂ ਉਤਪਾਦਨ ਸੰਰਚਨਾਵਾਂ ਓਵਰਫਲੋਜ਼ ਪੈਦਾ ਕਰਨਗੀਆਂ। S5S10

ਹਮਲੇ ਦੇ ਨਤੀਜੇ: ਇੱਕ ਬੇਨਤੀ ਬਣਾਉਣ ਨਾਲ Worker ਮੁੜ ਚਾਲੂ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਸੇਵਾ ਵਿੱਚ ਰੁਕਾਵਟ ਆ ਸਕਦੀ ਹੈ; ASLR ਬੰਦ ਹੋਣ ਜਾਂ ਬਾਈਪਾਸ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹੋਣ ਵਰਗੀਆਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਇੱਕ ਸੰਭਾਵੀ RCE ਹੈ। ਅੱਪਸਟਰੀਮ ਪੈਚ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ alias ਸੰਦਰਭ ਵਿੱਚ ਮੁੜ-ਲਿਖਤ URI ਮਾਰਗ ਮੈਪਿੰਗ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਹੈ ਜੋ ਕਿ ਹੁਣ ਵੈਧ ਨਹੀਂ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ ਬਫ਼ਰ ਨੂੰ ਵਧਾਉਣ ਦੀ ਬਜਾਏ। S5S10

2.3 CVE-2026-93479: ਸਕ੍ਰਿਪਟ ਮੁਲਾਂਕਣ ਵਿੱਚ “ਰਿਜ਼ਰਵਡ ਸਪੇਸ” ਅਤੇ ਅਸਲ ਵੇਰੀਏਬਲ ਲੰਬਾਈ ਦੇ ਵਿਚਕਾਰ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ

NGINX ਦੇ HTTP ਅਤੇ Stream ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਮੁਲਾਂਕਣਕਾਰ ਹੁੰਦੇ ਹਨ ਜੋ ਨਤੀਜਾ ਸਤਰ ਵਿੱਚ ਸ਼ਾਬਦਿਕ ਸਤਰ ਅਤੇ ਵੇਰੀਏਬਲ ਮੁੱਲਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਉਦਾਹਰਨਾਂ ਵਿੱਚ HTTP ਦਸਤਾਵੇਜ਼ root ਪਾਥ, ਐਕਸੈਸ ਲੌਗ ਪਾਥ, ਅਤੇ Stream ਵਿੱਚ ਵੇਰੀਏਬਲ ਸਮੀਕਰਨ ਸ਼ਾਮਲ ਹਨ।

map + ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਦੀਆਂ ਕੁਝ ਸੰਰਚਨਾਵਾਂ map ਨਤੀਜਾ ਵੇਰੀਏਬਲ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਚਰ ਕੀਤੇ ਮੁੱਲਾਂ ਨੂੰ ਹੋਰ ਸਮੀਕਰਨਾਂ ਦੁਆਰਾ ਪੜ੍ਹਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਰਿਜ਼ਰਵਡ ਲੰਬਾਈ ਦੇ ਨਾਲ ਸਕ੍ਰਿਪਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਿਧੀ ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਪੁਰਾਣਾ ਲਾਗੂਕਰਨ len ਰਿਜ਼ਰਵਡ ਸਪੇਸ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਮੁਲਾਂਕਣ ਕੀਤੀ ਲੰਬਾਈ ਸੰਚਵਕ ਵਿੱਚ ਗਿਣੇਗਾ, ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਲਿਖਣ ਵਾਲੇ ਪੁਆਇੰਟਰ ਗਣਨਾ ਹੁਣ ਬਫਰ ਸੀਮਾ ਦੇ ਨਾਲ ਇਕਸਾਰ ਨਾ ਹੋਣ। ਇੱਕ ਖਾਸ ਪਰਿਵਰਤਨਸ਼ੀਲ ਮੁਲਾਂਕਣ ਕ੍ਰਮ ਵਿੱਚ, ਅਗਲੀਆਂ ਸਤਰ ਰਾਈਟਸ ਰਾਖਵੇਂ ਖੇਤਰ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਹੀਪ ਓਵਰਫਲੋ ਹੋ ਸਕਦਾ ਹੈ। S6

ਭਾਗੀਦਾਰ ਤੱਤ	ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਕਿਉਂ ਹੈ
map ਵਿੱਚ regex	ਕੈਪਚਰ ਵੇਰੀਏਬਲ ਮੁਲਾਂਕਣ ਵਿੱਚ ਸੁਤੰਤਰ ਜੀਵਨ ਚੱਕਰ ਅਤੇ ਕੈਚਿੰਗ ਵਿਵਹਾਰ ਹੋ ਸਕਦਾ ਹੈ
ਅਗਿਆਤ ਕੈਪਚਰ ਜਿਵੇਂ ਕਿ $1, $2, ਆਦਿ।	ਹੋਰ ਨਿਯਮਤ ਸਮੀਕਰਨਾਂ ਜਾਂ ਸਮੀਕਰਨਾਂ ਦੁਆਰਾ ਆਸਾਨੀ ਨਾਲ ਓਵਰਰਾਈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਲਕੀਅਤ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ
root ਵਿੱਚ ਵੇਰੀਏਬਲ	ਸਕ੍ਰਿਪਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਅਤੇ ਬਫਰ ਰਿਜ਼ਰਵੇਸ਼ਨ ਜਦੋਂ ਪਾਥ ਬਿਲਡਿੰਗ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ
log_format/ਡਾਇਨੈਮਿਕ ਲੌਗ ਮਾਰਗ	ਉਸੇ ਤਰ੍ਹਾਂ ਦਾ ਮੁਲਾਂਕਣ ਬਾਅਦ ਵਿੱਚ ਬੇਨਤੀ ਵਿੱਚ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ
stream ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਸਮੀਕਰਨ	ਅੱਪਸਟਰੀਮ ਫਿਕਸ ngx_stream_script_run() ਨੂੰ ਵੀ ਸੋਧਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ HTTP ਮੋਡੀਊਲ ਦੀ ਸਮੀਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ।

ਮਹੱਤਵਪੂਰਨ ਰਿਗਰੈਸ਼ਨ ਸਬੰਧ: ਇਸ ਕਮਜ਼ੋਰੀ ਨਾਲ ਸਬੰਧਤ ਕੋਡ ਪਿਛਲੀਆਂ ਤਬਦੀਲੀਆਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਜੋ CVE-2026-42533 ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦੇ ਹਨ। Debian 13 ਲਈ ਅਧਿਕਾਰਤ DSA ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰਭਾਵਿਤ ਕੋਡ ਨੂੰ ਇੱਕ ਪੁਰਾਣੇ ਸੁਰੱਖਿਆ ਬੈਕਪੋਰਟ ਰਾਹੀਂ trixie ਪੈਕੇਜ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਲਈ, “ਜੁਲਾਈ map ਕਮਜ਼ੋਰੀ ਪੈਚ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਅਕਤੂਬਰ ਦੇ CVE-2026-93479 ਨੂੰ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ; ਪੂਰੀ ਸੁਰੱਖਿਆ ਫਿਕਸ ਚੇਨ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। S6S14S17

ਇੱਥੇ ਸੰਭਾਵੀ RCE ਜੋਖਮ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਵਾਤਾਵਰਣ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਅਤੇ ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ map regex ਹੀ ਅਗਿਆਤ ਹਮਲਾਵਰਾਂ ਦੁਆਰਾ ਸ਼ੋਸ਼ਣ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ। S11

2.4 CVE-2026-97205: AIO ਅਧੂਰਾ ਓਪਰੇਸ਼ਨ ਕਾਉਂਟ ਰੈਪਰਾਉਂਡ ਵਰਤੋਂ-ਬਾਅਦ-ਮੁਫ਼ਤ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ

ਇਹ ਕਮਜ਼ੋਰੀ ਸਿਰਫ਼ “SSI ਨੂੰ ਚਾਲੂ ਕਰੋ ਅਤੇ ਤੁਹਾਨੂੰ UAF” ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ। ਮੁੱਖ ਬੇਨਤੀ ਦੁਆਰਾ ਰੱਖੀ ਗਈ ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ ਸੰਦਰਭ ਗਿਣਤੀ ਵਿੱਚ ਕੁੰਜੀ ਹੈ।

NGINX ਅਸਿੰਕਰੋਨਸ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ r->main->blocked ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਅਜੇ ਤੱਕ ਪੂਰੀ ਨਹੀਂ ਹੋਈ ਹੈ, ਪੁਰਾਣੇ ਅਮਲ ਵਿੱਚ ਇਹ 8-ਬਿੱਟ ਗਿਣਤੀ ਸੀ; ਕੁਝ ਮਾਰਗਾਂ ਨੇ ਗਿਣਤੀ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉੱਚ ਸੀਮਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ। ਜਦੋਂ ਉਹੀ ਮੁੱਖ ਬੇਨਤੀ 256 ਬਕਾਇਆ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਗਿਣਤੀ 255 ਤੋਂ 0 ਤੱਕ ਸਮੇਟ ਸਕਦੀ ਹੈ। ਅਗਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਗਲਤੀ ਨਾਲ ਇਹ ਮੰਨਣਗੀਆਂ ਕਿ ਬੇਨਤੀ ਨੂੰ ਜਾਰੀ ਹੋਣ ਤੋਂ ਰੋਕਣ ਵਾਲਾ ਕੋਈ ਅਸਿੰਕਰੋਨਸ ਓਪਰੇਸ਼ਨ ਨਹੀਂ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਬੇਨਤੀ ਮੈਮੋਰੀ ਪੂਲ ਨੂੰ ਜਾਰੀ ਕੀਤਾ ਜਾਵੇਗਾ ਜੋ ਅਜੇ ਵੀ ਕਾਰਜ ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। S7

ਅਸਫਲਤਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਸ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

1. ਸੰਬੰਧਿਤ ਅਸਿੰਕਰੋਨਸ I/O/ਥ੍ਰੈੱਡ ਮਾਰਗ ਸਮਰਥਿਤ ਹੋਣ ਦੇ ਨਾਲ, SSI ਪੰਨਾ include virtual ਦੁਆਰਾ ਮਲਟੀਪਲ ਸਬ-ਰਿਕੁਸਟ ਜਾਂ ਰੀਡ ਓਪਰੇਸ਼ਨ ਪੇਸ਼ ਕਰਦਾ ਹੈ।
2. ਕਿਸੇ ਖਾਸ ਮੁੱਖ ਬੇਨਤੀ ਦੇ ਬਕਾਇਆ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਗਿਣਤੀ ਖੇਤਰ ਦੁਆਰਾ ਦਰਸਾਈ ਗਈ ਉਪਰਲੀ ਸੀਮਾ ਤੱਕ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
3. 8-ਬਿੱਟ ਗਿਣਤੀ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲਪੇਟਦਾ ਹੈ, “ਕੋਈ ਬਕਾਇਆ ਓਪਰੇਸ਼ਨ ਨਹੀਂ” ਵਜੋਂ ਗਲਤ ਢੰਗ ਨਾਲ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।
4. ਬੇਨਤੀ ਮੈਮੋਰੀ ਪੂਲ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਫਾਈਲ ਰੀਡ, ਕੈਸ਼ ਉਡੀਕ, ਜਾਂ ਥਰਿੱਡ ਕਾਰਜਾਂ ਦੇ ਕਾਲਬੈਕ ਅਜੇ ਵੀ ਇਸਦੇ ਹਵਾਲੇ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹਨ।
5. ਬਾਅਦ ਵਿੱਚ ਅਸਿੰਕਰੋਨਸ ਮੁਕੰਮਲ ਹੋਣ ਵਾਲੇ ਕਾਲਬੈਕਸ ਜਾਰੀ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ, ਨਤੀਜੇ ਵਜੋਂ UAF, Worker ਕਰੈਸ਼ ਜਾਂ ਸੰਭਾਵੀ ਮੈਮੋਰੀ ਖਰਾਬ ਹੋ ਜਾਂਦੀ ਹੈ।

ਅਧਿਕਾਰਤ ਫਿਕਸ ਬੇਨਤੀ ਹੈਡਰ ਫਾਈਲ ਵਿੱਚ NGX_HTTP_MAX_BLOCKED 250 ਜੋੜਦਾ ਹੈ, ਅਤੇ ਆਉਟਪੁੱਟ ਫਿਲਟਰ, ਕੈਸ਼ ਰੀਡ, ਅਤੇ ਅੱਪਸਟ੍ਰੀਮ ਥਰਿੱਡ ਮਾਰਗ ਵਿੱਚ ਪਾਬੰਦੀਆਂ ਜੋੜਦਾ ਹੈ; ਜਦੋਂ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ, ਸਮਕਾਲੀ ਮਾਰਗਾਂ ਦੇ ਨਾਲ ਓਪਰੇਸ਼ਨ ਸਮਕਾਲੀ ਤੌਰ ‘ਤੇ ਪੂਰੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਬਕਾਇਆ ਕਾਰਜਾਂ ਨੂੰ ਹੋਰ ਜੋੜਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ। S7

ਲਾਗੂ ਹੋਣ ਦਾ ਨਿਰਣਾ: ਇਸ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ SSI, AIO, ਵਰਚੁਅਲ ਸਮਾਵੇਸ਼, ਸਬ-ਰਿਵੈਸਟਸ ਅਤੇ ਸੰਬੰਧਿਤ ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ ਇੱਕੋ ਬੇਨਤੀ ਲੜੀ ਵਿੱਚ ਸੁਮੇਲ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਆਮ ਤੌਰ ‘ਤੇ ਡਿਫੌਲਟ ਪਲੇਨ ਸਟੈਟਿਕ ਪ੍ਰੌਕਸੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। aio off; ਜਾਂ ssi off; ਖਾਸ ਟਰਿੱਗਰ ਤੱਤਾਂ ਨੂੰ ਹਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਵਪਾਰਕ ਫੰਕਸ਼ਨ ਨਿਰਭਰਤਾ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। S4S7S25

2.5 CVE-2026-95101: HTTP/3 ਅਗਿਆਤ ਫ੍ਰੇਮ DATA ਬੇਨਤੀ ਬਾਡੀ ਦੀ ਸਥਿਤੀ ਨਾਲ ਉਲਝਣ ਵਿੱਚ ਹੈ

HTTP/3 ਫਰੇਮ ਪਾਰਸਰ ਨੂੰ DATA ਫਰੇਮਾਂ (ਜਿਨ੍ਹਾਂ ਨੂੰ HTTP ਬੇਨਤੀ ਬਾਡੀ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ) ਅਤੇ ਅਣਜਾਣ ਫ੍ਰੇਮਾਂ ਵਿੱਚ ਫਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਛੱਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਣਜਾਣ ਫਰੇਮਾਂ ਦੀ ਲੰਬਾਈ ਨੂੰ ਵੀ ਸਹੀ ਢੰਗ ਨਾਲ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਨੈੱਟਵਰਕ ਬਫਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।

ngx_http_v3_parse_data() ਦੇ ਪੁਰਾਣੇ ਲਾਗੂਕਰਨ ਨੇ ਅਣਜਾਣ ਫ੍ਰੇਮਾਂ ਨੂੰ ਛੱਡਣ ਵੇਲੇ “ਛੱਡੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਬਾਈਟਾਂ ਦੀ ਬਾਕੀ ਸੰਖਿਆ” ਨੂੰ ਬਚਾਉਣ ਲਈ st->length ਫੀਲਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜਦੋਂ ਕਿ ਬੇਨਤੀ ਬਾਡੀ ਫਿਲਟਰ ਨੇ ਉਸੇ ਖੇਤਰ ਨੂੰ “ਬਾਕੀ DATA ਪੇਲੋਡ ਲੰਬਾਈ” ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਆਖਿਆ ਕੀਤੀ। ਜੇਕਰ ਅਣਜਾਣ ਫ੍ਰੇਮ ਮਲਟੀਪਲ ਪਾਰਸ ਕਾਲਾਂ ਨੂੰ ਫੈਲਾਉਣ ਲਈ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਪਾਰਸ ਕਰਨ ਤੋਂ ਬਾਅਦ ਬਾਈਟਾਂ ਦਾ ਅਗਲਾ ਬੈਚ ਬੇਨਤੀ ਦੇ ਭਾਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। S8

ਦੋ ਕਿਸਮ ਦੇ ਜੋਖਮ ਪੈਦਾ ਹੁੰਦੇ ਹਨ:

• ਬਾਡੀ ਇੰਜੈਕਸ਼ਨ ਦੀ ਬੇਨਤੀ ਕਰੋ: ਕਲਾਇੰਟ ਦੁਆਰਾ ਜਮ੍ਹਾਂ ਕੀਤੇ ਗੈਰ-DATA ਫਰੇਮ ਪੇਲੋਡ ਨੂੰ ਬੈਕਐਂਡ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਬਦਲਦੇ ਹੋਏ, ਅੱਪਸਟ੍ਰੀਮ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸੰਚਾਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਆਕਾਰ ਸੀਮਾ ਬਾਈਪਾਸ: client_max_body_size ਅਤੇ ਹੋਰ ਪਾਬੰਦੀਆਂ। ਸੰਭਾਵਿਤ ਜਾਂਚਾਂ DATA ਮਾਰਗ ‘ਤੇ ਕੇਂਦ੍ਰਿਤ ਹਨ, ਅਤੇ ਗਲਤ ਢੰਗ ਨਾਲ ਬਦਲੀ ਗਈ ਸਮੱਗਰੀ ਸੰਬੰਧਿਤ ਪੁਸ਼ਟੀਕਰਨ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੀ ਹੈ।

ਅਧਿਕਾਰੀ ਦੁਆਰਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਖਾਸ ਟਰਿੱਗਰ ਦ੍ਰਿਸ਼ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ngx_http_v3_module HTTP/3 ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ proxy_request_buffering on ਨੂੰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਬਾਡੀ ਬਫਰਿੰਗ ngx_http_proxy_module ਵਿੱਚ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਹੈ। ਇਸ ਲਈ, ਉਲਟਾ ਪ੍ਰੌਕਸੀ ਜੋ HTTP/3 ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ, ਪਹਿਲਾਂ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਮੰਨਣਾ ਉਚਿਤ ਨਹੀਂ ਹੈ ਕਿ ਇੱਥੇ ਕੋਈ ਟਰਿੱਗਰ ਸਥਿਤੀ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ proxy_request_buffering on; ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਨਹੀਂ ਲਿਖਿਆ ਗਿਆ ਹੈ। S8S18

ਇਸ ਕਮਜ਼ੋਰੀ ਦਾ ਸਿੱਧਾ ਨਤੀਜਾ ਬੈਕਐਂਡ ਬੇਨਤੀ ਦੀ ਇਕਸਾਰਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਸੀਮਾ ਤਬਦੀਲੀ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਜੋ ਕਿ ਇਸ ਦੇ ਬਰਾਬਰ ਦਾ ਪ੍ਰਗਟਾਵਾ ਨਹੀਂ ਹੈ RCE ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਪੂਰਾ ਕੀਤਾ NGINX ਕੋਰ. ਅੰਤਮ ਵਪਾਰਕ ਪ੍ਰਭਾਵ ਇਸ ਗੱਲ ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਬਾਈਟਾਂ ਨੂੰ ਪਾਰਸ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅੱਪਸਟ੍ਰੀਮ ‘ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। S24

2.6 CVE-2026-97629: TLS ਟਿਕਟ ਰੋਟੇਸ਼ਨ ਤੀਜੇ ਕੁੰਜੀ ਸਲਾਟ ਤੋਂ ਖੁੰਝ ਗਈ

ਪ੍ਰਭਾਵਿਤ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ, NGINX ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਕੈਸ਼ ਦੁਆਰਾ TLS ਸੈਸ਼ਨ ਟਿਕਟ ਕੁੰਜੀਆਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ ‘ਤੇ ਤਿਆਰ ਅਤੇ ਘੁੰਮਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਲਟੀਪਲ Worker ਟਿਕਟਾਂ ਦੇ ਇੱਕੋ ਬੈਚ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਤਰਕ ਹਰੇਕ Worker ਲਈ 3 ਮੁੱਖ ਸਲਾਟ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਕਾਲਬੈਕ ਇਹਨਾਂ ਸਲਾਟਾਂ ਨੂੰ ਵੀ ਪਾਰ ਕਰੇਗਾ; ਪਰ ਪੁਰਾਣਾ ਲਾਗੂਕਰਨ ਹਰ ਵਾਰ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਤੋਂ ਸਿਰਫ 2 ਕੁੰਜੀ ਸਲਾਟਾਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ ਕੁੰਜੀ ਦਾ ਨਾਮ, HMAC ਕੁੰਜੀ ਅਤੇ ਤੀਜੇ ਸਲਾਟ ਦਾ AES। ਕੁੰਜੀ ਅਣ-ਸ਼ੁਰੂ ਰਹਿ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਟਿਕਟ ਦਾ ਮੁੱਖ ਪਛਾਣਕਰਤਾ ਇਸ ਸਥਿਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਅਣ-ਸ਼ੁਰੂਆਤੀ ਕੁੰਜੀ ਸਮੱਗਰੀ ਨੂੰ ਦਸਤਖਤ ਤਸਦੀਕ ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ TLS ਸੈਸ਼ਨ ਨੂੰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਮਾਰਗ ਬਣਾਉਂਦਾ ਹੈ। S9

ਉੱਚ-ਜੋਖਮ ਤੈਨਾਤੀ ਸੰਜੋਗ ਆਮ ਤੌਰ ‘ਤੇ ਹਨ:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

ਇਸ ਕਮਜ਼ੋਰੀ ਦਾ ਸਭ ਤੋਂ ਗੰਭੀਰ ਵਪਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ‘ਤੇ ਜੋ ssl_verify_client on; ਅਤੇ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ (mTLS) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਾਅਲੀ ਰਿਕਵਰੀ ਸੈਸ਼ਨ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪੁਸ਼ਟੀਕਰਨ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੇ ਹਨ। ਹਮਲੇ ਦੀ ਸਫਲਤਾ ਵੀ ਬੇਕਾਬੂ ਹਾਲਤਾਂ ਦੇ ਅਧੀਨ ਹੈ; ਇੱਕ ਸਾਈਟ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਸਧਾਰਨ ਸਰਵਰ-ਸਾਈਡ HTTPS ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਗਲਤ ਨਹੀਂ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ “ਹਮਲਾਵਰ ਪੂਰੀ ਵੈਬਸਾਈਟ ਲੌਗਇਨ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ।” S9S12

ਇਹ ਇੱਕ TLS ਸੈਸ਼ਨ ਪ੍ਰਮਾਣੀਕਰਨ ਸਥਿਤੀ ਦਾ ਮੁੱਦਾ ਹੈ ਅਤੇ ਇਸਦਾ ਇਸ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਸਰਵਰ ਦੀ TLS ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਕ੍ਰੈਕ ਹੈ ਜਾਂ ਕੀ ਜਨਤਕ CA root ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਹੈ। S24

2.7 DoS, RCE, ਪ੍ਰਮਾਣਿਕਤਾ ਬਾਈਪਾਸ ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਕਾਰਨਾਮੇ ਨੂੰ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ

• DoS: ਮੈਮੋਰੀ ਗਲਤੀ Worker ਕਰੈਸ਼ ਜਾਂ ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਰੀਬੂਟ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ। ਕੀ ਇਹ ਸਮੁੱਚੀ ਅਣਉਪਲਬਧਤਾ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ ਟ੍ਰੈਫਿਕ ਦਬਾਅ, ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਦੀ ਯੋਗਤਾ, ਕੁਨੈਕਸ਼ਨ ਰੱਖ-ਰਖਾਅ ਦਾ ਸਮਾਂ ਅਤੇ ਉੱਚ-ਉਪਲਬਧਤਾ ਢਾਂਚੇ ਨਾਲ ਸਬੰਧਤ ਹੈ।
• ਸੰਭਾਵੀ RCE: ਕੁਝ ਘੋਸ਼ਣਾਵਾਂ ਸੰਕੇਤ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਜਦੋਂ ASLR ਬੰਦ ਜਾਂ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇੱਕ ਜਨਤਕ ਹਮਲੇ ਦੀ ਲੜੀ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਸਥਿਰ ਅਤੇ ਸਰਵ ਵਿਆਪਕ ਤੌਰ ‘ਤੇ ਕਮਾਂਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ। S4
• ਇੰਜੈਕਸ਼ਨ/ਪ੍ਰਮਾਣੀਕਰਨ ਬਾਈਪਾਸ ਦੀ ਬੇਨਤੀ ਕਰੋ: ਇਹ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਸੁਰੱਖਿਅਤ ਕਾਰੋਬਾਰੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ ਜਾਂ ਸਮੱਗਰੀ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਅਣਡਿੱਠ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ ਇਹ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਸ਼ੈੱਲ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦਾ ਹੈ।
• ਨੇ ਹਮਲੇ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਖੋਜ ਕੀਤੀ ਹੈ: ਮਈ 2026 ਵਿੱਚ CVE-2026-42945 ਵਿੱਚ ਜੰਗਲੀ ਸ਼ੋਸ਼ਣ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਹਨ; ਇਸ ਇਤਿਹਾਸਕ ਤੱਥ ਦਾ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕੱਢਣਾ ਚਾਹੀਦਾ ਕਿ ਅਕਤੂਬਰ ਦੇ ਸਾਰੇ ਪੰਜ CVE ਦਾ ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਸਫਲਤਾਪੂਰਵਕ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਗਿਆ ਹੈ। S23

3. ਮੁਰੰਮਤ ਸੰਸਕਰਣ ਅਤੇ ਪੈਚ ਚੋਣ

3.1 NGINX Open Source ਅਧਿਕਾਰਤ ਪੈਚ ਬੇਸਲਾਈਨ

ਅੱਪਸਟਰੀਮ ਸ਼ਾਖਾ	ਅਕਤੂਬਰ ਵਿੱਚ ਪੰਜ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲਾ ਪਹਿਲਾ ਅਧਿਕਾਰਤ ਸੰਸਕਰਣ	2026-10-27 ਅਨੁਸਾਰ ਸਿਫ਼ਾਰਿਸ਼ਾਂ
Stable 1.30.x	1.30.6（2026-10-14）	ਘੱਟੋ-ਘੱਟ 1.30.6 ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ, ਅਤੇ ਅਗਲੇ ਸੁਰੱਖਿਆ ਸੰਸਕਰਣਾਂ ਨਾਲ ਫਾਲੋ-ਅੱਪ ਕਰੋ।
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
ਪਹਿਲਾਂ ਦੀ NGINX Open Source ਸ਼ਾਖਾ	ਇਸਦਾ ਨਿਰਣਾ ਸਿਰਫ਼ “ਪੁਰਾਣੇ ਕਮਜ਼ੋਰ ਪੈਚ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ” ਦੇ ਆਧਾਰ ‘ਤੇ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।	ਪਹਿਲਾਂ ਬਣਾਈ ਸ਼ਾਖਾ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰੋ; ਨਹੀਂ ਤਾਂ, ਵਿਕਰੇਤਾ ਨੂੰ CVE-by-CVE ਆਧਾਰ ‘ਤੇ ਸਮਰਥਨ ਦਾ ਰਸਮੀ ਸਬੂਤ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਹ nginx.org ਅੱਪਸਟ੍ਰੀਮ ਸੋਰਸ ਕੋਡ/ਅਧਿਕਾਰਤ ਸ਼ਾਖਾ ਦੇ ਸੰਸਕਰਣ ਸਿੱਟੇ ਹਨ, ਅਤੇ ਵੰਡ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਬੈਕਪੋਰਟ ਕੀਤੇ ਫਿਕਸਾਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਆ ਪੈਕੇਜ ਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਇਨਕਾਰ ਕਰਨ ਲਈ ਨਹੀਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਭਾਵੇਂ 1.31.6 ਦਾ ਮੁੱਲ 1.30.6 ਤੋਂ ਵੱਧ ਹੈ, ਇਹ ਅਜੇ ਵੀ ਮੇਨਲਾਈਨ ਬ੍ਰਾਂਚ ਦੀ ਪੈਚ ਬੇਸਲਾਈਨ ਤੋਂ ਘੱਟ ਹੈ। S1S2

3.2 ਪੰਜ CVEs ਦਾ ਅੱਪਸਟਰੀਮ ਪ੍ਰਭਾਵ ਸਕੋਪ

ਹੇਠ ਲਿਖੀਆਂ ਰੇਂਜਾਂ ਨੂੰ nginx.org ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ ਦੇ ਮੂਲ ਪਾਠ ਦੇ ਅਨੁਸਾਰ ਸੂਚੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ “ਮੌਜੂਦਾ ਚੱਲ ਰਹੀ ਸ਼ਾਖਾ” ਅਤੇ “ਅਸਲ ਸੰਰਚਨਾ ਮਾਰਗ” ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ:

ਸੀ.ਵੀ.ਈ	ਅੱਪਸਟਰੀਮ ਟੈਗ ਪ੍ਰਭਾਵਿਤ ਸੰਸਕਰਣ	ਅਧਿਕਾਰਤ ਤੌਰ ‘ਤੇ ਲੇਬਲ ਕੀਤਾ ਸਥਿਰ ਸੰਸਕਰਣ
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ ਜਾਂ 1.31.7+, ਉਹਨਾਂ ਦੀਆਂ ਸੰਬੰਧਿਤ ਸ਼ਾਖਾਵਾਂ ਦੇ ਅੰਦਰ
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ
CVE-2026-97205	0.8.11–1.31.6	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ
CVE-2026-95101	1.25.0–1.31.6	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ
CVE-2026-97629	1.23.2–1.31.6	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ

CVE-2026-93479 ਦੀਆਂ ਖਾਸ ਜਾਣ-ਪਛਾਣ-ਵਰਜਨ ਸੀਮਾਵਾਂ ਹਨ; ਹਰ ਪੁਰਾਣਾ NGINX ਸੰਸਕਰਣ ਇਸ ਰਿਗਰੈਸ਼ਨ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਰੇਂਜਾਂ ਤੋਂ ਬਾਹਰ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਅਜੇ ਵੀ ਪੁਰਾਣੇ map regex ਕਮਜ਼ੋਰੀ CVE-2026-42533 ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੇ ਹਨ। S1

3.3 Ubuntu: ਵੰਡ ਬੈਕਪੋਰਟ (USN-8955-1)

ਕੈਨੋਨੀਕਲ USN-8955-1 ਅਕਤੂਬਰ 26, 2026 ਚਾਰ Ubuntu ਬਿਲਡਾਂ ਲਈ ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: S13

Ubuntu ਸੰਸਕਰਣ	nginx ਅਤੇ ਉਹੀ ਸਰੋਤ ਪੈਕੇਜ ਸਥਿਰ ਸੰਸਕਰਣ	ਵਰਣਨ
22.04 LTS	1.18.0-6ubuntu14.22	ਇਹ ਇੱਕ ਵਿਕਰੇਤਾ ਬੈਕਪੋਰਟ ਹੈ; ਅੱਪਸਟ੍ਰੀਮ ਵਰਜਨ ਨੰਬਰ ਅਜੇ ਵੀ 1.18.0 ਦਿਖਾਉਂਦਾ ਹੈ
24.04 LTS	1.24.0-2ubuntu7.19	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ
26.04 LTS	1.28.3-2ubuntu1.12	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ
26.10	1.30.4-7ubuntu1.1	ਉਪਰੋਕਤ ਵਾਂਗ ਹੀ

ਘੋਸ਼ਣਾ ਵਿੱਚ ਸਮਰੂਪ ਪੈਕੇਜਾਂ ਦੇ ਅਨੁਸਾਰੀ ਸਥਿਰ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹਨ ਜਿਵੇਂ ਕਿ nginx-core, nginx-extras, nginx-full, ਅਤੇ nginx-light। ਸਿਰਫ਼ nginx -v ਦੁਆਰਾ ਦਿਖਾਏ ਗਏ ਅੱਪਸਟ੍ਰੀਮ ਹਿੱਸੇ ਤੋਂ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਸ ਬਾਰੇ ਸਿੱਟੇ ਨਾ ਕੱਢੋ। ਜਿਵੇਂ ਕਿ Ubuntu 24.04 ਅਤੇ 1.24.0-2ubuntu7.19 ਨੂੰ ਇਸ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਪੈਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਕਿਸੇ ਵੀ ਸਰੋਤ ਤੋਂ 1.24.0 ਕੁਦਰਤੀ ਤੌਰ ‘ਤੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ।

Ubuntu ਅਧਿਕਾਰਤ ਤੌਰ ‘ਤੇ ਵੀ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਮਾਰਕ ਕੀਤਾ ਹੈ CVE-2026-95101 ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ Ubuntu 26.04 / 26.10 , ਅਤੇ CVE-2026-97629 ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ Ubuntu 24.04 / 26.04 / 26.10. ਇੱਥੇ ਹੈ Ubuntu ਦੀ ਆਪਣੀ ਪੈਕੇਜਿੰਗ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਦਾਇਰੇ, ਜਿਸ ਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਹੋਰ ਵੰਡਾਂ ਲਈ ਉਤਸ਼ਾਹਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। S13

3.4 Debian: ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ‘ਤੇ ਜਾਂਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ

Debian ਸਲਾਹਕਾਰ DSA-6575-1 (2026-10-21) ਇਹਨਾਂ ਪੰਜ CVE ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ Debian 13 / trixie ਲਈ ਸਥਿਰ nginx ਪੈਕੇਜ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ:

1.26.3-3+deb13u10

ਹਾਲਾਂਕਿ, ਇਸ ਰਿਪੋਰਟ ਦੀ ਪੁਸ਼ਟੀ ਦੇ ਸਮੇਂ ਤੱਕ, Debian 12 / bookworm ਲਈ 1.22.1-9+deb12u10 ਨੂੰ ਅਜੇ ਵੀ Debian ਸੁਰੱਖਿਆ ਟਰੈਕਰ ਦੁਆਰਾ ਕਮਜ਼ੋਰ ਵਜੋਂ ਫਲੈਗ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਲਈ:

• Debian 13 ਬਸ ਅੱਪਡੇਟ ਕਰੋ ਅਤੇ DSA-6575-1 ਦੇ ਅਨੁਸਾਰ ਸਵੀਕਾਰ ਕਰੋ।
• Debian 12 ਨੂੰ ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਟਰੈਕਰ ਜਾਂ ELTS ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਸੁਰੱਖਿਆ ਫਿਕਸਾਂ ਦੀ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ; ਘੋਸ਼ਣਾ ਵਿੱਚ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਘੋਸ਼ਣਾ ਨਾ ਕਰੋ ਕਿ ਸਾਰੀਆਂ ਪੰਜ ਆਈਟਮਾਂ apt upgrade ਦੀ ਸਫਲਤਾ ਦੇ ਅਧਾਰ ‘ਤੇ ਫਿਕਸ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
• Debian ਸਰੋਤ ਪੈਕੇਜ nginx.org ਸੰਸਕਰਣ ਨੰਬਰ ਤੋਂ ਸੁਤੰਤਰ ਇੱਕ ਪੈਚ ਸੈੱਟ ਲੈ ਸਕਦਾ ਹੈ। ਕਸਟਮ ਬਿਲਡਾਂ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰੇ ਸਰੋਤ ਕੋਡ ਪੈਕੇਜ ਫਿਕਸ ਸੈੱਟ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਸਿੰਗਲ ਅਪਸਟ੍ਰੀਮ ਕਮਿਟ ਦੀ ਨਕਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਸਨੂੰ ਪੂਰਾ ਸਮਝ ਸਕਦੇ ਹੋ।

ਉਪਰੋਕਤ ਅੰਤਰ DSA ਅਤੇ CVE ਟਰੈਕਿੰਗ ਰਿਕਾਰਡਾਂ ‘ਤੇ ਅਧਾਰਤ ਹੈ। S14S15S16

3.5 NGINX Plus, njs ਅਤੇ ਪ੍ਰਵੇਸ਼ ਕੰਟਰੋਲਰ

ਉਤਪਾਦ/ਕੰਪੋਨੈਂਟਸ	ਸੁਰੱਖਿਆ ਚੋਣ ਅਤੇ ਪੁਸ਼ਟੀਕਰਨ ਮੁੱਖ ਨੁਕਤੇ
NGINX Plus (ਵਪਾਰਕ ਸੰਸਕਰਣ)	ਕਿਰਪਾ ਕਰਕੇ F5 ਨਾਲ ਸੰਬੰਧਿਤ ਪਲੱਸ ਸ਼ਾਖਾ ਦੀ ਘੋਸ਼ਣਾ ਅਤੇ ਅਪਗ੍ਰੇਡ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਵੇਖੋ। ਪੁਸ਼ਟੀਕਰਨ ਦੇ ਸਮੇਂ ਨਵੀਨਤਮ CR PLS.37.2.0.1 ਹੈ, ਅਤੇ LTS ਦੀ ਸੁਰੱਖਿਆ ਬਿਲਡ PLS.37.0.7.1 ਹੈ; ਪਲੱਸ ਸੰਸਕਰਣ ਅਤੇ ਸ਼ਾਮਲ ਬੈਕਪੋਰਟ ਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਓਪਨ ਸੋਰਸ ਦੇ 1.30/1.31 ਥ੍ਰੈਸ਼ਹੋਲਡ ਦੁਆਰਾ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ। S19
njs / ngx_http_js_module	2026-10-14 njs 1.0.2 ਜਾਰੀ ਕਰਦਾ ਹੈ ਅਤੇ CVE-2026-101019 ਅਤੇ CVE-2026-101025 ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ; ਜੇਕਰ ਤੁਸੀਂ njs ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ NGINX ਦੇ ਨਾਲ ਮੋਡੀਊਲ ਦੀ ਅਨੁਕੂਲਤਾ ਦੀ ਵੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। S20
F5 NGINX ਪ੍ਰਵੇਸ਼ ਕੰਟਰੋਲਰ / ਗੇਟਵੇ ਫੈਬਰਿਕ	NGINX ਕੋਰ ਇੱਕ ਸੰਬੰਧਿਤ ਪਰ ਸੁਤੰਤਰ ਸਾਫਟਵੇਅਰ ਵੰਡ ਚੇਨ ਹੈ। ਉਹਨਾਂ ਦੇ ਸੰਬੰਧਿਤ ਕੰਟਰੋਲਰਾਂ, ਚਿੱਤਰਾਂ ਅਤੇ ਰੀਲੀਜ਼ ਨੋਟਸ ਨਾਲ ਸੰਬੰਧਿਤ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਠੀਕ ਕਰੋ। ਤੁਸੀਂ Pod ਵਿੱਚ ਸਿਰਫ਼ NGINX ਬਾਈਨਰੀ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦੇ।
Kubernetes ਕਮਿਊਨਿਟੀ kubernetes/ingress-nginx	ਪ੍ਰੋਜੈਕਟ ਮਾਰਚ 2026 ਵਿੱਚ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਹੁਣ ਨਵੀਂ ਸੁਰੱਖਿਆ ਰੱਖ-ਰਖਾਅ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰੇਗਾ। ਤੁਹਾਨੂੰ F5 NGINX ਇਨਗਰੇਸ ਕੰਟਰੋਲਰ ਲਈ ਇਸਦੇ ਰੀਲੀਜ਼ ਨੰਬਰ ਨੂੰ ਗਲਤ ਮੰਨਣ ਦੀ ਬਜਾਏ ਇੱਕ ਰੱਖ-ਰਖਾਅ ਕੀਤੇ ਕੰਟਰੋਲਰ ਜਾਂ Gateway API ‘ਤੇ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। S21

3.6 ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪੈਚ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ?

ਤੈਨਾਤੀ ਫਾਰਮ	ਸਿਫਾਰਸ਼ੀ ਅਭਿਆਸ	ਮੁਰੰਮਤ ਦਾ ਸਬੂਤ
nginx.org ਅਧਿਕਾਰਤ DEB/RPM ਪੈਕੇਜ	ਅੱਪਸਟ੍ਰੀਮ ਸ਼ਾਖਾ ਦੇ ਸਥਿਰ ਸੰਸਕਰਣ ‘ਤੇ ਅੱਪਗ੍ਰੇਡ ਕਰੋ	nginx -v/-V, ਪੈਕੇਜ ਸਰੋਤ, ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਘੋਸ਼ਣਾ
Ubuntu/Debian ਅਧਿਕਾਰਤ ਭੰਡਾਰ	ਵਿਕਰੇਤਾ ਸੁਰੱਖਿਆ ਪੈਕੇਜ ਸਥਾਪਿਤ ਕਰੋ	ਪੂਰਾ ਪੈਕੇਜ ਸੰਸਕਰਣ + ਵਿਕਰੇਤਾ USN/DSA + CVE ਸਥਿਤੀ
RHEL/Alma/Rocky/SUSE/ਹੋਰ ਵੰਡ	ਖਾਸ ਵੰਡ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ ਅਤੇ ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਦੇ ਅਨੁਸਾਰ ਅੱਪਗਰੇਡ ਕਰੋ	ਸੰਬੰਧਿਤ ਵਿਕਰੇਤਾ CSAF/ਐਲਾਨ, Ubuntu/Debian ਸੰਸਕਰਣ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ
ਅਧਿਕਾਰਤ ਜਾਂ ਕਸਟਮ ਕੰਟੇਨਰ ਚਿੱਤਰ	ਪ੍ਰਮਾਣਿਤ ਮੁਰੰਮਤ ਚਿੱਤਰ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਓ ਜਾਂ ਖਿੱਚੋ ਅਤੇ ਇਸਨੂੰ ਰੋਲਿੰਗ ਅਧਾਰ ‘ਤੇ ਬਦਲੋ	ਚਿੱਤਰ ਡਾਇਜੈਸਟ, SBOM ਬਣਾਓ, ਪੌਡ/ਕੰਟੇਨਰ ਚਿੱਤਰ ਆਈ.ਡੀ
ਸਵੈ-ਕੰਪਾਈਲ ਕੀਤੇ NGINX, OpenResty, Tengine ਜਾਂ ਤੀਜੀ-ਧਿਰ ਮਾਡਿਊਲਾਂ ਨਾਲ ਪੈਚ ਕੀਤੇ ਸੰਸਕਰਣ	ਮੇਨਟੇਨਰ ਦੇ ਪੂਰੇ ਸੁਰੱਖਿਆ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; ਲੋੜ ਪੈਣ ‘ਤੇ ਟਾਰਗੇਟ ਸੋਰਸ ਟ੍ਰੀ ਲਈ ਸਮੀਖਿਆ ਕੀਤੇ ਪੈਚ ਬੈਕਪੋਰਟ ਕਰੋ	ਪੰਜ ਕਮਜ਼ੋਰੀ ਫਿਕਸ, ABI/ਮੋਡਿਊਲ ਅਨੁਕੂਲਤਾ, ਯੂਨਿਟ ਅਤੇ ਵਪਾਰਕ ਰਿਗਰੈਸ਼ਨ

OpenResty ਅਤੇ Tengine ਵੱਖ-ਵੱਖ ਰੀਲੀਜ਼ ਸਿਸਟਮ ਹਨ; ਇਹ ਸਾਰਣੀ ਸਿਰਫ਼ ਪੁਸ਼ਟੀਕਰਨ ਵਿਧੀ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸਦੇ ਸਾਰੇ ਸੰਸਕਰਣ ਸਟੈਂਡਰਡ NGINX ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਨਾ ਹੀ ਅਪਸਟ੍ਰੀਮ ਕੋਡ ਪੈਚ ਨੂੰ ਬਿਨਾਂ ਸ਼ਰਤ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

4. ਰਸਮੀ ਮੁਰੰਮਤ ਦੀ ਪ੍ਰਕਿਰਿਆ

4.1 ਬਾਹਰੀ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀਆਂ ਅਸਲ ਸਥਿਤੀਆਂ ਦੀ ਵਸਤੂ ਸੂਚੀ

ਘੱਟੋ-ਘੱਟ ਹਰੇਕ ਐਂਟਰੀ ਲਈ ਕੋਲੇਟ ਕਰੋ:

• ਡੋਮੇਨ ਨਾਮ, ਲੋਡ ਬੈਲੇਂਸਿੰਗ/CDN/ਐਜ ਪ੍ਰੌਕਸੀ ਲਿੰਕ, ਮੂਲ ਸਾਈਟ ਐਕਸਪੋਜ਼ਰ ਵਿਧੀ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤਿਆ ਗਿਆ।
• NGINX ਉਤਪਾਦ (ਓਪਨ ਸੋਰਸ, ਪਲੱਸ, ਇੰਗ੍ਰੇਸ, ਆਦਿ), ਪੂਰਾ ਸੰਸਕਰਣ, ਪੈਕੇਜ ਰਿਪੋਜ਼ਟਰੀ ਸਰੋਤ, ਚਿੱਤਰ ਡਾਇਜੈਸਟ।
• nginx -V ਬਿਲਡਿੰਗ ਮੋਡੀਊਲ ਅਤੇ ਕੰਪਾਈਲੇਸ਼ਨ ਪੈਰਾਮੀਟਰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ; ਕੀ ਇੱਥੇ njs, Lua, OpenResty, ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਗਤੀਸ਼ੀਲ ਮੋਡੀਊਲ ਹਨ।
• ਅਸਲ ਚੱਲ ਰਿਹਾ master/worker PID, ਸੇਵਾ ਯੂਨਿਟ/ਕੰਟੇਨਰ/Pod, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ Worker ਨੋਡ।
• ਅਸਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ http/stream, server, location, include ਸੰਰਚਨਾਵਾਂ।
• ਕੀ HTTP/3, mTLS, SSI/AIO, ਡਾਇਨਾਮਿਕ ਲੌਗ ਮਾਰਗ, ਗੁੰਝਲਦਾਰ map ਅਤੇ regex ਕੈਪਚਰ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਹੈ।

ਸਿਰਫ਼ ਡਿਫੌਲਟ /etc/nginx/nginx.conf ਦੀ ਜਾਂਚ ਨਾ ਕਰੋ। ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਅਕਸਰ include ਦੁਆਰਾ ਮਲਟੀਪਲ ਸਾਈਟਾਂ, TLS ਅਤੇ ਮੋਡੀਊਲ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ। ਕਈ NGINX ਇੰਸਟਾਲੇਸ਼ਨ ਮਾਰਗ ਜਾਂ ਮਲਟੀਪਲ ਪ੍ਰੌਕਸੀ ਲੇਅਰ ਵੀ ਹੋ ਸਕਦੇ ਹਨ।

4.2 ਸੰਸਕਰਣ ਅਤੇ ਸੰਕਲਨ ਜਾਣਕਾਰੀ ਦੀ ਜਾਂਚ ਕਰੋ

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V ਕਮਾਂਡ-ਲਾਈਨ ਮਾਰਗ ‘ਤੇ ਪਾਈ ਗਈ ਬਾਈਨਰੀ ਦੇ ਨਿਰਮਾਣ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਚੱਲ ਰਹੇ worker ਨੇ ਇਸਨੂੰ ਲੋਡ ਕੀਤਾ ਹੈ। nginx -v ਵੰਡ ਦੇ ਪੂਰੇ ਪੈਕੇਜ ਪਿਛੇਤਰ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਪੈਕੇਜ ਮੈਨੇਜਰ ਜਾਂ ਸਪਲਾਈ-ਚੇਨ ਰਿਕਾਰਡਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ।

4.3 ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਨੂੰ ਨਿਰਯਾਤ ਕਰੋ ਅਤੇ ਸਥਿਰ ਸਕ੍ਰੀਨਿੰਗ ਦਾ ਪਹਿਲਾ ਦੌਰ ਕਰੋ

nginx -T ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰੇਗਾ ਅਤੇ ਵਿਲੀਨ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਡੰਪ ਕਰੇਗਾ। ਆਉਟਪੁੱਟ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ ਜਿਵੇਂ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਮੁੱਖ ਮਾਰਗ, ਅੰਦਰੂਨੀ ਹੋਸਟ ਨਾਮ, ਆਦਿ। ਇਹ root ਅਨੁਮਤੀਆਂ ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਦੇ ਨਾਲ ਨਿਯੰਤਰਿਤ ਟਰਮੀਨਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅਸਲੀ ਫਾਈਲਾਂ ਨੂੰ ਜਨਤਕ ਕੰਮ ਦੇ ਆਦੇਸ਼ਾਂ ਵਿੱਚ ਪੋਸਟ ਨਾ ਕਰੋ:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

ਇਹ ਸਿਰਫ਼ ਉਮੀਦਵਾਰ ਮਾਰਗ ਲੋਕੇਟਰ ਹੈ, ਇੱਕ ਭਰੋਸੇਯੋਗ CVE ਆਟੋਮੈਟਿਕ ਨਿਰਧਾਰਨ ਟੂਲ ਨਹੀਂ ਹੈ:

1. grep ਇਹ ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਵੇਰੀਏਬਲ ਇੱਕੋ location ਵਿੱਚ ਸਥਿਤ ਹਨ ਜਾਂ ਇੱਕੋ ਬੇਨਤੀ ਮੁਲਾਂਕਣ ਚੇਨ ਵਿੱਚ ਹਨ, ਨਾ ਹੀ ਇਹ ਸੰਰਚਨਾ ਵਿਰਾਸਤ ਸਬੰਧਾਂ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।
2. proxy_request_buffering on, ਕੁਝ ਕੈਸ਼ ਅਤੇ ਟਿਕਟ ਸੰਰਚਨਾਵਾਂ ਦੇ ਡਿਫੌਲਟ ਮੁੱਲ ਹਨ, ਅਤੇ ਸੰਬੰਧਿਤ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਨਾ ਲਿਖਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਜੋਖਮ ਅਲੋਪ ਹੋ ਜਾਂਦਾ ਹੈ।
3. ਰਿਵਰਸ ਪ੍ਰੌਕਸੀਜ਼, CDN, ਕੰਟੇਨਰ ਸਾਈਡਕਾਰਸ, ਜਾਂ ਕੰਟਰੋਲਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਸੰਰਚਨਾਵਾਂ ਹੱਥੀਂ ਨਿਰੀਖਣ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਤੋਂ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
4. NGINX Plus ਅਤੇ ਡਾਇਨਾਮਿਕ ਮੋਡੀਊਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਸੰਬੰਧਿਤ ਅਧਿਕਾਰਤ ਪ੍ਰਬੰਧਨ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

4.4 ਭਰੋਸੇਮੰਦ ਚੈਨਲਾਂ ਰਾਹੀਂ ਫਿਕਸ ਨੂੰ ਲਾਗੂ ਕਰੋ

Debian/Ubuntu (ਅਧਿਕਾਰਤ ਵੰਡ ਭੰਡਾਰ):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

ਕਮਾਂਡਾਂ ਦਾ ਇਹ ਸੈੱਟ ਪਤਲੀ ਹਵਾ ਤੋਂ ਸੁਰੱਖਿਆ ਫਿਕਸ ਨਹੀਂ ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ ਅਜੇ ਉਪਲਬਧ ਨਹੀਂ ਹਨ। ਖਾਸ ਤੌਰ ‘ਤੇ Debian 12 ਲਈ, ਜੇਕਰ ਅੱਪਗਰੇਡ ਕੀਤੇ ਪੈਕੇਜ ਨੂੰ ਸੁਰੱਖਿਆ ਟਰੈਕਿੰਗ ਸਿਸਟਮ ਦੁਆਰਾ ਅਜੇ ਵੀ ਕਮਜ਼ੋਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਵਾਧੂ ਵਿਕਰੇਤਾ ਮੁਰੰਮਤ, ਅਲੱਗ-ਥਲੱਗ ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਉਪਾਅ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। S13S14S15

nginx.org ਅਧਿਕਾਰਤ ਪੈਕੇਜ:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

ਜੇਕਰ ਸਵੈ-ਕੰਪਾਈਲਡ, OpenResty, Tengine ਜਾਂ NGINX Plus ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸੰਬੰਧਿਤ ਮੇਨਟੇਨਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਫਿਕਸ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ nginx.org, ਵੰਡ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਰਿਪੋਜ਼ਟਰੀ ਪੈਕੇਜਾਂ ਨੂੰ ਨਾ ਮਿਲਾਓ। ਮੂਲ ਬਾਈਨਰੀ/ਚਿੱਤਰ, ਸੰਰਚਨਾ, ਦਸਤਖਤ, ਅਤੇ ਰੋਲਬੈਕ ਡਿਪਲਾਇਮੈਂਟ ਮੈਨੀਫੈਸਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕੰਟੇਨਰ/Kubernetes: ਅਟੱਲ ਚਿੱਤਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ, ਇਸ ਦਾ ਡਾਇਜੈਸਟ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਪੜਾਅਵਾਰ ਰੋਲਆਊਟ ਨਾਲ ਬਦਲੋ। kubectl rollout status ਸਿਰਫ਼ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਤੈਨਾਤੀ ਕੰਟਰੋਲਰ ਸਮਾਪਤ ਹੋ ਗਿਆ ਹੈ; ਚਿੱਤਰ ਪਾਚਨ, ਪ੍ਰਵੇਸ਼ ਰੂਟਿੰਗ ਅਤੇ ਗੈਰ-ਸਿਹਤਮੰਦ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ।

4.5 ਸੰਰਚਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਪੁਰਾਣੇ Worker ਨੂੰ ਬਦਲੋ

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

nginx -s reload ਨੂੰ ਸਬੂਤ ਵਜੋਂ ਨਾ ਮੰਨੋ ਕਿ ਇੱਕ ਨਵੀਂ ਬਾਈਨਰੀ ਚੱਲ ਰਹੀ ਹੈ: ਆਮ ਸੰਰਚਨਾ ਰੀਲੋਡ ਪੁਰਾਣੇ master ਨੂੰ ਇਸਦੇ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਨਵੇਂ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦਿੰਦੀ ਹੈ। NGINX ਇੱਕ ਸਮਰਪਿਤ ਔਨਲਾਈਨ ਬਾਈਨਰੀ ਅਪਗ੍ਰੇਡ ਪ੍ਰਕਿਰਿਆ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਲਈ ਵਾਧੂ ਕਦਮਾਂ ਅਤੇ ਪੁਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸਥਾਪਿਤ ਪ੍ਰਕਿਰਿਆ ਦੇ ਬਿਨਾਂ, ਇੱਕ ਉੱਚ-ਉਪਲਬਧ ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸੇਵਾ ਮੁੜ ਚਾਲੂ ਕਰੋ, ਜਾਂ ਬਦਲਣ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰੋ। S22

ਜੇਕਰ ਤੁਸੀਂ systemd ਸਾਕਟ, ਕੰਟੇਨਰ ਐਂਟਰੀ ਸਕ੍ਰਿਪਟ, ਜਾਂ ਮਲਟੀਪਲ ਸਥਾਪਨਾਵਾਂ ਰਾਹੀਂ NGINX ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਕਿ systemctl restart nginx ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਸਲ ਲਾਂਚ ਟੀਚੇ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

4.6 ਅਸਲ ਬਾਹਰੀ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਤੋਂ ਵਪਾਰਕ ਰਿਗਰੈਸ਼ਨ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ ਅਤੇ ਕਰੋ

ਇਹ ਘੱਟੋ ਘੱਟ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

• ਕੀ ਆਮ HTTPS, ਮੁੜ ਲਿਖੇ ਰੂਟ, ਸਥਿਰ ਸਰੋਤ, ਅਤੇ alias ਮੈਪਿੰਗ ਪੰਨੇ ਸਹੀ ਹਨ।
• ਕੀ ਨਿਯਮਤ map ਵੰਡ, ਵੇਰੀਏਬਲ root ਮਾਰਗ, ਪਹੁੰਚ ਲੌਗ ਮਾਰਗ, SNI/ਸਰਟੀਫਿਕੇਟ ਰੂਟਿੰਗ, ਅਤੇ Stream ਪ੍ਰੌਕਸੀ ਸਹੀ ਹਨ।
• ਕੀ ਆਮ ਅੱਪਲੋਡ, ਚੰਕਡ ਅੱਪਲੋਡ, API ਬੇਨਤੀਆਂ ਅਤੇ HTTP/3 (ਜਦੋਂ ਸਮਰਥਿਤ) ਲਈ ਅੱਪਸਟ੍ਰੀਮ ਵਾਲੀਅਮ ਸੀਮਾਵਾਂ ਅਜੇ ਵੀ ਉਮੀਦ ਅਨੁਸਾਰ ਹਨ।
• mTLS: ਜਾਇਜ਼ ਸਰਟੀਫਿਕੇਟ ਬੇਨਤੀਆਂ ਸਫਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ; ਗੁੰਮ, ਮਿਆਦ ਪੁੱਗ ਚੁੱਕੇ, ਜਾਂ ਅਣਅਧਿਕਾਰਤ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਅਜੇ ਵੀ ਅਸਵੀਕਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ TLS ਮੁੜ-ਚਾਲੂ/ਮੁੜ ਕੁਨੈਕਸ਼ਨ ਨੂੰ ਗਲਤੀ ਨਾਲ ਅਨੁਮਤੀਆਂ ਨੂੰ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਕੀ SSI ਪੰਨਾ ਅਤੇ ਅਸਿੰਕਰੋਨਸ ਫਾਈਲ ਐਕਸੈਸ ਆਮ ਹਨ; ਐਰਰ ਲੌਗ ਮੈਮੋਰੀ ਹਵਾਲਿਆਂ ਜਾਂ ਵਾਰ-ਵਾਰ Worker ਕਰੈਸ਼ਾਂ ਲਈ ਕੋਈ ਅਸਧਾਰਨ ਬੇਨਤੀਆਂ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਹੈ।
• ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਤੋਂ ਬਾਅਦ, ਪੁਰਾਣੀ ਸੰਸਕਰਣ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਪੁਰਾਣੀ ਚਿੱਤਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਟੈਸਟਿੰਗ ਆਪਣੇ ਜਾਂ ਅਧਿਕਾਰਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਧਾਰਣ ਬੇਨਤੀ ਸਮੋਕ ਟੈਸਟ ਇਕੱਲੇ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਕਮਜ਼ੋਰੀ ਨੂੰ ਠੀਕ ਕੀਤਾ ਗਿਆ ਹੈ; ਅੰਤ ਵਿੱਚ, ਸਪਲਾਇਰ ਦਾ ਨਿਸ਼ਚਿਤ ਸੰਸਕਰਣ, ਸਰੋਤ ਕੋਡ ਪੈਚ ਅਤੇ ਰਨਟਾਈਮ ਟੈਸਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਸਾਂਝੇ ਤੌਰ ‘ਤੇ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

5. ਜਦੋਂ ਤੁਰੰਤ ਅੱਪਗਰੇਡ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਘਟਾਉਣ ਦੇ ਉਪਾਅ

ਇਹ ਭਾਗ ਇੱਕ ਜੋਖਮ ਘਟਾਉਣ ਦਾ ਵਿਕਲਪ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਪੈਚ ਬਦਲਣਾ। ਸਾਰੀਆਂ ਅਸਥਾਈ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਦਾ ਬੈਕਅੱਪ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, nginx -t ਨੂੰ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਬੈਚਾਂ ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੁਰੰਤ ਵਾਪਸ ਰੋਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। S3S4

5.1 ਬਾਹਰੀ ਐਕਸਪੋਜ਼ਰ ਦੇ ਆਧਾਰ ‘ਤੇ ਟ੍ਰੈਫਿਕ ਤਰਜੀਹ ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ

ਸੇਵਾਵਾਂ ਦੇ ਹਮਲੇ ਦੀ ਸਤਹ ਨੂੰ ਘਟਾਉਣ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਸਮੇਂ ਵਿੱਚ ਅੱਪਗਰੇਡ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ: ਪ੍ਰਬੰਧਨ ਸਤਹ ਅਤੇ ਅੰਦਰੂਨੀ API ‘ਤੇ ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ, ਅੱਪਸਟ੍ਰੀਮ ਨੈੱਟਵਰਕ ਆਈਸੋਲੇਸ਼ਨ ਜਾਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਔਫਲਾਈਨ ਸ਼ਾਮਲ ਕਰੋ; ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰਾਂ ਲਈ ਕੁਨੈਕਸ਼ਨ ਜੋੜੋ, ਬਾਡੀ ਦੀ ਬੇਨਤੀ ਕਰੋ ਅਤੇ ਦਰ ਸੀਮਾਵਾਂ; ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਸਰੋਤ ਪ੍ਰਮਾਣਿਕਤਾ ਬੇਨਤੀ ਪ੍ਰੋਸੈਸਿੰਗ ਚੇਨ ਤੋਂ ਪਹਿਲਾਂ ਐਂਟਰੀ-ਸਬੰਧਤ NGINX ‘ਤੇ ਹੁੰਦੀ ਹੈ। ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਕਮਜ਼ੋਰੀਆਂ ਖੁਦ NGINX ਡਾਟਾ ਪਲੇਨ ਦੇ ਅੰਦਰ ਸਥਿਤ ਹਨ, ਰਵਾਇਤੀ WAF ਨਿਯਮ ਕਸਟਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਟਰਿੱਗਰ ਸਥਿਤੀਆਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ।

5.2 alias / rewrite: ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਾਅਦ $request_filename ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਬਚੋ

ਇਹ ਜਾਂਚ ਅਤੇ ਅਨੁਕੂਲ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

• rewrite ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ ਜੋ URI ਨੂੰ alias ਵਰਤਦੇ ਹੋਏ location ਦੇ ਰੂਪ ਵਿੱਚ ਬਦਲ ਦੇਵੇਗਾ।
• $request_filename ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਚੋ ਜਦੋਂ URI ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ ਪਰ ਸਹੀ ਸਥਿਤੀ ਦਾ ਮੇਲ ਅਜੇ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ ਹੈ।
• return, set, if, add_header, ਐਕਸੈਸ ਲੌਗ ਫਾਰਮੈਟ ਵਿੱਚ ਅਸਿੱਧੇ ਵੇਰੀਏਬਲ ਹਵਾਲਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਫਾਈਲਾਂ ਸ਼ਾਮਲ ਕਰੋ।
• ਕਾਰੋਬਾਰ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ‘ਤੇ ਸਪੱਸ਼ਟ root/try_files/ਸੁਤੰਤਰ location ਦੀ ਵਰਤੋਂ ਕਰੋ, ਪਰ ਸਿਰਫ਼ alias ਨੂੰ root ਵਿੱਚ ਬਦਲੋ। ਇਹ ਫਾਈਲ ਪਾਥ ਦੇ ਅਰਥ ਵਿਗਿਆਨ ਨੂੰ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ, ਜਿਸਦੀ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਮੌਜੂਦਾ ਸੰਰਚਨਾ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਲਈ ਇੰਟਰਨੈਟ ‘ਤੇ ਆਮ “ਸੁਰੱਖਿਅਤ ਰੀਰਾਈਟ ਟੈਂਪਲੇਟ” ਦੀ ਸਿੱਧੀ ਨਕਲ ਨਾ ਕਰੋ। ਵੱਖ-ਵੱਖ location ਅਗੇਤਰ ਅਤੇ ਮੁੜ-ਲਿਖਣ ਟੀਚਿਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਅਰਥਾਂ ਦੇ ਨਾਲ ਪਾਥ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। S5

5.3 map/Regex: ਕੈਪਚਰ ਵੇਰੀਏਬਲ ਸਟੇਟ ਮਿਕਸਿੰਗ ਨੂੰ ਘਟਾਓ

$1 ਵਰਗੇ ਅਗਿਆਤ ਕੈਪਚਰਾਂ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਰੀਜੈਕਸ ਮੁਲਾਂਕਣ ਮਾਰਗਾਂ ਵਿੱਚ ਮੁੜ-ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਦੀ ਬਜਾਏ, ਨਾਮਿਤ ਕੈਪਚਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਅਤੇ ਉਹਨਾਂ ਦੇ ਪ੍ਰਸਾਰ ਦੇ ਦਾਇਰੇ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

ਇਹ ਸਨਿੱਪਟ ਸਿਰਫ ਪਰਿਵਰਤਨਸ਼ੀਲ ਮਾਲਕੀ ਦੀ ਇੱਕ ਆਸਾਨ-ਤੋਂ-ਆਡਿਟ ਬਣਤਰ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ; ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਸਾਰੇ CVE-2026-93479 ਟਰਿੱਗਰ ਮਾਰਗਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਸਾਬਤ ਹੋਇਆ ਹੈ। ਖਾਸ ਤੌਰ ‘ਤੇ, ਸਮੀਖਿਆ ਕਰੋ ਕਿ ਕੀ ਕੈਪਚਰ ਵੇਰੀਏਬਲਾਂ ਦਾ ਹੋਰ root ਜਾਂ log_format ਦੁਆਰਾ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਕੀ volatile, ਗਤੀਸ਼ੀਲ ਮਾਰਗ, ਅਤੇ ਅੰਤਰ-ਨਿਰਭਰ ਮੁਲਾਂਕਣ ਚੇਨਾਂ ਹਨ। F5/CERT ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਰਾਹਤ ਵਜੋਂ ਨਾਮਿਤ ਕੈਪਚਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਵਰਤੋਂ ਦੇ ਦਾਇਰੇ ਨੂੰ ਸੰਬੰਧਿਤ ਨਿਯਮਤ ਮਿਲਾਨ ਸੰਰਚਨਾ ਤੱਕ ਸੀਮਤ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ। S3S6

5.4 AIO + SSI: ਬੇਲੋੜੇ ਫੰਕਸ਼ਨ ਸੰਜੋਗਾਂ ਨੂੰ ਬੰਦ ਕਰੋ

ਸਰਵਰਾਂ/ਪਾਥਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ SSI ਜਾਂ ਅਸਿੰਕਰੋਨਸ ਫਾਈਲ I/O ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਵਰਤੋਂ:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

ਕਮਜ਼ੋਰੀ ਨੂੰ ਟਰਿੱਗਰ ਕਰਨ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਬੰਦ ਕਰਨਾ ਆਮ ਤੌਰ ‘ਤੇ ਵਰਣਿਤ ਖਾਸ ਚੇਨ ਨੂੰ ਹਟਾਉਣ ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ; ਉਸੇ ਸਮੇਂ ਬੰਦ ਹੋਣਾ ਸਿਰਫ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ‘ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਕਾਰੋਬਾਰ ਇਸ ਸਮਰੱਥਾ ‘ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਹੈ। include virtual, subrequests, ਕੈਸ਼, ਅਤੇ ਥਰਿੱਡ ਪੂਲ ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰੋ; ਜਦੋਂ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਲੋਡ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ AIO ਨੂੰ ਬੰਦ ਕਰਨ ਨਾਲ ਲੇਟੈਂਸੀ ਅਤੇ I/O ਪ੍ਰਦਰਸ਼ਨ ਬਦਲ ਸਕਦਾ ਹੈ। S7

5.5 HTTP/3 ਸਰੀਰ ਦੇ ਟੀਕੇ ਦੀ ਬੇਨਤੀ ਕਰੋ: ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਅਸਥਾਈ ਤੌਰ ‘ਤੇ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਬੰਦ ਕਰੋ

ਨੂੰ ਅਯੋਗ ਕਰੋ quic ਸ਼ਾਮਲ ਸੁਣਨ ਵਾਲਾ HTTP/3 , ਰੱਦ ਕਰੋ Alt-Svc ਜਵਾਬ ਸਿਰਲੇਖ ਜੋ ਘੋਸ਼ਣਾ ਕਰਦਾ ਹੈ HTTP/3 , ਅਤੇ ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਕਿਨਾਰੇ ਦੀ ਪਰਤ/ਲੋਡ ਬੈਲੇਂਸਰ ਅਜੇ ਵੀ ਭੇਜਦਾ ਹੈ QUIC ਬਿਨਾਂ ਮੁਰੰਮਤ ਲਈ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਬੇਨਤੀਆਂ NGINX :

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

ਉਪਰੋਕਤ ਸਿਰਫ ਪਰਿਵਰਤਨ ਅੰਤਰ ਦਾ ਵਰਣਨ ਹੈ, ਇੱਕ ਪੂਰੀ ਸਰਵਰ ਸੰਰਚਨਾ ਨਹੀਂ ਜੋ ਵਿਅਕਤੀਗਤ ਤੌਰ ‘ਤੇ ਸਮਰੱਥ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। HTTP/2 ਦਾ ਸੈਟਿੰਗ ਸੰਟੈਕਸ NGINX ਸੰਸਕਰਣ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ; ਜੇਕਰ ਤੁਹਾਨੂੰ HTTP/2 ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਸੰਸਕਰਣ ਦੇ ਅਨੁਸਾਰ http2 on; ਜਾਂ ਮੌਜੂਦਾ ਵੈਧ ਸੰਟੈਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ nginx -t ਨਾਲ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਸਰਵਰ ਸੰਰਚਨਾ ਨਾਲ ਮਿਲਾ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪੂਰੇ ਭਾਗ ਨੂੰ ਇਸ ਭਾਗ ਨਾਲ ਬਦਲਣ ਦੀ ਬਜਾਏ। UDP 443 ਫਾਇਰਵਾਲ, HTTP/3 ਸਮਾਪਤੀ ਸਥਾਨ ਅਤੇ CDN/ਫਰੰਟ ਪ੍ਰੌਕਸੀ ਦੇ ਕਲਾਇੰਟ ਫਾਲਬੈਕ ਮਾਰਗ ਦੀ ਵੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਕਿਸਮ ਦੀ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀ ਕਮੀ ਪ੍ਰਭਾਵਿਤ ਪ੍ਰੌਕਸੀ ਮਾਰਗ ‘ਤੇ proxy_request_buffering off; ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ, ਪਰ ਇਹ ਅਪਸਟ੍ਰੀਮ ਬੇਨਤੀ ਬਾਡੀ ਸਟ੍ਰੀਮਿੰਗ, ਅਸਫਲ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਤੇ ਕੁਝ ਅਪਲੋਡ ਵਰਕਫਲੋਜ਼ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲ ਦੇਵੇਗਾ; ਸਿਰਫ਼ ਲੋੜੀਂਦੀ ਜਾਂਚ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਨਿਰਦੇਸ਼ ਪ੍ਰਭਾਵਿਤ HTTP/3 ਪ੍ਰੌਕਸੀ ਮਾਰਗ ਨੂੰ ਮਾਰਦਾ ਹੈ। S8S18

5.6 TLS ਸੈਸ਼ਨ ਟਿਕਟ: ਤਰਜੀਹ ਸੁਰੱਖਿਆ mTLS ਪ੍ਰਮਾਣੀਕਰਨ ਸੀਮਾ

ਜੇਕਰ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ ਅਤੇ ਉਦਾਹਰਨ ਸ਼ੇਅਰਡ ਸੈਸ਼ਨ ਕੈਸ਼ + ਆਟੋਮੈਟਿਕ ਟਿਕਟ ਕੁੰਜੀ ਰੋਟੇਸ਼ਨ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਮੁਲਾਂਕਣ ਕਰੋ:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

ਇਹ TLS ਸੈਸ਼ਨ ਟਿਕਟ ਵਿਧੀ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਇਸ ਕਮਜ਼ੋਰੀ ਵਿੱਚ ਦੱਸੇ ਗਏ ਟਿਕਟ ਜਾਅਲੀ ਮਾਰਗ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਹਾਲਾਂਕਿ, ਇਹ ਸੈਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ “ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਣ” ਲਈ ਸਿਰਫ਼ mTLS ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਤਸਦੀਕ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਇਹ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਅਸਲ ਪ੍ਰਮਾਣਿਕਤਾ ਸੀਮਾ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ। S9S12

ਸਪੱਸ਼ਟ ssl_session_ticket_key ਫਾਈਲਾਂ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਟੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਪੇਸ਼ੇਵਰ TLS ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੁਆਰਾ ਸਵੈ-ਤਿਆਰ ਸਥਿਤੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਵੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਮੁੱਖ ਹਿਰਾਸਤ, ਪੂਰੇ ਨੋਡ ਦੀ ਵੰਡ, ਰੋਟੇਸ਼ਨ, ਅਤੇ ਪੁਰਾਣੇ ਟਿਕਟ ਲਾਈਫਸਾਈਕਲ ਸਭ ਨੂੰ ਧਿਆਨ ਨਾਲ ਆਡਿਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਸਧਾਰਣ ਵੈੱਬ ਕੌਂਫਿਗਰੇਸ਼ਨ ਜਾਂ ਅਸਥਾਈ ਐਮਰਜੈਂਸੀ ਲਈ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਲਈ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਕੁੰਜੀ ਨੂੰ ਹਾਰਡਕੋਡ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। mTLS ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਨਾਜ਼ੁਕ ਸੇਵਾਵਾਂ ਨੂੰ TLS ਸੈਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਵਿਵਹਾਰ ਅਤੇ ਇੱਕ ਵੈਧ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨ ਲਈ ਵੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। S12

5.7 ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਬਾਰਡਰ ਸੁਰੱਖਿਆ ਦੀ ਭੂਮਿਕਾ

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, ਗੈਰ-root ਵਰਕਰ, ਸਿਰਫ-ਪੜ੍ਹਨ ਲਈ ਕੰਟੇਨਰ ਫਾਈਲਸਿਸਟਮ, ਘੱਟੋ-ਘੱਟ ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਅਤੇ ਨੈੱਟਵਰਕ ਆਈਸੋਲੇਸ਼ਨ ਸੰਭਾਵੀ RCE ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ। ASLR ਹੀਪ ਓਵਰਫਲੋ ਜਾਂ UAF ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਕਰਮਚਾਰੀ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੋਣਗੇ। WAF, ਦਰ ਸੀਮਾਵਾਂ ਅਤੇ ਬੇਨਤੀ ਬਾਡੀ ਆਕਾਰ ਦੀਆਂ ਸੀਮਾਵਾਂ TLS ਟਿਕਟ ਕੁੰਜੀ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀਆਂ ਹਨ। S4

5.8 ਆਮ ਗਲਤਫਹਿਮੀ: ਇਹ ਓਪਰੇਸ਼ਨ ਮੁਰੰਮਤ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕਾਫੀ ਨਹੀਂ ਹਨ

ਆਮ ਓਪਰੇਸ਼ਨ	ਇਹ ਨਾਕਾਫ਼ੀ ਕਿਉਂ ਹੈ?
“nginx -v ਮੁਕਾਬਲਤਨ ਨਵਾਂ ਲੱਗਦਾ ਹੈ”	ਜਿਸ ਬ੍ਰਾਂਚ ਨਾਲ ਇਹ ਸੰਬੰਧਿਤ ਹੈ, ਰੀਲੀਜ਼ ਸੰਸਕਰਣ ਦਾ ਪੂਰਾ ਬੈਕਪੋਰਟ ਪੈਕੇਜ ਸੰਸਕਰਣ ਅਤੇ ਔਨਲਾਈਨ ਪ੍ਰਕਿਰਿਆ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ।
“ਸਿਰਫ਼ ਇੱਕ ਇੰਟਰਾਨੈੱਟ ਅੱਪਗਰੇਡ ਕੀਤਾ ਗਿਆ ਸੀ”	ਪੁਰਾਣਾ Worker/ਪੁਰਾਣਾ ਕੰਟੇਨਰ/ਪੁਰਾਣਾ CDN ਮੂਲ ਉਦਾਹਰਨ ਅਜੇ ਵੀ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ
”ਸਾਈਟ PHP/ਡਾਇਨਾਮਿਕ ਟੈਗਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀ”	ਨੁਕਸ NGINX ਕੋਰ ਪਾਥ ਜਾਂ ਪ੍ਰੋਟੋਕੋਲ ਪਾਰਸਿੰਗ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਅਤੇ PHP ਐਗਜ਼ੀਕਿਊਸ਼ਨ ‘ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਹੈ।
“WAF/Cloudflare ਖੋਲ੍ਹਣਾ ਕਾਫ਼ੀ ਹੈ”	WAF ਸਾਰੀਆਂ NGINX ਸੰਰਚਨਾ-ਨਿਰਭਰ ਮੈਮੋਰੀ ਖਾਮੀਆਂ ਜਾਂ TLS ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀਆਂ ਖਾਮੀਆਂ ਨੂੰ ਬਲੌਕ ਕਰਨ ਲਈ ਸਾਬਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
“ASLR ਪਹਿਲਾਂ ਹੀ ਖੋਲ੍ਹਿਆ ਹੋਇਆ ਹੈ”	ਸਿਰਫ਼ ਮੁਸ਼ਕਲ ਘਟਾਉਣ ਦਾ ਫਾਇਦਾ ਉਠਾਉਣਾ; ਬੇਨਤੀ ਟੀਕੇ ਦੇ ਨਾਲ DoS ਅਜੇ ਵੀ ਸੰਭਵ ਹੈ
”HTTP/3 ਜਨਤਕ ਨੈੱਟਵਰਕ ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਬਿਲਕੁਲ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ”	ਬਾਕੀ ਚਾਰ CVE ਨੂੰ ਅਜੇ ਵੀ ਸੁਤੰਤਰ ਮੁਲਾਂਕਣ ਦੀ ਲੋੜ ਹੈ; ਅਤੇ ਲੁਕਵੇਂ ਮੂਲ ਨਾਲ ਸਿੱਧੇ ਸਬੰਧ ਹੋ ਸਕਦੇ ਹਨ
”ਜੁਲਾਈ ਦੀ map ਕਮਜ਼ੋਰੀ ਨੂੰ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ”	ਅਕਤੂਬਰ CVE-2026-93479 ਵਿੱਚ ਅਗਲੇ ਸਕ੍ਰਿਪਟ ਮੁਲਾਂਕਣ ਰਿਗਰੈਸ਼ਨ ਮੁੱਦੇ ਸ਼ਾਮਲ ਹਨ
”ਕੈਸ਼ਿੰਗ ਨੂੰ ਅਯੋਗ ਕਰਨ ਨਾਲ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ”	ਸਿਰਫ਼ ਕੁਝ TLS ਕੈਸ਼ ਜਾਂ AIO ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਪਨਾਮ, ਸਕ੍ਰਿਪਟ, HTTP/3 ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ ਹੈ

6. ਅਧਿਕਾਰਤ ਪੈਚ ਲਾਗੂ ਕਰਨ ਦੇ ਵਿਚਾਰ ਅਤੇ ਸਮੀਖਿਆ ਪੁਆਇੰਟ

ਇਹ ਸੈਕਸ਼ਨ ਅਕਤੂਬਰ 2026 ਦੇ ਅੱਪਸਟ੍ਰੀਮ NGINX ਫਿਕਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਸਨਿੱਪਟ ਪੈਚ ਸਮੀਖਿਆ ਲਈ ਪ੍ਰਤੀਨਿਧੀ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ; ਉਹ ਸੰਪੂਰਨ ਨਹੀਂ ਹਨ, ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਫਿਕਸ ਹਨ। ਕਸਟਮ ਬਿਲਡਾਂ ਲਈ, ਪੂਰੀ ਕਮਿਟਾਂ, ਆਲੇ ਦੁਆਲੇ ਦੇ ਕੋਡ ਅਤੇ ਟੈਸਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਇੱਕ ਪੂਰੀ ਸਮਰਥਿਤ ਰੀਲੀਜ਼ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। S5S6S7S8S9

6.1 CVE-2026-15176: URI ਨੂੰ alias ਮਾਰਗ ਮੈਪਿੰਗ ਅਸਵੀਕਾਰ ਸ਼ਰਤਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ

ਅੱਪਸਟ੍ਰੀਮ ਕਮਿਟ ਨੇ src/http/ngx_http_core_module.c ਵਿੱਚ ngx_http_map_uri_to_path() ਨੂੰ ਸੋਧਿਆ:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

ਸਮੀਖਿਆ ਫੋਕਸ: ਜਦੋਂ URI ਬਦਲ ਗਿਆ ਹੈ ਤਾਂ ਫਾਈਲ ਸਿਸਟਮ ਮਾਰਗ ਦੀ ਗਣਨਾ ਕਰਨਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪਰ alias ਦੇ ਅਨੁਸਾਰੀ ਟਿਕਾਣਾ ਅਰਥ ਵਿਗਿਆਨ ਹੁਣ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹਨ। ਇਹ ਪੂਰਵ-ਰਾਜ ਦੀ ਰੁਕਾਵਟ ਲਈ ਇੱਕ ਸੁਧਾਰ ਹੈ। ਇਹ ਕੋਈ ਸਧਾਰਨ ਜਾਂਚ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਬੇਨਤੀ URI ਵਿੱਚ ਗੈਰ-ਕਾਨੂੰਨੀ ਅੱਖਰ ਹਨ। S5

6.2 CVE-2026-93479: ਆਉਟਪੁੱਟ ਡੇਟਾ ਦੀ ਲੰਬਾਈ ਅਤੇ ਰਾਖਵੀਂ ਲੰਬਾਈ ਵਿਚਕਾਰ ਸਹੀ ਫਰਕ ਕਰੋ

ਅੱਪਸਟ੍ਰੀਮ ਕਮਿਟ ਇੱਕੋ ਸਮੇਂ src/http/ngx_http_script.c ਅਤੇ src/stream/ngx_stream_script.c ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਮੁੱਖ ਇਰਾਦੇ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੰਖੇਪ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

ਇੱਥੇ, pool ਇੱਕ ਵਿਆਖਿਆਤਮਕ ਪੈਰਾਮੀਟਰ ਨਾਮ ਹੈ: ਅਸਲ HTTP ਅਤੇ Stream ਵੰਡ ਸਮੀਕਰਨ ਵੱਖਰੇ ਹਨ। ਪਰਿਵਰਤਨ ਪਹਿਲਾਂ ਸਕ੍ਰਿਪਟ ਆਉਟਪੁੱਟ ਲੰਬਾਈ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਫਿਰ ਅੰਤਮ ਵੰਡ ਵਿੱਚ ਰਾਖਵੀਂ ਲੰਬਾਈ ਜੋੜਦਾ ਹੈ ਤਾਂ ਕਿ ਆਉਟਪੁੱਟ ਰਾਖਵੀਂ ਥਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰੇ। S6

ਆਡਿਟਿੰਗ ਅਤੇ ਬੈਕਪੋਰਟਿੰਗ ਕਰਦੇ ਸਮੇਂ, HTTP/Stream ਦੇ ਅਨੁਸਾਰੀ ਮੁਲਾਂਕਣਕਰਤਾ ਨੂੰ ਵੀ ਕਵਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਸਿਰਫ਼ map ਦੀ ਸੰਰਚਨਾ ਸੰਟੈਕਸ ਫਾਈਲ ਦੀ ਜਾਂਚ ਕਰਨ ਨਾਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਨੁਕਸ ਠੀਕ ਹੋ ਗਿਆ ਹੈ।

6.3 CVE-2026-97205: 8-ਬਿੱਟ ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ ਗਿਣਤੀ ਲਈ ਸੁਰੱਖਿਆ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੈੱਟ ਕਰੋ

src/http/ngx_http_request.h ‘ਤੇ ਅੱਪਸਟ੍ਰੀਮ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ:

#define NGX_HTTP_MAX_BLOCKED 250

ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਫਾਈਲ ਰੀਡਿੰਗ, ਕੈਚ ਵੇਟਿੰਗ, ਆਉਟਪੁੱਟ ਫਿਲਟਰਿੰਗ ਅਤੇ ਥ੍ਰੈਡ ਓਪਰੇਸ਼ਨ ਲਈ ਸਮਾਨ ਐਂਟਰੀਆਂ ਸ਼ਾਮਲ ਕਰੋ:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

ਸਮੀਖਿਆ ਫੋਕਸ: r->main->blocked ਨੂੰ ਜੋੜਨ ਵਾਲੇ ਸਾਰੇ ਅਸਲ ਕੋਡ ਮਾਰਗਾਂ ਨੂੰ ਕਵਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਸਿਰਲੇਖ ਫਾਈਲ ਵਿੱਚ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸਥਿਰ ਨਹੀਂ ਲਿਖ ਸਕਦੇ ਹੋ। ਬੈਕਪੋਰਟ ਨੂੰ ਸਮਕਾਲੀ ਫਾਲਬੈਕ, ਅਸਿੰਕਰੋਨਸ ਕਾਲਬੈਕ ਅਤੇ ਗਲਤੀ ਵਾਪਸੀ ਦੇ ਸੰਪੂਰਨ ਤਾਲਮੇਲ ਦੀ ਵੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਕਾਰਜਾਂ ਦੇ ਸਿੱਧੇ ਅਸਵੀਕਾਰ ਕਰਕੇ ਡੈੱਡਲਾਕ ਜਾਂ ਸੰਦਰਭ ਲੀਕੇਜ ਨਹੀਂ ਹੋਵੇਗਾ। S7

6.4 CVE-2026-95101: ਅਣਜਾਣ ਫਰੇਮਾਂ ਲਈ ਵੱਖਰੇ ਤੌਰ ‘ਤੇ skip ਸਥਿਤੀ ਬਣਾਈ ਰੱਖੋ

ਅੱਪਸਟ੍ਰੀਮ HTTP/3 ਪਾਰਸਰ ਸਥਿਤੀ ਢਾਂਚੇ ਵਿੱਚ skip ਫੀਲਡ ਨੂੰ ਜੋੜਦਾ ਹੈ ਅਤੇ ਸਥਿਤੀ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

ਕੁੰਜੀ “ਅਣਜਾਣ HTTP/3 ਫਰੇਮਾਂ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣਾ” ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਮਲਟੀਪਲ ਰੀਡਾਂ ਵਿੱਚ, ਛੱਡੀ ਗਈ ਬਾਈਟ ਗਿਣਤੀ ਅਤੇ DATA ਪੇਲੋਡ ਲੰਬਾਈ ਹਮੇਸ਼ਾ ਸੁਤੰਤਰ ਰਾਜਾਂ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਅਗਿਆਤ ਫ੍ਰੇਮ ਕਰਾਸ-ਬਫਰ ਸ਼ਾਰਡਿੰਗ, ਅਤੇ client_max_body_size ਦੀ ਅੰਤਮ ਇਕਸਾਰਤਾ ‘ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। S8

6.5 CVE-2026-97629: ਪੂਰੀ TLS ਕੁੰਜੀ ਸਲਾਟ ਐਰੇ ਨੂੰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰੋ

ਅੱਪਸਟਰੀਮ ਬਦਲਾਅ src/event/ngx_event_openssl.c ‘ਤੇ ਸਥਿਤ ਹਨ:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

ਅਸਲੀ ਚਿੱਤਰ ਵਿੱਚ ਤਿੰਨ ਮੁੱਖ ਸਲਾਟ ਸਨ, ਪਰ ਸਿਰਫ਼ ਪਹਿਲੇ ਦੋ ਨਕਲ ਕੀਤੇ ਗਏ ਸਨ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ Worker ਦਾ ਵੋਟਿੰਗ ਕੁੰਜੀ ਸੈਟ ਸਾਂਝੀ ਕੀਤੀ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਇਕਸਾਰ ਹੈ, ਐਰੇ ਤੱਤਾਂ ਦੀ ਅਸਲ ਸੰਖਿਆ ਦੇ ਆਧਾਰ ‘ਤੇ ਸਮਕਾਲੀਕਰਨ ਕਰੋ। ਸਮੀਖਿਆ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇੱਕ ਵਾਰ memcpy ਲੰਬਾਈ ਸੋਧ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਬਜਾਏ, ਐਰੇ ਅਲੋਕੇਸ਼ਨ, ਸ਼ੁਰੂਆਤੀਕਰਣ, ਸਾਂਝਾ ਲਾਕ ਅਤੇ ਰੋਟੇਸ਼ਨ ਤਰਕ ਇਕਸਾਰ ਹਨ। S9

6.6 ਸਿਰਫ ਖਿੰਡੇ ਹੋਏ ਪੈਚ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ?

ਇਹ ਪੰਜ ਸੋਧਾਂ ਕ੍ਰਮਵਾਰ src/http, src/stream, src/http/v3, ਅਤੇ src/event ਤੱਕ ਫੈਲੀਆਂ ਹਨ, ਅਤੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਬੈਕਪੋਰਟ ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਐਕਸਟੈਂਸ਼ਨ ਹੋ ਸਕਦੇ ਹਨ। ਬੈਕਪੋਰਟਿੰਗ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਚੈੱਕ ਮੈਟ੍ਰਿਕਸ ਬਣਾਉਣੇ ਚਾਹੀਦੇ ਹਨ:

ਵਸਤੂ ਦੀ ਜਾਂਚ ਕਰੋ	ਕੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ
ਪੈਚ ਸਰੋਤ	ਅਧਿਕਾਰਤ ਸਪੁਰਦਗੀ, ਮੇਲ ਖਾਂਦਾ ਟੀਚਾ ਸੰਸਕਰਣ, ਪੂਰਾ ਪੈਚ ਅਤੇ ਦਸਤਖਤ ਤਸਦੀਕ
ਮੂਲ ਪੈਚ ਸੈੱਟ	ਇਤਿਹਾਸਕ ਸੋਧਾਂ ਜਿਵੇਂ ਕਿ CVE-2026-42533, ਵੰਡ ਬੈਕਪੋਰਟ, ਆਦਿ ਨਾਲ ਟਕਰਾਅ ਨਹੀਂ ਕਰਦਾ।
ਕੋਡ ਮਾਰਗ	HTTP + Stream ਸਕ੍ਰਿਪਟ, AIO/ਥ੍ਰੈੱਡ, HTTP/3, OpenSSL ਟਿਕਟ ਸਾਰੇ ਕਵਰ ਕੀਤੇ ਗਏ ਹਨ
ਕੰਪਾਇਲ ਕੀਤਾ ਅਨੁਕੂਲ	OpenSSL, PCRE, ਮੋਡੀਊਲ ABI, ਡਾਇਨਾਮਿਕ ਮੋਡੀਊਲ ਅਤੇ ਲਿੰਕ ਨਿਰਭਰਤਾ ਇਕਸਾਰ ਹਨ
ਫੰਕਸ਼ਨਲ ਰਿਗਰੈਸ਼ਨ	alias ਰੀਰਾਈਟ, ਡਾਇਨਾਮਿਕ ਲੌਗ, SSI/AIO, HTTP/3 ਅੱਪਲੋਡ, mTLS ਸੈਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ
ਰਨਟਾਈਮ	ਸਾਰੇ Worker/Pods ਨਵੇਂ ਪ੍ਰਮਾਣਿਤ ਬਿਲਡ ਚਲਾਉਂਦੇ ਹਨ, ਕੋਈ ਵੀ ਵਿਰਾਸਤੀ ਚਿੱਤਰ ਨਹੀਂ ਰਹਿੰਦੇ

ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜੋ ਆਪਣੀਆਂ ਖੁਦ ਦੀਆਂ ਰੀਲੀਜ਼ਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਦੀਆਂ ਹਨ, ਹਰੇਕ CVE ਲਈ ਆਡਿਟ ਕਰਨ ਯੋਗ ਪੈਚ ਆਈਡੀ, ਪੈਕੇਜ ਸੰਸਕਰਣ, ਬਿਲਡ ਲੌਗ ਅਤੇ ਰਿਗਰੈਸ਼ਨ ਰਿਪੋਰਟਾਂ ਰੱਖਣ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਸਧਾਰਣ ਸੰਚਾਲਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ, ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੱਲ ਵਿਕਰੇਤਾ ਦੇ ਸੰਪੂਰਨ ਸੁਰੱਖਿਆ ਅਪਡੇਟਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ ਹੈ।

7. ਇਤਿਹਾਸਕ ਕਮਜ਼ੋਰੀ ਬੈਕਟ੍ਰੈਕਿੰਗ, ਪੁਰਾਣੀਆਂ ਸ਼ਾਖਾਵਾਂ ਅਤੇ ਹੋਰ ਉਤਪਾਦ

7.1 NGINX ਕੋਰ ਕਮਜ਼ੋਰੀ ਮਈ ਤੋਂ ਸਤੰਬਰ 2026 ਤੱਕ ਇੱਕੋ ਸਮੇਂ ਦੀ ਪੁਸ਼ਟੀ ਦੇ ਯੋਗ ਹੈ

ਬਹੁਤ ਸਾਰੇ NGINX ਉਦਾਹਰਨਾਂ ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਨਾ ਸਿਰਫ਼ ਅਕਤੂਬਰ ਵਿੱਚ ਨਵੇਂ ਮੁੱਦੇ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹਨ। ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰਤੀਨਿਧੀ ਮੁਰੰਮਤ ਨੋਡ ਹਨ: S1S2

ਸੀ.ਵੀ.ਈ	ਪਹਿਲਾਂ ਫਿਕਸ ਰੀਲੀਜ਼	ਮੁੱਖ ਜੋਖਮ ਅਤੇ ਸ਼ਰਤਾਂ ਜਿਨ੍ਹਾਂ ਲਈ ਆਡਿਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 ਮਈ	rewrite ਅਗਿਆਤ ਰੇਜੈਕਸ ਕੈਪਚਰ ਅਤੇ ਰਿਪਲੇਸਮੈਂਟ ਤਰਕ ਹੀਪ ਓਵਰਫਲੋ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਸੰਭਾਵੀ RCE; ਜੰਗਲੀ ਹਮਲੇ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀਆਂ ਜਨਤਕ ਰਿਪੋਰਟਾਂ ਹਨ
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 ਮਈ	rewrite ਵਿੱਚ ਓਵਰਲੈਪਿੰਗ ਰੇਜੈਕਸ ਕੈਪਚਰ ਅਤੇ ਲੰਬਾਈ ਦਾ ਅਨੁਮਾਨ ਓਵਰਫਲੋ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 ਜੂਨ	HTTP/2 ਅੱਪਸਟ੍ਰੀਮ ਜਾਂ gRPC ਲਈ ਖਾਸ ਸੰਰਚਨਾ, ਵੱਡੀ ਬੇਨਤੀ ਹੈਡਰ ਸਥਿਤੀ ਬਫਰ ਓਵਰਫਲੋ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ
CVE-2026-42530	Mainline 1.31.2, 17 ਜੂਨ	HTTP/3 ਵਰਤੋਂ-ਬਾਅਦ-ਮੁਫ਼ਤ; ਅਧਿਕਾਰਤ ਮਾਰਕ ਪ੍ਰਭਾਵਿਤ ਰੇਂਜ 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 ਜੁਲਾਈ	map + regex ਕੈਪਚਰ ਵੇਰੀਏਬਲ ਮੁਲਾਂਕਣ ਹੀਪ ਓਵਰਫਲੋ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਾਲੇ ਪੈਚ ਅਕਤੂਬਰ ਵਿੱਚ CVE-2026-93479 ਨਾਲ ਰਿਗਰੈਸ਼ਨ ਸਬੰਧ ਰੱਖਦੇ ਹਨ
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 ਜੁਲਾਈ	ngx_http_slice_module ਮੈਮੋਰੀ ਸਮੱਗਰੀ ਖਾਸ ਵੇਰੀਏਬਲ ਅਤੇ ਕੈਸ਼ ਅੱਪਡੇਟ ਹਾਲਤਾਂ ਵਿੱਚ ਲੀਕ ਹੋਈ
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 ਜੁਲਾਈ	SSI UAF ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ; ਅਕਤੂਬਰ ਦੀ AIO ਗਿਣਤੀ ਦੀ ਕਮਜ਼ੋਰੀ ਦੇ ਸਮਾਨ root ਕਾਰਨ ਨਹੀਂ ਹੈ
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 ਸਤੰਬਰ	HTTP/3 + ਖਾਸ OpenSSL ਸੰਸਕਰਣ ਸੰਜੋਗ ਦਾ ਸੀਮਿਤ ਹੀਪ ਓਵਰਫਲੋ, ਮੁੱਖ ਤੌਰ ‘ਤੇ ਕਰੈਸ਼/ਸੀਮਤ ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ

ਹੋਰ ਕਮਜ਼ੋਰੀਆਂ ਜਿਵੇਂ ਕਿ NGINX ਕੋਰ, HTTP/2, ਚਾਰਸੈੱਟ, ਅਤੇ 2026 ਵਿੱਚ ਘੋਸ਼ਿਤ SMTP ਦੀ ਵੀ ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨਾਂ ਦੇ ਅਨੁਸਾਰ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ; ਇਹ ਸਾਰਣੀ ਜਾਣਬੁੱਝ ਕੇ ਖਾਸ ਘਟਨਾਵਾਂ ‘ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦੀ ਹੈ ਜੋ ਮੌਜੂਦਾ NGINX ਪਬਲਿਕ-ਫੇਸਿੰਗ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਤੈਨਾਤੀਆਂ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਹਨ ਅਤੇ ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਜਾਂ ਬੇਨਤੀ ਦੀ ਇਕਸਾਰਤਾ ਪ੍ਰਭਾਵ ਹੈ। 2026 ਵਿੱਚ ਸਾਰੇ CVE ਨਹੀਂ ਹਨ। ਸੂਚੀ। S1

CVE-2026-42945 ‘ਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਕਿਉਂ ਦਿਓ

ਸਰਕਾਰੀ ਏਜੰਸੀਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ ਹਨ ਜੋ ਮਈ ਵਿੱਚ ਇਸ rewrite ਕਮਜ਼ੋਰੀ ਲਈ ਜੰਗਲੀ ਸ਼ੋਸ਼ਣ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਅਤੇ ਜਨਤਕ ਸ਼ੋਸ਼ਣ ਕੋਡ ਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੇ ਹਨ। ਇਸ ਲਈ, ਅਜਿਹੇ ਉਦਾਹਰਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਈ ਤੋਂ ਹੁਣ ਤੱਕ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪੈਚ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜਨਤਕ ਨੈੱਟਵਰਕ ‘ਤੇ ਖੁੱਲ੍ਹੇ ਗੁੰਝਲਦਾਰ ਨਿਯਮਤ ਸਮੀਕਰਨ ਰੀਰਾਈਟਸ ਹਨ, ਮੁਰੰਮਤ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਇਲਾਵਾ, ਅਸਧਾਰਨ Worker ਕਰੈਸ਼, ਐਕਸੈਸ ਲੌਗ ਅਤੇ ਉਸ ਸਮੇਂ ਸ਼ੱਕੀ ਤਬਦੀਲੀਆਂ ਦੀ ਵੀ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। S23

“ਇੱਕ ਹਮਲੇ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੋਈ” ਆਪਣੇ ਆਪ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਹਮਲਾਵਰ ਨੇ ਹਰ ਨਿਸ਼ਾਨੇ ‘ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਕਮਾਂਡਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ; ਜਦੋਂ ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ, ਸਮਝੌਤਾ ਸੂਚਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰੈਸ਼ਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਧੇ ਜਾਂ ਨਿਰੰਤਰਤਾ ਦੇ ਸੱਚੇ ਸਬੂਤ ਤੋਂ ਵੱਖਰੇ ਤੌਰ ‘ਤੇ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਅਤੇ ਵੰਡ ਬੈਕਪੋਰਟਾਂ ਲਈ 7.2 ਉਪਚਾਰ

NGINX ਵੱਖ-ਵੱਖ ਸ਼ਾਖਾਵਾਂ ਦੇ ਆਪਣੇ ਸਮਰਥਨ ਚੱਕਰ ਅਤੇ ਵੱਖ-ਵੱਖ ਕਮਜ਼ੋਰੀ ਜਾਣ-ਪਛਾਣ ਦੇ ਸਮੇਂ ਹੁੰਦੇ ਹਨ। ਪੰਜ ਨਵੇਂ ਪੈਚ ਬਿਨਾਂ ਸਮੀਖਿਆ ਦੇ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਸਰੋਤ ਰੁੱਖਾਂ ਲਈ ਰੋਲਆਊਟ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਦ੍ਰਿਸ਼	ਸਿਫਾਰਸ਼ੀ ਰਣਨੀਤੀ
ਰੀਲੀਜ਼ ਸੰਸਕਰਣ ਨੇ ਪੂਰੇ ਸੁਰੱਖਿਆ ਪੈਚਾਂ ਦਾ ਐਲਾਨ ਕੀਤਾ ਹੈ	ਵਿਕਰੇਤਾ ਪੈਕੇਜ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਸੰਪੂਰਨ ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ; ਅਸੰਗਤ ਅੱਪਸਟ੍ਰੀਮ ਬੇਅਰ ਬਾਈਨਰੀਆਂ ਨਾਲ ਬਦਲਣ ਤੋਂ ਬਚੋ
Debian 12 ਅਤੇ ਹੋਰ ਪ੍ਰਭਾਵਿਤ ਰੀਲੀਜ਼ ਜੋ ਅਜੇ ਤੱਕ ਇਸ ਬੈਚ ਦੇ ਸਾਰੇ CVE ਦੁਆਰਾ ਕਵਰ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ	ਜੋਖਮ ਦੇ ਕੰਮ ਦੇ ਆਦੇਸ਼ ਜਮ੍ਹਾਂ ਕਰੋ, ਬਾਹਰੀ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਸੀਮਤ ਕਰੋ, ਅਤੇ ਸਪਲਾਇਰ/ELTS ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ; ਮਾਈਗਰੇਟ ਕਰੋ ਜਾਂ ਲੋੜ ਪੈਣ ‘ਤੇ ਪ੍ਰਮਾਣਿਤ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਚੇਨ ਦੀ ਵਰਤੋਂ ਕਰੋ
ਇਤਿਹਾਸਕ ਸ਼ਾਖਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਅੱਪਸਟ੍ਰੀਮ ਸਮਰਥਨ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਹੈ	ਸਮਰਥਿਤ ਸੰਸਕਰਣਾਂ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; ਜੇਕਰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਬੈਕਪੋਰਟਿੰਗ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਮੇਨਟੇਨਰ ਨਿਰਭਰਤਾ ਅਤੇ ਪੈਚ ਅਨੁਕੂਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਗੇ, ਅਤੇ ਪੂਰੇ ਟੈਸਟ ਲਿਖਣਗੇ।
NGINX ਫੋਰਕ (OpenResty, Tengine, ਕਸਟਮਾਈਜ਼ਡ ਗੇਟਵੇ) ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ	ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਸੰਬੰਧਿਤ ਕੋਡ ਮਾਰਗ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਫਿਰ ਫੋਰਕ ਮੇਨਟੇਨਰ ਦੀ ਸੁਰੱਖਿਆ ਸਟੇਟਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਅੱਪਸਟ੍ਰੀਮ ਸੰਸਕਰਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਸੁਰੱਖਿਆ ਪੈਚ ਕਾਰੋਬਾਰੀ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ	ਪੜਾਅਵਾਰ ਰੋਲਆਉਟਸ, ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਟਰੈਫਿਕ ਸਵਿਚਿੰਗ, ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਨੁਕੂਲਨ ਨੂੰ ਅਪਣਾਓ; ਜਨਤਕ ਨੈੱਟਵਰਕ ਦੇ ਅਨਫਿਕਸਡ ਵਰਜਨ ਨੂੰ ਅਲੱਗ-ਥਲੱਗ ਕੀਤੇ ਬਿਨਾਂ ਬਹਾਲ ਕਰਨਾ ਉਚਿਤ ਨਹੀਂ ਹੈ।

7.3 njs, ਪ੍ਰਵੇਸ਼ ਅਤੇ NGINX ਕੋਰ ਲਈ ਵੱਖਰਾ ਉਪਚਾਰ

• njs: NGINX ਮੁੱਖ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ NGINX JavaScript ਮੋਡੀਊਲ ਦੇ ਸੰਸਕਰਣ ਦੀ ਵੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। njs 1.0.2 ਇੱਕ ਅਕਤੂਬਰ 2026 XML ਪਾਰਸਿੰਗ ਮੈਮੋਰੀ ਥਕਾਵਟ ਅਤੇ XML ਪ੍ਰਮਾਣਿਕਤਾ ਅਸੰਗਤਤਾ ਮੁੱਦੇ ਨੂੰ ਇਕਾਈ ਸੰਦਰਭ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ। nginx-saml ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ XML ਦਸਤਖਤ ਤਸਦੀਕ ਨਾਲ ਸੰਬੰਧਿਤ ਤੈਨਾਤੀਆਂ ਲਈ, ਤੁਹਾਨੂੰ ਪਲੱਗ-ਇਨ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਅਧਿਕਾਰਤ njs ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਹੋਰ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ। S20
• F5 NGINX Plus / NGINX ਪ੍ਰਵੇਸ਼ ਕੰਟਰੋਲਰ: ਪਲੱਸ, ਕੰਟਰੋਲਰ ਅਤੇ ਗੇਟਵੇ ਫੈਬਰਿਕ ਹਰੇਕ ਵਿੱਚ ਵਾਧੂ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ, ਵੱਖ-ਵੱਖ ਪੈਕੇਜਿੰਗ ਸੰਸਕਰਣ ਅਤੇ ਵਿਲੱਖਣ ਨੀਤੀ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਲੇਅਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਦੂਜੀ ਲੇਅਰ ਨੂੰ ਆਪਣੇ ਆਪ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਵੇ। S19
• Kubernetes ਕਮਿਊਨਿਟੀ ingress-nginx: Kubernetes ਅਧਿਕਾਰੀਆਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਐਲਾਨ ਕੀਤਾ ਹੈ ਕਿ ਕੰਟਰੋਲਰ ਨੇ ਮਾਰਚ 2026 ਵਿੱਚ ਰੱਖ-ਰਖਾਅ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਵੇਅਰਹਾਊਸ ਨੂੰ F5 ਕੰਟਰੋਲਰ ਨਾਲ ਉਲਝਣ ਵਿੱਚ ਨਹੀਂ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਪ੍ਰਭਾਵਿਤ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਇੱਕ ਨਵੇਂ ਸੁਰੱਖਿਆ ਸੰਸਕਰਣ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਨਿਰਵਿਘਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਇਨਗ੍ਰੇਸ ਐਨੋਟੇਸ਼ਨਾਂ ਅਤੇ Gateway API ਸਿਮੈਂਟਿਕ ਅੰਤਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। S21

8. ਸਵੀਕ੍ਰਿਤੀ ਦੇ ਮਾਪਦੰਡ ਅਤੇ ਫਾਲੋ-ਅੱਪ ਨਿਰੀਖਣ

ਇਹ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਸੂਚੀ ਨੂੰ ਕੰਮ ਦੇ ਆਰਡਰ ਬਦਲਣ ਲਈ ਸਵੀਕ੍ਰਿਤੀ ਦੀਆਂ ਸ਼ਰਤਾਂ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇ:

ਪ੍ਰੋਜੈਕਟ	ਯੋਗਤਾ ਮਾਪਦੰਡ	ਸਬੂਤ ਜੋ ਬਰਕਰਾਰ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ
ਸੰਪਤੀ ਅਤੇ ਪੋਰਟਲ ਕਵਰੇਜ	CDN ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਬਾਹਰੀ ਅਤੇ ਸਿੱਧੀਆਂ-ਕਨੈਕਟ ਕੀਤੀਆਂ ਉਦਾਹਰਣਾਂ ਦੀ ਸੂਚੀ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ।	ਡੋਮੇਨ ਨਾਮ, LB, IP, Pod/ਕੰਟੇਨਰ ਸੂਚੀ
ਪੈਕੇਜ ਸਰੋਤ ਅਤੇ ਮੁਰੰਮਤ ਦਾ ਘੇਰਾ	ਸਾਰੇ ਲਾਗੂ CVE ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਪੁਸ਼ਟੀ ਕੀਤੇ ਸੰਸਕਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ	ਅੱਪਸਟਰੀਮ ਸੁਰੱਖਿਆ ਸਲਾਹਕਾਰ, USN/DSA, ਪੈਕੇਜ ਸੰਸਕਰਣ, ਚਿੱਤਰ ਡਾਇਜੈਸਟ
ਪੁਰਾਣੀ ਪ੍ਰਕਿਰਿਆ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ	ਸਾਰੇ ਪੁਰਾਣੇ master/worker/ਕੰਟੇਨਰਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ	PID/ਸ਼ੁਰੂਆਤ ਸਮਾਂ, ਰੋਲਿੰਗ ਤੈਨਾਤੀ ਸਥਿਤੀ, ਚੱਲ ਰਹੀ ਤਸਵੀਰ
ਸੰਰਚਨਾ ਆਡਿਟ	ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਸੰਜੋਗਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ ਜਾਂ ਪੈਚਾਂ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਵਿਰਾਸਤੀ ਸਬੰਧਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ	nginx -T ਦਾ ਸੰਸ਼ੋਧਿਤ ਸੰਖੇਪ ਅਤੇ ਆਡਿਟ ਰਿਕਾਰਡ
TLS/mTLS	ਭਰੋਸੇਯੋਗ ਸਰਟੀਫਿਕੇਟ ਪਾਸ; ਅਵੈਧ ਜਾਂ ਗੁੰਮ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰ ਦਿੱਤੇ ਗਏ ਹਨ; ਸੈਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ ਹੋਣਾ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦਾ ਹੈ	ਨਕਾਰਾਤਮਕ/ਸਕਾਰਾਤਮਕ ਪ੍ਰਮਾਣੀਕਰਨ ਟੈਸਟ, ਨਿਯੰਤਰਿਤ TLS ਟੈਸਟ ਨਤੀਜੇ
HTTP/3 ਬੇਨਤੀ ਬਾਡੀ	ਪੱਥ ਫਿਕਸਡ ਨੂੰ ਸਮਰੱਥ ਕਰੋ; ਅੱਪਸਟਰੀਮ ਬੇਨਤੀ ਬਾਡੀ ਅਤੇ ਥ੍ਰੋਟਲਿੰਗ ਸਹੀ ਢੰਗ ਨਾਲ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ	HTTP/3, ਪ੍ਰੌਕਸੀ ਅਪਲੋਡ, ਵਾਲੀਅਮ ਸੀਮਾ ਰੀਗਰੈਸ਼ਨ ਟੈਸਟ
SSI/AIO	ਫੰਕਸ਼ਨ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, Worker ਦਾ ਕੋਈ ਅਸਧਾਰਨ ਅਧੂਰਾ ਨਹੀਂ ਹੈ	ਵਪਾਰਕ ਰਿਗਰੈਸ਼ਨ, ਕਰੈਸ਼ ਅਤੇ ਗਲਤੀ ਦਰ ਦੀ ਨਿਗਰਾਨੀ
ਓਪਰੇਸ਼ਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੀ ਨਿਗਰਾਨੀ	ਕੋਈ ਸਪੱਸ਼ਟ ਅਪਵਾਦ 5xx, SIGSEGV, ਪ੍ਰਕਿਰਿਆ ਵਾਰ-ਵਾਰ ਬਾਹਰ ਜਾਂਦੀ ਹੈ	ਪਰਿਵਰਤਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸੇਵਾ ਸੰਕੇਤਕ ਅਤੇ ਲਾਗ
ਰੋਲਬੈਕ ਰਣਨੀਤੀ	ਜੇਕਰ ਰੋਲਬੈਕ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਐਕਸਪੋਜਰ ਨੂੰ ਸੀਮਤ ਕਰੋ ਅਤੇ ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ	ਆਰਡਰ, ਸੰਕਟਕਾਲੀਨ ਪ੍ਰਵਾਹ ਅਤੇ ਕੁਆਰੰਟੀਨ ਪਲਾਨ ਬਦਲੋ
ਬਾਅਦ ਦੇ ਜੀਵਨ ਚੱਕਰ	ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਕੰਟੇਨਰ ਅੱਪਡੇਟ ਬਾਰੰਬਾਰਤਾ, ਅਤੇ ਬ੍ਰਾਂਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾਵਾਂ ਦਾ ਪਤਾ ਲਗਾਓ	ਬਹੀ, ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਅਤੇ ਅਗਲੀ ਆਡਿਟ ਮਿਤੀ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰੋ

8.1 ਲੌਗਸ ਅਤੇ ਚੱਲ ਰਹੀ ਸਥਿਤੀ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕਿਸ ‘ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ?

worker process exited on signal 、SIGSEGV , ਬੇਨਤੀ ਅਸਫਲਤਾ ਸਪਾਈਕਸ, ਅਸਧਾਰਨ ਸਰੋਤ ਐਕਸੈਸ ਏਗਰੀਗੇਸ਼ਨ, ਅਚਾਨਕ TLS ਸੈਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ/ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਬੰਧੀ ਵਿਵਹਾਰ ਦੀ ਸਫਲਤਾ ਲਈ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਸਰਵਰਾਂ ‘ਤੇ ਅਸਧਾਰਨਤਾਵਾਂ ਦਾ ਨਿਪਟਾਰਾ ਕਰੋ। ਇਹਨਾਂ ਸੂਚਕਾਂ ਨੂੰ ਸਿਰਫ਼ ਜਾਂਚ ਦੇ ਸੁਰਾਗ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇਹ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਸਾਬਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਸਬੂਤ ਨਹੀਂ ਹਨ ਕਿ ਕਿਸੇ ਖਾਸ CVE ਦਾ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਗਿਆ ਹੈ। ;ਸੰਬੰਧਿਤ ਲੌਗਸ ਦੀ ਘਾਟ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਹੈ ਕਿ ਕੋਈ ਹਮਲਾ ਨਹੀਂ ਹੋਇਆ ਹੈ।

8.2 ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਅੰਤਮ ਜੋਖਮ ਸਿੱਟਾ ਸ਼ਬਦ

ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਲਈ ਸਵੀਕ੍ਰਿਤੀ ਰਿਪੋਰਟ ਨੂੰ ਹੇਠ ਲਿਖੇ ਸਟੀਕ ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

NGINX ਬਾਹਰੀ ਸੇਵਾ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ ਸਰੋਤ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ। ਸਾਰੀਆਂ ਲਾਗੂ ਹੋਣ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਸੰਸਕਰਣ ਵਿੱਚ ਅੱਪਗਰੇਡ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਾਂ ਰੀਲੀਜ਼ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਬੈਕਪੋਰਟ ਪੂਰੀ ਹੋ ਗਈ ਹੈ; ਪੁਰਾਣੇ Worker ਅਤੇ ਪੁਰਾਣੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਉਪਨਾਮ/ਮੁੜ-ਲਿਖਤ/ਨਕਸ਼ੇ, AIO/SSI, HTTP/3 ਬੇਨਤੀ ਬਾਡੀ ਅਤੇ TLS ਸੈਸ਼ਨ ਟਿਕਟ/mTLS ਸੰਬੰਧਿਤ ਸੰਰਚਨਾਵਾਂ ਦਾ ਆਡਿਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਅਤੇ ਮੁੜ-ਪੜਤਾਲ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਹੈ। ਉਦਾਹਰਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੇ ਅਜੇ ਤੱਕ ਅੱਪਗਰੇਡ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਇਸ ਤੋਂ ਇਲਾਵਾ ਐਕਸਪੋਜ਼ਰ ਖੇਤਰ, ਮੁਆਵਜ਼ੇ ਦੇ ਉਪਾਅ, ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ, ਅਤੇ ਪੂਰਾ ਕਰਨ ਦੀਆਂ ਸਮਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕਰੋ।

ਜੇਕਰ Debian 12 ਜਾਂ ਹੋਰ ਰੀਲੀਜ਼ਾਂ ਲਈ ਪੈਚ ਅਜੇ ਵੀ ਅਧੂਰਾ ਹੈ, ਤਾਂ ਪੂਰੇ ਸਵੀਕ੍ਰਿਤੀ ਫਾਰਮ ਨੂੰ “ਪੂਰਾ” ਵਜੋਂ ਨਿਰਣਾ ਕਰਨਾ ਉਚਿਤ ਨਹੀਂ ਹੈ; ਅਣਸੁਲਝਿਆ CVE, ਭਾਵੇਂ ਕੋਈ ਸੰਬੰਧਿਤ ਟਰਿੱਗਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੈ, ਆਈਸੋਲੇਸ਼ਨ ਸਥਿਤੀ ਅਤੇ ਅੰਤਮ ਅੱਪਗਰੇਡ ਰੂਟ ਸਪਸ਼ਟ ਤੌਰ ‘ਤੇ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

---

ਅੰਤਿਕਾ: ਹਵਾਲੇ ਦਿੱਤੇ ਸਰੋਤ ਅਤੇ ਲਿੰਕ

ਵਰਣਨ: ਟੈਕਸਟ ਵਿੱਚ [Sx] ਨੰਬਰ ਇਸ ਸੈਕਸ਼ਨ ਨਾਲ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰੋਜੈਕਟ ਸੁਰੱਖਿਆ ਘੋਸ਼ਣਾਵਾਂ, ਕੋਡ ਪ੍ਰਤੀਬੱਧਤਾਵਾਂ, ਸਪਲਾਇਰ ਰਿਲੀਜ਼ ਘੋਸ਼ਣਾਵਾਂ ਅਤੇ ਰਾਸ਼ਟਰੀ ਸੁਰੱਖਿਆ ਏਜੰਸੀ ਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਹਵਾਲਾ ਦਿੱਤੀ ਗਈ ਕਮਜ਼ੋਰੀ ਦੀ ਤੀਬਰਤਾ ਹਰੇਕ ਜਾਰੀ ਕਰਨ ਵਾਲੀ ਸੰਸਥਾ ਦੇ ਰੇਟਿੰਗ ਮਾਪਦੰਡ ਦੇ ਅਨੁਸਾਰ ਵਰਣਨ ਕੀਤੀ ਗਈ ਹੈ; ਡਾਟਾ ਪੁਸ਼ਟੀਕਰਨ ਮਿਤੀ 27 ਅਕਤੂਬਰ, 2026 ਹੈ।

S1 — NGINX Open Source ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ

• https://nginx.org/en/security_advisories.html

ਪੰਜ ਅਕਤੂਬਰ ਦੇ CVEs ਦੇ ਅੱਪਸਟਰੀਮ ਪ੍ਰਭਾਵਿਤ ਸੰਸਕਰਣ, ਫਿਕਸ ਸ਼ਾਖਾਵਾਂ, ਅਤੇ ਅਧਿਕਾਰਤ ਗੰਭੀਰਤਾ ਪੱਧਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ 2026 ਤੱਕ ਇਤਿਹਾਸਕ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਵੀ ਕਵਰ ਕਰਦਾ ਹੈ।

S2 — NGINX ਅਧਿਕਾਰਤ ਸੰਸਕਰਣ ਰੀਲੀਜ਼ ਰਿਕਾਰਡ

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

1.30.6 / 2026-10-14 ਦੇ 1.31.7, 2026-10-21 ਦੇ 1.31.8, ਅਤੇ ਮਈ ਤੋਂ ਸਤੰਬਰ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਸੁਰੱਖਿਆ ਰੀਲੀਜ਼ ਮੀਲਪੱਥਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

S3 - ਸਿੰਗਾਪੁਰ ਦੀ ਸਾਈਬਰ ਸੁਰੱਖਿਆ ਏਜੰਸੀ: F5 NGINX ਤਿੰਨ ਗੰਭੀਰ ਕਮਜ਼ੋਰੀਆਂ

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

CVSS v4.0 9.2 ਸਕੋਰ, ਲੋੜੀਂਦੀਆਂ ਸੰਰਚਨਾ ਸ਼ਰਤਾਂ, ਅਤੇ CVE-2026-15176, CVE-2026-93479, ਅਤੇ CVE-2026-97205 ਲਈ ਅੰਤਰਿਮ ਕਮੀ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦਾ ਵੇਰਵਾ।

S4 - NHS ਇੰਗਲੈਂਡ: F5 NGINX ਉੱਚ ਜੋਖਮ ਸੰਬੰਧੀ ਸਲਾਹ

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਦੇ DoS / ਸੰਭਾਵੀ RCE ਪ੍ਰਭਾਵ, ਅਤੇ ASLR ਨੂੰ ਬੰਦ ਜਾਂ ਬਾਈਪਾਸ ਕਰਨ ਵਰਗੀਆਂ ਰੁਕਾਵਟਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

S5 — ਅਧਿਕਾਰਤ ਸਰੋਤ ਵਚਨਬੱਧ: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

ngx_http_map_uri_to_path() ਵਿੱਚ alias ਅਤੇ r->uri_changed ਦੀ ਸਥਿਤੀ ਜਾਂਚ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

S6 — ਅਧਿਕਾਰਤ ਸਰੋਤ ਵਚਨਬੱਧ: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

HTTP/Stream ਸਕ੍ਰਿਪਟ ਲੰਬਾਈ ਅਤੇ ਰਾਖਵੇਂ ਬਫਰ ਵੰਡ ਤਰਕ ਨਾਲ ਸੰਬੰਧਿਤ।

S7 - ਅਧਿਕਾਰਤ ਸਰੋਤ ਵਚਨਬੱਧ: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

r->main->blocked ਗਿਣਤੀ ਥ੍ਰੈਸ਼ਹੋਲਡ NGX_HTTP_MAX_BLOCKED 250 ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਪਾਥ ਫਾਲਬੈਕ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

S8 — ਅਧਿਕਾਰਤ ਸਰੋਤ ਵਚਨਬੱਧ: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

HTTP/3 ਅਗਿਆਤ ਫ੍ਰੇਮ ਦੀ ਬਾਕੀ ਬਚੀ ਲੰਬਾਈ ਅਤੇ DATA ਬੇਨਤੀ ਬਾਡੀ ਲੰਬਾਈ ਦੇ ਅਨੁਸਾਰੀ ਸਥਿਤੀ ਵਿਭਾਜਨ।

S9 — ਅਧਿਕਾਰਤ ਸਰੋਤ ਵਚਨਬੱਧ: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

ਸਮਕਾਲੀਕਰਨ TLS ਸੈਸ਼ਨ ਟਿਕਟ ਰੋਟੇਸ਼ਨ ਦੌਰਾਨ ਸਾਰੇ ਮੁੱਖ ਸਲਾਟਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

S10 — F5: CVE-2026-15176 ਵਿਕਰੇਤਾ ਦੀ ਘੋਸ਼ਣਾ

• https://my.f5.com/manage/s/article/K000162416

ਟਰਿੱਗਰ ਕਾਰਕਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜਿਵੇਂ ਕਿ alias, rewrite, $request_filename ਅਤੇ ਪਹੁੰਚ ਲੌਗ।

S11 — F5: CVE-2026-93479 ਵਿਕਰੇਤਾ ਘੋਸ਼ਣਾ

• https://my.f5.com/manage/s/article/K000162607

ਸੂਚੀ ਨਕਸ਼ਾ regex ਕੈਪਚਰ, root ਮਾਰਗ, ਅਤੇ ਲੌਗ ਵੇਰੀਏਬਲ ਮੁਲਾਂਕਣ ਸ਼ਰਤਾਂ।

S12 — NGINX ਅਧਿਕਾਰਤ TLS/SSL ਮੋਡੀਊਲ ਦਸਤਾਵੇਜ਼

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

ਵਰਣਨ ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key ਅਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਹੋਰ ਨਿਰਦੇਸ਼।

S13 — ਸੁਰੱਖਿਆ ਸਲਾਹਕਾਰ: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. ਦਾ ਪੂਰਾ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ ਫਿਕਸਡ ਸੰਸਕਰਣ ਅਤੇ ਵੰਡ ਸਕੋਪ ਪ੍ਰਦਾਨ ਕਰੋ

S14 — ਸੁਰੱਖਿਆ ਸਲਾਹਕਾਰ: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Debian 13 / trixie ਲਈ ਸੁਰੱਖਿਆ ਫਿਕਸ ਪੈਕੇਜ 1.26.3-3+deb13u10 ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ CVE-2026-93479 ਲਈ ਬੈਕਪੋਰਟ ਐਸੋਸੀਏਸ਼ਨ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ।

S15 — ਕਮਜ਼ੋਰੀ ਟਰੈਕਿੰਗ: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Debian 12 / bookworm ਅਤੇ Debian 13 / trixie ਦੀ ਵੰਡ ਫਿਕਸ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਭਵਿੱਖ ਦੇ ਸੁਰੱਖਿਆ ਅੱਪਡੇਟਾਂ ਨਾਲ ਬਦਲ ਸਕਦੀ ਹੈ।

S16 — ਕਮਜ਼ੋਰੀ ਟਰੈਕਿੰਗ: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

ਵੱਖ-ਵੱਖ Debian ਸ਼ਾਖਾਵਾਂ ‘ਤੇ HTTP/3 ਕਮਜ਼ੋਰੀ ਦੀ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਦੀ ਪੂਰਕ ਪੁਸ਼ਟੀ।

S17 — ਸੁਰੱਖਿਆ ਸਲਾਹਕਾਰ: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

ਅਕਤੂਬਰ ਦੀ ਰਿਗਰੈਸ਼ਨ ਕਮਜ਼ੋਰੀ ਅਤੇ ਜੁਲਾਈ CVE-2026-42533 ਲਈ ਫਿਕਸ ਵਿਚਕਾਰ ਸਬੰਧ ਦੀ ਪੂਰਕ ਸਮਝ।

S18 — NGINX ਅਧਿਕਾਰਤ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਮੋਡੀਊਲ ਦਸਤਾਵੇਜ਼

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

proxy_request_buffering, client_max_body_size, alias, aio, ਆਦਿ ਵਰਗੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੇ ਅਰਥ ਵਿਗਿਆਨ ਅਤੇ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲਾਂ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰੋ।

S19 — NGINX Plus ਅਧਿਕਾਰਤ ਰੀਲੀਜ਼ ਨੋਟਸ

• https://docs.nginx.com/nginx/releases/

ਸੂਚੀ ਪਲੱਸ CR/LTS ਬ੍ਰਾਂਚਾਂ, ਸੰਸਕਰਣ, ਪੈਚ ਅਤੇ ਅਪਗ੍ਰੇਡ ਅਨੁਕੂਲਤਾ ਰੀਮਾਈਂਡਰ।

S20 — NGINX JavaScript / njs ਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਬੁਲੇਟਿਨ

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

ਅਕਤੂਬਰ 2026 njs 1.0.2 ਅਤੇ ਸੰਬੰਧਿਤ XML ਪ੍ਰਮਾਣਿਕਤਾ, ਮੈਮੋਰੀ ਥਕਾਵਟ ਦੇ ਮੁੱਦੇ ਸ਼ਾਮਲ ਹਨ।

S21 — Kubernetes: ਕਮਿਊਨਿਟੀ ingress-nginx ਅਧਿਕਾਰਤ ਰਿਟਾਇਰਮੈਂਟ ਨਿਰਦੇਸ਼

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

ਨੋਟ ਕਰੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਨੇ ਮਾਰਚ 2026 ਵਿੱਚ ਨਵੀਆਂ ਰੀਲੀਜ਼ਾਂ ਅਤੇ ਸੁਰੱਖਿਆ ਫਿਕਸਾਂ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਸੰਭਾਲੇ ਹੋਏ ਕੰਟਰੋਲਰ ਜਾਂ Gateway API ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

S22 — NGINX ਅਧਿਕਾਰਤ ਸੇਵਾ ਨਿਯੰਤਰਣ ਅਤੇ ਔਨਲਾਈਨ ਬਾਈਨਰੀ ਅਪਗ੍ਰੇਡ ਨਿਰਦੇਸ਼

• https://nginx.org/en/docs/control.html

ਪ੍ਰਕਿਰਿਆ ਸਵਿਚਿੰਗ ਸਵੀਕ੍ਰਿਤੀ ਲਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਰੀਲੋਡ, ਰੀਸਟਾਰਟ ਅਤੇ ਔਨਲਾਈਨ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ ਅਪਗ੍ਰੇਡ ਵਿਧੀਆਂ ਨੂੰ ਵੱਖਰਾ ਕਰੋ।

S23 - ਸਰਕਾਰੀ ਸੁਰੱਖਿਆ ਨੋਟਿਸ: ਮਈ 2026 NGINX ਮੁੜ ਲਿਖਣ ਦੀ ਕਮਜ਼ੋਰੀ

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

CVE-2026-42945 ਲਈ ਇਤਿਹਾਸਕ ਜੋਖਮ ਪਿਛੋਕੜ ਅਤੇ ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ ਸੁਝਾਅ ਪ੍ਰਦਾਨ ਕਰੋ; ਜੰਗਲੀ ਸ਼ੋਸ਼ਣ ਨਾਲ ਸਬੰਧਤ ਨਿਰਣੇ ਉਸ ਸਮੇਂ ਏਜੰਸੀ ਦੀ ਘੋਸ਼ਣਾ ਅਤੇ ਹੋਰ ਘਟਨਾ ਦੇ ਸਬੂਤ ‘ਤੇ ਅਧਾਰਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

S24 — F5: CVE-2026-95101 ਅਤੇ CVE-2026-97629 ਵਿਕਰੇਤਾ ਘੋਸ਼ਣਾਵਾਂ

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

ਕ੍ਰਮਵਾਰ HTTP/3 ਬੇਨਤੀ ਬਾਡੀ ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਆਟੋਮੈਟਿਕ TLS ਟਿਕਟ ਕੁੰਜੀ ਰੋਟੇਸ਼ਨ ਦੇ ਜੋਖਮਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

S25 — F5: CVE-2026-97205 ਵਿਕਰੇਤਾ ਦੀ ਘੋਸ਼ਣਾ

• https://my.f5.com/manage/s/article/K000162608

ਵਰਣਨ SSI/AIO ਟਰਿੱਗਰ ਸਥਿਤੀਆਂ ਅਤੇ ਸੰਭਾਵੀ ਮੈਮੋਰੀ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਦੇ ਜੋਖਮ।

NGINX ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ: ਸੰਰਚਨਾ ਜਾਂਚ, ਅੱਪਗਰੇਡ ਅਤੇ ਪੁਸ਼ਟੀਕਰਨ