Two different things must be patched:
1. BAW itself - never replace jars by hand under the BAW install root. IBM ships the Log4j fixes as interim fixes / fix packs (BAW 20.0.0.2 IF, 21.0.x IF, 22.0.x; on CP4BA as new container images). Install them with Installation Manager (imcl install ... -repositories <fix repository>) - the fix updates every affected component (BPM, Case, Content, WebSphere). Check your level with versionInfo.sh -fixpacks -ifixes. Note that IBM BPM / BAW core did not use Log4j 2 for its own logging (WebSphere uses java.util.logging), the exposure came from bundled components and third-party toolkits.
2. Your own toolkit (the "EIE logging" toolkit) - the Log4j jar is a managed server file inside the toolkit, so it is fixed in the toolkit, not on the file system:
- Open the toolkit in Process Designer, go to Files (Server files), delete log4j-core-2.x.jar / log4j-api-2.x.jar and upload the 2.17.1 (or later) jars with the same names.
- Re-point the Java Integrations if the jar name changed (the integration references the managed file), take a new toolkit snapshot, upgrade the dependency in every process app, take new app snapshots and install them - the old snapshots still contain the old jar until they are replaced or archived.
- Also delete the copies that the server extracted for older snapshots: they live in <profile>/config/cells/.../managedfiles style caches only while the snapshot is installed; uninstalling / archiving the old snapshots removes them.
Verify with a scan of the file system (find / -name "log4j-core*.jar") and of the BPM database (select name from lsw_managed_asset where name like 'log4j%%') after the redeploy.
References
- IBM security bulletin: Log4j (CVE-2021-44228) and Business Automation Workflow
- IBM Fix Central