Risk assessment of log4j-core libraires in Layer7 API GW bundled package - CVE-2026-34477

Products

• CA Mobile API Gateway

Issue/Introduction

This article provides a risk assessment for the log4j-core-2.23.1.jar library identified in Layer7 API Gateway v11.1.2 environments, specifically regarding - CVE-2026-34477

Environment

• Layer7 API Gateway v11.1.2
• RHEL 8
• Software, Appliance, and Container deployments

Cause

Third-party vulnerability scanners may flag log4j-core-2.23.1.jar due to its presence in the /opt/SecureSpan/Controller/lib/ directory.

Resolution

Broadcom has conducted a thorough security assessment of the CA Layer7 API Gateway regarding recently identified Log4j2 vulnerabilities, specifically CVE-2026-34477.

We have confirmed that the Layer7 API Gateway is NOT exploitable by these vulnerabilities. While the log4j-core library version present in the Gateway falls within the upstream affected range, the Gateway's architectural configuration makes the vulnerable code paths entirely unreachable.

Technical Assessment & Verification

To assist customers with internal security audits and compliance reporting, the following technical details verify why the Gateway remains unaffected:

1. Architectural Bypassing of Log4j Core

• Bridge Utilization: The Gateway utilizes the log4j-to-slf4j bridge.

• Routing to JUL: All logging calls are routed directly to java.util.logging (JUL) via JdkLogConfig. This architectural design inherently bypasses the Log4j Core layout and appender processing where the vulnerabilities reside.

2. Absence of Vulnerable Configurations

• No Vulnerable Classes: Vulnerable classes, specifically XmlLayout and Rfc5424Layout, are not configured or utilized within the Gateway environment.

• No Direct Network Appenders: There are no network appenders (such as Socket, SMTP, or Syslog) configured to use Log4j Core directly.

Detailed Analysis of CVE-2026-34477 (Not Affected)

Vulnerability Requirements: Exploitation of CVE-2026-34477 requires Log4j2 network appenders (SMTP, Socket, or Syslog) to be configured with TLS via a nested <Ssl> element that relies on verifyHostName. Furthermore, it requires specific attacker conditions, such as presenting a certificate acceptable to the trust store.

Gateway Posture:

• No Vulnerable XML Configurations: The Gateway contains no log4j2.xml (or similar configuration files) that define the targeted appenders or the <Ssl verifyHostName="..."> element.

• No Vulnerable Java Instantiations: No Java code within the scanned Gateway source tree constructs a Log4j2 SocketAppender, SmtpAppender, or SyslogAppender with the vulnerable SSL configuration.

• Unrelated TLS Features: While the Gateway heavily utilizes TLS hostname features in its core product code (e.g., TrustedCert, HTTP clients), these are completely unrelated to Log4j2’s logging transport TLS.

Conclusion: Because the primary Gateway logging mechanism is java.util.logging, the specific Log4j2 SSL hostname-verification defect is structurally unreachable. This remains true even though the included log4j-core version (2.23.1) technically falls within the affected upstream range (up to 2.25.3).

Additional Information

Remediation and Future Actions

Action Required by Customers: None. The product is not vulnerable, and no immediate mitigation steps are necessary to protect against CVE-2026-34477.

Broadcom Action Plan: Although the Gateway is not exploitable, Broadcom is committed to maintaining clean security scans for our customers. To adhere to strict compliance standards, we target updating the underlying log4j-core library to an unaffected version in upcoming Monthly Platform Patches (MPP).

Details about the CVE-2026-34477