Marking as draft for now. I will extend the build files to validate that the jdbc package is gone from the built jars.

My I know why not simply bumping log4j version, or switching to jetbrains' fork if still used, or completely removing it if not used?

Excluding the contents from the uber jar seems a bit tricky.

I attempted to remove it entirely, but Kotlin still requires it (and still depends on version 1.2.17.2 that we also have). We could probably update to version 1.2.17.3 since tests are green but it seems like a bad idea to introduce such a mismatch between KSP and Kotlin. For now this seems like the best local fix that we can apply.

I see. But isn't the Kotlin compiler also suffering from the same vulnerability? How do they handle it?

I see. But isn't the Kotlin compiler also suffering from the same vulnerability? How do they handle it?

I'm not sure they really handle it at all, but I also do not think they are affected by it. The CVE requires that you misconfigure org.apache.log4j.jdb.JDBCAppender to allow for an attack in the first place, and Kotlin does not mention this class at all: https://github.com/search?q=repo%3AJetBrains%2Fkotlin+%22jdbc%22&type=code

Here is the important sentence from description of the CVE:

Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default.

Here is the description of the CVE (I have highlighted the same sentence as above):

By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

https://nvd.nist.gov/vuln/detail/cve-2022-23305

Of course, long-term it is better to suggest to them that they either also remove the class entirely or upgrade to log4j2.