Hi Rajadharani,

Since the reported CVE is against the Log4j dependencies bundled with Library Logging 1.13.0, I would recommend checking the module's dependency tree and the exact vulnerable component before applying a workaround.

A few things that may help narrow this down:

• Confirm whether the reported Log4j artifacts are actually packaged into the deployed application/runtime and not only present in the build dependency tree.
• Check whether the vulnerable Log4j functionality described in CVE-2026-49844 is used by Library Logging in your application.
• If possible, verify the finding against the exact Log4j version and affected component reported by AWS Inspector.
• Avoid manually replacing/removing the Log4j JARs from the deployed Mendix application, as this could introduce dependency conflicts or break Library Logging functionality.

For the long-term resolution, the Library Logging maintainer would need to confirm whether a newer module version will update the affected Log4j dependencies.

For the client's risk assessment, I would recommend documenting the AWS Inspector finding and requesting an official confirmation from the module maintainer regarding applicability and the planned remediation. If the vulnerability is confirmed as applicable, the recommended mitigation should come from the maintainer rather than manually modifying the bundled dependencies.

Kindly mark this as the accepted answer if it helps.