Cross-Site Request Forgery (CSRF)

A cross-site request forgery vulnerability in Jenkins Team Concert Plugin 1.3.0 and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.Show less

A cross-site request forgery vulnerability in Jenkins WebSphere Deployer Plugin 1.6.1 and earlier allows attackers to perform connection tests and determine whether files with an attacker-specified path exist on the Jenkins master file system.Show less

A cross-site request forgery vulnerability in a connection test form method in Jenkins Maven Release Plugin 0.16.1 and earlier allows attackers to have Jenkins connect to an attacker specified web server and parse XML documents.Show less

Various resources in the Crowd Demo application of Atlassian Crowd before version 3.1.1 allow remote attackers to modify add, modify and delete users & groups via a Cross-site request forgery (CSRF) vulnerability. Please be aware that the Demo application is not enabled by default.Show less

A vulnerability has been identified in XHQ (All versions < V6.0.0.2). The web interface could allow a Cross-Site Request Forgery (CSRF) attack if an unsuspecting user is tricked into accessing a malicious link. Successful exploitation requires user interaction by a legitimate user, who must be authenticated to the web interface. A successful attack could allow an attacker to trigger actions via the web interface that the legitimate user is allowed to perform. This could allow the attacker to read or modify contents of the web application. At the time of advisory publication no public exploitation of this security vulnerability was known.Show less

Due to insufficient CSRF protection, SAP BusinessObjects Business Intelligence Platform (Monitoring Application), before versions 4.1, 4.2 and 4.3, may lead to an authenticated user to send unintended request to the web server, leading to Cross Site Request Forgery.Show less

An issue was discovered in Decentralized Anonymous Payment System (DAPS) through 2019-08-26. It is possible to force wallets to send HTTP requests to arbitrary locations, both on the local network and on the internet. This is a serious threat to user privacy, since it can possibly leak their IP address and the fact that they are using the product. This also affects Dash Core through 0.14.0.3 and Private Instant Verified Transactions (PIVX) through 3.4.0.Show less

A CSRF issue was discovered in DAViCal through 1.1.8. If an authenticated user visits an attacker-controlled webpage, the attacker can send arbitrary requests in the name of the user to the application. If the attacked user is an administrator, the attacker could for example add a new admin user.Show less

In Octopus Deploy before 2019.10.7, in a configuration where SSL offloading is enabled, the CSRF cookie was sometimes sent without the secure attribute. (The fix for this was backported to LTS versions 2019.6.14 and 2019.9.8.)Show less

The csrf_callback function in the CSRF Magic library through 2016-03-27 is vulnerable to CSRF protection bypass as it allows one to tamper with the csrf token values. A remote attacker can exploit this by crafting a malicious page and dispersing it to a victim via social engineering, enticing them to click the link. Once the user/victim clicks the "try again" button, the attacker can take over the account and perform unintended actions on the victim's behalf. NOTE: A third-party maintainer has stated that this CVE is a false report. They state that the csrf_callback function is actually a callback function to the callers own handler for output. The function called can be changed via configuration to a custom callback to handle failed validation differently. They also stated that there is no way for an attacker to change tokens to make them valid from the client side. The only thing an attack can do is to pull the token out of the javascript, but that will always be possible and has nothing to do with the callbackShow less