CVE-2013-10023: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89)
value: A vulnerability was found in Editorial Calendar Plugin up to 2.6 on WordPress. It has been declared as critical. Affected by this vulnerability is the function edcal_filter_where of the file edcal.php. The manipulation of the argument edcal_startDate/edcal_endDate leads to sql injection. The attack can be launched remotely. Upgrading to version 2.7 is able to address this issue. The patch is named a9277f13781187daee760b4dfd052b1b68e101cc. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-225151.
CWE description: The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
CVSS v3 base score: 9.8
Published: 2023-04-08T09:15Z
Repository: https://github.com/wp-plugins/editorial-calendar
Language: Other
Files changed: edcal.php, readme.txt
Commit date: 2013-02-13 13:58:35 +0000
Commit message: We are now validating the start and end dates before adding them to the post filter so we can make sure there's no possible SQL injection attack.

git-svn-id: https://plugins.svn.wordpress.org/editorial-calendar/trunk@667412 b8457f37-d9ea-0310-8a92-e5e31aec5664

Diff: diff --git a/edcal.php b/edcal.php
index 3a45961..6a9ab44 100644
--- a/edcal.php
+++ b/edcal.php
@@ -493,10 +493,22 @@ class EdCal {
     function edcal_filter_where($where = '') {
         global $edcal_startDate, $edcal_endDate;
         if ($edcal_startDate == '00000000') {
             $where .= " AND post_date_gmt LIKE '0000%'";
         } else {
+            /*
+             * The start date and end date come from the client and we want to make
+             * sure there's no SQL injection attack here.  We know these values must
+             * be dates in a format like 2013-02-03.  Date parsing is complex and PHP
+             * dates allow a lot of different formats.  The simplest way to make sure
+             * this isn't a SQL injection attack is to remove the dashes and check if
+             * the result is numeric.  If it is then this can't be a SQL injection attack.
+             */
+             if (!is_numeric(str_replace("-", "", $edcal_startDate)) || !is_numeric(str_replace("-", "", $edcal_endDate))) {
+                die("The specified start date and end date for the posts query must be numeric.");
+             }
+             
             $where .= " AND post_date >= '" . $edcal_startDate . "' AND post_date < '" . $edcal_endDate . "' AND post_date_gmt NOT LIKE '0000%'";
         }
         return $where;
     }
     
diff --git a/readme.txt b/readme.txt
index 728786b..f11f74a 100644
--- a/readme.txt
+++ b/readme.txt
@@ -179,10 +179,14 @@ The calendar is now available in Italian thanks to Lorenzo Boldorini who blogs a
 
 Changed all calls of the jQuery live method to use the new on method so the calendar will keep working when WordPress upgrades to jQuery 1.9.
 
 The Editorial Calendar is now stripping all tags out of post titles created from the calendar.  This fixes a potential security issue found by the Mozilla security testing team.  https://bugzilla.mozilla.org/show_bug.cgi?id=738112
 
+We are now preventing a potential SQL injection attack with the start date and end date filter when querying posts.  This fixes a potential security issue found by the Mozilla security testing team.  https://bugzilla.mozilla.org/show_bug.cgi?id=738112
+
+
+
 = 2.6 = 
 
 Fixed some layout issues with the previous and next calendar buttons in WordPress 3.5.
 
 We are now properly saving new posts in the drafts drawer in WordPress 3.5.

Fixed code:             /*
             * The start date and end date come from the client and we want to make
             * sure there's no SQL injection attack here.  We know these values must
             * be dates in a format like 2013-02-03.  Date parsing is complex and PHP
             * dates allow a lot of different formats.  The simplest way to make sure
             * this isn't a SQL injection attack is to remove the dashes and check if
             * the result is numeric.  If it is then this can't be a SQL injection attack.
             */
             if (!is_numeric(str_replace("-", "", $edcal_startDate)) || !is_numeric(str_replace("-", "", $edcal_endDate))) {
                die("The specified start date and end date for the posts query must be numeric.");
             }
             
We are now preventing a potential SQL injection attack with the start date and end date filter when querying posts.  This fixes a potential security issue found by the Mozilla security testing team.  https://bugzilla.mozilla.org/show_bug.cgi?id=738112