The TablePress plugin 1.9.2 for WordPress allows tablepress[data] CSV injection by Editor users.

**CSV Injection**, also known as **Formula Injection**, occurs when websites embed untrusted input inside **CSV** files. When a spreadsheet program such as Microsoft Excel or LibreOffice Calc is used to open a **CSV**, any cells starting with ‘=’ will be interpreted by the software as a **formula**

👨🏼‍💻Discovered by **Pablo Santiago.**

📝Published **02/01/2020.**

💉**CVE-2019–20180**

🔗**Vulnerable Version Download**

📄**Vulnerable version ≤ 1.9.2**

✅**Solution: Update to version 1.10**

****Mitigation CSV Injection****

Ensure that no cells begin with any of the following characters:

*   Equals to (“=”)
*   Plus (“+”)
*   Minus (“-”)
*   At (“@”)

****Attack Vector / Criticality — Medium****

Through CSV injection vulnerability a malicious user can force other user to execute code in his machine, for example this can be used for spread malware..

**Paremeters / Vulnerable Resources**

As shows the next image the parameter vulnerable is tablepress\[data\].

****PoC****

AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:N

CVE-2019-20180: CVE-2019–20180 TABLEPRESS — 1.9.2- CSV Injection - 0xPablito - Medium

A flaw in Give before 2.5.5, a WordPress plugin, allowed unauthenticated users to bypass API authentication methods and access personally identifiable user information (PII) including names, addresses, IP addresses, and email addresses. Once an API key has been set to any meta key value from the wp_usermeta table, and the token is set to the corresponding MD5 hash of the meta key selected, one can make a request to the restricted endpoints, and thus access sensitive donor data.

**Description**: Authentication Bypass with Information Disclosure  
**CVSS v3.0 Score**: 7.5 (High)  
**CVSS Vector String:** CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  
**Affected Plugin:** GiveWP  
**Plugin Slug:** give  
**Affected Versions:** <= 2.5.4  
**Patched Version:** 2.5.5

A few weeks ago, our Threat Intelligence team discovered a vulnerability present in GiveWP, a WordPress plugin installed on over 70,000 websites. The weakness allowed unauthenticated users to bypass API authentication methods and potentially access personally identifiable user information (PII) like names, addresses, IP addresses, and email addresses which should not be publicly accessible. 

We privately disclosed the issue to the plugin’s developer on September 3rd, who were quick to respond and released a patch shortly after. Wordfence Premium customers received a new firewall rule on September 4th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days.

This is considered a high security issue, and **websites running Give 2.5.4 or below should be updated to version 2.5.5 or later right away.**

**Vulnerability In Detail**

GiveWP provides users with an API functionality in order to integrate donation data into webpages and applications like Zapier. Site owners are able to generate a unique API key along with a token and private key that can be used to access restricted endpoints and gain access to donation data. However, it turned out that if no API key was generated, any user was able to access restricted endpoints by simply selecting any meta key from the wp_usermeta table and setting that as the authentication key. For instance, the nickname or session_tokens meta key (which are defined for all users) could have been supplied instead of a valid API key. There is also an authentication token that is used to validate this API request, however, for users that have not generated an API key, the authentication token is simply just the MD5 hash of the meta key that is used in place of a valid API key.

The API key validation method can be found in the validate_request() method seen below.

private function validate\_request() {
		global $wp\_query;

		$this->override = false;

		// Make sure we have both user and api key
		if ( ! empty( $wp\_query->query\_vars\['give-api'\] ) && ( $wp\_query->query\_vars\['give-api'\] !== 'forms' || ! empty( $wp\_query->query\_vars\['token'\] ) ) ) {

			if ( empty( $wp\_query->query\_vars\['token'\] ) || empty( $wp\_query->query\_vars\['key'\] ) ) {
				$this->missing\_auth();

				return false;
			}

			// Retrieve the user by public API key and ensure they exist
			if ( ! ( $user = $this->get\_user( $wp\_query->query\_vars\['key'\] ) ) ) {

				$this->invalid\_key();

				return false;

			} else {

				$token  = urldecode( $wp\_query->query\_vars\['token'\] );
				$secret = $this->get\_user\_secret\_key( $user );
				$public = urldecode( $wp\_query->query\_vars\['key'\] );

				if ( hash\_equals( md5( $secret . $public ), $token ) ) {
					$this->is\_valid\_request = true;
				} else {
					$this->invalid\_auth();

					return false;
				}

			}
		} elseif ( ! empty( $wp\_query->query\_vars\['give-api'\] ) && $wp\_query->query\_vars\['give-api'\] === 'forms' ) {
			$this->is\_valid\_request = true;
			$wp\_query->set( 'key', 'public' );
		}
	}

The first check verifies if there is a valid user and API key, if there is no token or API key set then the request is automatically denied from moving further. If we have both the token and key set, we can then move on to retrieving the user by the public API key that was set and this is where we find our first major problem.

We then get to the get_user() method that does a check based on the API key that was provided. Unfortunately, in this check it doesn’t verify if the key was one generated by the Give API, but rather just fetches the user_id for any meta key in the wp_usermeta table, so if we pass in nickname or session_tokens as our meta key we’ll get back a valid user.

	public function get\_user( $key = '' ) {
		global $wpdb, $wp\_query;

		if ( empty( $key ) ) {
			$key = urldecode( $wp\_query->query\_vars\['key'\] );
		}

		if ( empty( $key ) ) {
			return false;
		}

		$user = Give\_Cache::get( md5( 'give\_api\_user\_' . $key ), true );

		if ( false === $user ) {
			$user = $wpdb->get\_var( $wpdb->prepare( "SELECT user\_id FROM $wpdb->usermeta WHERE meta\_key = %s LIMIT 1", $key ) );
			Give\_Cache::set( md5( 'give\_api\_user\_' . $key ), $user, DAY\_IN\_SECONDS, true );
		}

		if ( $user != null ) {
			$this->user\_id = $user;

			return $user;
		}

		return false;
	}

The next check is to verify a “signature” of the user’s API key which is the MD5 hash of a secret key concatenated with the supplied API key. The secret key is normally defined when an API key is created for a given user. For user’s that have not generated an API key, the secret is an empty value, so a valid signature can be forged using just the MD5 value of the meta key that we’ve passed in instead of a valid API key.

	$token  = urldecode( $wp\_query->query\_vars\['token'\] );
				$secret = $this->get\_user\_secret\_key( $user );
				$public = urldecode( $wp\_query->query\_vars\['key'\] );

				if ( hash\_equals( md5( $secret . $public ), $token ) ) {
					$this->is\_valid\_request = true;

**Taking a Look at the Exploit**

Once the key has been set to any meta key value from the wp_usermeta table, and the token is set to the corresponding MD5 hash of the meta key selected, you can make a request to the restricted endpoints accessing sensitive donor data. In this example, we used the meta\_key session_tokens and the MD5 hash of the string session_tokens which is ea78b7d35ff75719b36056cfa14ddcc8.

Personally Identifiable Information displayed when accessing vulnerable “donations” endpoint from GiveWP plugin.

As you can see, information in these endpoints can contain PII like names, addresses, IP addresses, and email addresses which should not be publicly accessible.

**Disclosure Timeline**

**September 3rd** – Plugin developer notified of the security issue  
**September 4th** – Firewall rule released to Wordfence Premium users  
**September 20th** – Patch released  
**October 4th** – Firewall rule becomes available to free users

**Conclusion**

In today’s post, we detailed an authentication bypass flaw present in the GiveWP plugin. This flaw has been patched in version 2.5.5 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since September 4th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on October 4th, 2019.

_Thank you to the plugin’s team at GiveWP, for their extremely prompt response and cooperation to get a fix out quickly, and to Matt Barry, Wordfence’s Lead Developer, for his assistance in researching this vulnerability._

CVE-2019-20360: Authentication Bypass Vulnerability in GiveWP Plugin

There was a flaw in the WordPress plugin, Email Subscribers & Newsletters before 4.3.1, that allowed SQL statements to be passed to the database in the hash parameter (a blind SQL injection vulnerability).

CVE-2019-20361

The Postie plugin 1.9.40 for WordPress allows XSS, as demonstrated by a certain payload with jaVasCript:/* at the beginning and a crafted SVG element.

CVE-2019-20204: Postie

An XSS issue was discovered in the Laborator Neon theme 2.0 for WordPress via the data/autosuggest-remote.php q parameter.

CVE-2019-20141

wp_kses_bad_protocol in wp-includes/kses.php in WordPress before 5.3.1 mishandles the HTML5 colon named entity, allowing attackers to bypass input sanitization, as demonstrated by the javascript&colon; substring.

WordPress 5.3.1 is now available!

This security and maintenance release features 46 fixes and enhancements. Plus, it adds a number of security fixes—see the list below.

WordPress 5.3.1 is a short-cycle maintenance release. The next major release will be version 5.4.

You can download WordPress 5.3.1 by clicking the button at the top of this page, or visit your **Dashboard → Updates** and click **Update Now**.

If you have sites that support automatic background updates, they’ve already started the update process.

**Security updates**

Four security issues affect WordPress versions 5.3 and earlier; version 5.3.1 fixes them, so you’ll want to upgrade. If you haven’t yet updated to 5.3, there are also updated versions of 5.2 and earlier that fix the security issues.

*   Props to Daniel Bachhuber for finding an issue where an unprivileged user could make a post sticky via the REST API.
*   Props to Simon Scannell of RIPS Technologies for finding and disclosing an issue where cross-site scripting (XSS) could be stored in well-crafted links.
*   Props to the WordPress.org Security Team for hardening wp_kses_bad_protocol() to ensure that it is aware of the named colon attribute.
*   Props to Nguyen The Duc for discovering a stored XSS vulnerability using block editor content.

**Maintenance updates**

Here are a few of the highlights:

*   Administration: improvements to admin form controls height and alignment standardization (see related dev note), dashboard widget links accessibility and alternate color scheme readability issues (see related dev note).
*   Block editor: fix Edge scrolling issues and intermittent JavaScript issues.
*   Bundled themes: add customizer option to show/hide author bio, replace JS based smooth scroll with CSS (see related dev note) and fix Instagram embed CSS.
*   Date/time: improve non-GMT dates calculation, fix date format output in specific languages and make get_permalink() more resilient against PHP timezone changes.
*   Embeds: remove CollegeHumor oEmbed provider as the service doesn’t exist anymore.
*   External libraries: update sodium_compat.
*   Site health: allow the remind interval for the admin email verification to be filtered.
*   Uploads: avoid thumbnails overwriting other uploads when filename matches, and exclude PNG images from scaling after upload.
*   Users: ensure administration email verification uses the user’s locale instead of the site locale.

For more information, browse the full list of changes on Trac or check out the version 5.3.1 HelpHub documentation page.

**Thanks!**

In addition to the security researchers mentioned above, thank you to everyone who contributed to WordPress 5.3.1:

123host, acosmin, Adam Silverstein, Albert Juhé Lluveras, Alex Concha, Alex Mills, Anantajit JG, Anders Norén, andraganescu, Andrea Fercia, Andrew Duthie, Andrew Ozz, Andrey “Rarst” Savchenko, aravindajith, archon810, Ate Up With Motor, Ayesh Karunaratne, Birgir Erlendsson (birgire), Boga86, Boone Gorges, Carolina Nymark, Chetan Prajapati, Csaba (LittleBigThings), Dademaru, Daniel Bachhuber, Daniele Scasciafratte, Daniel Richards, David Baumwald, David Herrera, Dion hulse, ehtis, Ella van Durpe, epiqueras, Fabian, Felix Arntz, flaviozavan, Garrett Hyder, Glenn, Grzegorz (Greg) Ziółkowski, Grzegorz.Janoszka, Hareesh Pillai, Ian Belanger, ispreview, Jake Spurlock, James Huff, James Koster, Jarret, Jasper van der Meer, Jb Audras, jeichorn, Jer Clarke, Jeremy Felt, Jip Moors, Joe Hoyle, John James Jacoby, Jonathan Desrosiers, Jonny Harris, Joost de Valk, Jorge Costa, Joy, Juliette Reinders Folmer, justdaiv, Kelly Dwan, Kharis Sulistiyono, Kite, kyliesabra, lisota, lukaswaudentio, Maciej Mackowiak, marcelo2605, Marius L. J., Mat Lipe, mayanksonawat, Mel Choyce-Dwan, Michael Arestad, miette49, Miguel Fonseca, mihdan, Mike Auteri, Mikko Saari, Milan Petrovic, Mukesh Panchal, NextScripts, Nick Daugherty, Niels Lange, noyle, Ov3rfly, Paragon Initiative Enterprises, Paul Biron, Peter Wilson, Rachel Peter, Riad Benguella, Ricard Torres, Roland Murg, Ryan McCue, Ryan Welcher, SamuelFernandez, sathyapulse, Scott Taylor, scvleon, Sergey Biryukov, sergiomdgomes, SGr33n, simonjanin, smerriman, steevithak, Stephen Bernhardt, Stephen Edgar, Steve Dufresne, Subrata Mal, Sultan Nasir Uddin, Sybre Waaijer, Tammie Lister, Tanvirul Haque, Tellyworth, timon33, Timothy Jacobs, Timothée Brosille, tmatsuur, Tung Du, Veminom, vortfu, waleedt93, williampatton, wpgurudev, and Zack Tollman.

CVE-2019-20041: WordPress 5.3.1 Security and Maintenance Release

In wp-includes/formatting.php in WordPress 3.7 to 5.3.0, the function wp_targeted_link_rel() can be used in a particular way to result in a stored cross-site scripting (XSS) vulnerability. This has been patched in WordPress 5.3.1, along with all the previous WordPress versions from 3.7 to 5.3 via a minor release.

CVE-2019-20042

In WordPress before 5.3.1, authenticated users with lower privileges (like contributors) can inject JavaScript code in the block editor, which is executed within the dashboard. It can lead to an admin opening the affected post in the editor leading to XSS.

**Package**

No package listed

**Affected versions**

5.0.7, 5.1.3, 5.2.4, and 5.3.0

**Description**

**Impact**

Authenticated users with lower privileges (like contributors) can inject JavaScript code in the block editor, which is executed within the dashboard. It can lead to an admin opening the affected post in the editor leading to XSS.

**Patches**

This has been patched in WordPress 5.3.1, along with all the previous affected WordPress versions via a minor release. Automatic updates are enabled by default for minor releases and we strongly recommend that you keep them enabled.

**References**

*   https://wordpress.org/news/2019/12/wordpress-5-3-1-security-and-maintenance-release/
*   https://hackerone.com/reports/731301

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue on HackerOne

CVE-2019-16781: Authenticated cross-site scripting (XSS) in WordPress block editor (within dashboard)

WordPress users with lower privileges (like contributors) can inject JavaScript code in the block editor using a specific payload, which is executed within the dashboard. This can lead to XSS if an admin opens the post in the editor. Execution of this attack does require an authenticated user. This has been patched in WordPress 5.3.1, along with all the previous WordPress versions from 3.7 to 5.3 via a minor release. Automatic updates are enabled by default for minor releases and we strongly recommend that you keep them enabled.

@@ -74,11 +74,11 @@ function has\_blocks( $post = null ) { \* @since 5.0.0 \* @see parse\_blocks() \* \* @param string $block\_type Full Block type to look for. \* @param string $block\_name Full Block type to look for. \* @param int|string|WP\_Post|null $post Optional. Post content, post ID, or post object. Defaults to global $post. \* @return bool Whether the post content contains the specified block. \*/ function has\_block( $block\_type, $post = null ) { function has\_block( $block\_name, $post = null ) { if ( ! has\_blocks( $post ) ) { return false; } @@ -90,7 +90,30 @@ function has\_block( $block\_type, $post = null ) { } }  
return false !== strpos( $post, '', $serialized\_block\_name, $serialized\_attributes ); }  
return sprintf( '%s', $serialized\_block\_name, $serialized\_attributes, $block\_content, $serialized\_block\_name ); }  
/\*\* \* Returns the content of a block, including comment delimiters, serializing all \* attributes from the given parsed block. \* \* This should be used when preparing a block to be saved to post content. \* Prefer \`render\_block\` when preparing a block for display. Unlike \* \`render\_block\`, this does not evaluate a block's \`render\_callback\`, and will \* instead preserve the markup as parsed. \* \* @since 5.3.1 \* \* @param WP\_Block\_Parser\_Block $block A single parsed block object. \* @return string String of rendered HTML. \*/ function serialize\_block( $block ) { $block\_content = '';  
$index = 0; foreach ( $block\['innerContent'\] as $chunk ) { $block\_content .= is\_string( $chunk ) ? $chunk : serialize\_block( $block\['innerBlocks'\]\[ $index++ \] ); }  
if ( ! is\_array( $block\['attrs'\] ) ) { $block\['attrs'\] = array(); }  
return get\_comment\_delimited\_block\_content( $block\['blockName'\], $block\['attrs'\], $block\_content ); }  
/\*\* \* Returns a joined string of the aggregate serialization of the given parsed \* blocks. \* \* @since 5.3.1 \* \* @param WP\_Block\_Parser\_Block\[\] $blocks Parsed block objects. \* @return string String of rendered HTML. \*/ function serialize\_blocks( $blocks ) { return implode( '', array\_map( 'serialize\_block', $blocks ) ); }  
/\*\* \* Filters and sanitizes block content to remove non-allowable HTML from \* parsed block attribute values. \* \* @since 5.3.1 \* \* @param string $text Text that may contain block content. \* @param array\[\]|string $allowed\_html An array of allowed HTML elements \* and attributes, or a context name \* such as 'post'. \* @param string\[\] $allowed\_protocols Array of allowed URL protocols. \* @return string The filtered and sanitized content result. \*/ function filter\_block\_content( $text, $allowed\_html = 'post', $allowed\_protocols = array() ) { $result = '';  
$blocks = parse\_blocks( $text ); foreach ( $blocks as $block ) { $block = filter\_block\_kses( $block, $allowed\_html, $allowed\_protocols ); $result .= serialize\_block( $block ); }  
return $result; }  
/\*\* \* Filters and sanitizes a parsed block to remove non-allowable HTML from block \* attribute values. \* \* @since 5.3.1 \* \* @param WP\_Block\_Parser\_Block $block The parsed block object. \* @param array\[\]|string $allowed\_html An array of allowed HTML \* elements and attributes, or a \* context name such as 'post'. \* @param string\[\] $allowed\_protocols Allowed URL protocols. \* @return array The filtered and sanitized block object result. \*/ function filter\_block\_kses( $block, $allowed\_html, $allowed\_protocols = array() ) { $block\['attrs'\] = filter\_block\_kses\_value( $block\['attrs'\], $allowed\_html, $allowed\_protocols );  
if ( is\_array( $block\['innerBlocks'\] ) ) { foreach ( $block\['innerBlocks'\] as $i => $inner\_block ) { $block\['innerBlocks'\]\[ $i \] = filter\_block\_kses( $inner\_block, $allowed\_html, $allowed\_protocols ); } }  
return $block; }  
/\*\* \* Filters and sanitizes a parsed block attribute value to remove non-allowable \* HTML. \* \* @since 5.3.1 \* \* @param mixed $value The attribute value to filter. \* @param array\[\]|string $allowed\_html An array of allowed HTML elements \* and attributes, or a context name \* such as 'post'. \* @param string\[\] $allowed\_protocols Array of allowed URL protocols. \* @return array The filtered and sanitized result. \*/ function filter\_block\_kses\_value( $value, $allowed\_html, $allowed\_protocols = array() ) { if ( is\_array( $value ) ) { foreach ( $value as $key => $inner\_value ) { $filtered\_key = filter\_block\_kses\_value( $key, $allowed\_html, $allowed\_protocols ); $filtered\_value = filter\_block\_kses\_value( $inner\_value, $allowed\_html, $allowed\_protocols );  
if ( $filtered\_key !== $key ) { unset( $value\[ $key \] ); }  
$value\[ $filtered\_key \] = $filtered\_value; } } elseif ( is\_string( $value ) ) { return wp\_kses( $value, $allowed\_html, $allowed\_protocols ); }  
return $value; }  
/\*\* \* Parses blocks out of a content string, and renders those appropriate for the excerpt. \*

CVE-2019-16780: Prevent stored XSS in the block editor. · WordPress/wordpress-develop@505dd6a

The WordPress plugin, Email Subscribers & Newsletters, before 4.2.3 had a flaw that allowed unauthenticated file download with user information disclosure.

Tag

#wordpress