High-severity findings.

Audited release

1.1.2

Findings

2

Worst severity

high

Content hash

0d34000f490923b5fb9e8c75… Copy

Findings

• high Checkout tracking writes full $_COOKIE and order data to a web-accessible debug.log

  information_disclosure

  Custom_Google_Analytics_Public::track_purchase (woocommerce_checkout_order_processed and woocommerce_order_status_processing) appends a print_r payload to CUSTOM_GOOGLE_ANALYTICS_PATH . 'debug.log' via error_log(..., 3, $destination). The payload always includes order_id, the Google Analytics collect RequestUrl (revenue, SKUs, product names), and the entire $_COOKIE superglobal. reverse_transaction and refund_transaction write the same file. The path is the plugin directory, which WordPress serves as static files; there is no .htaccess deny, no randomization, and no WP_DEBUG gate. Guest checkout is enough to append a dump. Cookies logged on a default WooCommerce install include wp_woocommerce_session_* (cart/session hijack), any wordpress_logged_in_* present on the request (account takeover of a logged-in customer or of an administrator who placed a test order), marketing emails, and Mailchimp landing-site URLs that embed wc_order_* keys (unauthenticated view of that order-received page). The v1.1.3 zip already ships a populated debug.log containing a live-looking WooCommerce session cookie, emails, and https://artpix-prod/checkout/order-received/18986/?key=wc_order_udFWbMfXVVTaz, so a fresh install is immediately readable.

  public/class-custom-google-analytics-public.php:229-278

  Recommendation

  Do not write logs under the plugin directory. If logging is required, use a non-web-accessible path (or uploads with deny-all), gate it on WP_DEBUG, and never serialize $_COOKIE, order keys, or emails. Delete shipped debug.log from the release artifact, add it to the packaged zip ignore list, and rotate/redact existing files on activation.

• high Admin Logs tab echoes debug.log unescaped, enabling stored XSS from checkout cookies

  xss_stored

  The manage_options settings page (cga_options → admin/partials/custom-google-analytics-admin-display.php) has a Logs tab that prints the tracking log with <?= @file_get_contents(CUSTOM_GOOGLE_ANALYTICS_PATH . 'debug.log'); ?> inside a <pre> and no esc_html(). That file is attacker-influenced: a guest or customer can set an arbitrary cookie value (RFC 6265 allows <, >, /, and quotes-free script tags) and complete checkout; track_purchase then print_r's $_COOKIE into debug.log. When an administrator opens Settings → Custom Google Analytics → Logs, the stored markup closes </pre> and runs in wp-admin (create-user, plugin install, option change). Product names and coupon codes in the same dump are additional HTML context if those strings contain markup. The Settings tab itself escapes cga_tracking_id with esc_attr; only the Logs consumer is a raw HTML sink.

  admin/partials/custom-google-analytics-admin-display.php:53-55

  Recommendation

  Escape the log with esc_html() (or serve it as text/plain with a download, not inline HTML). Combine with the logging fix: do not record raw cookies. Keep the Logs tab behind manage_options (already the case via add_options_page).

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.