grobid
grobid copied to clipboard
kermitt2
log4j vulnerability tracking ("log4shell")
Opening a tracking ticket to discuss this security issue (CVE-2021-44228) in the context of GROBID. I'm not even sure GROBID is impacted, but figure it would be good to document either way. Please feel free to update this issue with a summary.
My initial read is that current GROBID (0.7.x) uses log4j transitively via slf4j, but is using a 1.7.x version, which is not impacted by the log4shell issue (which impacts 2.0 <= Apache log4j <= 2.14.1). This holds regardless of JVM/JDK version used.
Hi @bnewbold thanks for the issue !
I also looked a bit, and you're right - as grobid is still using log4j 1.7.x (as normally all the other Grobid modules), there is no "JNDILookup plugin" related to the vulnerability.
Grobid server would anyway not really be impacted I suppose, because it does not connect to LDAP servers or any other registry services (from where sensitive data could be loaded) and Grobid is anyway normally not something to be deployed facing the internet (except the online demo!).
According to https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126, log4j 1.x is also affected but only if JNDI is enabled in the log mesasge template, which doesn't seem to be the case for GROBID. The problem with log4j v2 is that variables get expanded not only in message templates, but also recursively in variable payloads, e.g. malicious user-agents.
