The source files indicate that this project is resolving dependencies over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JARs or other dependencies were compromised, any developers using these could continue to be infected past updating to fix this.
CWE-829: Inclusion of Functionality from Untrusted Control Sphere CWE-494: Download of Code Without Integrity Check
The source files indicate that this project is resolving dependencies over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JARs or other dependencies were compromised, any developers using these could continue to be infected past updating to fix this.
This vulnerability has a CVSS v3.0 Base Score of 8.1/10 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
This isn't just theoretical
POC code has existed since 2014 to maliciously compromise a JAR file inflight. See:
MITM Attacks Increasingly Common
See:
Source Locations
Public Disclosure
Since this is a shipped project, once this is fixed and a new release published, a CVE number will need to be assigned.
Potential for Trusting Trust Attack
Since Kobalt is used to build Kobalt, there is the potential that this vulnerability could have been used to establish a trusting trust attack.
https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
A malicious compromise of one Kobalt build could mean that a vulnerability continues to live in the compiled bytecode of the project today.