This incident has been resolved. Our systems were not compromised nor affected by the Log4j vulnerability.
Posted Jan 25, 2022 - 16:27 CET
Update
We are closely following Log4j vulnerability evolution and the latest release of Log4j 2.17.0.
As we have fully removed Log4j packages from our infrastructure, we are not affected by newly found issues within Log4j packages.
Posted Dec 18, 2021 - 10:24 CET
Monitoring
Incident ongoing since December 11th. We're following the evolution of the situation around CVE-2021-45046.
Our Engineering and Security teams started to work on log4j incident on December 10th in the morning EU time and updated, mitigated or removed the vulnerable log4j packages from our environment.
No misuse has been detected and active threat hunting continues.
Our mitigation actions: - Updated log4j where possible - Scanned logs retrospectively one month back for various scenarios - Our security team is still actively hunting for signs of exploitation
The service affected is not directly accessible through internet. It sits within our private network. The request can be made through an API which goes through application first, not passing any headers and it correctly sanitizes all user entered content. This has been verified and confirmed. The service itself logs only minimum information, none of the user entered content makes it through to the logs. The attacker would need to be logged in to Inline Manual Portal or have API Access Tokens to be able to communicate indirectly through the API with the service - we have not detected any attempts to do so.