The XSS here is fairly basic, attacker controlled data reflected without sanitization, whats a bit more interesting is the input source, plugin metadata processed by the global Jenkin’s Update Center. There is a bit of a process to getting plugins listed in the Update Center, submitted a PR and the first plugin needs to be manually approved, though the authors note that this is mostly a procedural thing. Once approved though an attacker could update their plugins without any additional process.

From the plugin metadata, the Jenkins-Version (this is supposed to be the minimum required Jenkins version) value may be reflected in two locations one is on the update.jenkins.io domain and the other on the actual Jenkins server.

CVE-2023-27905 - When access the plugin’s page directly on the update.jenkins.io the required Jenkins version is reflected directly onto the page without sanitization. Resulting on XSS on that domain. CVE-2023-27898 - On the Jenkins server available plugins can be listed, in this list a version check is performed, comparing the required version to the server’s version. If the server’s version is earlier than the required version then a warning message will be displayed. Again, reflecting the required version without an sanitization this time resulting in XSS on the Jenkins server.

There is a bit of a hurdle to overcome with the second instance though, The Update Center generates a number of JSON files containing all the plugins that are compatible with each version of Jenkins. When a server requests theplugins list, it is essentially already filtering out those that are incompatible and so a malicious plugin with a high version simply would never be seen by anyone. The exception to this is very old versions, the Update Center only maintains the files going back so far, so versions older than the oldest maintained version (approximately 400 days old) will display plugins compatible with the oldest maintained list, so those instances may display the vulnerable warning.

With XSS on the Jenkins server, RCE is trivial given that the functionality of Jenkins is to run code. A POST to the /script endpoint can result in code execution from a provided Groovy script.