Edededededededed

Not sure which is worse, the exploitable XSS in the current version of plugin, or the non factual opinion assertion that a fixed was released.

I have seen no fix, I have seen it exploitable in the current version.
I have no idea why someone would say a vendor said its fixed.

shrug, you can’t patch stupid.

@justin FYI,
The vendor does not state, I had not stated, NO ONE BUT YOU have said some one stated. But no one has stated 1.8.2 is not vulnerable.

So were left with your factually incorrect post.

So if you might be so kind as to please restate it or remove it. As your your post (a few days ago) has real potential to confuse or even hurt peoples ability to know they are vulnerable with ALL versions of the plugin from rev 1.4 to the current rev. 1.8.2

Your doing no one a valuable service by inadvertently stating wrong information when people have worked their buts off to provide real value.

No, its common for security researchers to indicate what version # of vendor code the exposure was applicable to at the time the research was published.

The issue is not fixed with the most recent version of the plugin.

The obligation is on the vendor to patch and release new of the fix and until they do, you can assume its exploitable or retest it yourself by following the instructions in the article.

Regards
Edededededededed

WordPress core security should be considered as distinct and separate from plugin security. Assuming your wanting plugin best practice, I would take a look at https://owasp.org.

Below is the “best of” hit list you need to follow:

Start here https://www.owasp.org/index.php/PHP_Top_5 skip the system level stuff like safe mode and focus on the many web app vulnerabilities you can avoid including, XSS, parameter tampering, SQL injection, insecure data transmission, authentication and TCP hijack.

Follow with a visit to https://www.owasp.org/index.php/Category:OWASP_PHP_Project

and the security API
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=PHP

https://code.google.com/p/owasp-esapi-php

https://owasp-esapi-php.googlecode.com/files/esapi4php-contributing.pdf

If you are realizing you can’t leave it up to any other plugin or WordPress base code upgrade to fix your security messes you are farther along than 95% of the WordPress plugin writers.

This will likely be the only valid security coding advice you get. run with it, don’t get discouraged.

Don’t depend on your fellow plugin code writers for secure coding advice. One last piece of advice, If they say use plugin x y or Z to address web app XSS or SQL injection, they are ignorant or intentionally blowing smoke to encourage downloads of a particular (faulty) plugin they vainly pin their personal (ignorance is bliss) hopes on.