COMODO WAF: CSRF vulnerability in the MailPoet CVE-2014-3907

We got an issue with cwaf today. The audit log mentions

Message: Access denied with code 403 (phase 2). Match of “eq 1” against “&SESSION:wysija” required. [file “/usr/local/cwaf/rules/28_Apps_WPPlugin.conf”] [line “1249”] [id “226472”] [rev “3”] [msg “COMODO WAF: CSRF vulnerability in the MailPoet Newsletters WordPress plugin before 2.6.11 (CVE-2014-3907)”]

But the version of the plugin is 2.6.19 but the rule is still triggered.

The full message:

–69bf6554-H–
Message: Access denied with code 403 (phase 2). Match of “eq 1” against “&SESSION:wysija” required. [file “/usr/local/cwaf/rules/28_Apps_WPPlugin.conf”] [line “1249”] [id “226472”] [rev “3”] [msg “COMODO WAF: CSRF vulnerability in the MailPoet Newsletters WordPress plugin before 2.6.11 (CVE-2014-3907)”]
Action: Intercepted (phase 2)
Apache-Handler: proxy-server
Stopwatch: 1451337317782492 120291 (- - -)
Stopwatch2: 1451337317782492 120291; combined=3092, p1=606, p2=2473, p3=0, p4=0, p5=11, sr=95, sw=2, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache/2.4.16 (FreeBSD) PHP/5.6.14 OpenSSL/1.0.1p-freebsd
Engine-Mode: “ENABLED”

–69bf6554-Z–

Hello,

If you suppose that it’s false-positive, just exclude the rule 226470 in Comodo WAF - Catalog - Search By Rule Id - Status Off - Implement.

It certainly is a false positive because the mailpoet version is higher than the one mentioned in the rule’s description, so perhaps the rule could be mended instead of excluded?

ModSecurity can’t identify version of MailPoet Newsletters WordPress plugin so the rules was written for a worst scenario, for a case when you have most vulnerable application. If you are sure that your server isn’t vulnerable to certain vulnerability then you may exclude this rule. COMODO WAF provides flexible mechanism for this purposes. But remember, weakening of security is a customer’s deal.