Apache HTTP/2 ದೋಷ CVE-2026-119618: ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು 2.4.71 ಗೆ ಪ್ಯಾಚ್ ಮಾಡುವುದು ಹೇಗೆ

HTTP/2 ಬೆಂಬಲಿಸುವ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಎಂದಿಗೂ ಲಾಗಿನ್ ಆಗದ ಅಪರಿಚಿತ ವ್ಯಕ್ತಿಯೊಬ್ಬ ತನ್ನ ನಿಯಂತ್ರಣಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. Apache HTTP Server ನ HTTP/2 ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿನ ಗಂಭೀರ ದೋಷವಾದ CVE-2026-119618 ರ ಹಿಂದಿನ ಅಪಾಯ ಇದಾಗಿದೆ, ಮತ್ತು ಇದಕ್ಕೆ ಪರಿಹಾರವು ಈಗಾಗಲೇ ಹೊರಬಂದಿದೆ.

ಇಂದು ನವೆಂಬರ್ 13, 2026. ಈ ರಂಧ್ರವನ್ನು ಮುಚ್ಚಲು Apache ನವೆಂಬರ್ 11 ರಂದು 2.4.71 ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ, ಮತ್ತು ಭದ್ರತಾ ತಂಡಗಳು ಈಗ ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಿವೆ: ನಾವು ನಿಜವಾಗಿಯೂ ಅಪಾಯಕ್ಕೆ ಒಳಗಾಗಿದ್ದೇವೆಯೇ? ಪ್ರಾಮಾಣಿಕ ಉತ್ತರವು ಕೇವಲ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಇದು HTTP/2 ಆನ್ ಆಗಿದೆಯೇ, ನಿಮ್ಮ Linux ಮಾರಾಟಗಾರರು ಈಗಾಗಲೇ ತಮ್ಮ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡಿದ್ದಾರೆಯೇ ಮತ್ತು ಟ್ರಾಫಿಕ್ Apache ಅನ್ನು ಹೇಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನಾವು Acme ಎಂದು ಕರೆಯುವ ಕಂಪನಿಯ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿರುವ ರೋಹಿತ್ ಅವರನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿಕೊಂಡು ಈ ಮಾರ್ಗದರ್ಶಿಯು ಈ ಮೂರನ್ನೂ ವಿವರಿಸುತ್ತದೆ.

ಸರಳ ಮಾತುಗಳಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಏನಾಯಿತು

HTTP/2 ಎಂಬುದು ವೆಬ್‌ನ ಮುಖ್ಯ ಪ್ರೋಟೋಕಾಲ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯಾಗಿದೆ. ಇದರ ಪ್ರಮುಖ ಕಲ್ಪನೆಯೆಂದರೆ ಅನೇಕ ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು, ಇದು ವೆಬ್‌ಸೈಟ್‌ಗಳನ್ನು ವೇಗವಾಗಿಸುತ್ತದೆ. Apache ನಲ್ಲಿ, ಈ ವೈಶಿಷ್ಟ್ಯವು ಈ ಕೆಳಗಿನ ಹೆಸರಿನ ಮಾಡ್ಯೂಲ್‌ನಿಂದ ಬರುತ್ತದೆ: mod_http2.

ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು ಎಂದರೆ ಸರ್ವರ್‌ನ ಹಲವಾರು ಭಾಗಗಳು ಏಕಕಾಲದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಯಾರು ಮೆಮೊರಿಯ ಯಾವ ಭಾಗವನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅವು ಜಾಗರೂಕರಾಗಿರಬೇಕು. Red Hat ನ ತಾಂತ್ರಿಕ ಮೌಲ್ಯಮಾಪನದ ಪ್ರಕಾರ, ಆ ಜಾಗರೂಕತೆ ಇಲ್ಲಿ ವಿಫಲವಾಗಿದೆ. ಒಂದು worker thread (ಒಂದು ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್‌ನ ಒಂದು ಭಾಗವು) ಇದರ ಒಡೆತನದ ಮೆಮೊರಿಗೆ ಬರೆಯಬಹುದು: connection thread (ಸಂಪೂರ್ಣ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವ ಭಾಗ), ಹಂಚಿಕೆಯ, ಲಾಕ್-ಮುಕ್ತ ಮೆಮೊರಿ ಅಲೋಕೇಟರ್ ಮೂಲಕ. ಸಮಸ್ಯೆಯು ಈ ಹೆಸರಿನ ಫಂಕ್ಷನ್‌ನಲ್ಲಿದೆ: assign_headers(). ಎರಡು ಭಾಗಗಳು ಸಮನ್ವಯವಿಲ್ಲದೆ ಒಂದೇ ಮೆಮೊರಿಗೆ ಬರೆದಾಗ, ಆಂತರಿಕ ಮೆಮೊರಿ ದೋಷಪೂರಿತಗೊಳ್ಳಬಹುದು, ಮತ್ತು ಮೆಮೊರಿ ಕರಪ್ಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ದಾಳಿಕೋರನ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡಲು ದಾರಿಯಾಗುತ್ತದೆ.

Red Hat ಈ ದೋಷಕ್ಕೆ 10 ಕ್ಕೆ 9.8 ರ CVSS v3.1 ಸ್ಕೋರ್ ನೀಡಿದೆ. ಆ ಸ್ಕೋರ್ ಎಂದರೆ ದಾಳಿಯು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಯಾವುದೇ ಪಾಸ್‌ವರ್ಡ್ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಬಳಕೆದಾರರಿಂದ ಯಾವುದೇ ಸಹಾಯದ ಅಗತ್ಯವಿಲ್ಲ ಎಂದರ್ಥ.

ಯಾವ ಆವೃತ್ತಿಗಳು ಬಾಧಿತವಾಗಿವೆ

Apache ಈ ಕೆಳಗಿನ ಶ್ರೇಣಿಗಳನ್ನು ಬಾಧಿತವಾಗಿವೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿದೆ:

• Apache HTTP Server 2.4.55 ರಿಂದ 2.4.70 ರವರೆಗೆ.
• ಪ್ರತ್ಯೇಕವಾಗಿ ಬಿಡುಗಡೆಯಾದ mod_h2 GitHub ನಿಂದ ಮಾಡ್ಯೂಲ್, ಆವೃತ್ತಿಗಳು 2.0.8 ರಿಂದ 2.0.42 ರವರೆಗೆ.

ಪರಿಹಾರ ಹೊಂದಿರುವ ಆವೃತ್ತಿ: Apache HTTP Server 2.4.71, ಅಥವಾ ಈ ಪರಿಹಾರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಒಳಗೊಂಡಿರುವ ಮಾರಾಟಗಾರರ ಪ್ಯಾಕೇಜ್.

Red Hat ತನ್ನ ಸ್ವಂತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗಾಗಿ ಪ್ರಮುಖ ವಿವರಗಳನ್ನು ಸೇರಿಸಿದೆ:

• RHEL 8 ಮತ್ತು ಹಿಂದಿನ ಆವೃತ್ತಿಗಳು ಬಾಧಿತವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ದುರ್ಬಲ ಕೋಡ್ ಅಲ್ಲಿ ಇಲ್ಲ.
• RHEL 9 ಮತ್ತು RHEL 10 ಆವೃತ್ತಿಗಳನ್ನು Critical ಬದಲಿಗೆ Important ಎಂದು ರೇಟ್ ಮಾಡಲಾಗಿದೆ. ಅವುಗಳ HTTP/2 ಸ್ಟ್ರೀಮ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಅಲೋಕೇಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಇದು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದನ್ನು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ ಅವುಗಳಿಗೆ ಅಪ್‌ಡೇಟ್ ಅಗತ್ಯವಿದೆ, ಮತ್ತು Red Hat ನವೆಂಬರ್ 11 ರಂದು ಹಲವಾರು RHEL 9 ಮತ್ತು 10 ಸ್ಟ್ರೀಮ್‌ಗಳಿಗೆ ಪರಿಹಾರಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ.

ದಾಳಿಕೋರನಿಗೆ ವಾಸ್ತವವಾಗಿ ಏನು ಸಿಗಬಹುದು

ಯಶಸ್ವಿ ದುರುಪಯೋಗವು ದಾಳಿಕೋರನಿಗೆ ಇದರ ನಿಯಂತ್ರಣವನ್ನು ನೀಡಬಹುದು: web-server process. ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಇಡೀ ಯಂತ್ರದ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಪಡೆದುಕೊಂಡಂತಲ್ಲ. ದಾಳಿಕೋರನು ಏನನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದು Apache ಪ್ರಕ್ರಿಯೆಯು ಏನನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್‌ನ ಡೇಟಾ, ಅದು ಬರೆಯಬಹುದಾದ ವೆಬ್‌ಸೈಟ್ ಫೋಲ್ಡರ್‌ಗಳು, config ಫೈಲ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ರುಜುವಾತುಗಳು, ಮತ್ತು ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಡೇಟಾಬೇಸ್‌ಗಳಂತಹ ಯಾವುದೇ ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗಳು.

ಹೀಗಾಗಿ ಕಡಿಮೆ-ಪ್ರಿವಿಲೇಜ್ ಹೊಂದಿರುವ ಬಳಕೆದಾರನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ, ಉತ್ತಮವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟ ಸರ್ವರ್‌ನಲ್ಲಿನ ಹಾನಿಯು, ಬಾಕ್ಸ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ರಹಸ್ಯವನ್ನು Apache ಓದಬಹುದಾದ ಸರ್ವರ್‌ಗಿಂತ ಕಡಿಮೆಯಾಗಿರುತ್ತದೆ. ಅದನ್ನು ಕೂಡ ಪರಿಶೀಲಿಸಲು ಇದು ಉತ್ತಮ ಸಮಯ.

ನಿಮ್ಮ ಸರ್ವರ್ ನಿಜವಾಗಿಯೂ ಅಪಾಯಕ್ಕೆ ಒಡ್ಡಿಕೊಂಡಿದೆಯೇ?

ಇಲ್ಲಿಯೇ ಅನೇಕ ತಂಡಗಳು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ತಪ್ಪು ನಿರ್ಧಾರಕ್ಕೆ ಬರುತ್ತವೆ. ಕೇವಲ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯು ಅಪಾಯದ ಪುರಾವೆಯಲ್ಲ, ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಕಾಣುವ ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್ ಸುರಕ್ಷತೆಯ ಪುರಾವೆಯಲ್ಲ.

ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಮಾತ್ರವೇ ಸಾಕಾಗುವುದಿಲ್ಲ. ಲಕ್ಸೆಂಬರ್ಗ್‌ನ CIRCL ಗಮನಿಸಿದಂತೆ, ಸೇವೆಯು ವಾಸ್ತವವಾಗಿ HTTP/2 ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮಾತ್ರ ದುರ್ಬಲ ಮಾರ್ಗವನ್ನು ತಲುಪಲು ಸಾಧ್ಯ. mod_http2 ಲೋಡ್ ಆಗಿದ್ದರೂ ಯಾವುದೇ ಲಿಸನರ್ HTTP/2 ಅನ್ನು ನೀಡದಿದ್ದರೆ, ಆ ಮಾರ್ಗವನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಎರಡೂ ರೀತಿಯ HTTP/2 ಕೂಡ ಮುಖ್ಯವಾಗುತ್ತವೆ. TLS ಮೂಲಕ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ HTTP/2 ಅನ್ನು ಈ ರೀತಿ ಕರೆಯಲಾಗುತ್ತದೆ: h2. TLS ಇಲ್ಲದ ಕ್ಲಿಯರ್‌ಟೆಕ್ಸ್ಟ್ HTTP/2 ಅನ್ನು ಈ ರೀತಿ ಕರೆಯಲಾಗುತ್ತದೆ: h2c. ಯಾವುದೇ ಲಿಸನರ್‌ನಲ್ಲಿ ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಒಂದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದರೂ ಅದು ಮುಖ್ಯವಾಗುತ್ತದೆ.

ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ಗಳು ಭಿನ್ನವಾಗಿರಬಹುದು. ಇಡೀ ಸರ್ವರ್‌ಗಾಗಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು Apache ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಕೇವಲ ಮುಖ್ಯ config ಫೈಲ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದರಿಂದ, ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ HTTP/2 ಅನ್ನು ಆನ್ ಮಾಡಿಕೊಳ್ಳುವ ಒಂದು ಸೈಟ್ ಅನ್ನು ನೀವು ಗಮನಿಸದೇ ಹೋಗಬಹುದು.

ಪ್ರಾಕ್ಸಿಗಳು ಚಿತ್ರಣವನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. CDN, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಮುಂಭಾಗದಲ್ಲಿದ್ದು ಸಂದರ್ಶಕರೊಂದಿಗೆ HTTP/2 ಮಾತನಾಡುತ್ತಾ Apache ನೊಂದಿಗೆ ಕೇವಲ HTTP/1.1 ಮಾತನಾಡಿದರೆ, ಹೊರಗಿನ HTTP/2 ಸೆಶನ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಈ ದೋಷವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ. ಆದರೆ ಆರಿಜಿನ್ ಸರ್ವರ್‌ಗೆ ನೇರ ಪ್ರವೇಶ, ಆಂತರಿಕ ಲಿಸನರ್, ಅಥವಾ Apache ಗೆ HTTP/2 ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಪ್ರಾಕ್ಸಿ ಇದ್ದರೆ ಅದು ಅಪಾಯವನ್ನು ತಂದೊಡ್ಡುತ್ತದೆ.

ರೋಹಿತ್ ಅವರ ಪರಿಸ್ಥಿತಿಯು ಇದು ಏಕೆ ಮುಖ್ಯ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. Acme ನ ಮುಖ್ಯ ವೆಬ್‌ಸೈಟ್ CDN ನ ಹಿಂದಿದೆ, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ಸ್ಕ್ಯಾನ್ ಎಲ್ಲೆಡೆ HTTP/2 ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ಒಳಗಡೆ, ಅವರು ಮೂರು ಸಂದರ್ಭಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ: ಮುಖ್ಯ ಸೈಟ್‌ನ Apache ಕೇವಲ CDN ನಿಂದ HTTP/1.1 ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆಂತರಿಕ ವಿಕಿಯನ್ನು ನೇರವಾಗಿ h2 ಮೂಲಕ ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಒಂದು ಹಳೆಯ ಮಾರ್ಕೆಟಿಂಗ್ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ h2c ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಈ ಮೂರರಲ್ಲಿ ಎರಡಕ್ಕೆ ತಕ್ಷಣದ ಕೆಲಸದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಸ್ಕ್ಯಾನ್ ಅವುಗಳ ಬಗ್ಗೆ ಅವರಿಗೆ ಏನನ್ನೂ ತಿಳಿಸುತ್ತಿರಲಿಲ್ಲ.

ಹಂತ-ಹಂತವಾಗಿ: ರೋಹಿತ್ ಇಂದು ಏನು ಮಾಡುತ್ತಾರೆ

ಹಂತ 1: ಪ್ರತಿಯೊಂದು Apache ಸರ್ವರ್ ಮತ್ತು ಅದರ ಆವೃತ್ತಿಯನ್ನು ಹುಡುಕಿ

ಸರ್ವರ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ನಂತರ ಪ್ರತಿಯೊಂದನ್ನು ಪರಿಶೀಲಿಸಿ. ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಆಧಾರದ ಮೇಲೆ ಕಮಾಂಡ್ ಹೆಸರು ಭಿನ್ನವಾಗಿರುತ್ತದೆ.

# RHEL, Rocky, Alma, Fedora
httpd -v
# Debian, Ubuntu
apache2 -v

ಮಾರಾಟಗಾರರು ಸಾಮಾನ್ಯವಾಗಿ ಮುಖ್ಯ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸದೆಯೇ ದೋಷವನ್ನು ಸರಿಪಡಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ (ಇದನ್ನು ಈ ರೀತಿ ಕರೆಯಲಾಗುತ್ತದೆ: backporting). ಕೇವಲ ಆವೃತ್ತಿಯ ಸ್ಟ್ರಿಂಗ್ ಮಾತ್ರವಲ್ಲದೆ, ನಿಮ್ಮ ಮಾರಾಟಗಾರರ ಅಡ್ವೈಸರಿಗೆ ಅನುಗುಣವಾಗಿ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ.

# RHEL family: is the fix for this CVE available or installed?
dnf updateinfo list --cve CVE-2026-119618
# Debian and Ubuntu: does the installed package mention the CVE?
apt changelog apache2 | grep -i CVE-2026-119618

ಹಂತ 2: HTTP/2 ವಾಸ್ತವವಾಗಿ ಲಭ್ಯವಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಆಗಿದೆಯೇ ಎಂದು ನೋಡಿ, ನಂತರ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ಗಳು ಸೇರಿದಂತೆ ಪ್ರತಿಯೊಂದು config ಫೈಲ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹುಡುಕಿ.

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2
# Where is HTTP/2 enabled? Look for h2 or h2c on any Protocols line
grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null

ನಂತರ ಹೊರಗಿನಿಂದ ಮತ್ತು ಒಳಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ. --http2 TLS ಮೂಲಕ h2 ಗಾಗಿ ವಿನಂತಿಸುತ್ತದೆ, ಮತ್ತು --http2-prior-knowledge ಕ್ಲಿಯರ್‌ಟೆಕ್ಸ್ಟ್ h2c ಅನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. 2 ಎಂಬ ಫಲಿತಾಂಶವು HTTP/2 ಬಳಸಲಾಗಿದೆ ಎಂದು ಅರ್ಥೈಸುತ್ತದೆ.

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://app.example.com/
curl -s -o /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://203.0.113.10/

ಕೇವಲ ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಮಾತ್ರವಲ್ಲದೆ, ಆರಿಜಿನ್ ವಿಳಾಸ ಮತ್ತು ಆಂತರಿಕ ಹೆಸರುಗಳ ವಿರುದ್ಧವೂ ಇವುಗಳನ್ನು ರನ್ ಮಾಡಿ.

ಹಂತ 3: 2.4.71 ಗೆ ಅಥವಾ ಮಾರಾಟಗಾರರ ಪರಿಹಾರವಿರುವ ಪ್ಯಾಕೇಜ್‌ಗೆ ಪ್ಯಾಚ್ ಮಾಡಿ

ನಿಮ್ಮ ಮಾರಾಟಗಾರರ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಅನ್ವಯಿಸಿ (ಅಥವಾ ನೀವು ಮೂಲದಿಂದ Apache ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ 2.4.71 ಅನ್ನು ಬಿಲ್ಡ್ ಮಾಡಿ), ನಂತರ ಹೊಸ ಕೋಡ್ ನಿಜವಾಗಿಯೂ ಚಾಲನೆಯಾಗಲು ಸೇವೆಯನ್ನು ರಿಸ್ಟಾರ್ಟ್ ಮಾಡಿ. ಪ್ಯಾಕೇಜ್ ಅಪ್‌ಡೇಟ್ ನಂತರ ಕೇವಲ ರೀಲೋಡ್ ಮಾಡುವುದು ಯಾವಾಗಲೂ ಸಾಕಾಗುವುದಿಲ್ಲ; ರಿಸ್ಟಾರ್ಟ್ ಮಾಡುವುದು ಸುರಕ್ಷಿತ ಆಯ್ಕೆಯಾಗಿದೆ.

# RHEL family
sudo dnf update httpd mod_http2
sudo systemctl restart httpd
# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

ನಂತರ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಿಲ್ಡ್ ಸರಿಪಡಿಸಲಾದ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಹಂತ 1 ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ.

ಹಂತ 4: ನಿಮಗೆ ಇನ್ನೂ ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, HTTP/2 ಅನ್ನು ಸ್ವಿಚ್ ಆಫ್ ಮಾಡಿ

ತಾತ್ಕಾಲಿಕ ಕ್ರಮವಾಗಿ, ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HTTP/1.1 ಗೆ ಮಿತಿಗೊಳಿಸಿ. ಇದನ್ನು ಮುಖ್ಯ config ನಲ್ಲಿ ಮತ್ತು ತನ್ನದೇ ಆದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಹೊಂದಿಸುವ ಪ್ರತಿಯೊಂದು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಇರಿಸಿ, ಯಾವುದೇ h2 ಮತ್ತು h2c ನಮೂದುಗಳನ್ನು ತೆಗೆದುಹಾಕಿ:

Protocols http/1.1

config ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ, ಅದನ್ನು ಅನ್ವಯಿಸಿ, ಮತ್ತು ಹಂತ 2 ರ curl ಕಮಾಂಡ್‌ಗಳೊಂದಿಗೆ ಮತ್ತೊಮ್ಮೆ ಪರೀಕ್ಷಿಸಿ. ನೀವು ನೋಡಲು ಬಯಸುವುದು 1.1, ಇದನ್ನಲ್ಲ: 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

Debian ಮತ್ತು Ubuntu ನಲ್ಲಿ ನೀವು ಈ ಕಮಾಂಡ್ ಮೂಲಕ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು: sudo a2dismod http2, ನಂತರ ರಿಸ್ಟಾರ್ಟ್ ಮಾಡಿ. ಪ್ಯಾಚ್ ಮಾಡಿದ ನಂತರ HTTP/2 ಮರಳಿ ಬರುವವರೆಗೆ ಕೆಲವು ಸಂದರ್ಶಕರಿಗೆ ಪುಟಗಳು ಸ್ವಲ್ಪ ನಿಧಾನವಾಗಿ ಲೋಡ್ ಆಗುವುದನ್ನು ನಿರೀಕ್ಷಿಸಿ.

ಹಂತ 5: ಹಿಂದಿನ ತೊಂದರೆಯ ಯಾವುದೇ ಚಿಹ್ನೆಗಳಿವೆಯೇ ಎಂದು ನೋಡಿ

ಪ್ಯಾಚ್ ಮಾಡುವುದು ಬಾಗಿಲನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಆದರೆ ಯಾರಾದರೂ ಮೊದಲೇ ಅದರ ಮೂಲಕ ಪ್ರವೇಶಿಸಿದ್ದಾರೆಯೇ ಎಂದು ಅದು ನಿಮಗೆ ತಿಳಿಸುವುದಿಲ್ಲ. ಅನಿರೀಕ್ಷಿತ Apache ವರ್ಕರ್ ಕ್ರ್ಯಾಶ್‌ಗಳು, ವಿಚಿತ್ರ ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಗಳು, ವೆಬ್ ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿ ಅನಧಿಕೃತ ಫೈಲ್ ಬದಲಾವಣೆಗಳು, ಮತ್ತು ಸರ್ವರ್‌ನಿಂದ ಅಸಾಮಾನ್ಯ ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳನ್ನು ಪರಿಶೀಲಿಸಲು CIRCL ಸೂಚಿಸುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಳಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರತಿಯೊಂದನ್ನೂ ಪರಿಶೀಲಿಸುವುದು ಅಗತ್ಯವಾಗಿದೆ.

ಎಕ್ಸ್‌ಪ್ಲಾಯ್ಟ್ ವರದಿಗಳ ಬಗ್ಗೆ

ಮೂಲಗಳು ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಿವೆ, ಆದ್ದರಿಂದ ಮುಖ್ಯಾಂಶಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಿ. mod_http2 ಸಕ್ರಿಯಗೊಳಿಸಲಾದ ಡೀಫಾಲ್ಟ್ ಸರ್ವರ್ ವಿರುದ್ಧ ವಿಶ್ವಾಸಾರ್ಹ ದುರುಪಯೋಗವನ್ನು ಸಾರ್ವಜನಿಕ ಸಂಶೋಧನೆಯು ತೋರಿಸಿದೆ ಎಂದು Red Hat ಹೇಳುತ್ತದೆ. ನವೆಂಬರ್ 11 ರಂದು Wiz, ಯಾವುದೇ ಎಕ್ಸ್‌ಪ್ಲಾಯ್ಟ್ ಲಭ್ಯವಿಲ್ಲ ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ ಸಾರ್ವಜನಿಕವಾಗಿ ಯಾವುದೇ ದಾಳಿಗಳು ಕಂಡುಬಂದಿಲ್ಲ ಎಂದು ಹೇಳಿದೆ. ಒಂದು ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯು ಸಾರ್ವಜನಿಕವಾಗಿ ದಾಳಿಗಳು ನಡೆದಿವೆ ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ ಎಂದು CIRCL ಗಮನಿಸಿದೆ.

ತನ್ನದೇ ಆದ ಡೇಟಾದಲ್ಲಿರುವ 64% ಕ್ಲೌಡ್ ಪರಿಸರಗಳು ಈ ದೋಷಕ್ಕೆ ತುತ್ತಾಗಬಹುದಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು Wiz ವರದಿ ಮಾಡಿದೆ. ಆ ಅಂಕಿಅಂಶವು Wiz ನ ಡೇಟಾಸೆಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆಯೇ ಹೊರತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ Apache ಸರ್ವರ್‌ಗಳ ಪಾಲನ್ನಲ್ಲ.

ಸುರಕ್ಷಿತ ತೀರ್ಮಾನ: ಈ ವರದಿಗಳಲ್ಲಿ ಯಾವುದೇ ದೃಢಪಡಿಸಿದ ದಾಳಿ ಅಭಿಯಾನ ಕಂಡುಬಂದಿಲ್ಲ, ಆದರೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ತಂತ್ರವನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ತ್ವರಿತವಾಗಿ ಪ್ಯಾಚ್ ಮಾಡಿ.

ಇದನ್ನು ಯಾರು ಕಂಡುಕೊಂಡರು, ಮತ್ತು 2.4.71 ಬೇರೆ ಏನನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ

Apache ಸಂಸ್ಥೆಯು Anthropic ನ OSS Scanner ಹಾಗೂ Google Cloud Vulnerability Research ನ Anthony Weems ಮತ್ತು Simon Scannell ಅವರಿಗೆ ಇದರ ಶ್ರೇಯಸ್ಸನ್ನು ನೀಡಿದೆ. ಕಾಲಮಿತಿಯು ಅಕ್ಟೋಬರ್ 26 ರಂದು Anthropic ನಿಂದ ವರದಿ, ನವೆಂಬರ್ 3 ರಂದು Google ನಿಂದ ವರದಿ, ಮತ್ತು ನವೆಂಬರ್ 11 ರಂದು ಪರಿಹಾರ ಮತ್ತು ಬಿಡುಗಡೆಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಆವೃತ್ತಿ 2.4.71 ಇತರ ಎರಡು ಸಣ್ಣ ಸಮಸ್ಯೆಗಳನ್ನು ಸಹ ಸರಿಪಡಿಸುತ್ತದೆ:

• CVE-2026-106023 (Important): 2.4.30 ರಿಂದ 2.4.70 ರವರೆಗಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಬಹುದಾದ mod_md ನಲ್ಲಿನ null-pointer dereference.
• CVE-2026-109163 (Low): 2.4.69 ಮತ್ತು 2.4.70 ಆವೃತ್ತಿಗಳಲ್ಲಿ, mod_vhost_alias ನಲ್ಲಿನ stack-buffer overwrite.

ಉಪಸಂಹಾರ

CVE-2026-119618 ಗಂಭೀರವಾಗಿದೆ: ಯಾವುದೇ ಲಾಗಿನ್ ಅಗತ್ಯವಿಲ್ಲ, ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ತಲುಪಬಹುದು, ವೆಬ್ ಸರ್ವರ್‌ನ ನಿಯಂತ್ರಣ ಸಾಧ್ಯ. ಆದರೆ ನೈಜ ಅಪಾಯವು HTTP/2 ಅಥವಾ h2c ಲಭ್ಯವಿದೆಯೇ, ನಿಮ್ಮ ಮಾರಾಟಗಾರರ ಪ್ಯಾಕೇಜ್, ಮತ್ತು ಟ್ರಾಫಿಕ್ Apache ಅನ್ನು ಹೇಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ ಅನ್ನು ಹುಡುಕಿ, ಪ್ರತಿಯೊಂದು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, 2.4.71 ಅಥವಾ ಮಾರಾಟಗಾರರ ಪರಿಹಾರಕ್ಕೆ ಪ್ಯಾಚ್ ಮಾಡಿ, ನೀವು ಕಾಯಬೇಕಾದ ಸ್ಥಳಗಳಲ್ಲಿ HTTP/2 ಅನ್ನು ಆಫ್ ಮಾಡಿ, ಮತ್ತು ನಂತರ ಹಿಂದಿನ ದುರುಪಯೋಗದ ಯಾವುದೇ ಚಿಹ್ನೆಗಳಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಅನುಕೂಲಗಳು

• ಪರಿಹಾರವು ಈಗಾಗಲೇ ಬಿಡುಗಡೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ಸುರಕ್ಷತೆಗೆ ಸ್ಪಷ್ಟ ಮಾರ್ಗವಿದೆ.
• ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವಾಗಿ ಒಂದು config ಸಾಲಿನೊಂದಿಗೆ HTTP/2 ಅನ್ನು ಸ್ವಿಚ್ ಆಫ್ ಮಾಡಬಹುದು.
• RHEL 8 ಮತ್ತು ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಬಾಧಿತವಾಗಿಲ್ಲ, ಮತ್ತು RHEL 9 ಹಾಗೂ 10 ಅನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದು ಕಷ್ಟಕರವಾಗಿದೆ.
• Apache ನೊಂದಿಗೆ ಕೇವಲ HTTP/1.1 ಮಾತನಾಡುವ ಪ್ರಾಕ್ಸಿ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• Apache ಪ್ರಕ್ರಿಯೆಯು ಏನನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿಸಲು ಈ ಪರಿಶೀಲನೆಯು ಉತ್ತಮ ಅವಕಾಶವಾಗಿದೆ.

ಅನನುಕೂಲಗಳು

• ಈ ದೋಷಕ್ಕೆ ಯಾವುದೇ ಲಾಗಿನ್ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು 9.8 ಸ್ಕೋರ್ ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಅಪಾಯಕ್ಕೆ ಒಡ್ಡಿಕೊಂಡ ಸರ್ವರ್‌ಗಳು ನಿಜವಾದ ಅಪಾಯದಲ್ಲಿವೆ.
• ಮಾರಾಟಗಾರರು ಪರಿಹಾರಗಳನ್ನು backport ಮಾಡುವುದರಿಂದ ಆವೃತ್ತಿಯ ಸ್ಟ್ರಿಂಗ್‌ಗಳು ತಪ್ಪುದಾರಿಗೆಳೆಯಬಹುದು.
• ಪ್ರತಿ ವರ್ಚುವಲ್-ಹೋಸ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದಾಗಿ ಅಪಾಯಕ್ಕೊಳಗಾದ ಒಂದು ಸೈಟ್ ಅನ್ನು ಗಮನಿಸದೇ ಬಿಡುವುದು ಸುಲಭವಾಗುತ್ತದೆ.
• HTTP/2 ಅನ್ನು ಆಫ್ ಮಾಡುವುದರಿಂದ ಕೆಲವು ಪುಟಗಳು ಸ್ವಲ್ಪ ನಿಧಾನವಾಗಿ ಲೋಡ್ ಆಗಬಹುದು.
• ಪರಿಹಾರಕ್ಕೆ ಮುಂಚಿತವಾಗಿ ಸರ್ವರ್ ಮೇಲೆ ದಾಳಿ ನಡೆದಿದೆಯೇ ಎಂಬುದನ್ನು ಪ್ಯಾಚ್ ಮಾಡುವುದು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕ ಉದ್ದೇಶಕ್ಕಾಗಿ ಮಾತ್ರ. ಹೋಸ್ಟ್ ಹೆಸರುಗಳು, IP ವಿಳಾಸಗಳು ಮತ್ತು Acme ಕಂಪನಿಯ ಹೆಸರು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳಾಗಿದ್ದು, ಅವುಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ವಿವರಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು. ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ಗಳು ಮತ್ತು ಆವೃತ್ತಿಗಳ ನಡುವೆ ಕಮಾಂಡ್‌ಗಳು ಬದಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಮಾರಾಟಗಾರರ ಅಡ್ವೈಸರಿಯನ್ನು ಓದಿ ಮತ್ತು ಮೊದಲು ನಾನ್-ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ. ಎಕ್ಸ್‌ಪ್ಲಾಯ್ಟ್‌ಗಳು ಮತ್ತು ಬಾಧಿತ ಶ್ರೇಣಿಗಳ ಬಗೆಗಿನ ಮಾಹಿತಿಯು ಇಲ್ಲಿ ಸಾರಾಂಶಗೊಳಿಸಲಾದ ಮಾರಾಟಗಾರರ ಮತ್ತು ಸಂಶೋಧಕರ ಹೇಳಿಕೆಗಳಿಂದ ಬಂದಿದ್ದು ಬದಲಾಗಬಹುದು, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ಅಧಿಕೃತ Apache ಮತ್ತು ಮಾರಾಟಗಾರರ ಸಲಹೆಗಳೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• CVE-2026-119618 ಎಂದರೇನು? — ಇದು Apache HTTP Server ನ HTTP/2 ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿನ ಗಂಭೀರ ಮೆಮೊರಿ-ಕರಪ್ಶನ್ ದೋಷವಾಗಿದ್ದು, ಇದು ದೃಢೀಕರಣವಿಲ್ಲದೆಯೇ ರಿಮೋಟ್ ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ಗೆ ಅವಕಾಶ ನೀಡಬಹುದು.
• ಯಾವ Apache ಆವೃತ್ತಿಗಳು ಬಾಧಿತವಾಗಿವೆ? — Apache HTTP Server 2.4.55 ರಿಂದ 2.4.70 ರವರೆಗೆ, ಜೊತೆಗೆ ಪ್ರತ್ಯೇಕ mod_h2 ಮಾಡ್ಯೂಲ್ ಆವೃತ್ತಿಗಳು 2.0.8 ರಿಂದ 2.0.42 ರವರೆಗೆ.
• ಯಾವ ಆವೃತ್ತಿಯು ಇದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ? — ನವೆಂಬರ್ 11, 2026 ರಂದು ಬಿಡುಗಡೆಯಾದ Apache HTTP Server 2.4.71, ಅಥವಾ ಈ ಪರಿಹಾರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಒಳಗೊಂಡಿರುವ ಮಾರಾಟಗಾರರ ಪ್ಯಾಕೇಜ್.
• mod_http2 ಲೋಡ್ ಆಗಿದ್ದರೂ HTTP/2 ಸಕ್ರಿಯವಾಗಿಲ್ಲದಿದ್ದರೆ ನನ್ನ ಸರ್ವರ್ ಸುರಕ್ಷಿತವೇ? — ದುರ್ಬಲ ಮಾರ್ಗಕ್ಕೆ ಸೇವೆಯು HTTP/2 ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಲಿಸನರ್‌ನಲ್ಲಿ h2 ಅಥವಾ h2c ಯಾವುದನ್ನೂ ನೀಡದ ಸರ್ವರ್ ಅನ್ನು ಈ ದೋಷದ ಮೂಲಕ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ನಾನು CDN ಅಥವಾ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದಿದ್ದರೆ ಸುರಕ್ಷಿತವೇ? — ಪ್ರಾಕ್ಸಿಯು Apache ನೊಂದಿಗೆ ಕೇವಲ HTTP/1.1 ಮಾತನಾಡಿದರೆ ಮತ್ತು ಯಾರೂ ಆರಿಜಿನ್ ಸರ್ವರ್ ಅನ್ನು ನೇರವಾಗಿ HTTP/2 ಮೂಲಕ ತಲುಪಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಮಾತ್ರ.
• RHEL ಬಾಧಿತವಾಗಿದೆಯೇ? — RHEL 8 ಮತ್ತು ಹಿಂದಿನ ಆವೃತ್ತಿಗಳು ಬಾಧಿತವಾಗಿಲ್ಲ; RHEL 9 ಮತ್ತು 10 ಅನ್ನು Important ಎಂದು ರೇಟ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳಿಗೆ Red Hat ನ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕು.
• Apache ನಲ್ಲಿ HTTP/2 ಅನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಹೇಗೆ? — ಇದನ್ನು ಸೆಟ್ ಮಾಡಿ: Protocols http/1.1 ಮುಖ್ಯ config ಮತ್ತು ಪ್ರತಿಯೊಂದು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, config ಪರೀಕ್ಷೆ ನಡೆಸಿ, ನಂತರ Apache ಅನ್ನು ರೀಲೋಡ್ ಮಾಡಿ.
• ಈ ದೋಷವನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆಯೇ? — ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ವರದಿಗಳು ಸಾರ್ವಜನಿಕ ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತವೆಯೇ ಹೊರತು ಯಾವುದೇ ದೃಢಪಡಿಸಿದ ದಾಳಿಗಳನ್ನಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಅಭಿಯಾನವನ್ನು ಊಹಿಸದೆ ತ್ವರಿತವಾಗಿ ಪ್ಯಾಚ್ ಮಾಡಿ.

ಟ್ಯಾಗ್‌ಗಳು

#apache #cybersecurity #cve2026119618 #http2 #modhttp2 #vulnerabilitymanagement #patchmanagement #linuxsecurity #webserver #devsecops