StoreMingle Responsible Disclosure Policy

Last Modified: September 15, 2026

This policy is the disclosure program referred to in our Terms of Service §8(j) and Acceptable Use Policy §7. It is incorporated into the Terms of Service by §21(a) and forms part of them. Capitalised terms — Buyer, Vendor, Organizer, Show, Booth, Live Session, On Air — have the meanings given there.

This policy is the whole of what we offer a researcher. Acceptable Use Policy §7 points here and adds nothing; where any other document of ours describes our posture on security research more broadly, this policy governs.

Our Terms prohibit probing, scanning or testing the security of the Services. This policy is the exception. It says exactly what security research we permit, how to tell us what you found, what we will do in response, and what we promise not to do to you. It is a bounded permission, not a blanket one: research that stays inside it is welcome, and §8 says what that means for our agreements with you; research outside it is a breach of the Terms and may be unlawful.

1. Scope — what you may test

Our configuration versus their platform. Parts of the Services run on infrastructure we configure but do not operate: our clients talk directly to our database provider for storage and realtime, and directly to our video provider for live streams. A flaw in our configuration of those services — an access rule that lets you read data that is not yours, a storage path that is more public than it should be, a stream token that grants more than it says — is ours, is in scope, and is exactly the kind of finding we most want to hear about. A flaw in the provider's own platform is theirs: report it to them under their program, not to us. The test is who would write the fix.

Out of scope

Reports we will normally close without action

These are not vulnerabilities in themselves, and reports consisting only of them will be closed as informational: missing security headers without a demonstrated exploit; clickjacking on pages with nothing sensitive to click; software version disclosure; TLS-configuration scanner output; email-authentication (SPF/DKIM/DMARC) observations; "vulnerable dependency" reports with no reachable path; and raw automated-scanner output with no analysis. If you can chain one of these into real impact, that chained finding is very much in scope — show the chain.

2. Rules of engagement

You may test only under all of these conditions:

• Use accounts and businesses you own. Test with accounts you created and control, against data you put there. If the account you need is one you cannot create yourself, ask us at the address in §4 and we may provision a test account.
• Prove it, then stop. Go no further than the minimum needed to demonstrate that the vulnerability is real. Demonstrating that you could read a record is the finding; reading a thousand of them is a breach of this policy.
• If you hit someone else's data, stop immediately and report. Do not examine it beyond recognising what it is, do not copy more of it, do not share it, and delete anything your tooling retained once we confirm receipt of your report.
• Keep automated traffic gentle. Stay under roughly ten requests per second, back off when you see errors or slowdowns, and stop entirely if the Services degrade. This is a live platform used by real businesses.
• Follow the law and the rest of our Terms. This policy excuses the security-testing prohibition; it excuses nothing else.

3. Testing that is never permitted, whatever the intent

• Anything involving a Live Session with real people in it. A Booth stream or show session carries real people's live camera and audio. Do not test against a Live Session in progress, do not attempt to join, observe, capture or disrupt one, and do not attempt to put yourself or anyone else On Air as part of a test. If you want to test the live infrastructure, create your own session with your own participants.
• Accessing, modifying, deleting or exfiltrating another user's data. This includes verification documents — the business-identity files Buyers and Vendors upload are the most sensitive data class on the platform, and §2's stop-and-report rule applies with no tolerance.
• Denial of service in any form — flooding, resource exhaustion, lock contention, stress testing — and any automated scanning aggressive enough to have the same effect.
• Social engineering — phishing, pretexting, vishing or any deception aimed at our staff, contractors, Vendors, Buyers, Organizers or users. Physical attacks on people, offices or facilities.
• Sending spam or unsolicited messages through the Services' messaging, invitation or notification features, including as a "demonstration".
• Testing payment flows with anyone's payment details but your own, completing checkouts you do not intend to honour, or raising disputes or chargebacks as a test.
• Introducing malware or leaving any persistent change behind — accounts and test data excepted, and tell us about those so we can clean up.

4. How to report

Email security@storemingle.com.

A good report lets us reproduce the problem without guessing:

• what kind of vulnerability it is, and where — the URL, endpoint, screen or component;
• step-by-step reproduction instructions, with the account(s) you used;
• what an attacker could actually do with it — impact, in concrete terms;
• proof: a screenshot, a short recording, or proof-of-concept code;
• how to reach you for follow-up, and the name (or handle, or anonymity) you would want used if you accept credit under §7.

One vulnerability per report, please. We currently accept reports in English. We do not yet offer an encrypted reporting channel; do not include other people's personal data in a report — describe it and we will look at it ourselves.

5. What we will do

For a report made in good faith under this policy, we will read it, assess whether it is valid and how severe it is, and tell you what we concluded. We triage by severity — a flaw exposing verification documents or another business's data jumps every queue. When it is fixed we will tell you, so you can verify.

We will keep your identity and your report confidential, and we will not share either beyond the people who need them to fix the problem.

We do not publish response times, and you should read that as candour rather than evasion. We are a small team. A published clock that we miss is worth less to you than an unpublished one we keep, and it would tell you nothing about the thing you actually care about, which is whether the flaw gets fixed. Section 6 is written so that this costs you nothing: your disclosure window runs from the date of your report, not from anything we do, and our silence never extends it. If we go quiet, you are free on day 90 regardless.

6. Coordinated disclosure

We ask for 90 days from the date of your report before you publish anything about the vulnerability. In return:

• If we fix it sooner, we will happily coordinate an earlier publication date with you.
• If we need longer — some fixes genuinely do — we will ask before day 90, tell you why, and propose a specific new date. We will not ask for indefinite silence, and we will not use the request as a way of never fixing the problem.
• If we disagree about timing, we will say so in writing with our reasons, and keep talking. If we never acknowledge your report at all, the 90 days still runs — our silence does not extend your obligation.

Whenever and however you publish, one condition is absolute and survives the window: your publication must not contain other people's personal data — not user data you encountered during testing, and not verification documents, ever. Publishing such data takes you outside this policy and §8 entirely, no matter how long you waited.

7. No bounty — and what we offer instead

We do not pay bounties. We do not run a bug-bounty program, and we make no payment, in any amount, for any report. We say this plainly because silence on the question reads as "maybe" and wastes your time and ours.

What we offer is credit: with your permission, we will name you (or your handle) in an acknowledgements section on the published version of this page once the vulnerability is fixed. If you prefer anonymity, we will respect that. Asking whether payment is available costs nothing and does not affect §8 — demanding payment as a condition of reporting, of not exploiting, or of not publishing is extortion, not research, and is the fastest way out of this policy.

8. What this policy does for you

For security research conducted in good faith and in compliance with this policy, we will not treat your testing as a breach of the security-testing prohibitions in Terms of Service §8(j) or Acceptable Use Policy §7, and we will not bring a claim against you under them.

That is the whole of what we offer, and it is narrower than some disclosure policies you may have read. We make no promise about how any law applies to your research. We do not commit to anything about criminal referral or about what we would say to law enforcement; we do not undertake to help you if a third party sues you; and we do not purport to authorize your conduct, or to waive any claim, under the Computer Fraud and Abuse Act, the Georgia Computer Systems Protection Act, or Section 1201 of the DMCA. Your own compliance with the law is yours.

What Sections 1 and 2 grant matters more than what this Section withholds. Section 1 names the systems on which we permit testing and Section 2 sets the rules for it. That permission is real and this Section does not qualify it; this Section says only that exercising it is not a breach of our agreements with you.

You keep what this Section gives you by meeting all of these conditions — they are this policy, not additions to it:

1. you tested only in-scope targets (§1), under the rules of engagement (§2), and did nothing §3 forbids;
2. you did not access, alter or destroy data belonging to anyone else beyond an inadvertent encounter handled exactly as §2 requires — stop, report, delete;
3. you reported promptly to the §4 address and observed the §6 window and its no-personal-data condition;
4. you did not condition anything on payment (§7);
5. your conduct was otherwise lawful.

If you are unsure whether something you are planning is inside this policy, ask first at the §4 address. Testing first and arguing later is what this section does not protect.

9. Changes

We may update this policy; the date at the top tells you the version you are reading. The version published when you began your research is the one that governs it. This policy is part of the Terms of Service, whose §21(d) change-notice terms apply.

10. Contact

Celavii Software Inc (d/b/a StoreMingle) 800 Progress Center Ct, Suite 500 Lawrenceville, GA 30043, United States

Security reports: security@storemingle.com Everything else: support@storemingle.com · privacy matters: privacy@storemingle.com