Upgrading Log4j is the real fix, but in the real world you cannot always upgrade immediately. A vendor appliance, a frozen release, a system mid-migration, or a change-control window can all leave a vulnerable host running while you wait. This article is a defender's guide to the stopgap mitigations that reduce Log4Shell risk without a version change. It is honest about their limits: these measures buy time and shrink the attack surface, but only upgrading removes the vulnerability for good. Treat everything here as a bridge to patching, not a destination.
Before applying any mitigation, confirm which hosts actually need it by running the Log4Shell scanner so you focus effort where it matters. Targeting effort this way matters because applying stopgaps blindly across an estate wastes time on systems that were never vulnerable and can disrupt services unnecessarily.
The Most Effective Stopgap: Remove JndiLookup.class
The single most reliable mitigation short of upgrading is to remove the JndiLookup class from the Log4j JAR. The dangerous behaviour lives in that class, and deleting it from the log4j-core archive removes the JNDI lookup path while leaving the rest of logging intact. This is widely regarded as the strongest non-upgrade mitigation because it physically removes the vulnerable code rather than relying on a configuration flag the application might override.
The high-level approach is to remove the JndiLookup.class entry from the log4j-core JAR and restart the application so the change takes effect. Because Log4j is often bundled in multiple places, you must repeat this for every copy on the host, including nested and shaded JARs, and then re-scan to confirm the behaviour is gone. The caveat is that a redeploy from an unmodified artifact will reintroduce the class, so this mitigation needs to be reapplied or, better, baked into your build until you can upgrade. Because of that fragility, many teams treat removing the class as a deliberately tracked temporary bridge, ensuring it is reapplied automatically on every deploy until a proper version upgrade makes it unnecessary.
The Configuration Flag: formatMsgNoLookups
Older versions in the affected range support a setting that disables message lookups. Setting log4j2.formatMsgNoLookups to true, typically via a JVM system property or environment variable, stops the lookup substitution that the attack depends on. It is easy to deploy at scale because it is just a property, which makes it attractive for a fleet-wide quick win.
However, it comes with important caveats. It is effective only on certain versions within the affected range, it can be inadvertently overridden by application configuration, and it does not address every variant as comprehensively as removing the class. Treat it as a useful, fast, partial measure rather than a complete one, and prefer removing JndiLookup.class where you can. Either way, confirm the result with the scanner rather than assuming the flag took effect.
Network and WAF Controls
You can also reduce risk at the network layer while you arrange a patch. None of these are reliable on their own because of the obfuscation techniques discussed in obfuscated JNDI payloads, but in combination they raise the bar:
- Egress filtering. Block outbound LDAP, RMI, and unexpected DNS from server tiers so a triggered lookup cannot reach an attacker's host. This is one of the more durable network mitigations because the attack depends on an outbound callback.
- WAF rules. Filter requests containing JNDI lookup syntax, accepting that obfuscation will bypass naive signatures, so this is a speed bump, not a wall.
- Reduced exposure. Restrict or take offline non-essential internet-facing services that you cannot patch immediately.
- Heightened monitoring. Pair the controls with the detections in detecting Log4Shell in logs so attempts are visible.
Egress filtering deserves emphasis: because exploitation requires the server to call out, blocking that callback path can neutralise many attempts even when the inbound payload slips through.
Applying Mitigations in the Right Order
When you must mitigate at speed, work through a clear sequence so you do not leave gaps:
- Identify the targets. Use the scanner and version checker to list hosts that are vulnerable and cannot yet be upgraded.
- Remove JndiLookup.class from every Log4j copy on each host where you control the JAR.
- Set formatMsgNoLookups where removing the class is not feasible, as an additional or fallback layer.
- Apply egress filtering to block outbound LDAP, RMI, and unusual DNS from the affected tiers.
- Add WAF rules as a speed bump and raise monitoring on the hosts.
- Verify and track. Re-scan to confirm, and keep each host on a list until it is properly upgraded.
Why These Are Stopgaps, Not Fixes
It is worth being explicit about the limits so nobody mistakes a mitigation for a cure. Removing JndiLookup.class is strong but reversible by a redeploy. The formatMsgNoLookups flag is partial and can be overridden. WAF rules are defeated by obfuscation. Egress filtering is powerful but can be incomplete if some outbound path is overlooked. Each measure shrinks the window or the surface, but none of them changes the fact that the host still runs vulnerable code. The definitive fix remains upgrading to 2.17.1 or the appropriate backport, as set out in how to patch Log4j and contextualised by the follow-on CVEs.
Keep a Path to the Real Fix
Stopgaps tend to become permanent if nobody owns the follow-through. Avoid that by recording every mitigated host with the date applied and the target upgrade version, and review the list regularly until each item is closed by a proper patch. Where the blocker is a vendor product, track the vendor's advisory and apply their fixed release as soon as it is available. The discipline of treating mitigation as a tracked, time-boxed bridge is what keeps a temporary measure from quietly becoming a long-term exposure.
Verify Mitigations Actually Worked
Never assume a mitigation took effect. Configuration flags can be overridden, a second bundled JAR can be missed, and an egress rule can have a gap. After applying any measure, re-run the Log4Shell scanner against the host to confirm the vulnerable behaviour is no longer observable, and double-check the version state with the version checker so you have an accurate record of what is mitigated versus what is genuinely patched.
Documenting Every Temporary Measure
The biggest long-term risk with stopgaps is that they quietly become permanent because nobody is tracking them. To avoid that, document each mitigation as it is applied: which host, which measure, the date, and the target upgrade that will eventually replace it. Review the list on a regular cadence and treat any item that has lingered too long as a flag for escalation. This matters because a mitigated host still runs vulnerable code; it is safer than before but not actually fixed. Where the blocker is a vendor product, record the advisory you are waiting on and chase it, so the temporary measure is genuinely temporary. A well-maintained list of mitigations is what turns a chaotic emergency response into an orderly path toward full remediation.
When a Stopgap Is Good Enough for Now
There are situations where a strong stopgap, such as removing JndiLookup.class combined with egress filtering, genuinely reduces risk to an acceptable level while you wait for a maintenance window. That is fine as a conscious, time-boxed decision, but it should never be mistaken for closure. Set a date, record the rationale, and revisit it, so a reasonable short-term call does not silently turn into an indefinite acceptance of vulnerable code.
Conclusion
When you cannot upgrade right away, removing JndiLookup.class is the strongest stopgap, with formatMsgNoLookups, egress filtering, WAF rules, and heightened monitoring layered behind it. All of these buy time and shrink the surface, but only upgrading removes the vulnerability. Identify what needs mitigating with the Log4Shell scanner at log4shell.tools, apply the stopgaps, and keep driving every host toward a real patch.