After numerous requests, we've decided to revive our previous security newsletter, taking it one step further. We’re excited to announce the launch of Patchstack WordPress Security Weekly. 

In Patchstack’s WordPress Security Weekly, you will learn:

• How to approach WordPress security practically and actionably (no confusing jargon, just clear explanations)
• High-priority vulnerabilities our team logged in the past 7 days
• Security advice from experts
• Vital news on WordPress security, trends, and Patchstack

And more!

Crash course with 5 bite-sized WordPress security lessons

Plus, as soon as you sign up, you'll get your crash course in WordPress security through lessons drawn up by our security experts:

• How do hacks happen?
• What are the consequences you haven't considered? (Spoiler alert: SEO is a big one)
• How do you prevent attacks?

You'll come out knowing exactly which measures you should put in place to protect your site(s).

As the #1 CNA in the world, Patchstack’s team and community of ethical hackers process the most WordPress vulnerabilities and issue real-time protection. Through our newsletter, they share their insights with you. 

If you’re not an expert at WordPress security (yet), don’t worry. We’ll show you the ropes, giving you practical information to protect your and your clients’ websites. 

See you there?

Scroll down to subscribe! 

The post Announcing the Patchstack WordPress Security Weekly Newsletter appeared first on Patchstack.

Forking a project allows anyone to take ownership of an open-source project and lead it in a new direction, but there is far more to forking a project beyond declaring a project has been forked.

Open source has a powerful tool up its sleeve that allows anyone to clone a project and take it in a new direction. This superpower is simply known as forking the project, and the web's most widely used content management system WordPress was started as a fork of another open-source project: b2/cafelog.

There is also a community-led fork of modern WordPress called ClassicPress.

The creators of nulled plugins and themes sometimes claim they are simply creating a fork. But there is more to forking a project than just making it available.

What is an open-source fork?

An open-source fork refers to a project that has been derived from an existing open-source project. When a project is forked, it means that a copy of the original project’s source code is taken and further developed independently.

The purpose of forking a project can vary, but it generally involves making modifications, adding new features, or addressing specific needs that differ from the original project’s direction.
Forks can occur for various reasons, such as:

1. Development Divergence: When the goals or priorities of a group of developers diverge from the original project, they may decide to create a fork to pursue their own vision.
2. Bug Fixes and Improvements: Forks can be created to address specific issues or add enhancements that are not being actively pursued in the original project.
3. Community Support: If a project loses momentum or its development slows down, a fork can be initiated to continue the project’s progress with a new community of contributors.
4. Experimentation and Innovation: Forks can serve as a sandbox for experimentation and innovation, allowing developers to explore new ideas without affecting the stability of the original project.

It’s important to note that open-source forks maintain their own separate development paths and can evolve into independent projects with their own communities, development teams, and features.

However, they often retain the underlying principles of open-source software, allowing others to freely access, use, and contribute to the forked project’s source code.

What does forking a project mean?

Forking a project refers to creating a copy of an existing project’s source code. When you fork a project, you duplicate the entire codebase, including its history and branches, to your own repository.

Forking is commonly done in open-source software development (e.g. WordPress), where the original project’s source code is made publicly available for anyone to view, modify, and distribute. By forking a project, you establish a separate and independent development branch that allows you to make changes to the code without directly affecting the original project.

When you fork a project, you effectively create your own instance of the project that you can freely modify, experiment with, or contribute to. This copy becomes your own repository, and you gain full control over its development.

Any changes you make in your forked repository do not impact the original project unless you explicitly choose to contribute those changes back through a process called a pull request.

Is forking good for a project like WordPress?

Forking is a powerful mechanism in collaborative software development as it encourages community involvement and enables different individuals or groups to take a project in diverse directions based on their specific needs, goals, or ideas.

It allows for experimentation, customization, bug fixes, feature additions, and even the creation of entirely new projects based on the original codebase.

Forking a project means the new project owners are taking on the responsibility of the project—responsibilities such as communication, community, updates, and maintenance.

Sometimes, these important considerations can be missed by short-sighted developers looking to take a project in a new direction.

How can forking be bad?

While forking a project can be beneficial and often leads to positive outcomes, there are scenarios where forking can have negative implications or be considered undesirable. Here are a few potential drawbacks or challenges associated with forking:

1. Fragmentation of Development: Forking a project can lead to fragmentation, where the developer community becomes divided between multiple forks. This can result in efforts being spread thin across various versions, reducing collaboration and potentially slowing down overall progress.
2. Maintenance Burden: Forking a project means taking on the responsibility of maintaining the forked codebase independently. This includes addressing bugs, security vulnerabilities, and compatibility issues, which can be time-consuming and resource-intensive, especially if the original project has a larger community and support.
3. Loss of Centralized Governance: When a project is forked, it often means separating from the centralized governance structure of the original project. This can lead to challenges in decision-making, coordination, and establishing a clear project direction, particularly if the forked project lacks a strong leadership or community consensus.
4. Community Fragmentation: Forking a project can result in a split within the developer community. Contributors may need to choose between the original project and the forked version, leading to a divided community and a decrease in overall collaboration and shared resources.
5. Diluted Userbase and Support: With multiple forks, the userbase of each individual project may be divided. This can lead to diluted user support, documentation, and community resources, making it more challenging for users to find help or guidance.
6. Duplication of Effort: Forking a project without apparent differentiating factors or substantial improvements can result in redundant efforts. Instead of pooling resources and collaborating on the original project, energy, and contributions are divided between similar projects, potentially hindering overall progress.

Despite these potential challenges, forking can still be a valuable strategy in certain cases, especially when there are strong motivations, clear differentiators, and a dedicated community behind the forked project. It’s important to evaluate the trade-offs and consider the potential long-term implications before deciding to fork over a project.

Want to listen to what an open-source fork is?

Listen to this Patchstack Weekly episode where Robert talks about securing open-source forks. 👇

The post What Is An Open-Source Fork And How To Secure it? appeared first on Patchstack.

This week's knowledge share is about a rare but serious security bug that can be found in any PHP application. Luckily it is easy to avoid and WordPress has a built-in function that developers can utilize to help secure against it.

I will then cover 3 security bugs that were patched recently in this week's vulnerability roundup.

How to prevent insecure inclusion bugs

Inclusion is a good thing, open source communities are all about inclusion. But inclusion has its limits, like inclusion of security bugs - we don't want to include those in our PHP code.

What are inclusion security bugs?

Inclusion security bugs are caused when user-controlled data is sent to PHP's include or require functions. This can lead to arbitrary code execution or disclosure of sensitive data (such as a server's /etc/passwd file) because the purpose of these functions is to read and execute the contents of the file as if it was part of the PHP application.

There are two primary types of inclusion security bugs:

1. Local File Inclusion (LFI for short)
2. Remote File Inclusion (RFI for short)

When it comes to Local File Inclusion, the code can be tricked in to reading any file in the file system and either displaying the contents or executing it as PHP. This may seem harmless, however, if attackers can upload files or in some cases include the web server's log files then arbitrary execution can occur.

With Remote File Inclusion, the risk is the same but remote files make it much easier for attackers to control the code being executed as well. Luckily default PHP configurations protect against this.

Both types of inclusion security bugs are dangerous, so let's now talk about how to secure against them.

Securing code against inclusion bugs

Inclusion security bugs are caused when the user controls what file or URL will be included. The fix for these types of bugs will come down to limiting or validating what users are allowed to pass through to the dangerous function (include or require in this case.)

WordPress includes a handy filename sanitize function called sanitize_file_name(). If you intend to use a user-supplied value as a file name, the sanitize_file_name function will strip out any character that does not belong in a file's name. This includes slashes, so that will protect against directory traversal concerns too.

I already mentioned default PHP configurations protection against remote file includes, but since open source projects do not control PHP configurations it's a good idea to code defensively to protect end users. There are no easy built in functions to address this, but you can use a function like stripos() to inspect the variable to see if it looks like a URL (e.g.. does it start with http:// or https:// ? ) and disallow it.

Another defensive coding tactic that applies to both LFI and RFI is to hard code the path of the file you plan to include (be sure to sanitize the file name.) This will protect against URLs being used, ensure you are reading a file located in a place you expect it, and protects against directory traversal concerns.

Vulnerability roundup

User Role by BestWebSoft - Cross Site Request Forgery (CSRF)

Developers of the User Role by BestWebSoft (slug name user-role) patched a serious CSRF bug. This bug could have allowed user privilege escalation on the website, if attackers can trick logged in users to visit a specially crafted link.

WP-EasyCart - Local File Inclusion

The developers of wp-easycart patched a local file inclusion bug last month. It requires a high privileged user (administrator) account to perform the attack, which reduces its relevant severity. It is still great that they addressed this bug, and site owners should update as soon as they can.

Advanced Custom Fields - PHP Object Injection

The developers for Advanced Custom Fields patched an authenticated PHP Object Inject bug in their code base recently. The developers also provided a backport for this patch, according to their [detailed release notes] users should upgrade to either ACF 5.12.5 or 6.0.7 to address this bug on their websites.

Thanks and appreciation

This week's thanks go out to the developers of User Role (Best Web Soft), wp-easycart (WP Easy Cart), and Advanced Custom Fields (WPEngine). These developers did a great job addressing those security bugs and ensuring their end-user websites are safe and secure.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #66: How To Secure Your Code Against Insecure Inclusion Bugs appeared first on Patchstack.

This week's knowledge share is all about how a serious security risk closed source software faces, that open source embraces and turns into one of its strengths.

I will then cover another serious security bug that was patched, but attackers are already attacking. Site owners need to know about this high-severity security bug and need to update their sites if it's not already too late.

Weekly knowledge

Closed-source software has one vulnerability Open Source software will never face. Source code leaks.

Twitter was affected by a source code leak recently, with portions of its source code found on GitHub.

The LastPass breach also included confirmation attackers were able to exfiltrate some Last Pass source code last summer.

Microsoft had multiple projects' source code get stolen in 2022 too, this only affected their web and mobile applications like Bing, Maps, and Cortana. Not the operating system.

Even video games' source code is not safe, with a leak reported by Rockerstar's famous GTA series.

When a closed-source or proprietary software gets its source code leaked, that can be dangerous. Not only are there security implications of bugs being found, but sometimes close source software includes secret credentials right in the code base (a very bad practice). From a business perspective, there are also stolen intellectual property concerns, this could give competitors an advantage if they review the source code.

Source code leak attacks could negatively affect any software company, every type but one. Open source software companies.

Open source, by it's very nature gives the source freely to all for review.

Open source takes what is an inherent risk with closed source software, and turns it into a strength. Because, when the code is available for all to see, then security researchers can look for bugs for free.

Of course, someone finding the bug and someone reporting the bug to the project are two separate steps. If someone doesn't report the security bug to the developer, well, they're not exactly helping.

This is where services like Patchstack Alliance come in to play. The Alliance incentives researchers, encouraging them to report to our team. The alliance team then works with the developers to professionally inform them of the bug, its impact, and if needed some guidance on a patch.

Users of open source software, be it WordPress, Linux, BSD, Apache, PHP, or many other free open-source software packages out there can be assured, there is no risk when their favorite projects' source code is made publicly and free. This is the intent of open source and through it, open source turns a risk inherent in closed source into a strong method of security.

Vulnerability roundup

In this week's vulnerability roundup, I will share the details of an actively exploited vulnerability that has already been patched in Elementor Pro.

The developers released a patch to address an authenticated arbitrary option table update bug that only affected the Pro version (e.g. not the free version of Elementor).

The vulnerability was originally reported by NinTechNet and provided a detailed write up. The classification of this vulnerability is an arbitrary option table update risk, something I have commented on in Patchstack Weekly #27: How up Update wp_options Securely.

This vulnerability requires authentication to perform the attack, so it is only a concern for websites that do not trust their users. This includes subscriber and customer user accounts, so e-commerce websites that create user profiles are especially at risk.

Arbitrary option table updates are a unique risk to WordPress sites, but the impact could be that attackers can create new accounts with administrator roles. If your sites are running Elementor Pro, it may be a good idea to check for indicators of compromise (something Patchstack shared details on what to look for on our blog) and double check that no new administrator users have been added to your site.

Like most security bugs, the developers have made a patch available and now it is up to the site owner to apply the patch before their sites get hacked.

Thanks and appreciation

This week's thanks go out to the developers of Elementor Pro as well as the researchers over at NinTechNet. By working together they were able to address a serious security concern in the pro version of the plugin.

A special thank you goes out to the members of the Patchstack Alliance. Just as with NinTechNet and Elementor, the Alliance works every day to help bridge the gap and eliminate security bugs in open source projects.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #65: The One Serious Vulnerability Open-Source Doesn't Have to Worry About appeared first on Patchstack.

This week's news is about understanding security bug severity, and how not all security bugs are equal. Some can wait for a patch, but others may need immediate attention. You can save yourself a lot of headaches when you learn how to differentiate.

I will then discuss one security bug which is an actual emergency, in this week's vulnerability roundup.

How fast should you apply a security update?

Everyone running any software has performed an update. From your cell phone to your desktop, and even your websites. Everyone knows that updates are important and need to be performed. Luckily the process is normally nothing more than a click of a button away.

But, when should you click that update button? Should you update immediately every time, stopping your work and waiting for the update to complete or can you wait until a more convenient time?

The common assumption is some updates can wait, but, when it comes to security updates you should take action right away. But, not all security updates are equal, some require immediate action, while others can wait.

How can you tell the difference? Pay attention to the severity of security bug patches, because not all security vulnerabilities carry equal risk.

Don't panic over every vulnerability

In 2022, 87% of the reported security bugs in the WordPress ecosystem would be considered medium or low severity. It is fantastic that these low and medium-security bugs received a patch from the developers, but site owners need not panic, drop everything, and apply those patches.

It is relatively safe to wait, and a good idea to take your time (remembering to backup first) before applying patches for these low or medium-risk bugs.

I do mean relative too. These bugs commonly require an authenticated user to perform the attack or an attacker to trick an authenticated user to perform some action. If you trust your website's users to not be malicious, or not get duped by attackers, then it is relatively safe. But, if your WordPress website has open registration or your website's users are not to be trusted, then these medium-risk bugs may pose a more serious risk.

Have a response plan ready when you need to

Not all security bugs are low or medium risk though. There are the high-risk bugs (11% of reported bugs in 2022) and the most dangerous critical severity bugs (2%.)

What makes a bug a critical risk? Commonly they require no authentication to perform, which means simply having your website accessible on the internet means it is at risk. And, well, we all have our websites accessible to the internet, that is the whole purpose.

These critical risk bugs (and some high-risk ones) are the security bugs you need to have an emergency action plan for. They are the bugs you should be dropping all other work to address ASAP.

Your plan for these bugs should be the same as any patch update, just performed sooner than later. Back up your site(s) first, then apply the patch. It should not take too long, however, if you do not have the time (or wish to avoid the stress) that is where using security services comes in super handy. These services (like the Patchstack app) can apply vPatching to buy you the time you need to apply the security update.

Vulnerability roundup

Talking about critical risk security bugs, there was one patched this week in a plugin with half a million installations. This security bug patch really does need your immediate attention.

The WooCommerce Payments plugin is the affected plugin. The developers received a report from a security researcher, and with this information, they released the patch to address the critical severity security issue.

This bug was critical because it would allow attackers to make a single unauthenticated request and receive a valid WordPress authentication cookie for any user on the website. This includes administrator users if they know or guess the user's identification number.

The Woocommerce payments plugins team, worked with the plugins repository team to push an emergency update to all sites running the plugin. This means even sites with auto-update disabled for the plugin, received the update. Based on the severity of this vulnerability, this decision will prevent sites from being hacked.

Within 24 hours of the patch being made available, some security vendors are already reporting that active exploitation is being attempted. Based on my review of the code, this is an easily weaponized attack so this is likely true.

Hopefully, sites have auto-updated faster than the attackers can find their websites, but if you haven't already, it is strongly recommended you double check your site's installation of WooCommerce Payments is up to date immediately. It may also be a good idea to rotate your WordPress website's secret salts. This will invalidate all authentication cookies WordPress has already issued, log out any currently logged-in users, and protect the site in case an attacker has already used the exploit to acquire a valid authentication cookie using this exploit.

You can read more regarding this issue on the Patchstack blog or directly from the developers of the plugin on the WooCommerce Developer blog.

Thanks and appreciation

This week's thanks goes out to the developers of WooCommerce payments plugin and the plugin review team. Their actions to address this serious security bug are critical for securing end user sites from critical security bugs.

A special thank you goes out to the researcher(s) who found the bug. WooCommerce credits Michael Mazzolini of Gold Network for their report, and I personally thank them for reporting this issue responsibly, ethically, and for the good of the user.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #64: Understanding Security Bug Severity appeared first on Patchstack.

In this week's knowledge share, I will be sharing a review of Patchstack's annual 'State of WordPress Security' report. This report was just released and is jam-packed with useful insights from the front lines of WordPress security.

I will then cover 3 vulnerabilities of interest in this week's vulnerability roundup. One of these three contained a mystery I am still uncertain about.

2022 WordPress security highlights

The Patchstack team has been hard at work the last few weeks with the 2022 State of WordPress Security report. After a lot of collecting, reviewing, commenting, re-writing, collaborating, and designing, we have finally released the 2022 State of WordPress security paper.

In this week's knowledge share, I will highlight some key facts from this paper.

Plugins lead the way

WordPress plugins still account for the lion's share of patched security bugs in the WordPress ecosystem. This of course makes sense, as they also account for the vast majority of lines of code in the ecosystem.

The good news is the WordPress plugin ecosystem is well supported by their respective developers. The majority of developers Patchstack worked with regarding a security bug, had patches made available in short order. In one case I handled last year, the patch was made available in just a few hours!

2022 was the biggest year in security bug patches

The number of bugs reported, patched and/or addressed in the WordPress ecosystem tripled in 2022 compared to 2021.

This trend is showing the power of collaboration between security researchers and open-source software developers. This cooperation led to thousands of security bugs being patched in the WordPress ecosystem - in other words, this is how vulnerabilities get removed.

Two WordPress core bugs were left unpatched

There were two security bugs in WordPress core (one is in Gutenberg) that were publicly disclosed in 2022, but never received a patch.

Don't worry though - while these bugs went unpatched they present a very low or no risk at all to an average website. This is due to the unlikely conditions needed to be met for exploitation, such as the requirement to break existing browser security models or exploitation and control of the DNS server a website relies on.

Hopefully, patches are merged into the WordPress core project for these bugs. But,there is no need for site owners to panic if they see them pop up in security reports.

The danger of unsupported plugins

Not all unpatched security bugs are acceptable risks though. We identified that 26% of critical severity security bugs in WordPress components went unpatched in 2022. This was due to the plugins that were unsupported or abandoned by their developers.

These plugins will remain active on WordPress websites they were installed on, which will happily display 'no update available' notice in the admin dashboard. The site owners will therefore be in the dark about the risk that exists on their site, unless they have something like the Patchstack App installed to provide them with a warning.

Patchstack Alliance helping out

The Patchstack Alliance handled around 1,000 security bug reports in 2022. Some reports are still pending, but 661 of those resulted in a patch for the bug, and a more secure component (plugin or theme). Unfortunately, 87 components ended up being closed after we escalated the cases to the WordPress plugin repository - these projects have likely been abandoned and are unsupported.

The Patchstack Alliance provided support for the teams and volunteers behind open-source repositories. By handling 80% of the security reports directly with the developers, we did not need to take any of the WordPress volunteers' time. This means less work for the teams managing the respective repositories, so they can focus on other matters.

Looking ahead

We are looking forward to what 2023 brings. With the knowledge the Patchstack team has learned over the years, we have begun offering services to help with any security pain point we spot. From notifying site owners and agencies directly with the Patchstack App, through partnerships with hosting providers that use Patchstack's vulnerability intelligence for pro-active security warnings, as well as helping security researchers prove their skills and sometimes earn bounties through the Patchstack Alliance.

In 2022 we also started the Patchstack mVDP, as a way to help developers handle security bug reports, currently free of charge.

If 2022 predicts anything, I would say 2023 will bring a more secure WordPress ecosystem.

Vulnerability roundup

n-media-woocommerce-checkout-fields - Unauthenticated File Upload

Users of the WooCommerce Checkout Field Manager plugin are encouraged to update immediately. The recent release patches a critical risk, an unauthenticated file upload security bug. There are only a few hundred websites running this plugin, however, it looks like only 16% of them have applied this security patch so far.

Watu Quiz - Reflected Cross Site Scripting

Developers of the watu quiz plugin released version 3.3.9.1 to address a Reflected Cross Site Scripting security bug. This update does not include a changelog entry highlighting its importance so it is important you make sure this update is applied.

Postmatic - PHP Object Injection

The developers for the postmatic plugin, also known as Replyable, patched a PHP Object Injection bug months ago. This bug's information was just publicly released, however, it is a mystery to me why the plugin appears to be listed as closed since December due to an unknown security concern.

Hopefully, the developers of postmatic/replyable are able to get their plugin back in working order soon. In the meantime though, users may want to consider looking for an alternative plugin.

Thanks and appreciation

This week's thanks goes out to the developers of WooCommerce Checkout Field Manager, Watu Quiz, and Postmatic plugins. I see your efforts to keep your customer sites secure.

This week's special thank you goes out to the reporters and writers who have also reviewed and covered Patchstack's 2022 State of WordPress security paper. Authors like Nyasha Green at MasterWP and Dan Knauss of iThemes provided their own summaries and insight of what they learned from this great review of the WordPress security landscape.

If you would like to read the 2022 State of WordPress security paper just go to patchstack.com and click on the banner at the top of the page.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #62: The Patchstack State of WordPress Security Report appeared first on Patchstack.

This week's news is about static sites and security. Did you know with the right plugin WordPress can be used to generate HTML? If you have a non-interactive website, you could benefit from using static sites to practically guarantee security.

This week's vulnerability roundup will list over a dozen WordPress plugins that have unpatched security bugs in them. Most of these were reported through the Patchstack Alliance. While it is unfortunate the plugins were removed from the WordPress.org repository, it is a good thing that site owners will not be able to easily install these unsupported, possibly abandoned plugins on their WordPress websites.

The benefits of a static WordPress site

Did you know WordPress can be used to generate static HTML? Well, with the right plugin it can.

Converting to a static site may be an ideal way to manage some websites. Some examples would be brochure websites that direct the visitor to a brick-and-mortar store (with no online sales) or public journals or blogs would also be highly appropriate (as long as comments are disabled.)

A static website differs from a normal WordPress installation because it requires two separate components:

• A WordPress installation to generate static HTML files. You will want this installation only accessible by the site owner.
• A basic hosting account for the HTML files. This will be the site you point your DNS to, and people would visit.

This separation of HTML generation and hosting provides a lot of benefits (and a few drawbacks) which I will share with you now.

Static is the ultimate cache

If you believe caching plugins gives a performance boost. You can think of static sites as the ultimate cache. With static sites, you use the WordPress backend to add new or modify posts, content or even the design of the website. When you're done with your changes, you export and upload the site's files to your hosting provider (just like we did back in the 90s!) Once you do the changes are live and your site will be faster than any caching plugin could offer.

Static is secure

Using a static website removes almost all possible security threats. Think about it. What can get hacked? There is no database, it is just HTML files. There is no wp-login.php for bots to brute force either.

There are a few attacks I can think of, such as DOM-based or reflected XSS or your sFTP password could get compromised. But these threats affect dynamic WordPress websites just the same.

Never worry about updates

Since there is virtually no risk of vulnerabilities, you can rest easy. You will still have to update the WordPress installation you use to generate the static HTML from time to time, but this installation should only be accessible to the site owner. Allowing you to have a leisurely pace when it comes time to update.

The drawback - limited features

The biggest drawback of static sites is that the site will not be interactive. This means no contact forms, no e-commerce, no newsletters, no comments, etc… at least not directly managed by the website itself.

There are ways to make these features work in static websites, by using JAMstack design methods or headless WordPress. But that is a talk for another Patchstack weekly.

This drawback of limited features could be made up for not only by improved security and performance but also by reduced hosting fees. It is probably the first time I will get to say this, but it is …

The less expensive option is more secure.

Sites that can switch to static files instead of dynamically generated content can save a ton on hosting fees. There are multiple extremely affordable options (I'm talking the cost of a coffee or less per month) and even free options offered by GitHub, Google, CloudFlare, and more.

Static files may not be a right fit for every website but if you can go static, I recommend you do. Your site will be more secure, more performant, and cost less!

For dynamic web applications though, static files are not an option. This is why it is important dynamic web applications have robust security programs that include things like a security.txt file, preventative WordPress security, and vPatching.

Vulnerability roundup

The Patchstack Database added over 80 new vulnerability records in the last week, of which 80% received a timely patch from their respective developers. Unfortunately, that also means 16 of those 80 did not receive a patch. That is one in five, and should emphasize the importance of choosing actively developed plugins and supporting your plugin developers. Without your support, these open source projects will not thrive.

Here is the list of possibly abandoned plugins that have unpatched security bugs disclosed in the last week.

• fontiran - Broken Access Controls
• wp-post-comment-rating - Unauthenticated Vote Manipulation
• olevmedia-shortcodes - Authenticated XSS
• eyes-only-user-access-shortcode - Authenticated XSS
• tapfiliate - Authenticated XSS
• facebook-like-send-button - Authenticated XSS
• service-area-postcode-checker - Authenticated XSS
• upload-file-type-settings-plugin - Authenticated XSS
• download-info-page - Authenticated XSS
• sticky-ad-bar - Authenticated XSS
• open-social - Authenticated XSS
• vslider - Authenticated XSS
• ultimate-wp-query-search-filter - Authenticated XSS
• feed-changer- Authenticated XSS
• nooz - Authenticated XSS
• wp-baidu-submit - Authenticated XSS

Thanks and appreciation

This week's thanks goes out to the hard working security researchers behind the Patchstack Alliance. Without your efforts identifying, verifying, and reporting these security bugs then they would never be getting addressed. And more insecure projects would continue to be distributed to unsuspecting websites.

A special thank you goes out to the people putting the hard work in behind the WordPress plugin repository. The extraordinary effort of wrangling over 50,000 plugins is not missed by me. Keep up the good work behind the scenes that keeps that repository running smoothly and safely.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #60: Should You Convert WordPress To a Static Site? appeared first on Patchstack.

This week's knowledge share will be about virtual patching. I will explain how it works, why vPatching through Patchstack is different, and how it can save you from a lot of stress and anxiety when it comes to deciding when to update your site's components.

Then, in this week's vulnerability roundup, I will share the story of one plugin that patched a lot of security bugs in a single release. A heroic effort by the developer, but end users may receive a lot of alerts if they haven't updated yet.

Do you need Virtual Patches?

Everyone knows software has updates, but not all updates are equal. Some updates add minimal features, and some updates secure the software, but on rare occasions, some software updates break the thing they're updating.

This inequality of update importance has led to some site owners either opting out of updates outright, at least until they can monitor that the patch does not break things.

This delay can lead to security patches not being applied in a timely manner. This is where virtual patching comes into play.

What is a Virtual Patch?

Virtual patching is a term used when a software patch can be applied without updating the software itself. Typically using another technology layer like a WAF (Web Application Firewall) on the web server.

It is mostly used in the information security field as a way to secure software temporarily until a time that the software can be patched formally. It acts as a stop-gap when patches are delayed.

Patchstack has built the vPatch system, a specific method that provides auto-mitigation to open-source software security vulnerabilities through crowdsourced security research and AI/ML based source code analysis.

This is why vPatching is a valuable tool to have for any WordPress website where updates are not automated. In the event of a security bug being discovered in a plugin or theme, a vPatch buys you time to perform the update on your schedule.

vPatching is also handy if you encounter a bug in the update process. The extra protection vPatching provides gives you the option to downgrade back to the known working (but insecure) version of a plugin to work out the problem. Keeping the site online while you troubleshoot.

That is not all vPatching helps with; it can also be a last line of defense if you are using unpatched or unsupported software.

Protection from unpatched vulnerabilities

It is an unfortunate reality that not all open source projects are actively developed. I have written about this issue before, and even wrote some last patches for WordPress plugins that have been abandoned.

A vPatch is the only option to secure your website if a vulnerability is identified in an abandoned plugin. The vPatch will protect the website until you can find the time to find a replacement for the abandoned component that is putting your site at risk.

Of course, Patchstack offers vPatches for all paid Patchstack app accounts. If you are interested in being in control of how and when patches get applied but do not want to compromise site security, then you should be sure you have vPatching in place to protect your sites in the meantime.

Vulnerability roundup

This week's vulnerability roundup is all about one plugin, and twenty patched bugs. The plugin is Wicked Folders, the twenty bugs can be classified as either Missing authorization or Cross-Site-Request-Forgery. Both bugs are considered a Medium severity, and may not apply to you at all because they require a subscriber level account or to trick logged in users to follow links.

It appears a researcher familiar with finding these two types of security bugs audited the plugin and found 10 API endpoints that lacked nonce or authorization checks. I am unsure if Wicked Folders paid for an audit or if this was found independently. But it shows someone was looking for as many instances of these bugs as they could find.

The developer did a great job providing the patch back on February 6th and noted in the changelogs that this update includes security patches. Now, it is all up to the users to get their site(s) updated.

If you run a site with Wicked Folders and have not yet updated, you may receive a lot of notifications about this. Twenty notifications to be specific. This is because the CNA requesting CVE numbers reported 2 vulnerabilities for each of the 10 API endpoints that lacked nonce or authorization checks. This may result in a little alert fatigue or a temporary spell of anxiety when you see your inbox full of alerts. Don't worry though, all twenty of those CVEs are addressed in a single release and none are an emergency. So, update away at your convenience, and be certain the developer for Wicked Folders is attentive to security bugs (even 20 at a time!)

Thanks and appreciation

This week's thanks goes out to the developer of the Wicked Folders plugin. Thank you for patching all of those AJAX endpoints, and addressing each of those reported bugs.

A special thank you goes out to iThemes. The team announced this week that the iThemes Security and iThemes Security Pro plugins are now powered by Patchstack's Vulnerability Intelligence. This collaboration means more sites are being protected and is a win for everyone except the botnets.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #59: Do You Need Virtual Patches? appeared first on Patchstack.

This week, I learned a fun fact about something security related Automattic is leading the way on. In this week's knowledge share, I will explain a proposed security standard that Automattic has already implemented more than anyone else. I will leave it up to you if you want to add this proposed standard yourself and show you how easy it is to set up.

In this week's vulnerability roundup I will cover one plugin with a high-risk security bug patched by its developer. As well as share details on some bugs in lesser-known possibly abandoned plugins which have left just a few sites at risk as these security bugs may go unpatched.

Weekly knowledge

I have been hanging out on mastodon recently and found it wonderfully nostalgic. There are a lot of people there sharing some really stellar posts, ideas, and blogs. It reminds me of the halcyon days of social media.

One of those blogs that I encountered was about a proposed security.txt standard. A security researcher out of Denmark wrote up a blog to encourage more websites to adopt the use of security.txt files.

Their post "A free way to improve your security.(txt)" shares some great insight from the security researcher's point of view.

One neat thing they did was scan 10 million websites looking for a security.txt file. They found very few websites have a discoverable security.txt file, but this is expected as the proposal is not a standard yet, and it is relatively new.

But, some big names have security.txt files, including Google, Facebook, Github, Slack, and multiple government organizations. But a company we all know is leading the way, Automattic. Automattic is listed as the security point of contact for the majority of security.txt files this researcher found. It appears Automattic installed security.txt files on the biggest number of websites, which means they're the organization with the largest adoption of the proposed standard.

That may or may not be reason enough to set up a security.txt file yourself, but let me show you how easy it is.

What is a security.txt file?

The primary purpose of a security.txt file is to identify a security-related point of contact for the website. You place this file in a well-known location, such as /security.txt or /.well-known/security.txt on your website so researchers who identify concerns on your website know who to contact.

This is a huge time saver for security researchers and bug bounty hunters. This is both a good and bad thing, but I will explain how to avoid the bad aspects in a second.

The contents of the security.txt file are simple. In a minimalist style, it can be just one field:

Contact: https://yourwebsite/vulnerability-disclosure-policy

or

Contact: mailto:[email protected]

There are many more fields you can add to the security.txt file, as well as a handy securtity.txt generator tool all available for free on securitytxt.org. You should check it out if you want to set this up.

Security.txt files work really well in conjunction with a vulnerability disclosure policy (VDP). You can avoid some of the bad aspects of bug bounty begging by using a VDP. When you communicate to researchers and bug bounty hunters what they can expect for bounties (including making it clear if you offer no bounties) you can save everyone time. You can also clarify what sort of security reports you want to hear about (or which you do not). Don't worry if you are offering no bounties either, you can still set up a VDP because some security researchers really do just want to help you out.

While the security.txt file is specific to vulnerabilities found on websites. If you are thinking something similar, something that helps communication between developers and researchers should exist for plugins and themes, well… you're right, luckily there is something. Patchstack launched a service for just this reason, a way to help plugin developers to communicate with security researchers called Patchstack mVDP. You should look into it. Bonus, it is free for FOSS WordPress plugins and we will write the vulnerability disclosure policy for you.

Vulnerability roundup

js-support-ticket - Unauthenticated Arbitrary File Upload

Users of the JS Support Ticket plugin should update to the newest release as soon as possible. The developers have been hard at work addressing security bugs and improving the plugin.

Seeing developers providing security updates is a great sign of a thriving and healthy project like JS Support ticket. The same can not be said for the next two plugins:

marketing-performance - Cross Site Scripting (XSS)

The generically named plugin "marketing-performance" has only a few installations, and was last updated 4 years ago. This week, a cross site scripting vulnerability was publicly disclosed. If anyone out there has the "marketing performance" installed on their site, you likely want to look for an alternative that is actively developed.

1003-mortgage-application - Authenticated (subscriber+) Arbitrary File Download

The 1003 mortgage application plugin is vulnerable to a bug that could allow any logged in user (including subscribers) to download arbitrary files off the web server. The last release was just 2 months ago, so hopefully, the developers are still active and will provide a patch soon.

Thanks and appreciation

This week's thanks goes out to the developers of js-support-ticket a.k.a.. JS Help Desk. Thank you for patching the security bugs and really improving your project's code quality in the last few weeks.

Further thanks is extended to EdOverflow and Yakov Shafranovich the creators of the security.txt standard, and maintainers of securitytxt.org

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #58: Do You Need security.txt? appeared first on Patchstack.

This week's knowledge share is for developers and site owners alike. I will be discussing how open source projects (really any code project) can show, not just tell, their users that their project's code is secure and safe to use.

In this week's vulnerability roundup, I will share details about 3 high-risk security bugs in WordPress components of which 2 received patches and 1 went without.

How developers can prove their security

This week's knowledge share continues the trend in the past few weeks' new years security resolutions. This week's resolution is how developers and project owners can prove their project is secure and safe to use.

If you're not a developer, stick around. You may learn what to look for in a project that is serious about handling security and is willing to prove it.

As in previous new years resolutions I will share a few checklist items that open source projects can take to improve and show their security process to users. Or, as I prefer to say - to prove they have a mature security model.

Let's get started.

Do they have a history of security releases?

This one may sound counterintuitive at first. You want to look for a lot of security releases. Because a project with a regular history of security fixes is proof of active security-related development and improvements. If a project has zero security-related patches, don't think that means it's security bug-free - it might just mean the opposite.

Where can you review or publish a project's security releases? Changelogs.

Developers, you should always include details about releases in the changelogs. Site owners, you can also cross reference a third party like a public vulnerability database to confirm if there are really no security bugs known in the product, or if they omit security details from changelogs.

Another counter-intuitive idea is to look for releases with multiple security patches. Those may be another good sign, it may mean they paid a third party to perform a security audit and then made the fixes in a single security release to improve their code base.

If you spotted no security release details in the changelog, but there are publicly reported security bugs in the Patchstack Database? In this case, you may have a developer who is not communicating security issues very well with their users. This leads me to my next recommendation:

Do they communicate security issues?

Developers write the patches but a site is not secure until that patch is applied. This is why it is important for a developer to inform their users when a security patch is made available.

This communication can take place in a few places. Most commonly, the project's changelog is the first place to look. This is how you can prioritize if that "update is available" needs to be performed next week (features) or immediately (security releases.)

In addition to changelogs, many open source projects have a dedicated "Security" section in their blog. If a project has a security feed I can subscribe to via RSS, then that's the best. I will pipe that feed right into the company slack (or email list) and we never miss an important release.

Now, onto the final recommendation:

Do they have a vulnerability disclosure policy?

Vulnerability disclosure policies are formal documents describing how to report security issues to a project. I talked about what makes a good vulnerability disclosure policy last year on the Patchstack weekly(Week 5 - Open Source & Vulnerability Disclosure Policies). This year, Patchstack makes setting up a vulnerability disclosure policy a lot easier with the managed Vulnerability Disclosure Policy program.

If you're a developer, I recommend you communicate how you would like security bugs reported to your project. If you lack this, you might get reports in unexpected places, like your public support forums.

Conclusions

These three points: A history of security releases, communication of security and a vulnerability disclosure policy are not just recommendations. They are how mature open-source projects approach security. You need not look far for an example, as WordPress itself has all three. WordPress security releases are clearly communicated with each release when security bugs are responsibly reported.

Vulnerability roundup

enable-media-replace - Author+ Arbitrary File Upload

The popular Enable Media Replace plugin, with over 600,000 installations addressed a security bug which could have allowed users with Author or higher roles the ability to upload arbitrary files. It is recommended to patch as soon as you can if you have many author accounts on your site.

mainwp-file-uploader-extension - Unauthenticated File Upload

The MainWP File Uploader extension released a patch which addresses an unauthenticated file upload security bug found by Patchstack's very own Dave Jong. Users of the MainWP File Uploader extension are strongly encouraged to update as soon as possible.

mainwp-links-manager-extension - Unauthenticated Object Injection

In light of this object injection security bug being reported in it, MainWP has retired the MainWP Links Manager Extension. It is recommended site owners remove this plugin immediately and find an alternative solution.

This week included multiple vulnerabilities affecting various MainWP plugins. If your websites use MainWP, then it is highly recommended you check for updates or if the components you are using have been retired.

Thanks and appreciation

This week's thanks goes out to the developers of Enable Media Replace, Short Pixel as well as the developers at MainWP for providing your security releases.

A special thank you goes out to all of the developers who don't just say they take security seriously, but actually do. With clear communication about security releases, regular security updates and a vulnerability disclosure policy. That is how you prove you walk the walk not just talk the talk.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #56: How Can Developers Prove Their Plugins Are Secure? appeared first on Patchstack.

When it comes to your WordPress site, security isn't merely an option – it's an absolute necessity. A secure web hosting environment forms the bedrock of your site's defense against an ever-evolving landscape of cyber threats. It's the digital moat that protects your valuable content, sensitive data, and online presence from malicious actors.

We understand that the vast array of hosting options can be overwhelming, which is why we've crafted this guide to demystify the process. 

At Patchstack, we don't just talk about security – we live and breathe it. Your website's security is our top priority, and we're dedicated to ensuring that you have the knowledge and resources to make the right choice.

We're proud to be partnered with some of the industry's most reputable hosting companies, all of whom share our unwavering commitment to WordPress security. These partnerships allow us to bring you the best recommendations and insights into hosting providers that prioritize your website's safety.

Keep reading to know more!

What Makes a Web Hosting Secure?

A hosting environment that is specifically designed and configured to safeguard WordPress websites from various online threats and vulnerabilities should protect your sites against unauthorized access, data breaches, malware infections, and other security risks that can compromise the integrity and functionality of a WordPress site.

Secure web hosting for WordPress typically comes with:

• Server Hardening: Implementing stringent security measures at the server level to prevent unauthorized access and mitigate potential risks.
• Regular Updates: Ensuring that server software, including the operating system and server applications, is kept up to date with security patches.
• Firewalls: Deploying firewalls to filter out malicious traffic and protect against common web application attacks.
• Malware Scanning and Removal: Conducting regular scans for malware and offering tools to remove any detected threats.
• Backup Solutions: Providing automated backup options to enable website owners to restore their sites in case of data loss or security incidents.
• SSL Certificates: Offering secure sockets layer (SSL) certificates to encrypt data transmission between the server and website visitors, enhancing data security.

Significance of Hosting Companies

The pivotal role played by hosting companies in ensuring the security of websites cannot be overstated. Hosting providers undertake a multifaceted approach to enhance website security:

• Infrastructure and Network Security: Hosting companies need to meticulously maintain secure server infrastructure and networks. This care greatly mitigates the risk of unauthorized access and data breaches.
• Security Patching: Hosting companies prioritize regular updates for server software and the application of security patches. This proactive measure is vital for addressing known vulnerabilities and strengthening defenses against emerging threats.
• Customer Support: Hosting companies extend responsive customer support to assist website owners in addressing security concerns and incidents. This support network is invaluable for promptly resolving issues and maintaining the integrity of websites.
• Server Maintenance: Hosting companies ensure that routine server maintenance tasks are performed without compromising security. This includes configuring server settings securely and isolating websites from one another, preventing cross-site vulnerabilities.

The significance of these security measures cannot be understated for website owners, with the hosting companies playing a pivotal role in maintaining the security of the hosting infrastructure, and assisting website owners in securing their WordPress sites.

Recent events have underscored the critical importance of robust security measures. For instance, consider the case of a recent ransomware attack on a prominent cloud provider, CloudNordic. This attack, which occurred on August 18, resulted in the complete encryption of CloudNordic's servers, effectively paralyzing their operations. The malefactors behind the attack also wiped out both the company's and customers' websites and email systems. Despite ongoing efforts by CloudNordic's IT team and third-party responders to restore data, even backup systems were compromised.

In response to the extortion demands of the attackers, CloudNordic chose to uphold its principles and refused to pay a ransom to retrieve the information and systems. This incident serves as a stark reminder of the need for robust security measures, and hosting companies' dedication to security is paramount in safeguarding against such threats.

What to Look for When Choosing Secure Web Hosting

To ensure your website's security, here's a checklist of key factors you should consider:

1. HTTPS Availability 

In today's digital landscape, HTTPS is no longer a luxury but a necessity. Most hosting providers offer free HTTPS, thanks to initiatives such as Let's Encrypt and ZeroSSL, which provide free TLS certificates.

To check if your website has HTTPS enabled, simply type "https://" followed by your domain name in your browser. If you see a lock icon (or a Tune icon in newer versions of Chrome), then you're good to go. If not, explore how to set up HTTPS with your hosting provider.

2. Backup and Restoration 

Backups are your safety net in case of emergencies. However, it's crucial to not only rely on them – but also test their functionality. Reach out to your hosting provider to understand their backup and restoration process.

If possible, perform a test run – but do avoid overwriting your live site! This proactive approach ensures your backups are reliable when you need them the most.

3. Keeping Software Updated

We all know the importance of regularly updating a WordPress website, as well as our laptop or PC’s operating system. But web servers have operating systems too – and they also need regular updating.

Luckily, WordPress allows you to confirm the versions of the software it relies on. Simply log in to your WordPress admin panel, open Tools, and Site Health. From the Site Health page you will get a list of details – including server versions, if you click on the “Info” tab, then expand the “Server” section.

The server section has information about software versions of PHP, Web Server, and more. Alternatively, you can expand the “Database” section to find out the server and software version for your database server as well.

You will need to do a little manual verification to find out if these components are still supported by their respective software vendors, but it is worth the time and effort.

If you find a software version is out of date or unsupported – don’t panic. Simply reach out to the hosting provider’s support team to ask them about it. You may be able to easily upgrade, or they may inform you the package is “backported” – which means someone did apply the security patches needed, but it still reports an old version number.

4. Brute Force Protection

An analysis by Google Cloud shows that Brute-force attacks are the most common threat for cloud service providers. This type of attack doesn’t require any skill and it can be automated easily; this is why almost half of all attacks on websites are brute force attacks. We have covered brute-force attacks on WordPress extensively in one of our previous posts.

Hosting providers often implement mechanisms to throttle or block repeated failed login attempts. To test your host's brute force protection, go to your site’s login page (usually wp-login.php), and then deliberately enter the wrong login details. If you're not blocked after ten or more incorrect attempts, it's a cause for concern.

Note: Don’t try this if you rely on the same IP address to access your site. We recommend you try it during off-hours or from a different location.

5. Proactive Insecure Component Identification

The world has moved on to proactive security instead of reactive security – you should check if your hosting provider identifies insecure components on your website. However, it is not advisable to install malware on your websites to see what your host does (because what they do won’t be good!)

Instead, you can consider installing a known insecure version of a component – you can find many in the Patchstack database. Be sure that the security bug in question requires a high-privilege logged-in user too. You do not want to install something that could result in your site being hacked.

Once an insecure version of a component is installed, and you have auto-updates turned off, all you need to do is wait. Count the days until you receive a notification from your hosting provider (if you receive a notification at all).

Proactive notification of insecure components is available from a few Patchstack hosting partners already. However, if you do not receive a notification then you can address this yourself by installing the Patchstack plugin.

6. Customer Support

Responsive customer support is an integral component of any web hosting environment, especially when it comes to addressing security issues. 

Security incidents can happen at any time. Having responsive customer support means that when you encounter a security issue, you can quickly reach out to experts who can guide you through the resolution process. This reduces downtime and minimizes the potential damage from security breaches.

Moreover, security can be complex, and not all website owners are security experts. Responsive support ensures that you have access to knowledgeable professionals who can help you understand and address security concerns effectively.

Conclusion

We've emphasized the paramount importance of selecting a secure web hosting provider for your WordPress site. Your hosting choice forms the foundation of your website's security.

Consider the security features and practices discussed in this guide, and ensure that your hosting provider aligns with these best practices. This includes aspects such as firewalls, regular backups, DDoS protection, and responsive customer support.

If you find that your hosting provider lacks certain security features, explore the option of using WordPress plugins to supplement your site's security.

Patchstack is here to help you enhance the security of your WordPress site. Think of us as your dedicated team of security specialists, vigilantly safeguarding your online presence.

Additional Resources

• Most Common WordPress Vulnerabilities & How to Fix Them
• How To Find Out If My WordPress Site Has Vulnerable Plugins?
• How To Limit Login Attempts on WordPress (Should You?)

Vulnerability roundup

wp-booklet - Remote Code Execution

The wp-booklet plugin was recently closed for unofficial reasons, but it is likely because of this remote code execution bug. Luckily, it appears a valid user account (subscriber or higher) is required to exploit this vulnerability. Which may buy you some time to find an alternative.

hide_my_wp - Unauthenticated SQL injection

The developers for hide_my_wp have released a patch to address an unauthenticated SQL injection security bug. Users should make sure they update their installed versions of hide_my_wp as soon as possible.

Please note this is the hide_my_wp premium plugin found in the Envato market.

Thanks and appreciation

This week's thanks go out to the developers of hide_my_wp, wpWave. Great job patching that SQL injection bug.

This week's special thanks go out to everyone taking responsibility for the website's security. Hopefully, that means you.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #55: How To Choose a Secure Web Hosting Provider? appeared first on Patchstack.

This week's knowledge share will continue the trend of new years resolutions. I am honored to share with you these simple tasks you can do, in hopes you will improve your website and business security maturity as we start this year off by taking responsibility. This week's new years security resolution is all about how to ensure your sites are not running insecure, abandoned, or unsupported components.

This week's vulnerability roundup will include one critical unauthenticated security bug that was patched. I will also share a list of plugins reportedly being targeted by a botnet that is attacking WordPress websites.

How to check if WordPress is running insecure, abandoned, or unsupported plugins/themes?

In the past week, there has been a lot of news about a botnet targeting WordPress websites. The botnet's behavior is simple, it has weaponized attacks against insecure WordPress plugins. Upon successful compromise of a website, it installs a backdoor or node which will listen for further commands from a central or "Command and Control" server the attacker's control. Which perpetuates further attacks against more websites.

The only surprise is the age of some of the weaponized vulnerabilities this botnet uses are. Full details on the vulnerabilities being targeted were not included in the reports, but some investigations show they are targeting vulnerabilities that were patched back in 2016.

This brings me to the point of this week's knowledge share. This a reminder to ensure your WordPress sites are running updated, secure, and supported components.

Checklist for ensuring your website's plugins are secure

Let's walk through how to check that your WordPress websites are running up-to-date software. Don't worry, it won't take long for each site.

Check for any updates

First, let's check if your plugins have any updates available. All you need to do is log in to your website's WordPress admin panel and check the plugins and themes tabs. It'll have a red number highlighting the tab to let you know if there are updates available.

These updates could be features or security updates, a default WordPress installation only tells you if an update is available.

Check for security updates

To go one step further, we can check if any installed components have known vulnerabilities. This is where a tool like the Patchstack plugin comes in handy. It will tell you if you are running known vulnerable components and allow you to easily update just the insecure components.

This is very handy for detecting insecure components that receive no updates from their developers. Or for any website that is sensitive to applying updates out of fear of breaking the website.

Now that we can confirm the site's components are up to date, or at least up to date on security patches what more is there?

Confirm the components are actively supported

We should confirm the components you chose are actively supported and not abandoned.

Active development is important, you can see this via the last code commit date or via the component's changelog (if one is provided.) If it has been years since the developer's last commit, you may want to reconsider using a project that receives such infrequent updates.

But, slow commits are not a sign of insecurity or abandonment, they are just a sign of slow commits. There is a chance the developer is still active. You can reach out to them via email, or the component's support forums. In fact, if you see the developer is active in the support forums that may be a great sign. Reach out! Ask them how things are going with the project and what the priorities are for the next release.

Engaging with the developers is a fine way to show support for their projects. I'm sure financial donations would also be appreciated too, but sending them a thank you and showing your appreciation and interest in where the project is going is infinitely better than being one more anonymous tick on their project's download counter.

Choose good replacements

During this process, you may come to a point where replacing a component seems keen. So I will leave you with one last recommendation. If you find yourself comparing two components, both appear regularly updated and well-supported. What could a tipping point be? Well, to me, I would check if they have a mature security posture. Specifically, do they have a vulnerability disclosure policy? Do they make it easy for security researchers to report issues to their team and is the project's changelog include at least a few clearly communicated security updates?

If they do this, then that is the sort of project you know you can trust is supported, will respond to security appropriately, and genuinely cares about their user's safety.

Vulnerability roundup

membership-for-woocommerce - Unauthenticated Arbitrary File Upload

The developers of Membership for Woocommerce released a patch to secure their code against an unauthenticated arbitrary file upload security bug. The plugin only has a few hundred installations, but site owners should apply the most recent update as soon as possible. The CNA that handled this bug report plans to release the proof of concept to the public] on January 25th, 2023. Site owners have only the next few weeks to update.

Doctor Web's Report

The security research firm Doctor Web recently released a report regarding backdoors infecting web servers through insecure WordPress websites. This report includes details on the backdoors the botnet was using as well as the insecure components the hackers were exploiting.

Their report lacks vulnerable version ranges for these components, but if you are running any of the following plugins it would be a good idea to make sure you have applied all available updates.

• WP Live Chat Support
• Yuzo Related Posts
• Yellow Pencil Visual Theme Customizer
• EasySMTP
• WP GDPR Compliance
• Newspaper Theme on WordPress Access Control
• Thim Core
• Google Code Inserter
• Total Donations
• Post Custom Templates Lite
• WP Quick Booking Manager
• Facebook Live Chat by Zotabox
• Blog Designer
• WordPress Ultimate FAQ
• WP-Matomo Integration (WP-Piwik)
• WordPress ND Shortcodes For Visual Composer
• WP Live Chat
• Coming Soon Page and Maintenance Mode
• Hybrid

Thanks and appreciation

This week's thanks go out to the developers of Membership for Woocommerce, thank you for that quick patch and for securing your user's websites.

A special thank you goes out to Doctor Web, thank you for your honest reporting of botnet activity. Your initial report was clear and even-handed that these were old and publicly known vulnerabilities in these components.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #54: How To Make Sure Your Sites Are Running Safe WordPress Plugins appeared first on Patchstack.

I will start by wishing you a Happy New Year - and thank you for listening/reading!

2023's first week's news will include an update related to the LastPass compromise from last summer. The cloud-based password vault vendor released an important announcement during the holidays, which you need to know about.

LastPass's announcement is an inconvenience, but also a reminder about a common security best practice: always rotate your passwords. I will kick off the new year by sharing some security best practices with you over the next few weeks.

In this week's vulnerability roundup I will discuss a handful of security bugs found in WordPress components that have gone unpatched. Unfortunately for these open-source projects, the new year is starting out rough, but it's important for users of these plugins to know about the risks so they can take action.

LastPass security breach update

I have shared updates in the past related to the LastPass security incident from August 2022. The updates I have shared with you are based on the official announcements made by LastPass.

Previously, I said that LastPass assured users that no customer password vaults were leaked during the breach. On December 22nd, 2022 LastPass released an update that now makes it clear - attackers did gain access to an encrypted copy of customer data, including the password vaults.

The data was encrypted, so the attackers do not have access to your passwords as plain text. However… all encrypted data can be de-encrypted eventually, given enough time. The fact the attackers have a copy of the LastPass source code also means they know what algorithms were used to encrypt the data, and they know how the salts were generated, which gives the attackers an advantage. It will still take a lot of computational time to crack every last pass user's encrypted vault, but it will happen if an attacker who has a copy of this stolen data puts the effort into it.

This means if you've used LastPass, you should be rotating your passwords before it is too late. The only good news is, you have some time to get this done - but the sooner, the better.

In fact, you should be rotating your passwords regularly. LastPass has this as a feature to make this automatic (for some websites.) For the rest of us non-LastPass users, it isn't hard to do manually.

Security best practice: rotating passwords

With the LastPass incident fresh on our minds we are reminded passwords should be temporary, not permanent. This is because breaches happen. Backups of account login credentials get leaked from major vendors all the time. LastPass is not alone in this, you can view details on many public breaches on haveibeenpwned.com.

If we accept that breaches happen, companies we trust with our data with get hacked, and we need to be responsible for our own account data. What can we do?

As far as passwords and credentials are concerned, here is what I recommend:

1. Rotate passwords regularly, maybe once a year but always rotate them after an incident occurs when the secret may have been leaked.
2. Never use a password twice, every login needs its own unique and strong, password.
3. Use 2FA, and rotate your 2FA secrets too. Different 2FA options have different risks, but if you can rotate the 2FA code you should.

Take some time this new year to rotate the important account passwords in your life. LastPass user or not this is a best practice for everyone.

Vulnerability roundup

The trend of abandoned open-source projects not receiving security patches continues as the new year starts. I spent some time writing some last patches for abandoned WordPress plugins in 2022, but there are so many each week that it's unsustainable to write a patch for everything.

I will continue to share a list of abandoned WordPress components with serious vulnerabilities that have gone unpatched each week.

wp-upg - Unauthenticated Remote Code Execution

This is a serious risk and it is strongly recommended sites using wp-upg aka "User Post Gallery" find another solution for their websites. This plugin has not been updated in over a year, and the developer appears focused on other projects at this time.

images-optimize-and-upload-cf7 - Unauthenticated Content Deletion

The developers for this projects have been active in the last few months. Answering support questions in the plugin's forums and pushing a release in November. So there is still hope they may be working on a patch.

fontsy -Unauthenticated SQL Injection

Users of this fontsy plugin should find an alternative ASAP. The plugin's developer activity has been silent for over 2 years, with no updates and no support activity on WP.org in that time. It appears the developer has moved on to focus on other projects.

cbxpetition - Unauthenticated SQL Injection

The cbxpetition plugin has not received an update in 3 years and was last tested against WordPress 5.2.17. This is a signal the project has been abandoned. It would be recommended users of cbxpetition find an alternative plugin for their needs.

Thanks and appreciation

This week's thanks goes out to the team at LastPass for being transparent about the customer password vault data being compromised during the breach. I suspect your security, incident response, and development teams have been working extra hard in response to this incident. Great job, keep it up.

Special thanks goes out to the Patchstack Alliance. We are still adding up the numbers, but 2022 was a big year for WordPress vulnerabilities being reported, patched, and managed through the Patchstack Alliance.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #53: Security Best Practice - Rotate Your Passwords appeared first on Patchstack.

This week's news is about some interactions I had with an AI chatbot called ChatGPT. I will share this chatbot's amazing ability to write code, correct itself, to learn - and I will share some shortcomings too.

In this week's vulnerability roundup I will share details about more unpatched security bugs, including one bug in WordPress core that is still unpatched to this day.

The AI WordPress code test

This week, I took some time toying around with ChatGPT an AI engine that generates text, including code. This astounding program is highly knowledgeable on a vast array of topics, including writing WordPress plugins … but it has a knack for being a little overconfident in its responses.

Today I will share with you some of the good, bad and ugly I saw when chatting with ChatGPT about WordPress development.

The good

ChatGPT puts the 'awe' in 'awesome'. I asked it to write a basic WordPress plugin, explaining details using basic English and it replied with functional code (most of the time).

There were limitations though. More often than not, I had to specifically ask for security functionality. But, ChatGPT handled it like a champion and knew exactly what to add when I asked for a nonce and authorization checks.

This experience was strangely natural. Natural in the sense that many WordPress plugins follow this path of functionality first, then security easily added in revisions.

The bad

Not all is perfect with ChatGPT though. As I mentioned before, the bot sometimes gives answers that sound confident, but are very confidently wrong.

When I asked ChatGPT to identify a common security vulnerability in some supplied code, it sometimes missed the mark by a long shot.

This was easily addressed by re-asking the question. Typically on the second attempt, ChatGPT got things right.

The catch here is that I knew the answer to the question I was asking. This should serve as a warning to users to not seek out new knowledge through AI, as the answers may be misleading. Instead use AI engines to enhance, augment or improve upon your existing knowledge and experience.

The ugly

As a bit of fun, I asked ChatGPT for some jokes about WordPress security.

While ChatGPT has some good advice, unfortunately, it falls flat as a comedian. Perhaps comedy is too complex of a task to ask from an AI chatbot.

So, if you find yourself worried your job might be replaced by an AI chatbot (hint: it won't), then maybe a career in stand-up may be a safe backup plan.

Vulnerability roundup

This week's vulnerability roundup will be about many more unpatched security bugs. The biggest of which is an unpatched security bug affecting WordPress core which was published by Sonarsource a few months ago.

WordPress's Unpatched SSRF Bug

Reviewing SonarSource's write-up, here are a few key details:

The bug cannot easily lead to an exploited WordPress website. Attackers need to control the DNS server the web server is configured to use in order to exploit this bug.

In scenarios where a site is vulnerable, the impact is limited. This is after all an SSRF bug, which I've written about before in Patchstack Weekly #33, What is SSRF?. You may recall in that episode, SSRF could lead to internal servers being targeted. With this in mind, we should consider that if the attacker already has control over DNS servers, then things are already much worse than SSRF for the organization.

I would not be terribly worried about this specific security bug, but I will still look forward to the WordPress core security team pushing a patch.

Unpatched plugin security bugs

WordPress core was not the only project affected by unpatched security bugs this week. In total 14 unpatched security bugs were published in 9 unique plugins.

• wp-autosearch - Unauthenticated SQLi
• cryptocurrency-widgets-pack - Unauthenticated SQLi
• letsrecover-woocommerce-abandoned-cart - Unauthenticated SQLi
• letsrecover-woocommerce-abandoned-cart - Authenticated SQLi 1
• letsrecover-woocommerce-abandoned-cart - Authenticated SQLi 2
• wp-rss-by-publishers - Authenticated SQLi 1
• wp-rss-by-publishers - Authenticated SQLi 2
• wp-rss-by-publishers - Authenticated SQLi 3
• web-invoice - Authenticated SQLi 1
• web-invoice - Authenticated SQLi 2
• launchpad-by-obox - CSRF
• gs-instagram-portfolio - CSRF
• sunshine-photo-cart - Unauthenticated XSS
• wp-table-reloaded - Authenticated XSS

Of the above list, the most serious unpatched security bugs are the unauthenticated ones affecting wp-autosearch, cryptocurrency-widgets-pack, letsrecover-woocommerce, and sunshine-photo-cart.

I hope the developers of these plugins find the time to write and push a patch soon.

Thanks and appreciation

This week's thanks goes out to the developers of ChatGPT, OpenAI and the whole team behind this project. It was amazing working with this tool.

A special thank you goes out to Sonarsource for finding and reporting the bug in WordPress core. Even though this went un-patched, I appreciate your efforts and understand why you published the details publicly after 5 years of it going unaddressed.

I will be back in 2023 with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #52: Will AI Change Web Security? appeared first on Patchstack.

This week's knowledge share is about a recent influx of patched security bugs affecting a single vendor. Don't panic though, the bugs are low risk. The noteworthy part is the number of products affected by the same bug. Stay tuned for this weekly knowledge share where I explain why one vendor has multiple products affected by the same bug, and what this has to do with the software supply chain.

In this vulnerability roundup, I will cover the plugins patched from the above single bug report. Remember, they've all been patched (which is not always the case).

I will also provide an update for this week's unpatched security bugs. The concerning trend continues, but the numbers are leveling out.

Securing the software supply chain

Securing the software supply chain has been in the news a lot this year. Ever since the log4j incident last year, it has been a hot subject. But, what does it really mean? What specific problem does this solve? Today I will answer those questions.

Users of software may think of it as an application they run, nothing more. We need to pull back and look at this from another perspective though - the developer's perspective. Developers write code, but they also integrate other people's code (via libraries, frameworks, or other means) into their projects.

The applications users use are conglomerations or collections of code. An easy way to understand this is with WordPress. A WordPress site is normally not WordPress alone, you add plugins and themes and customize it for your needs. You are, in effect, orchestrating a medley of software to build the application. Just as developers do.

Now that we know how single applications are built, and they are not stand-alone products.

This makes security, complicated

We all know it is our responsibility to update insecure software. But, what if there is a security bug in a library or component our applications use, who is responsible then? How would end users even know about the problem?

In an ideal world, the developers or architects who chose the components their projects were built on hold the responsibility to apply the updates. In turn, if needed, they also need to inform their end users about the update and it's importance.

Enter YITH

This ideal behavior is what we saw with the popular Woocommerce add-on vendor YITH. The YITH developers built in-house libraries for all of their products. Unfortunately, one of those libraries had a lower-risk security bug in them. After a little discussion with the Patchstack Alliance, the YITH developers updated their in-house library to address the bug in multiple of their projects.

This is why the Patchstack Database recently added a large number of YITH plugins. One bug in a library was patched and now all of the downstream projects that used the library are more secure and safe to use.

This was ideal. But, we all know things don't always work out that way.

Enter SBOM

This is why there is a push from many in the security field for SBOM - or software build of materials. It is proposed that every project should include a SBOM to allow users to cross reference the project's libraries and dependencies for security concerns.

The Patchstack App is a SBOM + alerting system already. Site owners who set up the Patchstack App on their site(s) will receive a list of installed components, plus receive automated alerts if or when any of those components have known security bugs in them.

Developers have options too, like GitHub's dependabot which will alert developers if their repository uses an insecure dependency.

Future

In the upcoming months and years, we will likely see an increase in proactive security measures like SBOMs and alerting systems like Patchstack or dependabot. Preemptive security alerts are the future, anyone relying on security vendors who provide post-compromise detection, like an anti-virus, will be seen as two steps behind the attackers and part of the past.

Vulnerability roundup

YITH addresses 20+ security bugs

If your sites use YITH plugins, you may want to check for a security update on your sites. The Patchstack Alliance recently received reports of CSRF security bugs which affected multiple YITH plugins.

CSRF is a low risk security bug, requiring an attacker to target logged in users and get them to visit links or web pages. But, it is still worthwhile to apply these updates.

The YITH developers did a great job addressing this bug that was found in multiple projects of theirs. As I mentioned in this week's knowledge share, the bug was in their in-house library. You could say this was one small bug patched resulting in many plugins and many websites being secured.

Unpatched security bugs.

This week's unpatched security bug numbers are still steady. With 7 plugins in the last 7 days being closed on the WordPress repository due to lack of security bug patches. I see evidence that some of these plugin's developers are actively working on a patch, so I wish them good luck and godspeed in their efforts to secure their customer's websites.

Thanks and appreciation

This week's thanks goes out to the developers at YITHemes. It was great discussing security bugs with your team, even if we had to iron out some wrinkles in the process. In the end, the YITHemes developers came through with a patch and addressed the issue acrossed all of your projects. Great job.

Every project that patches security bugs and communicates security effectively deserves recognition. There are simply too many to name, developers are patching security bugs every day.

So, further thanks is extended to the developers who are actively working on patching security bugs. Your efforts are not ignored, and I acknowledge your commitment to security and safety for your users.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #51: How One Vulnerability Affects Many appeared first on Patchstack.

This week's knowledge share is about the lingering problems that can happen after a compromise. This is related to the recent news of LastPass reporting a secondary incident months after an initial break-in.

I will discuss this negative experience that LastPass is handling like a professional and use it as a reminder of what to do if you ever experience a compromise.

In this week's Vulnerability Roundup, I will talk about more unpatched security bugs, and share information about a contest the Patchstack Alliance is running each week of December. Stay tuned to hear about the bonus bounty opportunities we are opening up for the holidays.

When hacks come back

Like many people this week, I received a notification from LastPass regarding a recent security incident connected to a prior security breach from a month ago.

I applaud the LastPass team for their honesty and transparency in the matter. The notification this week informed users they recently identified unusual activity in a third-party storage service.

Their investigation concluded this recent unexpected access was likely made by someone with information leaked from an incident that happened months ago in August.

Before I continue, I should also share that LastPass reiterated that customer passwords were still encrypted and were not accessed in this recent incident. However, other elements of customer data may have been accessed.

We should applaud LastPass for detecting the unusual activity in the third-party storage service and for making this information public. They are not trying to hide from their responsibilities, instead, they're being open and showing trustworthiness.

What can we learn?

Incidents are not always one-time events. Attackers who gain access can ex-filtrate sensitive data, then later use that data to target other services at a later time.

This is just my personal speculation, exfiltrated secrets may have been what lead to the lingering hack LastPass experienced.

The attackers gained access to a developer's environment back in August, they could have pilfered secrets like passwords or API tokens at that time. Months later they are using these secrets to access third-party systems even after the initial compromise was cleaned up.

What could have prevented this?

Always change your secrets after a breach

If your website or business experienced a compromise, then you will want to change or rotate all of your secrets to prevent experiencing a recurring hack.

What sort of secrets should you change? Here are three.

Passwords obviously. If attackers had access to read your website's database, then they have a copy of your password hash. With a little effort, password hashes can be cracked, exposing the secret value.

WordPress secrets. The secret keys stored in your site's wp-config.php file are sensitive data, and for the most part, easily rotated to new values.

Just visit the WordPress secret key generator and get new randomly selected values. Attackers could use these secret key values to brute force authentication tokens. In prior work as a Security Researcher, I wrote the how-to jam WordPress sessions knowing only a username and secret token value. Another Researcher Gennady Kovshenin also wrote about the importance of unique keys and salts in WordPress a year prior to my write-up.

Third-Party API keys. Finally, if you have integrations with third parties like Twitter, Apple, Google, Recurly, Stripe, Paypal, or any other service. Your site likely uses an API key to authenticate itself with that service. If this API key gets exposed during a compromise, then attackers can use it to abuse this access and interact with these third-party services as if they were your website.

This is what happened with the FastCompany breach and led to expedient damage control taken by the FastCompany security team.

There may be more examples of secrets that need to be rotated in the event of a compromise. I would recommend performing a simulated compromise.

Simply scan your site's files and database for any secrets as if you were a malicious party and make a note of all of the secrets found and their location. Bonus points for also writing down how to rotate the value. This way, if you ever do experience a compromise you already know what sort of secrets need to be revoked and rotated to new values.

Vulnerability roundup

This week's vulnerability roundup will highlight 8 plugins with unpatched security bugs reported in them in the last week.

• iws-geo-form-fields - Unauthenticated SQLi
• menu-items-visibility-control Authenticated Remote Code Execution
• export-users-data-csv CSV Injection
• aio-time-clock-lite Authenticated XSS
• apptivo-business-site Authenticated XSS
• 1app-business-forms Authenticated XSS
• content-repeater Authenticated XSS
• clictracker Authenticated XSS

The biggest concern would be that iws-geo-form-fields unauthenticated SQL injection vulnerability. WPScan has announced they will be sharing the proof of concept on December 14th, less than 10 days away. Site owners running this plugin need to disable it or find an alternative as soon as possible.

Patchstack Alliance holiday bounties

In other vulnerability news, the Patchstack Alliance is announcing this week a special contest for bug bounty reports in December.

Each week in December, starting this week, there are additional bounties paid for the alliance members who report specific categories of bugs in WordPress components.

If you are a specialist bug bounty hunter who can track down bugs like CSRF, XSS, SQLi, or RCE then you may want to put some time aside to target these bugs and submit them to the Patchstack Alliance during December. More details about the holiday bounties can be found on the Patchstack blog.

Thanks and appreciation

This week's thanks go out to the team at LastPass for the honest, transparent, and full disclosure to customers about experiencing a breach. The LastPass team is dealing with a serious and ongoing compromise, which is a bad thing, but they are communicating to their users what they need to know about the incident as the information becomes available. Which is a good thing. Great job showing us how to show responsibility and owning the problem.

I would also like to send out some encouragement to the Patchstack Alliance team members. Good luck and go for broke with this December's bonus bug bounty hunting! If you are interested in joining in on some bug bounty-hunting fun, you can join the Patchstack Alliance by reporting a new security bug in a WordPress component. It's that easy.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #50: When Hacks Come Back appeared first on Patchstack.

This week's knowledge share will be all about how to find bugs in code - security bugs that is. I will share techniques I use for basic static code analysis and provide examples of what to look out for.

This week's vulnerability roundup will once again highlight only WordPress components with unpatched security bugs.

Hunting security bugs with static code analysis

Knowing where to look is the key to finding what you're looking for. When it comes to finding security bugs in code though, knowing where to look is essential.

In this week's knowledge share, I will share with you a basic process for finding security bugs using static code analysis also known as SAST (static application security testing.)

All you need to bring with you is knowledge of what to look for, so I will share a few things to look for today.

Unauthenticated API actions

Let's start with not a vulnerability, but something that would make a security bug much higher risk. We can all agree if we can find a security bug without the need for an authorized user account, then that bug is more severe.

So, how can we find a list of unauthorized actions in the WordPress API? We just need to search for API endpoints (AJAX actions) being created that require no authorization.

WordPress uses add_action() to create new endpoints, and if the "hook" for the endpoint starts with "wp_ajax_nopriv" then no authentication is required.

Searching for add_action("wp_ajax_nopriv will give you a list of no authentication required endpoints, but you will still need to review every function that is being called by each endpoint. So, there is still a lot of manual work to do, but you have a starting point.

Object injection

PHP object injection or insecure deserialization bugs are easy to spot, you will want to look for any time user-controlled variables (like $_POST, $_GET, $_COOKIE, $_REQUEST etc..) are passed directly to unserialize().

It may look like this:

$lorem = unserialize($_COOKIE['ipsum']);

Insecure instantiation

Finding insecure instantiation bugs is easy as well. To unearth this risk, look for code that passes user-controlled variables to the "new" constructor.

It may look like this:

$dolor = new $_GET['sit'];

Insecure option update

This WordPress specific security bug happens whenever code allows user-controlled variables to choose both the key and value pair values sent to the update_option() function.

It may look like this:

update_option($_POST['amet', $_POST['consectetur']);

Commonly misused functions

Sometimes what you want to look for is a common mistake, such as a function commonly misused for the wrong purpose.

Here are two examples I have seen in the wild:

is_admin() tells you if the request is from /wp-admin/, but I have seen many WordPress developers use this for Authorization checks. What they meant to use was current_user_can()

maybe_unserialize() will re-instantiate any string as long as it is a valid serialized string. Attackers will use valid serialized string to create valid objects found in the code base, so this function contains no protection against object injection.

Searching en masse

Now you know what to look for, but is there a way to look for bugs at scale? Of course there is - in fact, you have two options.

You can download the entire repository's code base yourself and use a tool to search the source code directly. I personally use grep (because I am old school). You can scan any plugin's source code that you have a local copy of.

If you want to get started ASAP, you can use a site like WPDirectory.net. Which is significantly faster than grep (I have first-hand experience with) at scanning the entire WordPress.org plugin repository.

Congratulations, now you're doing SAST. This is a fundamental process for bug bounty hunting or for any project just get started with having a mature security model.

Vulnerability roundup

This week's vulnerability roundup is once again a list of plugins without security patches added to the Patchstack database in the last 7 days. You may be surprised how many there are …

• ifeature-slider - Stored Cross Site Scripting
• wooswipe - Broken Access Controls
• ultimate-tables - Reflected Cross Site Scripting
• profilegrid-user-profiles-groups-and-communities - CSV Injection
• user-export-with-their-meta-data - CSV Injection
• wpb-show-core - Reflected Cross Site Scripting
• dpt-oauth-client - CSRF
• transposh-translation-filter-for-wordpress - Authorization Bypass
• add-multiple-marker - Missing Access Controls
• activity-reactions-for-buddypress - Broken Access Controls
• activity-reactions-for-buddypress - CSRF
• postmagthemes-demo-import - Authenticated File Upload

That is 12 unpatched security bugs in the last 7 days. Better than last week's 20 unpatched bugs, but again I hope some of these developers were just delayed in providing a patch, and for their users' sake, a patch can be released soon. But time will tell.

Thanks and appreciation

This week's thanks go out to the members of the Patchstack Alliance who continue to identify and respectfully report security bugs in open-source components to our team so we can triage, verify and inform the developers of those projects.

If this week's knowledge share sounded interesting to you, perhaps you too could join the Patchstack Alliance. If you join you will learn new skills or improve existing skills in security bug hunting and make the open-source world a better place.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #49: Hunting Open-Source Security Bugs with SAST. appeared first on Patchstack.

This week's knowledge share is about the security concern caused when software has been abandoned or has reached its end of life (EOL). I will discuss what the risks of running unsupported software, and what you can do to confirm your WordPress website's full tech stack is up to date.

On the topic of unsupported software, this week's vulnerability roundup will focus on abandoned plugins in the WordPress.org repository. I will share details on a surprising number of WordPress components recently removed from the .org repository due to abandonment after security flaws went unaddressed.

Abandoned and EOL projects

This week's knowledge share comes with a warning. I will be talking about an existential truth that we all must face in our lives, many people find it unsettling so I don't blame you for turning this episode off now.

The existential fact I will be talking about, is that …

Everything has an end

Including the software you may rely on. One example is PHP announcing the end of support (EoS) and end of life (EoL) for the 7.4 branch in just a few weeks from now. This is done to inform users and developers about the need to upgrade, which must be done because it is extremely burdensome to maintain support for old software releases. While this end is more of an evolution, evolution is full of dead ends.

Luckily for PHP users, the solution is easy - update to a supported version, in this case: 8.0 or 8.1.

You may think I am going a little overboard with that warning I gave. But, I have observed behavior in the WordPress community that makes me believe some people do not face the fact that old software needs to be replaced or updated. They seem to want to hold onto the idea of "if it isn't broken, then don't update it."

From website owners running abandoned plugins to web servers still configured to run on old unsupported versions of PHP, Apache, or Linux. Ignoring or making excuses for running out of date software ultimately just leaves your websites and servers unsupported against unprotected risks.

We need to face the facts. If your site or web server is running the same code as it was several years ago, maybe it's time to rebuild some things. Even if it is running smoothly now, that's the best time to look for a replacement. The alternative is waiting until something breaks and you will be left scrambling to fix a website that is offline or compromised.

So we can acknowledge that everything has an end. What can we do about it? How can we make this an easy process?

Have a plan

Planning is the key to making any process easy. Put together a checklist of what to do. In this case, a list of software your site is running, and how to check if it is running a currently supported version.

WordPress site owners already have a very handy Site Health check screen in the wp-admin dashboard. This screen does not provide you warnings about insecure versions of software (you will need a service like the Patchstack app for that.) It does provide you with a list of your server's underlying software and the versions of each. Using a little manual work you can check your PHP version, Linux kernel, MySQL versions, and much more.

Once you know what version of software you are running, you just need to look up if it is still supported or needs any security patches.

Here are some handy links:

• PHP supported versions
• MySQL supported versions
• Linux kernel support versions
• Endoflife.date (for anything else)

The site health screen also includes a list of plugins, themes and their versions. Now, all you need to find out is if the component is abandoned or if that version has any known security issues. The Patchstack plugin will make identifying insecure WordPress plugins and themes automatic. You will also want to identify abandoned WordPress plugins too.

However you go about checking the software versions of your website and its technology stack is up to you. The important part is you write down how it is done so you have a plan on how to update or replace the software before it gets abandoned and becomes a problem.

Now that you have the process down, you just need to schedule periodic times to do the work. I would recommend this to be done as frequently as possible, which is why automation or using a third party like Patchstack will help you save a lot of time. But, if you must do this manually maybe set aside some time every month or at least once a quarter.

You do not want to find out you missed an update, too late.

Vulnerability roundup

This week's vulnerability roundup is a list of plugins without security patches added to the Patchstack database in the last 7 days. You may be surprised how many there are …

• add-multiple-marker - Missing Access Control
• add-multiple-marker - CSRF
• activity-reactions-for-buddypress - Broken Access Control
• activity-reactions-for-buddypress - CSRF
• adrotate - CSRF
• postmagthemes-demo-import - Authenticated File Upload
• uji-countdown - Authenticated XSS
• add-comments - Authenticated XSS
• advanced-wp-columns - Authenticated XSS
• clerkio - Authentication Bypass and API key disclosure
• wp-pagebuilder - Authenticated XSS
• wpupper-share-buttons - Authenticated XSS
• quick-restaurant-reservations - CSRF
• sitepress-multilingual-cms - CSRF 1
• sitepress-multilingual-cms- CSRF 2
• asgaros-forum - CSRF
• car-rental - Authenticated XSS
• simple-video-embedder - Authenticated XSS
• cyklodev-wp-notify - Authenticated XSS
• testimonial-slider - CSRF

That is 20 unpatched security bugs in the last 7 days. 17 unique plugins with no security patches, and potentially no support. I do hope some of these developers were just delayed in providing a patch, and for their users' sake, a patch can be released soon. But time will tell.

Thanks and appreciation

This week's thanks goes out to the developers of every open-source project that clearly documents and shares the timeline of support for each release. Remember, everything has an end, including support for a project. Mature open-source projects understand this, and clearly communicate with their users how long they can continue to expect support. Thank you for doing that.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #48: Dealing with End of Life and Unsupported Open Source Projects. appeared first on Patchstack.