[Aikido] Fix security issue in log4j-core via minor version upgrade from 2.14.0 to 2.25.4 in services

[aikido-autofix]

Upgrade log4j-core to fix critical RCE vulnerabilities via JNDI injection and MDC exploitation, plus XML sanitization issues. This update includes breaking changes that require manual migration.

⚠️ Code affected by breaking changes.

⚠️ The upgrade from log4j-core 2.14.0 to 2.25.4 introduces breaking changes that affect this codebase:

1. JNDI functionality disabled by default (2.16.0)

• Where your code is affected: services/identity/src/main/java/com/crapi/service/Impl/UserServiceImpl.java (lines 48-50, 95-103) - The code instantiates Log4jContextFactory and uses LOG4J_LOGGER to log user input containing JNDI expressions.

• Impact: The code appears to be intentionally testing Log4j JNDI vulnerability behavior. With JNDI disabled by default in 2.16.0+, the LOG4J_LOGGER.error() call with JNDI expressions will no longer trigger JNDI lookups, changing the application's behavior when ENABLE_LOG4J environment variable is set to true.

• Remediation: If JNDI functionality is required for testing purposes, set the system property log4j2.enableJndiLookup=true (though this is not recommended for security reasons). Otherwise, update the test logic to reflect that JNDI lookups are now disabled by default.

2. Message Lookups completely removed (2.16.0)

• Where your code is affected: Same location as above - services/identity/src/main/java/com/crapi/service/Impl/UserServiceImpl.java (line 103)

• Impact: Any message lookups in log statements will no longer be processed. The JNDI expression ${jndi:ldap://127.0.0.1/a} in the email field will be logged as a literal string rather than being evaluated.

• Remediation: Update test expectations to reflect that lookup expressions are now treated as literal strings in log messages.

Note: The codebase uses logback.xml for configuration (not log4j2.xml), but explicitly imports and uses log4j-core classes (Log4jContextFactory, LogManager) alongside the default SLF4J/Logback setup. This dual logging setup means the log4j breaking changes will affect the LOG4J_LOGGER usage specifically.

All breaking changes by upgrading org.apache.logging.log4j:log4j-core from version 2.14.0 to 2.25.4 (CHANGELOG)

Version	Description
2.15.0	Lookups in log messages are now disabled by default. The feature must be explicitly enabled by specifying %msg{lookup} in Pattern Layout. The log4j2.formatMsgNoLookups property and nolookups message pattern converter option have been removed.
2.15.0	JNDI protocols are restricted by default to only java, ldap, and ldaps. LDAP no longer supports classes implementing the Referenceable interface and restricts Serializable classes to Java primitive classes by default, requiring an allow list for remote LDAP servers.
2.16.0	JNDI functionality is disabled by default and requires the log4j2.enableJndi system property to be set to true to enable it.
2.16.0	Message Lookups support has been completely removed.
2.17.0	The single log4j2.enableJndi property has been replaced with three individual properties: log4j2.enableJndiContextSelector, log4j2.enableJndiJms, and log4j2.enableJndiLookup.
2.17.0	LDAP and LDAPS protocols have been removed as supported protocols from JNDI, limiting it to only the java protocol.
2.17.0	Recursive evaluation of Lookups is disabled during log event processing (though still allowed during configuration generation).
2.21.0	Bundle symbolic names changed from using hyphens to dots to function as JPMS module names.
2.21.0	Four bridge modules (log4j-slf4j-impl, log4j-slf4j2-impl, log4j-to-jul, log4j-to-slf4j) have had their module names changed.
2.21.0	All artifacts migrated from automatic modules to named JPMS modules with private packages not exported.
2.24.0	JUL-to-Log4j API and Log4j 1-to-Log4j API bridges can no longer modify Log4j Core configuration by default; explicit enablement is required.
2.24.0	JMX support is disabled by default and requires log4j2.disableJmx=false to enable.
2.24.0	Configuration properties subsystem now only accepts official pre-2.10 property names and normalized post-2.10 names.
2.24.0	Programmatic configuration in Log4j 1 Bridge is disabled by default if log4j1.compatibility is false.
2.24.0	Removed configuration properties caching and undocumented fuzzy property name matching.
2.25.0	Stack traces are now consistently prefixed with a newline instead of other whitespace
2.25.0	The default exception converter has changed from extended to plain
2.25.0	Support for the {ansi} option in exception converters has been removed
2.25.0	Date and time formatting now uses Java's DateTimeFormatter instead of custom formatters (FixedDateFormat and FastDateFormat), which may cause formatting issues with n or x directives
2.25.0	JAnsi library support has been removed
2.25.0	The GraalVmProcessor will fail the build if required log4j.graalvm.groupId and log4j.graalvm.artifactId parameters are not provided when building third-party Log4j plugins

✅ 7 CVEs resolved by this upgrade, including 2 critical 🚨 CVEs

This PR will resolve the following CVEs:

Issue	Severity	Description
CVE-2021-44228	🚨 CRITICAL	[log4j-core] JNDI injection vulnerability allowing remote code execution through attacker-controlled LDAP endpoints via log messages or parameters when message lookup substitution is enabled.
CVE-2021-45046	🚨 CRITICAL	[log4j-core] A bypass of the CVE-2021-44228 fix allows attackers to exploit Thread Context Map input in non-default Pattern Layouts using JNDI Lookup patterns, resulting in information disclosure and remote code execution.
CVE-2026-34480	HIGH	[log4j-core] XmlLayout fails to sanitize XML 1.0 forbidden characters in log messages, causing malformed XML output that conforming parsers reject or throws exceptions during logging, potentially causing log records to be dropped by downstream systems.
CVE-2021-44832	MEDIUM	[log4j-core] A remote code execution vulnerability exists when JDBC Appender uses JNDI LDAP data source URIs, allowing attackers controlling the LDAP server to execute arbitrary code. The fix restricts JNDI data source names to the java protocol.
CVE-2021-45105	MEDIUM	[log4j-core] Uncontrolled recursion vulnerability in Thread Context Map lookups allows attackers to cause denial of service through crafted self-referential lookup strings.
CVE-2026-34477	MEDIUM	[log4j-core] The verifyHostName attribute in the element was silently ignored, allowing man-in-the-middle attacks on SMTP, Socket, and Syslog appenders even when hostname verification was configured. This enables network attackers to intercept TLS connections if they possess a certificate from a trusted CA.
CVE-2025-68161	MEDIUM	[log4j-core] Socket Appender fails to verify TLS hostname certificates even when verification is enabled, allowing man-in-the-middle attackers to intercept or redirect log traffic if they can present a trusted certificate.