log4j-check

log4j 2025/2026 के इस "कॉन्फ़िगरेशन साइलेंट रूप से विफल" घोषणाओं के बैच के लिए स्व-जाँच उपकरण। शून्य रनटाइम निर्भरता, एकल jar, नेटवर्क से जुड़ता नहीं।

⚠️ पहले बात साफ़ कर लें: ये सभी medium हैं, एक भी RCE नहीं है, Log4Shell जैसा कुछ नहीं है। इन सबकी समान विशेषता यह है कि कॉन्फ़िगरेशन बिना किसी त्रुटि के साइलेंट रूप से विफल हो गया —— प्रॉपर्टी को साइलेंट रूप से अनदेखा किया गया, प्रॉपर्टी का नाम साइलेंट रूप से बदल दिया गया, लॉग साइलेंट रूप से खो दिए गए। इसलिए केवल संस्करण संख्या देखकर यह नहीं पता चल सकता कि आप वास्तव में प्रभावित हैं या नहीं, कॉन्फ़िगरेशन पढ़ना आवश्यक है। यदि आप CVE-2021-44228 (Log4Shell) खोज रहे हैं, तो यह उपकरण आपकी सहायता नहीं कर सकता।

java -jar log4j-check.jar app.jar          # fat jar 里带配置,一步到位
java -jar log4j-check.jar ./target ./src   # 构建产物 + 源码
java -jar log4j-check.jar ~/.m2/repository --no-config

यह किस प्रश्न का उत्तर देता है

Dependabot आपको बताता है कि "log4j में N कमज़ोरियाँ हैं"। यह टूल उन तीन सवालों के जवाब देता है जिनका जवाब वह नहीं देता:

1. आपको वास्तव में किस संस्करण तक अपग्रेड करना चाहिए? —— किसी एक advisory की नकल करना नहीं, बल्कि मिलने वाली प्रविष्टियों का एक-एक करके प्रतिच्छेद (intersection) निकालना।
2. इन 7 में से आप वास्तव में कितनी से प्रभावित हैं? —— हर एक के लिए आवश्यक है कि आपने कोई विशिष्ट layout / appender उपयोग किया हो, और वे चीज़ें log4j2.xml में लिखी होती हैं, जिन्हें पढ़ा जा सकता है, और सटीक रूप से पढ़ा जा सकता है।
3. क्या आप उन लोगों में हैं जो「पहले ही अपग्रेड कर चुके हैं और मानते हैं कि ठीक हो गया」? —— इनमें दो पैच-अंतराल श्रृंखलाएँ हैं।

तीन भार-वहन करने वाले निष्कर्ष(सभी स्वयं सत्यापित किए जा सकते हैं)

एक、🔥 जिन्होंने 2.25.4 तक अपग्रेड किया, वे पूरी तरह नहीं पहुँचे(छूटी हुई वह प्रविष्टि, जिसे कभी Dependabot भी रिपोर्ट नहीं कर पाता था)

इन 7 में से, 6 के फ़िक्स संस्करण ≤ 2.25.4 हैं। इसलिए अधिकांश लोग「2.25.4 तक अपग्रेड करें」यह उत्तर निकालेंगे।

लेकिन CVE-2026-49844 के लिए 2.25.5 चाहिए(2.26 लाइन के लिए 2.26.1)। इसकी advisory में मूल रूप से लिखा है कि यह CVE-2026-34481 का अपूर्ण फ़िक्स है:

संस्करण 2.25.4 में जारी किया गया फ़िक्स सभी प्रभावित कोड पथों को कवर नहीं करता था। शेष समस्या के लिए CVE-2026-49844 निर्दिष्ट किया गया था …

📌 सुधार(2026-08-16)

इस अनुभाग में मूल रूप से लिखा था「और यही वह प्रविष्टि है जिसे Dependabot संरचनात्मक रूप से रिपोर्ट नहीं कर सकता」—— वह वाक्य अब आधा ही सही है।

GHSA-qv9r-c865-cp47 को 2026-08-13 को GitHub द्वारा reviewed में बदल दिया गया और पैकेज जानकारी पूरी कर दी गई, जोड़े गए दो रेंज हैं >= 2.13.1, < 2.25.5 और >= 2.26.0, < 2.26.1:

• ✅ 2.x चलाने वाले लोगों को अब Dependabot चेतावनी मिल सकती है।
• 🔴 लेकिन 3.x प्रीव्यू लाइन(3.0.0-alpha1 ~ 3.0.0-beta2)के लिए अब तक कोई संगत रेंज नहीं है, उस लाइन के लिए अभी भी रिपोर्ट नहीं हो सकती।

अपग्रेड निष्कर्ष बिल्कुल नहीं बदला —— log4j-api के लिए अभी भी 2.25.5 चाहिए(2.26 लाइन के लिए 2.26.1)। बदला है तो केवल यह कि「मशीन इसे देख पाती है या नहीं」。इस टूल की निर्धारण तालिका को संस्करण लाइन के अनुसार एक-एक करके अद्यतन किया गया है, रिपोर्ट में छपी संख्याएँ तालिका से गणना की जाती हैं, अब हार्डकोड नहीं हैं।

🔑 यह बात स्वयं उस पुराने उदाहरण से अधिक याद रखने योग्य है: advisory का स्वरूप समय के साथ अपस्ट्रीम द्वारा पूरा किया जाता है, और आपके पिछले स्कैन का निष्कर्ष स्वयं अद्यतन नहीं होगा, और कोई आपको सूचित भी नहीं करेगा। 「उस समय स्कैन कर लिया था」और「अब सुरक्षित है」, ये दो अलग बातें हैं।

इसकी GitHub advisory(GHSA-qv9r-c865-cp47)2026-08-13 से पहले unreviewed थी, और vulnerabilities सरणी खाली थी —— कोई पैकेज नाम नहीं, कोई संस्करण रेंज नहीं, कोई फ़िक्स संस्करण नहीं, उस अवधि में Dependabot को आपके निर्भरता वृक्ष से तुलना करने के लिए कोई भी डेटा नहीं मिलता था।

OSV.dev पर उस समय भी ऐसा ही था: अन्य 6 प्रविष्टियाँ GHSA alias के माध्यम से Maven निर्देशांक प्राप्त कर सकती थीं, केवल यही नहीं कर सकती थी (OSV में इसका GHSA alias भी नहीं था)। यह तीसरे स्रोत पर स्वतंत्र प्रमाण है, tools/recheck_before_publish.py हर बार दोबारा चलाने पर पुनः सत्यापित करता है (यह स्क्रिप्ट अब「पूरा हो चुका」इस बात को भी स्वयं रिपोर्ट करती है)।

🔴 इस प्रविष्टि को「Dependabot काम नहीं आता」के रूप में न पढ़ें। यह「यह डेटा उस समय मौजूद नहीं था」है, न कि「इस टूल में बग है」。 unreviewed GitHub की सामान्य प्रक्रिया स्थिति है, और 08-13 का पूर्णीकरण उसी प्रक्रिया के सामान्य रूप से पूरा होने का परिणाम है।

दूसरी श्रृंखला है CVE-2025-68161(2.25.3)→ CVE-2026-34477(2.25.4): verifyHostName प्रॉपर्टी 2.12.0 से पेश हुई, लेकिन 2.25.3 तक लगातार चुपचाप अनदेखी की गई, सेट करना बराबर था कि सेट न करना। 68161 के अनुसार 2.25.3 तक अपग्रेड करने वाले, और प्रॉपर्टी(न कि system property)से होस्टनेम सत्यापन कॉन्फ़िगर करने वाले लोग, अभी भी प्रभावित हैं।

दो、निर्धारण का ग्रैन्युलैरिटी CVE × मॉड्यूल है, कुल 4 मॉड्यूल

मॉड्यूल	मिलने वाली प्रविष्टियाँ	किस तक अपग्रेड करें
log4j-core	34477 / 34478 / 34480 / 68161	2.25.4
log4j-api	49844	2.25.5(2.26 लाइन: 2.26.1)
log4j-1.2-api	34479	2.25.4
log4j-layout-template-json	34481	2.25.4

लक्ष्य संस्करण एक ही संख्या नहीं है। और अधिकांश परियोजनाओं के pom में केवल log4j-core लिखा होता है —— उस एक निर्देशांक से पीछे देखने पर केवल 4 प्रविष्टियाँ मिलती हैं, अन्य 3 उनके लिए अस्तित्व में ही नहीं हैं।

यह टूल चारों मॉड्यूल के संस्करण अलग-अलग स्कैन करता है और अलग-अलग निर्धारण करता है। जब चारों मॉड्यूल के संस्करण अलग-अलग हों(BOM ओवरराइड, मैन्युअल exclusion, पुराने WAR में दो पीढ़ियों के jar भरे होना)तो यह स्पष्ट रूप से रिपोर्ट करता है।

तीन, शोर कम करना: हर प्रविष्टि के लिए एक विशिष्ट layout / appender आवश्यक है, और वह कॉन्फ़िगरेशन में लिखा होता है

CVE	ट्रिगर की शर्तें (आधिकारिक मूल पाठ से ली गई)
CVE-2026-34477	<Ssl> का verifyHostName गुण + Socket / Syslog / SMTP appender
CVE-2025-68161	SocketAppender + TLS
CVE-2026-34478	सीधे Rfc5424Layout कॉन्फ़िगर करना (SyslogAppender का उपयोग करने वाले प्रभावित नहीं हैं)
CVE-2026-34480	log4j-core का XmlLayout
CVE-2026-34479	ब्रिज का Log4j1XmlLayout, या log4j 1 संगतता परत + org.apache.log4j.xml.XMLLayout
CVE-2026-34481	JsonTemplateLayout + MapMessage/ObjectMessage में फ़्लोटिंग-पॉइंट मान
CVE-2026-49844	JsonTemplateLayout का message resolver, या MapMessage.asJson()

वास्तविक मापन (वास्तविक घटक, नीचे देखें): एक ही सेट में प्रभावित संस्करण के चार मॉड्यूल स्थापित हैं,

• कॉन्फ़िगरेशन सबसे सामान्य प्रकार का है (Console + RollingFile + PatternLayout) → संस्करण-स्तर पर 7 प्रविष्टियाँ रिपोर्ट हुईं, वास्तव में मेल खाईं 0
• कॉन्फ़िगरेशन में Socket+<Ssl verifyHostName>+Rfc5424Layout+XmlLayout है → 7 प्रविष्टियाँ रिपोर्ट हुईं, वास्तव में मेल खाईं 4

दो नकारात्मक मानदंड आधिकारिक मूल पाठ में स्पष्ट रूप से कहे गए हैं, अलग से प्रलेखित: SyslogAppender का उपयोग करने वाले पर 34478 लागू नहीं होता; केवल HTTP appender के verifyHostname का उपयोग करने वाले पर 34477 लागू नहीं होता। इस श्रेणी की विश्वसनीयता और "मुझे नहीं मिला" की विश्वसनीयता बिल्कुल भिन्न है — पूर्व के पीछे मूल पाठ का समर्थन है, बाद वाला केवल हमारी अनुपस्थिति है।

🔴 verifyHostName (बड़ा N, <Ssl>, प्रभावित) और verifyHostname (छोटा n, HTTP appender, आधिकारिक रूप से अप्रभावित बताया गया) में केवल एक अक्षर के केस का अंतर है, निष्कर्ष पूरी तरह विपरीत है। इसी प्रकार XmlLayout (34480, log4j-core) Log4j1XmlLayout (34479, ब्रिज) का उपस्ट्रिंग है। केवल नाम grep करने से लोगों पर अनावश्यक रूप से ऐसे CVE थोप दिए जाएँगे जो उनके नहीं हैं। इसलिए कॉन्फ़िगरेशन स्तर पर संरचित पार्सिंग की जाती है, पाठ मिलान नहीं।

यह आपके कॉन्फ़िगरेशन को कैसे पढ़ता है