2 New Wordpress Plugin SQL Injection Vulnerabilities

That’s right Wordpresss kiddies, two new vulnerabilities, and they’re pretty nasty. Author Houssamix From H-T Team has released two remote SQL injection proof of concepts for WP-Cal and fGallery 2.4.1.

The vulnerability for WP-Cal exists in:

/wp-content/plugins/wp-cal/functions/editevent.php

and here’s what’s vulnerable:

$id = $_GET['id'];
$event = $wpdb->get_row("SELECT * FROM $table WHERE id = $id");

Why? No sanitization of $id. Since id in the DB is a numerical value, only numbers should get passed in $id. I’m no PHP expert, but I’m sure this is an easy fix. If you’re not a PHP expert, either, I highly recommend you disable and remove this plugin immediately.

Next up, fGallery 2.4.1. The hole exists in:

/wp-content/plugins/fgallery/fim_rss.php

and here’s what’s vulnerable:

$cat = $wpdb->get_row("SELECT * FROM $cats WHERE id = $_GET[album]");
$images = $wpdb->get_results("SELECT * FROM $imgs
WHERE cat = $_GET[album] AND status = 'include'");

Again, there’s a lack of proper sanitization. Can you spot the hole?

I’d love to provide a fix, but since neither of these plugins are used on Nullamatix, I’ll leave the patching up to those bold enough to use this stuff. If you’re feeling generous and come across a fix, feel free to share in the comments. In the mean time, deactivate and remove these plugins until a patch or fix is released. Yet another potential for your non-vulnerable site hosted on a shared provider to get r00ted. Happy blogging!

Additional Posts Worth Reading

 

3 Comments »

collapse Comment by Lee
2008-01-30 09:17:34

This is why you have to use as few plugins and check them all the time. I always find putting a blank index.html file in plugins can help too… Or closing it in cpanel or Apache (If you use it).

collapse Comment by Guy Patterson
2008-01-30 12:48:48

yea, good call. That reminded me, I hadn’t put a blank index.htm in my /plugins/ directory since the updrade. Thanks!

 
 
collapse Comment by Will Brown Subscribed to comments via email
2008-02-13 16:41:01

Well, I can tell you that the first one can be fixed by changing

$id = $_GET[’id’];

to

$id = (is_numeric($_GET[’id’])) ? intval($_GET[’id’]) : ”;

that checks to make sure that $_GET[’id’] is a number, and if it is it assigns the numerical value of it to $id.

Dunno about the second. Figured that one would help, at least!

Thanks for the heads up about the holes.

 
Name (required)


E-mail (required - never shown publicly)


URI - Web Site Address






Subscribe

Site of The Day

Sponsors

Categories

Recent Comments

  • Arthur: I can’t even be an Ebay affiliate. Tried various ways but still declined. Any help or suggestions?
  • chicago web design: I can’t imagine that these will last very long before Google banishes them all. But for now...
  • D.Ksyte: Anyone involved with cron job scheduling might find this resource useful. Cron Sandbox at HxPI is an...
  • FoNiX: “…decode md5″ is not possible, only bruteforce: generate hash and compare with original.
  • Z@$#: plz plz decript this hash for me any one….its really important…. 2CAD28C7C619F27DDE7B83C4999795BA
  • Joe: Thanks for writing this up. I tried the second method…however after the debian install the screen looks...
  • Scott: Was this issue ever resolved? I just started having a problem a couple weeks ago. I don’t do any kind of...
  • Prashant Patel: I had integrated Sp3 in Xp But finding one problem. In the Task Manager Process windows many services...
  • Ed: This looks like a real ‘leet’ linux command but it misses the point. Why would a hacker keep the name of...
  • Sudesh: My account was disabled but I followed their guideline and in one sec it was back on :) Here is the...

Top Commentators

Miscellaneous

  • Add to Technorati Favorites