What if my vendor's advisory says the product is not affected, but I find Log4j files in the installation directory?

The vendor's statement is the authoritative source. They may have compiled Log4j with mitigations or disabled the vulnerable feature. If you are unsure, contact the vendor's support team and reference the advisory.

Can I patch the embedded Log4j library myself if the vendor has not released a fix?

Replacing the embedded Log4j jar file is risky because it may break the product or void support. It is safer to apply compensating controls and wait for an official vendor update.

How do I know if a product I use is in the CISA affected database?

Download the CSV from the cisagov/log4j-affected-db repository and search for your product name. The database includes many commercial products, but not every product. If yours is missing, check the vendor's advisory directly.

What should I do if my product is still unpatched after several months?

Escalate with the vendor. In the meantime, ensure the product is isolated from the internet and monitor logs for exploitation attempts. Consider replacing the product if a fix is not forthcoming.

Log4Shell in Third-Party Products: Checking Vendor Exposure

When you cannot patch Log4j yourself because the vulnerable library is embedded in a commercial appliance or third-party application, your path to closure depends entirely on the vendor. Searching for log4shell vendor products affected leads you to public databases, vendor advisories, and community lists that track which releases are vulnerable and which versions fix the issue. Here is how to identify affected systems in your environment, interpret vendor advisories, and apply compensating controls when no patch exists.

Start with CISA's Log4j Affected Products Database

The Cybersecurity and Infrastructure Security Agency (CISA) maintained a public GitHub repository called cisagov/log4j-affected-db that listed vendor releases and their Log4Shell status. This database was a central reference for defenders checking their inventory against known affected systems. To use it:

Clone or download the repository from GitHub.
Open the CSV or JSON file that contains the entries.
Search for your system by vendor name or product name.
Check the status field: "Affected", "Not Affected", or "Fixed".
Note the fixed version or the vendor advisory URL listed in the entry.

This database was updated as vendors reported their status. Supplement it with community-maintained lists of log4j affected products list available from security vendors and open-source projects.

Find and Read the Vendor's Log4j Advisory

Once you identify a system as potentially affected, locate the official vendor log4j advisory. Vendors publish advisories on their support portals, security bulletins, or knowledge bases. The advisory should state:

Whether the system embeds Log4j 2 and its version.
Whether CVE-2021-44228 applies to that system.
The fixed release version number (not just the embedded Log4j version).
Any interim workarounds or compensating controls.

Trust the Fixed Release, Not the Embedded Library

Do not rely solely on the embedded Log4j version number. A vendor may have applied a hotfix or recompiled the library with mitigations. The fixed release version is the authoritative indicator. VMware Horizon servers were widely exploited via Log4Shell after December 2021, and VMware published advisories specifying the patched Horizon build number.

Assess Exposure from Known Affected Products

After collecting vendor advisories, categorize your affected systems by their network exposure and business criticality. Minecraft: Java Edition was affected and Mojang released a patched version. For appliances that cannot be patched immediately, consider these steps.

Network-Level Controls

Restrict inbound network access to the appliance to only trusted IP ranges. If the appliance does not need to be reachable from the internet, place it behind a firewall or VPN. For outbound connections, block or restrict the appliance's ability to reach external servers. Log4Shell exploitation triggers JNDI lookups to attacker-controlled hosts.

Monitoring and Detection

Logs from affected systems can be pasted into the site's scanner to check for JNDI exploitation attempts. Look for patterns such as ${jndi:ldap://...} or ${sys:env...} in application logs. CVE-2021-44228 was added to CISA's Known Exploited Vulnerabilities catalog in December 2021, making it a priority for detection and remediation.

Apply Compensating Controls Where No Vendor Fix Exists

If a vendor has not released a fix for an affected system, apply compensating controls to reduce risk. Common controls include:

Disabling unused features that process user-supplied data, such as input fields and file uploads.
Configuring the system to use a non-default logging format that does not interpret JNDI syntax.
Using a web application firewall (WAF) or reverse proxy to filter known Log4Shell payloads.
Segmenting the appliance onto an isolated network segment with strict egress filtering.

These controls do not eliminate the vulnerability. They reduce the attack surface. Continue monitoring vendor channels for a permanent fix.

Verify Your Environment Against Known Exploitation

Even after applying patches or controls, verify that no exploitation has occurred. Review logs from the period before the fix was applied. Use the site's scanner to check logs for JNDI lookup patterns. Cross-reference your inventory against the cisa log4j affected db to ensure you have not missed any embedded instances. For log4shell appliances such as network security devices, load balancers, or email gateways, check the vendor's advisory page regularly. They may update their status as new information emerges.

Maintain a Watch List for Unpatched Products

Create a watch list for each system that remains unpatched. The list should include:

Product name and version
Vendor advisory URL
Date of last check
Current status (fixed, workaround, no fix)
Risk level based on network exposure

Revisit the list regularly or whenever a new vendor advisory is published. Some vendors release a fix months after the initial disclosure. Persistence is necessary.