Log4Shell Still Breaches Companies Through Forgotten Software

The patch dashboard is green. Then someone finds a vulnerable Log4j JAR inside an application nobody remembers deploying, running on a server excluded from the scanner because it belongs to a vendor.

That is how Log4Shell still gets a foothold years after the initial zero-day panic. The technical problem was serious, but the long tail is an ownership problem. Companies patched the obvious systems, closed the emergency ticket, and left behind appliances, abandoned services, container images, backup nodes, and third-party products carrying old Log4j components.

Attackers do not care that the remediation programme was marked complete. They care that one reachable copy remains.

Log4Shell did not expire when the headlines stopped

CVE-2021-44228, commonly called Log4Shell, allows remote code execution through vulnerable versions of the Log4j logging library. Attacker-controlled text reaches a logging path, Log4j processes a JNDI lookup, and the application can be made to retrieve or execute attacker-controlled content.

The exploit was unusually useful because logging sits everywhere. A malicious string could arrive through an HTTP header, form field, API value, chat message, device name, or another input that eventually gets logged. The affected application did not need to advertise that it used Java. Log4j might be buried several layers down in a commercial package.

CISA's Log4Shell guidance warned that exploitation would continue over an extended period. That prediction was not difficult. Internet-facing software remains online for years, and dependency inventories are usually less complete than teams think.

Updating the Java runtime does not fix a vulnerable Log4j library. Patching the load balancer does not fix the application behind it. Blocking one callback domain does not remove the vulnerability. These sound like basic distinctions, right up until an incident bridge reveals that three teams each believed another team owned the component.

A new CVE, the same old operational failure

CVE-2026-20230 is not a Log4j vulnerability. It affects Cisco Unified Communications Manager, Unified CM, and Unified Communications Manager Session Management Edition, Unified CM SME. It belongs in this discussion because it exposes the same failure mode: a business system treated as infrastructure furniture, reachable longer than intended, with patching deferred because changing it might disrupt something important.

The flaw is server-side request forgery caused by improper validation of specific HTTP requests. According to Cisco's advisory, an unauthenticated remote attacker can send a crafted request to an affected system. Successful exploitation can write files to the underlying operating system, which may later be used to elevate privileges to root.

CISA added CVE-2026-20230 to its Known Exploited Vulnerabilities catalog on 25 June 2026. The KEV record identifies active exploitation and known ransomware use. This is no longer a theoretical exposure or a reason to schedule a meeting next quarter.

The organisations most at risk are those running affected Unified CM or Unified CM SME releases, particularly where web interfaces are internet-accessible, reachable through poorly restricted partner networks, or exposed broadly inside a flat corporate network. Voice systems often connect to identity services, management networks, monitoring platforms, gateways, and administrative workstations. Root access to the call manager is therefore not just a telephony problem. It creates a trusted place from which an attacker can persist, inspect connected systems, and attempt further movement.

Do not claim a specific data theft or outage without evidence. The confirmed facts already justify urgent action: unauthenticated access, file write capability, a path toward root, active exploitation, and ransomware use.

Start by proving what is actually exposed

Ask for evidence, not reassurance. For Cisco Unified CM, record every node, its role, software release, management address, owner, and permitted source networks. Run the following from an authorised assessment host against known addresses, not against arbitrary internet ranges:

nmap -Pn -sT -p 443 --reason cucm.example.internal

A closed external port does not settle the question. Check public DNS, NAT rules, reverse proxies, VPN routes, cloud security groups, firewall policy, and access from partner networks. Exposure includes any route an attacker could gain after compromising an ordinary user endpoint.

On Unified CM, an administrator can verify the active release from the CLI:

show version active

Compare that output with the current Cisco advisory. Cisco lists 14SU6 as the first fixed Release 14 version. For Release 15, Cisco lists 15SU5, scheduled for September 2026, or the appropriate version-specific COP patch. Read the COP README and confirm cluster compatibility before touching production. Cisco states there are no workarounds that fix the flaw.

For Log4j, scan both hosts and build artefacts. A simple filesystem check is useful, although it will miss renamed files and some nested archives:

find /opt /srv /app -type f -name 'log4j-core-*.jar' 2>/dev/null

Also inspect container images and packaged applications. Tools such as Syft can produce an SBOM, while Grype, Trivy, or your existing scanner can match discovered components against CVE data.

syft registry.example.com/payments/api:production -o cyclonedx-json
trivy image registry.example.com/payments/api:production

Do not scan only the image currently referenced by a deployment. Check running container digests, old replicas, job images, disaster recovery environments, and images that can still be deployed from the registry. Kubernetes makes it easy to update a manifest while an forgotten workload keeps running elsewhere.

Patching is not the same as incident response

When an affected system was reachable during a period of active exploitation, patching closes the vulnerability but does not remove an attacker who arrived yesterday.

Preserve evidence before rotating everything into oblivion. Collect vendor-supported diagnostic bundles, web and application logs, authentication records, firewall flows, proxy logs, EDR telemetry, and file metadata. Look for unexpected files, new accounts, altered scheduled tasks, suspicious child processes, unusual outbound connections, and administrative logins from unfamiliar sources. Keep timestamps and time zones straight. They will matter later.

For Unified CM, follow CISA's BOD 26-04 remediation and forensics triage requirements, along with Cisco's instructions. If compromise is suspected, involve Cisco TAC and an incident response team that understands both appliance constraints and network evidence. Running generic cleanup commands as root on a vendor appliance can destroy evidence and leave the product unsupported, which is an impressive way to create two incidents at once.

Temporary network restriction is still sensible while arranging the update. Limit management access to named administrative networks, remove public exposure, and monitor attempts against the blocked service. Call this containment, not remediation. Cisco is explicit that no workaround addresses CVE-2026-20230.

Patch management needs an owner and a clock

A useful patch process starts with asset ownership and ends with verification. CVSS alone should not set the queue. CISA KEV status, internet exposure, available exploit code, privilege gained, business role, and evidence of targeting should move a vulnerability ahead of routine maintenance.

The defensive side verifies inventory, applies updates, hardens access, and watches for exploitation. The offensive side tests whether the supposed boundary is real. Threat detection and incident response cover the uncomfortable gap where a system may already have been touched. Treating these as separate annual exercises leaves attackers plenty of room between them.

If you only do one thing this week

Reconcile your external attack surface against the CISA KEV catalog, then require a named owner to prove the version and exposure of every match. Start with CVE-2026-20230 and any remaining Log4j findings.

A spreadsheet marked patched is not proof. A version check, a network path test, and a review of evidence are proof.

If this is on your plate, TecLeads does exactly this as part of our Cybersecurity work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.