Title: SQL Injection Vulnerability
Last modified: August 30, 2016

---

# SQL Injection Vulnerability

 *  Resolved [Scott Arciszewski](https://wordpress.org/support/users/sarciszewski/)
 * (@sarciszewski)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/)
 * So, you have this query here:
 *     ```
       $tablerows = $wpdb->get_results( "SELECT <code>login_id</code>, <code>login_ip</code>,<code>login_attempts</code>,<code>attempt_time</code>,<code>locked_time</code> FROM  <code>$tablename</code>   WHERE <code>login_ip</code> =  '$ip'  ORDER BY <code>login_id</code> DESC LIMIT 1 " );
       ```
   
 * The variable $ip is populated by this function
 *     ```
       function getip(){
                          if (!empty($_SERVER['HTTP_CLIENT_IP'])) {
                           $ip = $_SERVER['HTTP_CLIENT_IP'];
                       } elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
                           $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
                       } else {
                           $ip = $_SERVER['REMOTE_ADDR'];
                            if($ip=='::1'){
                                $ip = '127.0.0.1';
                            }
                       }
                       return $ip;
                   }
       ```
   
 * So if someone sends an X-Forwarded-For HTTP header with a malicious SQL injection
   payload, they could overwrite your query and hack your database.
 * [https://wordpress.org/plugins/wp-limit-login-attempts/](https://wordpress.org/plugins/wp-limit-login-attempts/)

Viewing 8 replies - 1 through 8 (of 8 total)

 *  Plugin Author [Arshid](https://wordpress.org/support/users/arshidkv12/)
 * (@arshidkv12)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513650)
 * Added more security in new version .
    Thank you 🙂
 *  Moderator [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * (@ipstenu)
 * 🏳️‍🌈 Advisor and Activist
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513711)
 * While we appreciate you informing plugin developers of this, we ask you not publicly
   disclose security issues like this in the public venue of the forums for a couple
   reasons.
 * 1) We can’t actually promise that anyone will notice it in a reasonable time.
 * 2) Not all developers are responsible and monitor the forums regularly.
 * 3) Public disclosure runs a higher risk of the hack being let loose in the wild
   before the developer has a reasonable chance to validate and patch the issue.
 * Because of that, we ask you contact the plugin review team at [plugins@wordpress.org](https://wordpress.org/support/topic/sql-injection-vulnerability-9/plugins@wordpress.org?output_format=md)–
   If you chose to publicly release on your own site, we’re not about to try and
   stop you. At the same time, we have the ability to email developers directly 
   and, if needed, patch their plugin for them. So you will actually get a faster
   result than you would posting here and hoping someone notices promptly.
 * From [https://wordpress.org/about/security/](https://wordpress.org/about/security/)
 * > When a plugin vulnerability is discovered by the WordPress Security Team, they
   > contact the plugin author and work together to fix and release a secure version
   > of the plugin. If there is a lack of response from the plugin author or if 
   > the vulnerability is severe, the plugin/theme is pulled from the public directory,
   > and in some cases, fixed and updated directly by the Security Team.
 * We understand the concept of ‘my bug, I decide how to report it’ but in this 
   case, it’s not going to get things patched faster.
 * Please review our documentation on how to report security issues with WP (and
   plugins): [https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#where-do-i-report-security-issues](https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#where-do-i-report-security-issues)
 * We prioritize ALL security reports above everything else in plugin land, and 
   we directly contact developers pretty much daily. Furthermore, we take the extra
   step of giving the plugin a full re-review for any thing else we might have missed,
   just in case. Obviously it’s not perfect, but we try.
 * Please. Email us. We will make SURE the developer gets the memo and it gets addressed.
   We have the power. Let us wield it for you.
 *  Thread Starter [Scott Arciszewski](https://wordpress.org/support/users/sarciszewski/)
 * (@sarciszewski)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513713)
 * Okay. I’ll email you 24 hours before public disclosure. My previous coordinated
   disclosure time table of 30 days was counter-productive, but maybe immediate 
   full disclosure isn’t the right answer.
 *  Moderator [James Huff](https://wordpress.org/support/users/macmanx/)
 * (@macmanx)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513716)
 * Or, maybe give them the time they need to fix the issue before you become the
   one who releases it to the wild, thus creating the danger you hoped to avoid 
   by identifying the vulnerability in the first place?
 * Publicly disclosing a security vulnerability doesn’t make code spontaneously 
   happen, all it does is immediately endanger everyone using it.
 * When you publicly disclose a security vulnerability, you aren’t the hero saving
   the day, you’re the villain who has just put everyone’s site (and sometimes their
   livelihoods) in the line of fire.
 * Please don’t be the villain, be the hero. Disclose responsibly by disclosing 
   privately. 🙂
 *  Thread Starter [Scott Arciszewski](https://wordpress.org/support/users/sarciszewski/)
 * (@sarciszewski)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513717)
 * > When you publicly disclose a security vulnerability, you aren’t the hero saving
   > the day, you’re the villain who has just put everyone’s site (and sometimes
   > their livelihoods) in the line of fire.
 * Every security expert disagrees.
 * [https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html](https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html)
 *  Moderator [Jan Dembowski](https://wordpress.org/support/users/jdembowski/)
 * (@jdembowski)
 * Forum Moderator and Brute Squad
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513718)
 * I’m afraid that’s not the case, almost all reputable security experts want and
   advocate responsible disclosure.
 * Yes, Bruce Schneier is one of the top experts and among the most knowledgable
   and experienced. But cherry picking your favorite doesn’t change a simple fact:
   just finding and spilling the beans without taking into account the result doesn’t
   help anyone.
 * I’m glad that’s something that you do seem to get.
 * > Okay. I’ll email you 24 hours before public disclosure. _My previous coordinated
   > disclosure time table of 30 days was counter-productive, but maybe immediate
   > full disclosure isn’t the right answer._
 * Emphasis is mine. 😉 Thank you for trying to disclose responsibly.
 *  Thread Starter [Scott Arciszewski](https://wordpress.org/support/users/sarciszewski/)
 * (@sarciszewski)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513719)
 * Emphasis: Immediate. I’m still going to disclose publicly.
 * Also, can we please 86 the meme that coordinated disclosure is responsible? Full
   disclosure can be responsible too, as can non-disclosure. Context matters a lot
   here.
 *  Moderator [Jan Dembowski](https://wordpress.org/support/users/jdembowski/)
 * (@jdembowski)
 * Forum Moderator and Brute Squad
 * [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513720)
 * Right. We get that and all you’re being asked to do is be responsible.
 * This was disclosed and I’m 86’ing this topic by closing it.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘SQL Injection Vulnerability’ is closed to new replies.

 * ![](https://ps.w.org/wp-limit-login-attempts/assets/icon-256x256.png?rev=1225433)
 * [WP Limit Login Attempts](https://wordpress.org/plugins/wp-limit-login-attempts/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-limit-login-attempts/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-limit-login-attempts/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-limit-login-attempts/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-limit-login-attempts/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-limit-login-attempts/reviews/)

## Tags

 * [sql](https://wordpress.org/support/topic-tag/sql/)
 * [sql injection](https://wordpress.org/support/topic-tag/sql-injection/)
 * [sqli](https://wordpress.org/support/topic-tag/sqli/)

 * 8 replies
 * 5 participants
 * Last reply from: [Jan Dembowski](https://wordpress.org/support/users/jdembowski/)
 * Last activity: [10 years, 8 months ago](https://wordpress.org/support/topic/sql-injection-vulnerability-9/#post-6513720)
 * Status: resolved