Rudder

1. json-smart-2.4.7.jar
   CVE-2023-1370 https://nvd.nist.gov/vuln/detail/CVE-2023-1370

Stackoverflow on tailored json object. Rudder unlikely to be impacted since that lib is only used in JSON path selector (either for datasource or groups). It would means that either the datasource json is corrupted ; and for group, we do use other libs to parse data from nodes, so error should be catch before that.
In any case, the only impact is a potential stack overflow and rudder server crash, which is not a major security issue for Rudder security profil.

Can be corrected with upgrade to json-smart 2.4.11 which seems totally compatible.

1. spring-web-5.3.29.jar
   CVE-2016-1000027 https://nvd.nist.gov/vuln/detail/CVE-2016-1000027

New iteration of reporting that old CVE which won't ever be addressed in spring, see: https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525.
The CVE RCE relies on deserializing java object from POST/PUT requests, which of course nobody does because it is unsafe and a well know security hole since ever in java.

New compatible version of spring available (5.3.30) but the "CVE" is still their. Can update though.

#org.eclipse.jgit-6.3.0.202209071007-r.jar

CVE-2023-4759 https://nvd.nist.gov/vuln/detail/CVE-2023-4759

Arbitrary file overwrite with specialy crafted symlinks on git clone.
This a very bad CVE. Fortunatly, Rudder does not clone any git repository and all of the one in Rudder are created by Rudder (so there is no place for crafting the data leading to exploit).
Still a bad CVE, and we should try to update to JGit 6.6.1 or 6.7 (as in 8.0) which does not have that problem

1. bcprov-jdk18on-1.72.jar
   CVE-2023-33201 https://nvd.nist.gov/vuln/detail/CVE-2023-33201

"The vulnerability only affects applications that use an LDAP CertStore from Bouncy Castle to validate X.509 certificates"
We don't.
We still can try to update to 1.76, bouncy castle upgrade are generally flawless.

1. org.graalvm.sdk.graal-sdk-22.3.0.jar

Ouch. Lots of CVEs here. Fortunatly for us, we are using GraalVM in a very restricted way:
- it's only for execting the JS from directive parameters (so need access to Directive edition in Rudder)
- the execution of graalvm it self is sandboxed by the host JVM (ie not by GraalVM)
- we don't have a running GraalVM, but a scoped execution of GraalVM as a library

And some of these issues don't even target GraalVM

CVE-2023-21930 https://nvd.nist.gov/vuln/detail/CVE-2023-21930 => need TLS connection to a running GraalVM
CVE-2023-22036 https://nvd.nist.gov/vuln/detail/CVE-2023-22036 => targets JD Edwards EnterpriseOne Tools product of Oracle JD Edwards
CVE-2023-21937 https://nvd.nist.gov/vuln/detail/CVE-2023-21937 => need network access to a running GraalVM
CVE-2023-21938 https://nvd.nist.gov/vuln/detail/CVE-2023-21938 => need network access to a running GraalVM
CVE-2023-21939 https://nvd.nist.gov/vuln/detail/CVE-2023-21939 => need network access to a running GraalVM
CVE-2023-22041 https://nvd.nist.gov/vuln/detail/CVE-2023-22041 => targets Oracle BI Publisher product of Oracle Analytics
CVE-2023-22044 https://nvd.nist.gov/vuln/detail/CVE-2023-22044 => need network access to a running GraalVM + target Oracle Essbase
CVE-2023-22045 https://nvd.nist.gov/vuln/detail/CVE-2023-22045 => targets MySQL
CVE-2023-22049 https://nvd.nist.gov/vuln/detail/CVE-2023-22049 => targets Oracle Database Server
CVE-2023-21954 https://nvd.nist.gov/vuln/detail/CVE-2023-21954 => need network access to a running GraalVM
CVE-2023-21967 https://nvd.nist.gov/vuln/detail/CVE-2023-21967 => need network access to a running GraalVM
CVE-2023-21968 https://nvd.nist.gov/vuln/detail/CVE-2023-21968 => need network access to a running GraalVM
CVE-2023-22006 https://nvd.nist.gov/vuln/detail/CVE-2023-22006 => need network access to a running GraalVM

So nothing at risk for Rudder! Still, we can try to update to the same version as Rudder 8.0 (or even 23.0.3)