Author Topic: FoxyCart Bug Bounty  (Read 1109 times)


  • Moderator
  • Experienced Member
  • *****
  • Posts: 357
    • View Profile
FoxyCart Bug Bounty
« on: July 31, 2023, 05:28:03 pm »
submit bug  report:

We appreciate all security concerns brought forth and are constantly striving to keep on top of the latest threats. Being pro-active rather than re-active to emerging security issues is a fundamental belief at Foxy. Every day new security issues and attack vectors are created. FoxyCart strives to keep abreast on the latest state-of-the-art security developments by working with security researchers. We appreciate the community's efforts in creating a more secure world.

No technology is perfect, and we at Foxy believe that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.

Disclosure Policy
Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
While researching, we'd like to ask you to refrain from:

Denial of Service attempts
Social engineering (including phishing) of Foxy staff or contractors
Any physical attempts against Foxy property or data centers
Thank you for helping keep and our users safe!

Before You Begin
Please read and follow the rules in the Standard Disclosure Terms.
Please review our blog post about submitting helpful reports.
Review the "Out of Scope" section below.
Please review the "Known Issues" below.
What, Where, and How to Test
At its simplest, FoxyCart works by adding products to a /cart endpoint via GET or POST request. Click here for some examples on our homepage.

To do more in-depth testing and create your own account:

Create an account at
When creating your account, please use the following format:
When creating your store's subdomain, please use the following format:
Test as desired. You can use the default gateway test account and the test credit card 4111 1111 1111 1111 to test successful transactions. Full documentation is available at, and there's a quick cheat sheet as well.
Create an API client at or from the "integrations" page in the admin. The API uses Oauth 2.0, and can handle nearly every request that can.
Please do not use automated scanners or aggressive scripts.

DO NOT REPORT Known Issues & False Positives
DMARC, DKIM, or SPF records missing on domains or subdomains.
DROWN ATTACK NOTE: (2016-03-02) Don't report that we're vulnerable to DROWN unless you can show an IP and domain that match what you're attempting, and that are actually vulnerable. The DROWN test tool isn't giving you the info you might think it's giving you.
BREACH Attack: Unless you can confirm our mitigation approach at isn't sufficient, please do not report this.
Session persistence after logout.
For If you believe you can reuse a logged in cookie after a logout, please confirm you can replicate it. This has been reported a few times in error, so we'll need a screencast, details of the requests/responses, AND confirmation that you've been able to replicate it (with detailed steps) before we will spend time attempting to reproduce this.
For This is a known issue and excluded from our bug bounty program.
SSRF: Our cache endpoint (which caches images and is publicly accessible) and our template caching (available in the admin) make outbound GET requests. Similarly, other functionality may make outbound requests (webhooks, tax systems, etc.). This is by design. We'll only accept SSRF reports if you can demonstrate accessing internal or otherwise privileged access.
CSRF: If you report a CSRF issue and you include a valid CSRF token in your POC... Please just don't do that.
Automated Scanning Tools: Don't just blindly report whatever your tool reported. It'll waste our time and yours if you don't verify it's an actual issue.
Moving on…

The most important thing to note is how FoxyCart works. Please don't report the following behavior:

Products can be added via a GET or POST, and a product's name, price, or other options can be modified. This is by design. We designed our system for flexibility and there is a way to protect add-to-cart links and forms.
These requests can be submitted to SSL from a non-SSL page.
The templates (cart, checkout, receipt, email) can include whatever javascript the user would like. Again, this flexibility is by design.
The following finding types are specifically excluded from the bounty:

General issues:

Self-XSS and issues exploitable only through Self-XSS.
Editing certain non-user-controllable HTTP headers such as Referer can trigger a reflected XSS on certain pages.
SSL cipher strength issues as reported by automated scanning tools, unless you have a practical exploit.
Clickjacking headers not present on some of our subdomains.
HTTP 404 codes/pages or other HTTP non-200 codes/pages.
CSRF on forms that are available to anonymous users (e.g. the contact form, search form).
Presence of application or web browser 'autocomplete' or 'save password'.
Disclosure of known public files or directories, (e.g. robots.txt).
Banner disclosure on common/public services.
No Strict Transport Security (HSTS) headers set.
Normal OPTIONS responses.
Some domains do not have proxy protection.
cache.php will cache/load images from 3rd-party domains. This is by design. (See the note about SSRF above.)
Some forms do not have rate limiting / brute-force protections. (Please don't automate a ton of contact forms or anything.)
Lookalike domains exist that we don't own or are unregistered.
Host Header validation/injection, unless you have a demonstrable exploit. (Please don't submit host header redirection issues.)
Admin-related issues:

NEW ADMIN at We're currently only accepting security-related bug reports.
3rd-party scripts are loaded within the admin.
Account creation at does not have captcha or email validation.
Multiple failed login attempts for an invalid user do not result in an IP-based block. (Please note that multiple failed login attempts for a valid user will result in a temporary lock for that user, but you'll still get a 200 response. Also, we do IP-based blocking in certain other cases.)
Login Page / Forgot Password page messaging, account brute force, or account lockout not enforced. (Again, there's enforcement in some areas, and we're aware of others already.)
Password resets...
Indicate whether an account exists or not.
Don't generate an additional email to the admin user.
Are sent via a link that's Base64 encoded.
That link shows in the referrer header when loaded in the Foxy admin.
Aren't rate limited.
Aren't expired on email change.
Admin email changes happen without an email confirmation.
There's no maximum password length. This is not a DoS issue.
Admin sessions are not invalidated on… certain events. In the situations where sessions aren't invalidated, this is a known issue. (Similarly, we don't support MFA yet, and don't have robust "suspicious" login detection. We're working on that.)
Admin does not require re-authentication on certain actions.
Logout Cross-Site Request Forgery (logout CSRF).
Clickjacking is possible in certain old browsers that don't support X-Frame-Options-Header but do support TLSv1.1+.
There exists an edge case where it's possible to change an admin password without providing the original password. We are aware and working to diagnose. (If you can reliably reproduce, that'd be a valid submission. Otherwise it's a known issue.) (There exists another way to do this that we can reproduce, related to the password reset email URL. This is a known issue.)
Generated CSVs may allow for Excel-specific functions to be output.
RC4 encryption is used in legacy webhook systems.
Cart and Checkout issues:

Form POSTs and GETs to /cart are possible from http. (http->https MITM attack vector.)
Cart requests do not require CSRF or have other protection (aside from the HMAC signing mentioned above).
The ability to modify product parameters in a link or form, if the account has the HMAC signing functionality disabled. (Again, as mentioned above.)
Clickjacking headers (and/or other mitigating precautions) not present on some of our subdomains.
The session-specific referrer header can be manipulated, and is output to customers in certain situations.
Password resets (and customer logins) indicate whether an account exists or not.
It's possible create a duplicate customer account with an existing email under very specific circumstances.
Networking and infrastructure:

Host Header injection/modification/redirects. We're aware.
It's possible to reveal an internal IP address if you modify a redirected request. This is an AWS ELB/ALB thing, and the IP revealed is not one of ours.
Open redirect on the store's * subdomain (or custom domain) without a /cart parameter, redirects to the configured store URL.
A Note about XSS
Please note: If you've identified an XSS issue (especially on on our www site), please make sure it is actually exploitable beyond Burp Suite or whatever you're using. If you can't reproduce the XSS in a browser, we will likely consider it self-XSS, and an invalid submission.

A Note about CSRF
We get a lot of CSRF reports that include the CSRF token in the proof of concept. Before reporting CSRF, make sure you actually understand what CSRF is, because if you include the CSRF token in your POC, it's just a waste of your time and ours.

Out of Scope: Other or Domains
Foxy customer sites and applications are out of scope for this program. You can create a free test account at if you'd like to test the cart and checkout flow itself. Please don't test our users.

For vulnerabilities found at the following subdomains, we make a distinction between the underlying system and our own modifications. For example, we use Dokuwiki for our wiki. If you find a security issue in our implementation of Dokuwiki, that may be valid and eligible for a reward from us. But, for instance, an issue with Dokuwiki itself should be reported to them. uses Grav CMS uses Wordpress
Please note that reports about xmlrpc.php being present are excluded from our program. uses Dokuwiki uses iDevAffiliate uses HelpJuice