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 అని పిలిచే కంపెనీలోని సిస్టమ్ అడ్మినిస్ట్రేటర్ అయిన Rohit ని ఉదాహరణగా తీసుకుంటూ, ఈ గైడ్ ఈ మూడింటినీ వివరిస్తుంది.

ఏం జరిగింది, సరళమైన మాటల్లో

HTTP/2 అనేది వెబ్ యొక్క ప్రధాన ప్రోటోకాల్ యొక్క సరికొత్త వెర్షన్. దీని ముఖ్య ఉద్దేశ్యం ఏమిటంటే, ఒకే సమయంలో అనేక రిక్వెస్ట్‌లు మరియు రెస్పాన్స్‌లు ఒకే కనెక్షన్‌ను పంచుకోగలవు, ఇది వెబ్‌సైట్‌లను వేగవంతం చేస్తుంది. Apache లో, ఈ ఫీచర్ ఈ పేరుతో పిలవబడే మాడ్యూల్ నుండి వస్తుంది: mod_http2.

ఒకే కనెక్షన్‌ను పంచుకోవడం అంటే సర్వర్ యొక్క అనేక భాగాలు ఒకేసారి పనిచేస్తాయి, మరియు ఏ మెమరీ భాగాన్ని ఎవరు ఉపయోగించాలో అవి జాగ్రత్తగా ఉండాలి. Red Hat సాంకేతిక అంచనా ప్రకారం, ఇక్కడే ఆ జాగ్రత్త విఫలమైంది. ఒక worker thread (ఒక రిక్వెస్ట్‌ను నిర్వహించే సర్వర్ భాగం) ఈ క్రింది భాగం యొక్క మెమరీలోకి వ్రాయగలదు: connection thread (మొత్తం కనెక్షన్‌ను నిర్వహించే భాగం), ఇది ఒక షేర్డ్, lock-free memory allocator ద్వారా జరుగుతుంది. సమస్య ఈ క్రింది పేరు గల ఫంక్షన్‌లో ఉంది assign_headers(). రెండు భాగాలు సమన్వయం లేకుండా ఒకే మెమరీకి వ్రాసినప్పుడు, అంతర్గత మెమరీ కరప్ట్ కావచ్చు, మరియు మెమరీ కరప్షన్ అనేది తరచుగా దాడిదారుడి కోడ్‌ను రన్ చేయడానికి మార్గం సుగమం చేస్తుంది.

Red Hat ఈ లోపానికి 10కి 9.8 CVSS v3.1 స్కోరును ఇచ్చింది. ఆ స్కోరు ప్రకారం దాడి నెట్‌వర్క్ ద్వారా పనిచేస్తుంది, ఎటువంటి పాస్‌వర్డ్ అవసరం లేదు మరియు యూజర్ నుండి ఎలాంటి సహాయం అవసరం లేదు.

ఏ వెర్షన్‌లు ప్రభావితమయ్యాయి

Apache ఈ క్రింది శ్రేణులను ప్రభావితమైనవిగా పేర్కొంది:

• Apache HTTP Server 2.4.55 through 2.4.70.
• ప్రత్యేకంగా విడుదల చేయబడిన mod_h2 GitHub నుండి వచ్చిన మాడ్యూల్, వెర్షన్‌లు 2.0.8 through 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 ఫైల్‌లలో నిల్వ చేయబడిన ఆధారాలు (credentials), మరియు అంతర్గత నెట్‌వర్క్‌లోని డేటాబేస్‌ల వంటి ఏవైనా బ్యాకెండ్ సేవలు.

కాబట్టి తక్కువ అధికారాలు కలిగిన యూజర్‌గా రన్ అవుతున్న చక్కగా వేరుచేయబడిన (well-isolated) సర్వర్‌పై జరిగే నష్టం, Apache బాక్స్‌లోని ప్రతి రహస్యాన్ని చదవగలిగే సర్వర్‌పై జరిగే నష్టం కంటే తక్కువగా ఉంటుంది. దానిని కూడా తనిఖీ చేయడానికి ఇది మంచి సమయం.

మీ సర్వర్ నిజంగా ఎక్స్‌పోజ్ అయిందా?

ఇక్కడే చాలా బృందాలు రెండు విధాలుగానూ తప్పుగా అర్థం చేసుకుంటాయి. కేవలం వెర్షన్ నంబర్ మాత్రమే ప్రమాదానికి రుజువు కాదు, మరియు సురక్షితంగా కనిపించే పబ్లిక్ వెబ్‌సైట్ భద్రతకు రుజువు కాదు.

మాడ్యూల్‌ను లోడ్ చేయడం మాత్రమే సరిపోదు. సర్వీస్ వాస్తవానికి HTTP/2 ను అంగీకరించినప్పుడు మాత్రమే హానికరమైన మార్గాన్ని చేరుకోవచ్చని Luxembourg కు చెందిన CIRCL పేర్కొంది. mod_http2 లోడ్ చేయబడినప్పటికీ, ఏ లిజనర్ కూడా HTTP/2 ని అందించకపోతే, ఆ మార్గాన్ని చేరుకోలేరు.

రెండు రకాల HTTP/2 లు పరిగణనలోకి వస్తాయి. TLS పై ఎన్‌క్రిప్ట్ చేయబడిన HTTP/2 ను ఇలా పిలుస్తారు: h2. TLS లేని క్లియర్‌టెక్స్ట్ HTTP/2 ను ఇలా పిలుస్తారు: h2c. ఏ లిజనర్‌పై అయినా వీటిలో ఏది ఎనేబుల్ చేయబడి ఉన్నా అది ముఖ్యమైనదే.

Virtual hosts వేర్వేరుగా ఉండవచ్చు. మొత్తం సర్వర్ కోసం మరియు ప్రతి వర్చువల్ హోస్ట్ కోసం విడివిడిగా ప్రోటోకాల్‌లను సెట్ చేయడానికి Apache మిమ్మల్ని అనుమతిస్తుంది. కేవలం ప్రధాన config ఫైల్‌ను మాత్రమే సమీక్షించడం వలన స్వయంగా HTTP/2 ని ఆన్ చేసుకునే సైట్‌ను విస్మరించే అవకాశం ఉంది.

ప్రాక్సీలు పరిస్థితిని మారుస్తాయి. ఒక CDN, లోడ్ బ్యాలెన్సర్ లేదా రివర్స్ ప్రాక్సీ ముందు ఉండి, సందర్శకులతో HTTP/2 లోనూ మరియు Apache తో కేవలం HTTP/1.1 లోనూ కమ్యూనికేట్ చేస్తే, బయటి HTTP/2 సెషన్ దానంతటదే ఈ బగ్‌ను ఎక్స్‌పోజ్ చేయదు. కానీ ఆరిజిన్ సర్వర్‌కు ప్రత్యక్ష యాక్సెస్, అంతర్గత లిజనర్ లేదా Apache కి HTTP/2 ని ఫార్వర్డ్ చేసే ప్రాక్సీ ఉంటే మాత్రం ప్రమాదానికి గురిచేస్తుంది.

ఇది ఎందుకు ముఖ్యమో Rohit పరిస్థితి తెలియజేస్తుంది. Acme యొక్క ప్రధాన వెబ్‌సైట్ ఒక CDN వెనుక ఉంది, కాబట్టి పబ్లిక్ స్కాన్ ప్రతిచోటా HTTP/2 ని చూపిస్తుంది. అంతర్గతంగా, అతను మూడు కేసులను గమనించాడు: ప్రధాన సైట్ యొక్క Apache కేవలం CDN నుండి HTTP/1.1 ని మాత్రమే స్వీకరిస్తుంది, అంతర్గత వికీ నేరుగా h2 ద్వారా యాక్సెస్ చేయబడుతోంది, మరియు ఒక పాత మార్కెటింగ్ వర్చువల్ హోస్ట్ దానంతటదే h2c ని ఎనేబుల్ చేస్తుంది. ఈ మూడింటిలో రెండింటికి తక్షణ చర్యలు అవసరం, మరియు పబ్లిక్ స్కాన్ వాటి గురించి అతనికి ఏమీ చెప్పి ఉండేది కాదు.

దశలవారీగా: ఈ రోజు Rohit ఏమి చేస్తాడు

దశ 1: ప్రతి Apache సర్వర్‌ను మరియు దాని వెర్షన్‌ను కనుగొనండి

సర్వర్‌ల జాబితాను రూపొందించి, ఆపై ప్రతిదాన్ని తనిఖీ చేయండి. distribution ని బట్టి కమాండ్ పేరు మారుతుంది.

# 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 ని బిల్డ్ చేయండి), ఆపై కొత్త కోడ్ నిజంగా రన్ అయ్యేలా సర్వీస్‌ను రీస్టార్ట్ చేయండి. ప్యాకేజ్ అప్‌డేట్ తర్వాత reload ఎల్లప్పుడూ సరిపోకపోవచ్చు; restart చేయడం సురక్షితమైన ఎంపిక.

# 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 worker క్రాష్‌లు, విచిత్రమైన child processes, వెబ్ ఫోల్డర్‌లలో అనధికారిక ఫైల్ మార్పులు మరియు సర్వర్ నుండి అసాధారణమైన అవుట్‌బౌండ్ కనెక్షన్‌లను సమీక్షించాలని CIRCL సూచిస్తుంది. వీటిలో ఏ ఒక్కటీ సొంతంగా దాడిని నిరూపించలేవు, కానీ ప్రతి ఒక్కటీ పరిశీలించదగినవే.

ఎక్స్‌ప్లాయిట్ నివేదికల గురించి

మూలాలు భిన్నాభిప్రాయాలు వ్యక్తం చేస్తున్నాయి, కాబట్టి ముఖ్యాంశాలను జాగ్రత్తగా చదవండి. mod_http2 ఎనేబుల్ చేయబడిన డిఫాల్ట్ సర్వర్‌పై విశ్వసనీయమైన ఎక్స్‌ప్లాయిటేషన్‌ను పబ్లిక్ పరిశోధన చూపించిందని Red Hat చెబుతోంది. నవంబర్ 11న Wiz మాట్లాడుతూ, ఎటువంటి ఎక్స్‌ప్లాయిట్ అందుబాటులో లేదని మరియు ఆ సమయంలో ఇన్-ది-వైల్డ్‌లో ఎలాంటి దాడులు కనిపించలేదని తెలిపింది. ఒక ప్రదర్శన (demonstration) వాస్తవ ప్రపంచ దాడులను నిరూపించదని CIRCL పేర్కొంది.

Wiz తన సొంత డేటాలోని 64% క్లౌడ్ ఎన్విరాన్‌మెంట్‌లలో ఈ లోపానికి గురయ్యే రిసోర్స్‌లు ఉన్నాయని నివేదించింది. ఆ సంఖ్య Wiz యొక్క డేటాసెట్‌ను వివరిస్తుంది తప్ప, ఇంటర్నెట్‌లోని మొత్తం Apache సర్వర్‌ల వాటాను కాదు.

సురక్షితమైన అవగాహన: ఈ నివేదికలలో ఎటువంటి ధృవీకరించబడిన దాడి ప్రచారం (attack campaign) లేదు, కానీ పనిచేసే టెక్నిక్ చూపబడింది, కాబట్టి త్వరగా ప్యాచ్ చేయండి.

దీన్ని ఎవరు కనుగొన్నారు, మరియు 2.4.71 ఇంకా వేటిని సరిచేస్తుంది

Anthropic యొక్క OSS Scanner కి మరియు Google Cloud Vulnerability Research కి చెందిన Anthony Weems మరియు Simon Scannell లకు Apache క్రెడిట్ ఇస్తుంది. కాలక్రమం ప్రకారం అక్టోబర్ 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 అనేవి కేవలం ఉదాహరణలు (placeholders) మరియు వాటిని మీ స్వంత వాటితో భర్తీ చేయాలి. distributions మరియు వెర్షన్‌ల మధ్య కమాండ్‌లు మారుతూ ఉంటాయి, కాబట్టి మీ వెండర్ అడ్వైజరీని చదవండి మరియు మార్పులను ముందుగా నాన్-ప్రొడక్షన్ సర్వర్‌పై పరీక్షించండి. ఎక్స్‌ప్లాయిట్‌లు మరియు ప్రభావిత శ్రేణుల గురించిన క్లెయిమ్‌లు ఇక్కడ సంగ్రహించబడిన వెండర్ మరియు పరిశోధకుల ప్రకటనల నుండి వచ్చాయి మరియు అవి మారవచ్చు, కాబట్టి వాటిపై ఆధారపడటానికి ముందు అధికారిక Apache మరియు వెండర్ అడ్వైజరీలతో వాటిని ధృవీకరించుకోండి.

తరచుగా అడిగే ప్రశ్నలు

• CVE-2026-119618 అంటే ఏమిటి? — ఇది Apache HTTP Server యొక్క HTTP/2 మాడ్యూల్‌లోని క్లిష్టమైన memory-corruption లోపం, ఇది ఆథెంటికేషన్ లేకుండానే రిమోట్ కోడ్ ఎగ్జిక్యూషన్‌ను అనుమతించగలదు.
• ఏ 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 ని reload చేయండి.
• ఈ లోపం ఇన్-ది-వైల్డ్‌లో ఎక్స్‌ప్లాయిట్ చేయబడుతోందా? — ఇక్కడ పేర్కొన్న నివేదికలు పబ్లిక్ ప్రదర్శనను వివరిస్తున్నాయి కానీ ఇన్-ది-వైల్డ్‌లో ఎలాంటి నిర్ధారిత దాడులు లేవు, కాబట్టి ఎలాంటి దాడి ప్రచారాన్ని ఊహించకుండా త్వరగా ప్యాచ్ చేయండి.

ట్యాగ్‌లు

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