The Customizer Export/Import WordPress plugin before 0.9.5 unserializes the content of an imported file, which could lead to PHP object injection issues when an admin imports (intentionally or not) a malicious file and a suitable gadget chain is present on the blog.

CVE-2022-3380

The WP Word Count WordPress plugin through 3.2.3 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Cross-Site Scripting attacks even when unfiltered_html is disallowed.

CVE-2022-3408

The Automatic User Roles Switcher WordPress plugin before 1.1.2 does not have authorisation and proper CSRF checks, allowing any authenticated users like subscriber to add any role to themselves, such as administrator

CVE-2022-3419

The Official Integration for Billingo WordPress plugin before 3.4.0 does not sanitise and escape some of its settings, which could allow high privilege users with a role as low as Shop Manager to perform Stored Cross-Site Scripting attacks.

CVE-2022-3420

The Rock Convert WordPress plugin before 2.11.0 does not sanitise and escape an URL before outputting it back in an attribute when a specific widget is present on a page, leading to a Reflected Cross-Site Scripting

CVE-2022-3440

The Rock Convert WordPress plugin before 2.11.0 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

CVE-2022-3441

The Gallery Plugin for WordPress plugin before 1.8.4.7 does not escape the $_SERVER['REQUEST_URI'] parameter before outputting it back in an attribute, which could lead to Reflected Cross-Site Scripting in old web browsers

CVE-2022-2190

How to solve the software vulnerability problem across the entire SDLC.

In the opening keynote of the 2022 Black Hat security conference, Chris Krebs, the former Department of Homeland Securities cybersecurity director, stated that security is going to get worse before it gets better. Why? Krebs said that "software remains vulnerable because the benefits of insecure products far outweigh the downsides." Rather than ensuring security, the focus across the software development life cycle (SDLC) is beating the competition to market. In fact, innovation is often seen at odds with security — the former believed to be fast-paced and productive, and the latter a roadblock that stifles quick-moving application development. This view is proving to be outdated in the current threat landscape.

With cyberattacks on the rise, the software supply chain is a popular target for cybercriminals who recognize the huge disruption they cause when infecting insecure code. For example, the now infamous Log4Shell vulnerability posed such a risk because the open source Log4j is so commonly used across software applications and online services worldwide, and exploiting the vulnerability requires very little expertise. More recently, the 25,000 malicious plug-ins found across WordPress sites highlight the cybersecurity risk that many businesses face, despite believing they were using secure applications and programs within their websites.

Innovation and security must therefore be viewed through a single lens; one is not possible without the other. Even more importantly, security can no longer be the responsibility of one siloed team. It must be a priority for everyone across the SDLC.

**The AppSec Dilemma**

Despite increased investment into application development, the same importance isn't being applied to security. In such a competitive space, first movers tend to get the reward. Those that enter the market with their "first viable product" are likely looking at how this product can serve customers, not how it can be used securely. With these high expectations, code demands on developers have increased 100 times over the past 10 years, with 92% feeling pressured to write code faster. Pair this with the fact that 53% have no professional secure coding training, while the number of new vulnerabilities within the NIST National Vulnerability Database has increased by over 200% in the past several years, and it seems we're in something of an application security dilemma.

However, it is not an unsolvable dilemma. The solution requires a complete switch-up in the way that many view coding and innovation, with a specific focus on the mindset of the people. It puts security first and recognizes that it's OK to be slower to market if the end product is more secure. According to Boehm's law, "the cost of finding and fixing a defect grows exponentially with time" — a concept that can benefit the bottom line of organizations that prioritize security from the start.

Establishing this security-first mindset is crucial — not just for the development team, but for everyone who plays a role within the SDLC. Product and project managers, DevOps, user experience (UX) designers, and quality assurance (QA) professionals will all influence the end result and therefore need to recognize the current dilemma for application security and how this challenge can be overcome.

**Getting Integrated Education Right**

If teams do not understand _why_ a security-first mindset is so important within application development, they are never going to buy into _how_ it can be achieved. Integrated and continuous application security education for the whole development organization has therefore never been more important. For those creating the code, it is important to deliver foundational learning before hands-on exercises that speak directly to the issues they face on a daily basis. This developer-specific education should be run in parallel with foundational and advanced application security training programs for those with roles in the SDLC that may not necessarily need hands-on expertise. These kinds of initiatives will empower the whole team to think differently, make more informed decisions, and integrate security across every aspect of development.

Yet it is important that organizations understand that application security constantly evolves and changes. Building a security-minded team who apply key AppSec principles at every step of the development cycle can't be accomplished with a "one and done" training program. To ensure teams maintain this security-first mindset, a continued and evolving educational program is key.

Many organizations engage teams by acknowledging and celebrating security champions, who lead a shift in security behavior across the team. By offering incentives or rewards to those that are consistently applying security best practices in their day-to-day work, they encourage champions to engage others and organically influence change. For example, by measuring results — like the number of vulnerabilities in a code before and after training programs — and recognizing success, it is also far easier to get buy-in from the board and justify investment on secure coding education to the decision-makers.

Innovating fast and beating the competition to market while also putting security first is possible when the people of the SDLC make security a top priority. In fact, as the number of vulnerabilities grows and cyberattacks show no sign of slowing down, coding securely is a must for any application to be successful. As long as the entire SDLC is considered in continuous, bespoke, and measurable education initiatives, security does not _have_ to get worse before it gets better.

Does Security Have to Get Worse Before It Gets Better?

The Web Stories plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including 1.24.0 due to insufficient validation of URLs supplied via the 'url' parameter found via the /v1/hotlink/proxy REST API Endpoint. This made it possible for authenticated users to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

Wordfence is authorized by the Common Vulnerabilities and Exposures (CVE®) Program as a CNA, or CVE Numbering Authority. As a CNA, Wordfence assigns CVE IDs for new vulnerabilities in WordPress Core, WordPress Plugins and WordPress Themes.

Assigned CVE IDs and the vulnerability details are published below. For more information about submitting vulnerabilities to Wordfence for CVE ID assignment, please refer to our vulnerability disclosure policy.

This is a continuation of Vulnerability Advisories.

**Restaurant Menu – Food Ordering System – Table Reservation <= 2.3.0 – Missing Authorization on AJAX Actions**

The Restaurant Menu – Food Ordering System – Table Reservation plugin for WordPress is vulnerable to authorization bypass via several AJAX actions in versions up to, and including 2.3.0 due to missing capability checks and missing nonce validation. This makes it possible for authenticated attackers with minimal permissions to perform a wide variety of actions such as modifying the plugin’s settings and modifying the ordering system preferences.

**Restaurant Menu – Food Ordering System – Table Reservation <= 2.3.1 – Cross-Site Request Forgery**

The Restaurant Menu – Food Ordering System – Table Reservation plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 2.3.1. This is due to missing or incorrect nonce validation on several functions called via AJAX actions such as forms\_action, set\_option, & chosen\_options to name a few . This makes it possible for unauthenticated attackers to perform a variety of administrative actions like modifying forms, via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

**Ultimate Member – User Profile, User Registration, Login & Membership Plugin <= 2.5.0 – Authenticated (Admin+) Limited Remote Code Execution via um\_populate\_dropdown\_options**

The Ultimate Member plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including, 2.5.0 via the populate\_dropdown\_options function that accepts user supplied input and passes it through call\_user\_func(). This is restricted to non-parameter PHP functions like phpinfo(); since user supplied parameters are not passed through the function. This makes it possible for authenticated attackers, with administrative privileges, to execute code on the server.

**Ultimate Member – User Profile, User Registration, Login & Membership Plugin <= 2.5.0 – Authenticated (Admin+) Remote Code Execution via Multi-Select**

The Ultimate Member plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including, 2.5.0 via the get\_option\_value\_from\_callback function that accepts user supplied input and passes it through call\_user\_func(). This makes it possible for authenticated attackers, with administrative capabilities, to execute code on the server.

**Ultimate Member – User Profile, User Registration, Login & Membership Plugin <= 2.5.0 – Authenticated (Contributor+) Directory Traversal via Shortcodes**

The Ultimate Member plugin for WordPress is vulnerable to directory traversal in versions up to, and including 2.5.0 due to insufficient input validation on the ‘template’ attribute used in shortcodes. This makes it possible for attackers with administrative privileges to supply arbitrary paths using traversal (../../) to access and include files outside of the intended directory. If an attacker can successfully upload a php file then remote code execution via inclusion may also be possible. Note: for users with less than administrative capabilities, /wp-admin access needs to be enabled for that user in order for this to be exploitable by those users.

**Ultimate Member – User Profile, User Registration, Login & Membership Plugin <= 2.5.0 – Authenticated (Admin+) Directory Traversal**

The Ultimate Member plugin for WordPress is vulnerable to directory traversal in versions up to, and including 2.5.0 due to insufficient input validation on the ‘pack’ parameter. This makes it possible for attackers with administrative privileges to supply arbitrary paths using traversal (../../) to access and include files outside of the intended directory. If an attacker can successfully upload a file with the exact name ‘init.php’ then remote code execution may also be possible.

**Web Stories <= 1.24.0 – Server Side Request Forgery**

**Affected Plugin:** Web Stories  
**Plugin Slug:** web-stories  
**Affected Versions:** <= 1.24.0  
**CVE ID:** CVE-2022-3708  
**CVSS Score:** 9.6 (Critical)  
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N  
**Researcher/s:** Aymen Borgi  
**Fully Patched Version:** 1.25.0  
**Recommended Remediation:** Update to version 1.25.0, or newer.  
**Publication Date:** 2022-10-26

The Web Stories plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including 1.24.0 due to insufficient validation of URLs supplied via the ‘url’ parameter found via the /v1/hotlink/proxy REST API Endpoint. This made it possible for authenticated users to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

**ImageMagick Engine <= 1.7.4 – Cross-Site Request Forgery to Remote Command Execution**

**Affected Plugin:** ImageMagick Engine  
**Plugin Slug:** imagemagick-engine  
**Affected Versions:** <= 1.7.4  
**CVE ID:** CVE-2022-2441  
**CVSS Score:** 8.8 (High)  
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H  
**Researcher/s:** Rasoul Jahanshahi  
**Fully Patched Version:** Unpatched.  
**Recommended Remediation:** Uninstall plugin from site until patched version available.  
**Publication Date:** 2022-10-17

The ImageMagick Engine plugin for WordPress is vulnerable to remote code execution via the ‘cli\_path’ parameter in versions up to, and including 1.7.4. This makes it possible for unauthenticated users to run arbitrary commands leading to remote command execution, granted they can trick a site administrator into performing an action such as clicking on a link. This makes it possible for an attacker to create and or modify files hosted on the server which can easily grant attackers backdoor access to the affected server.

**Log HTTP Requests <= 1.3.1 – Stored Cross-Site Scripting**

**Affected Plugin:** Log HTTP Requests  
**Plugin Slug:** log-http-requests  
**Affected Versions:** <= 1.3.1  
**CVE ID:** CVE-2022-3402  
**CVSS Score:** 6.1 (Medium)  
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  
**Researcher/s:** Etan Imanol Castro Aldrete  
**Fully Patched Version:** 1.3.2  
**Recommended Remediation:** Update to version 1.3.2, or newer.  
**Publication Date:** 2022-10-05

The Log HTTP Requests plugin for WordPress is vulnerable to Stored Cross-Site Scripting via logged HTTP requests in versions up to, and including, 1.3.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers who can trick a site’s administrator into performing an action like clicking on a link, or an authenticated user with access to a page that sends a request using user-supplied data via the server, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

**Bricks 1.2 – 1.5.3 – Remote Code Execution**

**Affected Theme:** Bricks  
**Theme Slug:** bricks  
**Affected Versions:** 1.2 to 1.5.3  
**CVE ID:** CVE-2022-3401  
**CVSS Score:** 8.8 (High)  
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  
**Researcher/s:** Anonymous  
**Fully Patched Version:** 1.5.4  
**Recommended Remediation:** Update to version 1.5.4, or newer.  
**Publication Date:** 2022-10-03

The Bricks theme for WordPress is vulnerable to remote code execution due to the theme allowing site editors to include executable code blocks in website content in versions 1.2 to 1.5.3. This, combined with the missing authorization vulnerability (CVE-2022-3400), makes it possible for authenticated attackers with minimal permissions, such as a subscriber, can edit any page, post, or template on the vulnerable WordPress website and inject a code execution block that can be used to achieve remote code execution.

**Bricks 1.0 – 1.5.3 – Missing Authorization to Arbitrary Content Creation/Modification**

**Affected Theme:** Bricks  
**Theme Slug:** bricks  
**Affected Versions:** 1.0 – 1.5.3  
**CVE ID:** CVE-2022-3400  
**CVSS Score:** 6.5 (Medium)  
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N  
**Researcher/s:** Anonymous  
**Fully Patched Version:** 1.5.4  
**Recommended Remediation:** Update to version 1.5.4, or newer.  
**Publication Date:** 2022-10-03

The Bricks theme for WordPress is vulnerable to authorization bypass due to a missing capability check on the bricks\_save\_post AJAX action in versions 1.0 to 1.5.3. This makes it possible for authenticated attackers with minimal permissions, such as a subscriber, to edit any page, post, or template on the vulnerable WordPress website.

CVE-2022-3708: Vulnerability Advisories Continued - Wordfence

The Log HTTP Requests plugin for WordPress is vulnerable to Stored Cross-Site Scripting via logged HTTP requests in versions up to, and including, 1.3.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers who can trick a site's administrator into performing an action like clicking on a link, or an authenticated user with access to a page that sends a request using user-supplied data via the server, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Tag

#wordpress