Remediating Apache Log4j Vulnerability in Standalone Kafka Installation on MID Server Host (LES)Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } When the Log Export Service (LES) is configured to forward logs to an external SIEM (such as Splunk), some historical implementations involved installing a standalone Apache Kafka consumer directly on the MID Server host. This standalone Kafka distribution ships with its own Log4j libraries under <kafka_install_dir>\libs\, which are not managed or patched by the ServiceNow MID Server upgrade cycle. If a vulnerability scanner flags a Log4j library inside a Kafka installation on the MID Server host, this article explains how to assess whether the standalone Kafka consumer is still needed and how to safely remediate the vulnerability. Issue Description A vulnerability scanner reports a vulnerable version of Apache Log4j Core located at a path similar to: C:\kafka\libs\log4j-core-<version>.jar This library is part of a standalone Apache Kafka installation on the MID Server host, not part of the MID Server itself. The MID Server's own Log4j libraries (under agent\lib\) are patched by ServiceNow through the normal MID Server upgrade process. From the Tokyo release onward, log4j-core.jar was removed from the MID Server entirely and replaced with a non-vulnerable translation wrapper (log4j-to-slf4j.jar). Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } No release specific Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The standalone Kafka consumer was installed on the MID Server host as part of an older LES configuration pattern. Because it is a separate Apache distribution, its bundled libraries — including Log4j — are not updated when the MID Server is upgraded. If the Kafka installation is no longer actively used (e.g., the SIEM integration was reconfigured to use HTTP Event Collector instead), the installation may be an orphaned artifact that can be safely removed. Determining Whether the Standalone Kafka Is Still Needed Before remediating, confirm whether the Kafka consumer is actively in use. Step 1 — Check whether the Kafka process is running On the MID Server host, open PowerShell or Command Prompt and run: powershell Get-Process | Where-Object { $_.CommandLine -like "*kafka*" } Or in Command Prompt: cmd tasklist /FI "IMAGENAME eq java.exe" /V | findstr kafka If no results are returned, the Kafka consumer is not currently running. Step 2 — Check for scheduled tasks or Windows services that could restart it powershell Get-ScheduledTask | Where-Object { $_.TaskPath -like "*kafka*" -or $_.Actions.Execute -like "*kafka*" } Get-Service | Where-Object { $_.DisplayName -like "*kafka*" -or $_.Name -like "*kafka*" } If both return no results, there is no automated mechanism to restart Kafka. Step 3 — Confirm the SIEM integration is operating independently Verify with the SIEM administrator (e.g., Splunk admin) that logs are actively flowing in via an alternative path such as HTTP Event Collector (HEC). If the SIEM is receiving data successfully without the Kafka consumer running, this confirms the standalone Kafka installation is not in the active delivery path. Step 4 — Review the LES configuration on the ServiceNow instance Navigate to the LES system properties on the instance (search sys_properties for glide.log_export). Check the bootstrap server configuration. If it points to an internal Hermes/instance-managed Kafka address rather than the local MID Server host, the standalone consumer is not part of the integration chain. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Remediation Option A — Remove the standalone Kafka installation (Recommended) If all checks above confirm the Kafka consumer is inactive and not needed, removal is the cleanest remediation. Rename the Kafka directory as a precaution before deleting: Rename C:\kafka\ to C:\kafka_bak\ Monitor for 24–48 hours and confirm the SIEM continues to receive logs normally.If no issues are observed, permanently delete C:\kafka_bak\.Notify the vulnerability management team that the flagged library has been removed so they can close the finding. Option B — Upgrade the Log4j library in place If the Kafka consumer is still actively in use and cannot be removed: Identify the current Log4j version: C:\kafka\libs\log4j-core-<version>.jar Download the latest patched Log4j release from the Apache Logging project.Stop the Kafka consumer process before replacing the library.Replace log4j-core-<version>.jar and log4j-api-<version>.jar in C:\kafka\libs\ with the patched versions.Restart the Kafka consumer and verify functionality.Alternatively, consider upgrading to a newer Kafka distribution that ships with a patched Log4j version.