Anton Vlasenko 4:18 pm on September 9, 2022
Tags: best practices, security

Top reasons not to use setlocale() for character encoding conversion

Many WordPress plugins use the setlocale() function.

While it’s generally safe to use setlocale() to get various information about a specific locale, it’s essential to understand that using setlocale() to perform string manipulations has significant disadvantages.

The goal of this article is to raise awareness about those disadvantages.

Disadvantages

So, what are they?

Firstly, setlocale() is not thread-safe. If you run WordPress on shared hosting, you may experience sudden changes in locale settings, as though your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party never called setlocale().
String functions that rely on setlocale() to detect the current locale don’t process some characters correctly, even if the correct locale is set with setlocale().

Take a look at this 3vl4.org example.

The expected output of the script is Ž, but the actual output is Ů.

Recommendations

These are some recommendations on using setlocale() that could make using it safer:

Don’t use setlocale() to process strings in different encodings unless absolutely unavoidable.
Don’t use setlocale() with LC_ALL. Instead, specify the exact categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of functions you need (e.g., LC_MONETARY, LC_NUMERIC).
If you need to change the current locale, you must change it back to the previous value in order to preserve thread-sanity. At this time, C should be used as the default locale setting.

#best-practices, #security

Ipstenu (Mika Epstein) 6:45 pm on May 25, 2022
Tags: core ( 2 ), security

Rejoice to sanitize_url()

At least once a day, someone has to explain that the only esc_ function you can use to sanitize is esc_url_raw(). This stems from what was (at the time) a logical change. The function sanitize_url() was an alias for esc_url_raw() and it’s redundant to have both.

Except …

Over the years, WordPress has evolved and improved function names to the point that we can nearly say “Use sanitize_ functions to sanitize and esc_ functions to escape” which makes life a lot easier for new users. They don’t have to remember any odd-functions-out except the wp_kses* ones.

For WordPress 5.9, I made a ticket to restore sanitize_url() and I’m delighted to be able to say that it’s back! It’s un-deprecated!

What’s the difference?

Nothing, except the name.

Can I keep using esc_url_raw()?

Yes, for now. Eventually we’d like to wean people off it, but it’s a process. No worries. If you’re using it, we won’t ding you.

Why does this matter?

Because now you (and anyone else) can look at $variable = sanitize_url( $_POST['variable_url'] ); and know “Ah, yes, this is sanitized.”

Are you only posting this because you made the change?

No. I’m posting this because I promised some of the people I made that ticket for that I would 🙂 It’s delayed because I’ve been swamped.

It’s something that changes very little for most people, but will greatly help newer developers and minimize their confusion. And that? That is a fantastic thing!

My code sniffer tells me it’s wrong, what do I do?

Tell the people who run the sniffer, but keep in mind they’re probably adding in a bunch of changes, so it may take a while 🙂 Be cognizant of the work they do and respectful of the time they give you. Helps everyone.

#core, #security

Ipstenu (Mika Epstein) 3:29 pm on April 15, 2022
Tags: features ( 5 ), security

Featured/Beta Plugins Now Limit Changes

If your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is a FEATURED or BETABeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. plugin, which means officially recognized as such by the WordPress project, you will no longer be able to add or remove committers, nor will you be able to change ownership.

This change was made due to the high profile nature of those plugins, and the potential for abuse if a plugin is given to someone who turns out to be malicious. We hope that it will prevent issues like a featured plugin being turned into a premium-upsell plugin.

This does not relate to the size of a plugin. If a 2-user plugin is made a Featured Plugin, then it will be have this limitation. That said, it also will not cause any change to proposed feature plugins or self-declared beta.

If you are an owner/committer to one of those plugins, you can add support reps as needed, but you will need to email the plugins team (`plugins@wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/`) to have new committers added/removed, and to change ownership if needed.

#features #security

Ipstenu (Mika Epstein) 5:10 pm on November 29, 2021
Tags: reminder ( 30 ), security, trademarks ( 5 )

Please don’t ‘test’ submitting other people’s plugins.

tl;dr: Never test vulnerabilities on someone else’s live site without their permission.

By now, a lot of you have read the post about the so-called “WordPress Plugin Confusion” whereby a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ can ‘override’ a plugin not hosted here, by using the same name/permalink. Someone even made a CVE for it.

Please stop ‘testing’ this vulnerability with us.

This is not a new issue by any means. Heck, this has been something people report on now and then for years. In the past, the plugin team coordinated a release of a plugin to intentionally do that and protect users from a significantly dangerous plugin. We’ve locked out permalinks to prevent abuse and so on.

Sadly, the post conflated a couple of issues, which have to do with social engineering and a misunderstanding of why we have those permalink-checks for trademarks. Also it’s entirely incorrect with this one claim:

and the whole approval process is automated

This could not be further from the truth. All new plugins submitted go through human review. When you submit a plugin, somebody reads your plugin code, your submitted slug and name, checks on the history of the plugin, checks that the developer isn’t a returned banned user, etc. The process is by no means “automated” and while it has some automated pre-flight checks, they’re really there to weed out things that would end with a pended review, to make the process faster for everyone. While we have some tools we run, they don’t actually approve or reject anything, they’re just fancy code-sniffers, customized to look for specific patterns or known bad behavior, outside of the overall quality like PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. (you are using that, right?). Submitting things to test out what you think is an “automated” system is wasting the time of our volunteers and reviewers.

See, that trademark ‘blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.’ isn’t actually there to protect trademarks for the owners. We have them to make our life easier and to protect you, the developers, from making some pretty common mistakes. Just for an example, we block ‘akismet’ not because we were asked to by Automattic, but because over 50 people a year tried to submit a copy of Akismet instead of uploading it to their own site.

As the post (properly) notes, you can’t submit a plugin with a permalink that’s already in use, be it on WordPress.org or if it has a notable user-base outside of WordPress.org. Even if a name gets by those checks, the review team can see if the permalink is being used and by (roughly) how many people. That’s a large part of why we have humans checking these things. A human can look at an email and a plugin and check for proper ownership.

By the way, as a number of people have complained about, this is why we require official plugins to be owned by demonstrably official accounts (like with an email address that uses the right domain, and so on). It’s not just to prevent trademark abuse, it’s to ensure that kind of thing is less likely to happen.

Now. Do you need to test this? No. All you’re doing is making things more stressful and more likely to be missed, which doesn’t solve a problem. Do you need to add your trademark to the blocked list? Again, no. Unless it’s being actively abused, or there’s a high-risk situation that it might be, it’s just adding more work for a low (to negligible) risk in the first place.

How DO you protect your own, non-org hosted plugins, from this?

Use the UPDATE URI flag.

We check for it on .org, and won’t allow you in with it (since… why?) but for plugins we don’t host, well that’s literally why it exists 🙂 Use it. Love it. But please, remember the first step in ethical hacking is never trying out a vulnerability on someone else’s site without their permission.

#reminder, #security, #trademarks

Ipstenu (Mika Epstein) 10:37 pm on October 26, 2016
Tags: reminder ( 30 ), security

The Perils of Partnership

If you’ve ever received an email offering to partner with you or to join an affiliate network or to help you earn money for your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, it’s probably a scam.

In the last three months, we’ve seen a serious uptick in emails like “please join our affiliate network” or “I can help you earn money” or “increase your plugin’s SEO” sent to plugin developers. On review, every last one that looked iffy has turned out to be by a nefarious or malicious group of people, who want to either install backdoors into plugins or black hat SEO links.

These deals should sound too good to be true, and they are. They can irreparably harm you, your reputation, and your standing on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Our reaction, when we see it, is to remove the plugin and revoke all SVNSVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. access from the developers involved. We don’t always restore access, especially if we feel you may fall for such a scam again or your online behavior is inherently insecure.

I know some of you are reading this thinking “Who falls for stupid stuff like that!” and the reality is anyone. All it takes is one mistake, one moment where you’re not thinking all the way through, and you’ve shot yourself in the foot.

There are some simple tips you can take to protect yourself.

Never let anyone else use your SVN account. If you work with a team, everyone should use their own account. This will help you track changes too.
Look up the people. Check that they seem legit. Are they using wordpress in their domain name (which you know is not permitted)? Do they already have any plugins? Are they active in the community?
What other kinds of plugins do they own? If the plugins are all over the place, ask yourself: Why would they want MY plugin? Companies that make a grab for a lot of different plugins are often trying to find ones with a high user count in order to spam.
Preview the code. Never add anything you’re not 100% sure is safe. If the code that gets added has links that look like http://api.wp' . '-example.com/api/upd' . 'ate or 'ht'.'tp://wpcdn.example.com/api/update/ then it’s not trustworthy (those aren’t the real URLs).
Does the email look like a form letter? WordPress is such a small community that people generally reach out like human beings. If someone’s spam-blasting a form, it’s sketchy.
Check spelling and grammar. If it’s `Wordpress` with a lower case P, or `JetPack` with an uppercase one, it might just be an innocent mistake, but it might not. Businesses should care about these things. After all, you do.

Above all, if you see something, say something. If you get an email like that, forward it on to plugins@wordpress.org with as much information as possible. We would love to see some code samples, for example, as we can add it to our scan routines.

#reminder, #security

Ipstenu (Mika Epstein) 11:12 pm on July 20, 2016
Tags: security

Security Alert: Httpoxy

You may have heard about this already. Even so, please read this post. Normally we email all possibly impacted developers directly. In this case, trying to generate a list gave me over 6 gigs of results. I trimmed it down, but given the volume of people using Guzzle and possibly using suspect code, it was more straightforward to post an alert.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict:

RFC 3875 (CGI) puts the HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Proxy headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. from a request into the environment variables as HTTP_PROXY
HTTP_PROXY is a popular environment variable used to configure an outgoing proxy

This leads to a remotely exploitable vulnerability.

You can read about the entire situation on httpoxy.org. While the fix is, as most are, a server one, all developers should be aware of this.

Don’t bother doing the following:

Using unset($_SERVER['HTTP_PROXY']) – it does not affect the value returned from getenv(), so is not an effective mitigation
Using putenv('HTTP_PROXY=') – it does not work either (to be precise: it only works if that value is coming from an actual environment variable rather than a header – so, it cannot be used for mitigation)

You can prevent and mitigate some of this in your code. Read up on httpoxy Prevention.

#security

Ipstenu (Mika Epstein) 12:35 pm on January 4, 2016
Tags: email ( 7 ), reminder ( 30 ), repository ( 18 ), security

Reminder: Your Email Account Must Be Valid

Since the only way we have to get in touch with pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors is their emails, we’re going to be enforcing that you have a valid email that goes to a human being for you plugins.

This simple statement covers a multitude of situations but to clarify, we’re talking about the email associated with the user accounts that have commit access to your plugins.

Go to https://wordpress.org/plugins/YOUR-PLUGIN/admin/ and look at the people listed under Committers. Those accounts are who we email when there’s an issue with a plugin, or when we’re alerting you to new WordPress updates. Those emails must go to real human beings. It can be a shared email box (goodness knows plugins is a shared email box) but real people have to read those emails because without that, we cannot communicate with you.

We strongly suggest you whitelist plugins@wordpress.org

The following email situations may result in your plugin being closed if we can’t find a way to communicate with you:

Invalid Emails

If your email bounces, your plugin gets closed. We can only assume that a dead email means you’re done with things, and since we have no way to contact you, your plugin can only be considered unsupportable. If you notice your plugin is closed and you didn’t get an email from us, check your account’s email. If that’s not right, that’s probably why.

Auto-Replies

If your email has an auto-reply, such as the sort that goes to a support ticket generator, stop it. This makes it nigh impossible for us to communicate with you, we can never tell if a human has read the email, and we get a mail box filled with auto-replies which means you’re the reason plugin reviews are backlogged. We will normally email you one sternly worded warning about this. If it keeps up, your plugin may be closed.

2-Step Verification

If your email auto-replies and asks people to click or reply in a special way to ensure our email gets to you, guess what? Half the time that doesn’t work. We often get expired tokens because it takes us more than 24 hours to get through all the emails in our queue, and once that happens we have no way to get our email to you.

Deceased Authors

This is a touchy subject so I apologize in advance. If a plugin author has died and we can verify this, we remove their account’s access to their plugins (and usually reset their passwords to something random). This is in the interest of security, as doing so will prevent any possible issues if their account is hacked. We do not close the plugins. If there are co-committers, they will be notified. Otherwise the plugin will simply remain in place. Taking over those plugins is a similarly touchy subject, and priority will be given to their coworkers or close friends/family who are also WordPress developers.

#email, #reminder, #repository, #security

Ipstenu (Mika Epstein) 8:20 am on November 23, 2015
Tags: reminder ( 30 ), security

Your Plugin Committers Should be Your Developers

After we started pushing back on the auto-reply stuff, a couple pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party devs said that they used their support accounts (like support@example.com) as their committer so that they could get email updates from the forums.

This is a terrible idea. It’s insecure and rather dangerous.

That means the support account is the one with write access to your plugin. And that means anyone with access to your group email (or your support tool) can click on reset password, get the password, change it, and blow up your plugin. Obviously that’s a major security issue. The only people who should have write access to your plugin should be people who know how to code and are responsible and reliable and trustworthy. And remember, people can go nutters in a company of any size and seek out revenge in weird ways. Limiting the damage they can do is your responsibility.

This also means that when we send you an email about your plugin, you may be accidentally sharing privileged information with people who have no business knowing these things. With a support account for a company of four people, it may be okay for everyone to know your plugin was pulled from the repository for a security hole. When you have a company of 300 and you use a system like ZenDesk (not to pick on them, but they are popular), now everyone knows. This may not seem like a big deal, but if one person tweets “OMG! Plugin FOO has a security hole!” then there’s a major risk that you’ve opened up the floodgates of potential hacks. Limiting the risks you put on your users is important.

Only allow your developer account(s) to have commit access to your plugin.

If you want one joint email-alias (wp-plugin-dev@example.com) that forwards to everyone, that’s okay, but not great. Remember, if everyone has their OWN user account, then you can easily track who pushed what change to a system. If you’re only using SVNSVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. as your version control, it’s a good idea to make sure you know who did what. If you’re using GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. or Mercurial or your own SVN to track the changes, then make sure that only responsible, reliable, people have access to that dev account. Again, remember that we’re talking about access to push code to (say) a million users.

Remember: Anyone listed as a developer has the ability to remove anyone else as a committer. So you really want to limit those users.

Make a separate account to handle support

Make a separate account (wp-plugin-support@example.com) that does whatever it needs to do. Then you can sign up for email alerts. Go to https://wordpress.org/support/plugin/YOUR-PLUGIN and scroll to the bottom where it says “Subscribe to Emails for this Plugin”:

Click “Subscribe to Emails for this Plugin” when logged in.

Click the link and baboom, that account gets email alerts. You can do the same for reviews at https://wordpress.org/support/view/plugin-reviews/YOUR-PLUGIN if you want to catch the inevitable ‘this review should have been a support post’ threads.

Remember: If you sign a support account up for getting those emails, you should still disable auto-replies. Otherwise you’ll be generating a lot of unnecessary email every time someone replies to your threads and you may get caught as a spammer.

Add your support accounts as Contributors

Contributors are the people you list under the ‘Authors’ field on your readme. They do not have any commit access to a plugin. They can’t edit the code.

Example: “Automattic” has an account for Jetpack. That account can be a placeholder account. It can be a support account if you want to use it in the forums. It can be marked as a Contributor in the plugin’s readme.txt in order to get special markings in the forums for replies from that account for that plugin.

The other accounts should be individual accounts, belonging to the devs, and preferably using their company email addresses. This way, if the organization changes, an individual leaves, etc, the email address still goes to the company and the plugin can be recovered, if necessary.

Back on Jetpack, there are over 70 people listed as ‘authors.’ They all get that happy plugin author green lozenge in their forum replies and they can officially help people without you worrying they’ll miss a semi-colon and take down 20 thousand users with a bad push of code.

Remember: Anyone listed as an author is going to get that green lozenge. If you don’t want people representing you, credit them in the readme but remove them as an author.

#reminder, #security

Ipstenu (Mika Epstein) 6:00 am on May 4, 2015
Tags: repository ( 18 ), security

Reporting Plugin Issues

Note: I’ll be using Hello Dolly as my example ‘bad’ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for this post. It’s fine and not (to my knowledge) vulnerable.

There are a few reasons people report plugins but the main two are as follows:

Guideline violations
Security vulnerabilities

If you report a plugin, you can make everyone’s life easier if you do the following:

Verify that it’s still applicable

Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.

Use a good subject line

“Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.

Send it in plain text

SupportPressSupportPress The ticket management interface for the plugin emails. It has been replaced with Help Scout. is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.

Link to the plugin

https://wordpress.org/plugins/hello-dolly/

Yes, it’s that easy. Put the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.

If the plugin is not hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, I’m sorry, but there’s nothing we can do, so please don’t bother reporting it to us. We have no power there.

Explain the problem succinctly

Keep it simple.

“Hello Dolly has an XSS vulnerability” or “The Author of Hello Dolly is calling people names in the forums” or “Hello Dolly puts a link back to casino sites in your footer.”

Think of your intro like a tweet. Boil it down to the absolutely basic ‘this is what’s wrong.’

Keep the details clear

If someone’s acting up in the forums, link to the forum threads.

If you know that on line 53, the plugin has a vulnerability (or a link back to that casino site), then you can actually link right to that line: https://plugins.trac.wordpress.org/browser/hello-dolly/tags/1.6/hello.php#L53

We love that. If you don’t have that line, it’s okay. Tell us exactly what you see. “When I activate the plugin using theme X, I see a link to a casino site by my ‘powered by WordPress’ link.” Perfect. Now we know where to look when we test.

Show us how to exploit it

Don’t ask us ‘Can I send you an exploit?’ Just send us all the information. If the exploit’s already up online, like on Secunia, link us to it.

If you know exactly how to exploit it, tell us with a walk through. If the walkthrough involves a lot of weird code, you may want to consider using a PDF.

We’re going to take that information and, often, pass it on directly to the developers.

Tell us if you want them to have your contact info

We default to not passing it on, out of privacy, so “If the developer needs more help, I can be reached at…” is nice. Even “You can give the developer my information so they can credit me…”

We’re probably not going to follow up with you

We love the report, we review them, but we’re not going to loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. you back in and tell you everything that’s going on for one very simple reason. We don’t have the time. If you told us to give the dev your contact info, then we did, but we don’t have any way to promise they will, and we don’t have the time to play middle management.

Emailing us over and over asking for status gets your emails deleted. It’s not personal, it’s seriously a time issue. We’re nothing more than gatekeepers, we are not a security company and we’re not equipped for keeping everyone up to date. We don’t have an administrative assistant to handle that. We work with the developer to fix the issue and we work with the .org team to see if we need to force update the plugin, and that takes a lot of time.

We don’t do bounties

This is a little interesting but basically we’re not going to pay you. A lot of people ask for ‘credit’ so they can ‘earn’ a bounty, and that’s cool, but we’re not going to report that for you. Generally if you say you want a bounty, we give your info to the plugin dev, though, so they do know you’re interested.

How do you report?

You can report plugins by emailing plugins@wordpress.org

That’s it 🙂 Thanks!

#repository, #security

Gary Pendergast 5:00 pm on April 20, 2015
Tags: security

Fixing add_query_arg() and remove_query_arg() usage

Background: Due to a now-fixed ambiguity in the documentation for the add_query_arg() and remove_query_arg() functions, many plugins were using them incorrectly, allowing for potential XSS attack vectors in their code.

Both add_query_arg() and remove_query_arg() have an optional argument to define the base query string to use. If this argument is undefined, it will use $_SERVER['REQUEST_URI'], which is unescaped. When printed out to a page, this could be used as an XSS attack vector.

The easiest way to fix this in your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is to escape the output of add_query_arg() and remove_query_arg(). When it’s being printed to a page (for example as a link), you should use esc_url(). When it’s being used in HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. headers or as part of a HTTP request (for example, as part of a location redirect headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. or in a wp_remote_get() call), you should use esc_url_raw().

Edit by Ipstenu: Also read Sucuri’s reasonable disclosure on the matter. Many plugins have been patched and auto-updated in a massive coordinated effort to stem this one before it gets nasty.