A cross-site request forgery (CSRF) vulnerability in Jenkins Subversion Plugin 2.15.3 and earlier allows attackers to connect to an attacker-specified URL.
A flaw was found in the Jenkins Subversion plugin. The Jenkins subversion plugin does not escape the name and description of List Subversion tags and parameters on views displaying the parameters. This issue results in a stored Cross-site scripting (XSS) vulnerability, exploitable by attackers with Item/Configure permission.
Jenkins Subversion Plugin 2.15.0 and earlier does not restrict the name of a file when looking up a subversion key file on the controller from an agent.
A flaw was found in the subversion Jenkins plugin. The XML parser is not properly configured to prevent XML external entity (XXE) attacks allowing an attacker the ability to control an agent process and have Jenkins parse a crafted changelog file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery. The highest threat from this vulnerability is to data confidentiality.
Subversion Plugin connects to a user-specified Subversion repository as part of form validation (e.g. to retrieve a list of tags). This functionality improperly checked permissions, allowing any user with Item/Build permission (but not Item/Configure) to connect to any web server or Subversion server and send credentials with a known ID, thereby possibly capturing them. Additionally, this functionality did not require POST requests be used, thereby allowing the above to be performed without direct access to Jenkins via Cross-Site Request Forgery attacks.
Kohsuke Kawaguchi reports:
Insecure storage of passwords in Subversion plugin.
Description Just noticed, that ssh-key passphrases in <JOB>/subversion.credentials are only coded in base64 an can easily be decoded. maybe this is fixed already. My setup is old and grown over time. Although i am running 1.500 the config-files may be old. i did run the "re-keying" process, as jenkins told me to do. Nevertheless, passphrases are still stored in base64
This was originally reported by Lennart Starr