How to find cause of Boolean Based SQL Injection Vulnerability for PCI scan

Hi Shawn,

It’s great that you are proactively addressing these concerns, and I understand that identifying the source can feel a bit overwhelming, especially if you’re new to this.

Out of curiousity, could you share a screenshot of flag? Have you already tried reproducing the issue manually? For example, by appending the scanner’s payloads to the product URL and observing whether the page output changes. Is your WooCommerce store using any custom product‑page plugins or custom code? Some plugins modify how attributes or quantities are validated, which can influence scanner behavior.

To help pinpoint the cause, you’ll want to focus on any plugins or custom code that interacts with product attributes like quantity or selectable options on your product pages. Here are a few steps and tips to guide your investigation:

• Review any plugins or themes that have recently been added or updated before you noticed the vulnerability. Sometimes new or updated code can introduce unexpected issues.
• Focus on plugins that manage product variations, quantity selectors, or custom fields on product pages. Many extensions that add complex product options or filters might be involved.
• If possible, temporarily disable plugins related to product options one by one and rerun the scan (in a staging environment) to see if the vulnerability persists. This can help isolate the problematic plugin.
• If your site uses any custom PHP code or code snippets related to quantity or product attributes, check for proper sanitization and validation of input before database queries. Unsanitized input is a common cause of SQL injection.
• Ensure that WooCommerce, your theme, and all plugins are updated to their latest versions, as updates often patch vulnerabilities.

I hope that helps. Let us know if you need anything else.

• This reply was modified 1 month, 2 weeks ago by Frank Remmy (woo-hc).

Hi @shawnz28,

Thank you for sharing the scan output, I completely understand wanting to be cautious while also getting to the bottom of this. You are doing the right thing by digging into the details.

Looking at the report you shared , the scanner is posting a manipulated value to the quantity field on a product page and detecting a different response between a true and false SQL condition. Specifically, it is sending payloads like: 1' or '4202'='4202 to the quantity field via POST, and interpreting the different responses as a Boolean based SQL injection vulnerability.

A few important clarifications here:
WooCommerce does not use the raw quantity POST value directly in SQL queries. Quantities are sanitized, cast to integers, and validated before being processed. In many cases, PCI scanners flag dynamic response differences as SQL injection even when the application is safely handling the input. A 200 OK response alone does not confirm a real exploitable SQL injection.

Here is how I recommend proceeding:
First, confirm whether this is a false positive. On a staging site, try manually submitting a clearly invalid quantity like: 1' OR 1=1

If the product page simply reloads, resets the quantity, or ignores the input without exposing database errors or unexpected data, that is a strong indication that this is not a real SQL injection, but scanner behavior detection.

Second, temporarily switch your theme from Woodmart to a default theme like Storefront or Twenty Twenty Four and retest. Since Woodmart modifies quantity UI and product templates, this helps rule out theme level customization.

Third, perform a full plugin conflict test. Deactivate all plugins except WooCommerce, then retest. If the issue disappears, reactivate plugins one by one to isolate the cause. You mentioned outdated shipping plugins, those would definitely be worth including in this process even if their changelogs do not mention security fixes.

If after isolating everything, the behavior still occurs with only WooCommerce active and a default theme, please share your full System Status Report via https://pastebin.com or https://gist.github.com so we can review your environment configuration more closely.

Regarding the cookie flags and path disclosure items, adding headers in .htaccess does not always override how WordPress or PHP sets cookies. WooCommerce already sets Secure and HttpOnly on its cookies when the site is fully HTTPS, which your report shows in the response headers. For PHP session settings, those typically need to be enforced at the server or php.ini level rather than .htaccess, depending on hosting configuration. If you are on managed hosting, it may require their assistance.

At this stage, the most likely scenarios are either a false positive from the scanner or a third party plugin or theme customization interacting with quantity handling. Let us narrow it down systematically and we will get clarity.

Once you have tested with a default theme and minimal plugins, let me know the outcome and we can take the next step together.

Hi there!

Thanks for the detailed follow-up I appreciate you taking the time to walk through this.

To clarify point 1: you don’t need to force invalid characters directly into the quantity input field via the browser UI. The scanner is submitting those payloads programmatically via a POST request, which is why it’s able to bypass normal front-end restrictions. The goal of that step is simply to confirm whether WooCommerce safely handles unexpected input (which it generally does) and whether any actual SQL errors or data exposure occur not necessarily to replicate the exact scanner behavior manually.

You’re right that point 2 is the easiest initial test. Temporarily switching to a default theme (such as Twenty Twenty-Four or Storefront) is a reasonable overnight check and helps rule out theme-level customizations affecting request handling.

Regarding staging: for PCI scanning, a staging site is strongly recommended. Password protection is fine during normal use, but you would indeed need to temporarily remove it while running the scan. To avoid indexing and customer access, you can:

• Add a noindex directive,
• Block crawlers via robots.txt,
• Or restrict access by IP rather than basic auth, if your host allows it.

That keeps the environment safe while still allowing the scanner to function.

On the cookie and path disclosure notes thanks for clarifying. Since some settings are being enforced at the PHP-FPM/server level, that aligns with what we typically see. From a WooCommerce perspective, when the site is fully HTTPS, WooCommerce core already sets Secure and HttpOnly flags on its cookies, and anything beyond that is usually host- or server-specific.

At this stage, from a WooCommerce core support standpoint, the most important next step is still isolating whether this behavior occurs:

• With a default theme, and
• With only WooCommerce active.

If the scanner results persist under those conditions, please share a fresh System Status Report so we can review the environment configuration further. Otherwise, it would indicate the issue is coming from a third-party theme, plugin, or server-level configuration, which would be outside WooCommerce core.

Take your time working through the checks, and feel free to update us as you go we’ll take it step by step.

Hi @shawnz28,

Please feel free to take the time you need to test on staging, switch themes, or run through the plugin checks we discussed. There is no rush from our side. When you are ready and have new findings, just drop an update here and we will gladly continue working through it with you. Looking forward to hearing back from you when you are ready.

Hi there,

Thank you for running that test with the default theme that was exactly the right troubleshooting step.

Since the SQL Injection warnings and cookie attribute issues disappear when switching from Woodmart to Twenty Twenty-Four, that strongly indicates the issue is theme-related. In this case, contacting the theme author is the correct next step, as theme-level vulnerabilities fall outside WooCommerce core support.

Regarding the “Misconfigured HTTP Caching” Warning

You’re correct — this is generally not WooCommerce-specific.

This type of warning is usually related to:

• Server configuration
• Caching plugins (e.g. W3 Total Cache)
• CDN settings
• Cache headers

It’s rarely caused by WooCommerce core itself. You may want to temporarily disable your caching plugin and re-run the scan to confirm whether that changes the result.

Regarding the remaining warnings, many automated PCI/security scans flag items that are informational, hosting-level, or related to server configuration rather than WooCommerce itself.

Since these items involve HTTP caching, cookie attributes, or potential path disclosure, I recommend contacting your hosting provider. They can review:

• Server header configuration
• PHP error display settings
• Cache rules
• Security modules (e.g., ModSecurity)
• SSL/TLS configuration

These settings are controlled at the server level and are outside WooCommerce core functionality.

Before you go, If you found WooCommerce helpful in setting up your store, we would really appreciate it if you could leave a five-star review:https://ww.wp.xz.cn/support/plugin/woocommerce-paypal-payments/#new-topic-0. Your feedback helps us improve and lets other users know how WooCommerce can support their business.

Hi @shawnz28,

Thank you for sharing the update and for continuing to dig into this with both the theme developers and the tests you ran. It is great to see the methodical troubleshooting you have already done.

Since the scan warnings disappeared when switching from Woodmart to a default theme, that test result is still an important indicator. It tells us that the behavior detected by the scanner is influenced by how the theme renders the product page output.

What the theme developers mentioned about related products generating different HTML is technically possible. Related products in WooCommerce can be randomized, which means the HTML output can vary between requests. Some security scanners interpret any difference in response content as evidence of a Boolean based SQL injection, even when the difference is unrelated to database queries.

Because of that, temporarily disabling related products is a reasonable test to run. Either approach mentioned in the guide works, but the safest and most reliable method is using the code snippet that removes the related products output, since it completely prevents that section from rendering during the scan.

You can follow the guide here: https://woocommerce.com/document/remove-related-posts-output/

After disabling related products, I recommend running the PCI scan again and comparing the results. If the warnings disappear, that would strongly suggest the scanner was reacting to dynamic page output rather than a real SQL injection vulnerability.

Regarding the other warning you mentioned, Misconfigured HTTP Caching, that is typically controlled by server headers, caching plugins, or CDN configuration rather than WooCommerce itself. Your hosting provider or caching plugin documentation will usually be the best place to review those settings.

Please let us know what the results look like after testing with related products disabled and we will gladly continue working through it with you.