# BENEFEATURE VULNERABILITY DISCLOSURE POLICY

**Effective Date:** May 12, 2026
**Version:** v1.2

Marketshare LLC, a Maine limited liability company doing business as Benefeature ("**Marketshare**", "**Benefeature**", "**we**", "**our**"), takes the security of the Benefeature platform and our customers' data seriously. This Vulnerability Disclosure Policy ("**Policy**") describes how independent security researchers can responsibly report potential security issues in Benefeature systems and what they can expect from us in return.

This Policy is referenced from our `/.well-known/security.txt` file (per [RFC 9116](https://datatracker.ietf.org/doc/html/rfc9116)) and is the canonical location of our disclosure terms.

---

## 1. SCOPE

### 1.1 In-Scope Systems

This Policy covers any vulnerability you reasonably believe affects:

- The Benefeature web application at `app.benefeature.com` and its supporting subdomain `dev.benefeature.com`.
- The Benefeature public discovery surfaces:
  - The Model Context Protocol (MCP) server reachable under `/api/mcp/*`.
  - The Agent-to-Agent (A2A) discovery documents under `/.well-known/*`.
  - The OAuth Protected Resource Metadata document at `/.well-known/oauth-protected-resource`.
- Marketshare-operated AWS infrastructure under the `benefeature.com` domain. Some platform components (for example, web application firewall rules and security groups) are shared with the AskGMS product line; findings against shared components are in scope only to the extent they affect a Benefeature surface.

### 1.2 Out-of-Scope Systems

The following are **out of scope** and reports against them will be closed without further action:

- Third-party services that Benefeature integrates with but does not operate (Stripe, HubSpot, Sentry, Google Analytics, Auth providers, etc.). Please report issues with these directly to the responsible vendor.
- Any system not owned, operated, or controlled by Marketshare LLC.
- The Marketshare corporate website (`marketsharellc.com`) and other non-Benefeature properties.
- Subscriber-controlled data or content (an issue is in scope only if it allows access to *another* subscriber's data, not the reporter's own).

### 1.3 Out-of-Scope Findings

Even within in-scope systems, the following classes of finding are **out of scope** unless you can demonstrate concrete harm:

- Volumetric or denial-of-service attacks (network-level DDoS, application-level resource exhaustion without an authentication bypass, brute-force attacks against rate-limited endpoints).
- Reports based solely on the absence of a "best practice" header or hardening control with no demonstrated exploitation path (e.g. missing `Cross-Origin-Embedder-Policy` on a page that does not use credentialless subresources).
- Self-XSS that requires the victim to paste attacker-controlled content into their own browser console.
- Theoretical attacks against features that are gated behind authentication and have no privilege-escalation impact.
- Reports of public-by-design endpoints returning data that is in fact public (the marketing site, the agent card, the OAuth discovery document, etc.).
- Vulnerabilities in software that is end-of-life and clearly marked as such.
- Issues that require unrealistic prerequisites, such as a fully compromised victim browser, a malicious browser extension installed by the victim, or physical access to the victim's device.
- Email spoofing or open-relay reports that rely on the absence of SPF/DKIM/DMARC on subdomains we do not send mail from.

If you are not sure whether a finding is in scope, **ask first** before performing any further testing. See Section 4 for contact details.

---

## 2. RULES OF ENGAGEMENT

By participating in this disclosure program, you agree to:

1. **Test only on accounts you own.** Do not access, modify, or delete data belonging to any subscriber other than yourself or accounts you have explicit permission to test against. If you inadvertently access another subscriber's data, **stop immediately**, do not retain or distribute it, and report what happened in your disclosure.
2. **Avoid harm.** Do not run automated scanners that generate substantial load. Vulnerability scanners against production are by default *not authorized* without prior written approval (see Section 4). Do not attempt denial-of-service, resource exhaustion, or any action that would degrade service for legitimate users.
3. **Do not perform social engineering.** Phishing, vishing, or any pretexting against Marketshare employees, contractors, or customers is **out of scope and prohibited**, regardless of the underlying technical finding it might reveal.
4. **Do not perform physical attacks.** Tailgating, dumpster diving, badge cloning, and similar physical-security testing is **out of scope and prohibited**.
5. **Do not pivot.** If you find a vulnerability that gives you access to internal systems, customer data, or third-party services, **stop, document what you have, and report**. Do not use the access to explore further.
6. **Keep your findings confidential** until we have had a reasonable opportunity to remediate (see Section 6 for our disclosure timeline).
7. **Do not accept payment from third parties** in exchange for vulnerability information about Benefeature. Coordinated disclosure must remain non-commercial.

Violating these rules may forfeit safe-harbor protection (Section 5) and may result in legal action.

---

## 3. WHAT TO INCLUDE IN A REPORT

A high-quality report dramatically shortens our triage time. Please include, where applicable:

- **A clear summary** of the vulnerability and the security impact (data exposure, privilege escalation, account takeover, etc.).
- **Affected component:** URL, API endpoint, page, or system.
- **Reproduction steps:** numbered, copy-pasteable, with screenshots or HAR files where they help.
- **Proof-of-concept** payload, request, or script that demonstrates the issue in a controlled way. **Do not exfiltrate data beyond what is needed to demonstrate the vulnerability.**
- **Affected accounts:** the email address(es) of the test accounts you used. We need this to scope blast radius and confirm we have remediated for any real impact.
- **Suggested remediation:** optional, but appreciated.
- **Your preferred contact details** and whether you want public acknowledgement on resolution (see Section 7).

---

## 4. HOW TO REPORT

Email vulnerability reports to **`support@benefeature.com`** with the subject line **"Security Report"** so our triage routing picks them up correctly. Per RFC 9116, this is the address listed in our [`/.well-known/security.txt`](/.well-known/security.txt).

> We do not currently publish a PGP key for security reports. If you want to encrypt a report end-to-end, contact us at the address above and we will arrange a secure channel.

If your finding involves a vulnerability that is **already being actively exploited**, please indicate this clearly in the subject line ("**Security Report: ACTIVE EXPLOITATION**"). We monitor that inbox during business hours (US Eastern Time) and route to on-call after hours for active-exploitation reports.

We do **not** accept vulnerability reports through:

- Twitter / X / public social media.
- GitHub issues on any repository, public or private.
- Phone calls to Marketshare general lines.
- Paper mail.

---

## 5. SAFE HARBOR

We will not pursue civil or criminal action against security researchers (including under the Computer Fraud and Abuse Act (CFAA), the Digital Millennium Copyright Act (DMCA), state computer-crime statutes, or our [Terms of Service](/legal/terms-of-service)) who:

1. Make a good-faith effort to comply with this Policy.
2. Report any potential vulnerability they discover to us promptly.
3. Avoid privacy violations, destruction of data, and degradation of service.
4. Do not exploit the vulnerability for purposes other than verification.
5. Do not disclose the vulnerability publicly before we have had a reasonable opportunity to remediate (see Section 6).

This safe harbor extends only to the activities described in this Policy, performed against in-scope systems, and within the rules of engagement in Section 2. It does **not** extend to actions that:

- Violate any third party's rights, terms of service, or applicable laws (you are still bound by Stripe's, AWS's, etc. terms when you interact with their systems through ours).
- Cause harm to Benefeature, our subscribers, or our infrastructure beyond what is strictly necessary to demonstrate the vulnerability.
- Continue after we have asked you to stop.

We are not in a position to authorize testing on systems we do not operate, and this Policy does **not** authorize you to violate any third party's terms of service.

If legal action is initiated against you by a third party for activities you conducted under this Policy in good-faith compliance with it, we will make reasonable efforts to clarify the authorized nature of your work to the relevant parties.

---

## 6. RESPONSE COMMITMENTS

We commit to:

| Stage | Target |
| --- | --- |
| **Acknowledgement** | Within five (5) business days of receipt at `support@benefeature.com`. |
| **Initial triage** | Within ten (10) business days of acknowledgement, with a severity assessment and an indication of whether we accept the report as a valid in-scope vulnerability. |
| **Remediation status updates** | At least every thirty (30) days while the vulnerability remains unfixed. |
| **Public disclosure window** | Up to ninety (90) days from the date of our triage acknowledgement, extended only by mutual agreement when fixing the issue genuinely requires more time (e.g. a coordinated multi-vendor patch). |

If we close a report as out-of-scope or as not-a-vulnerability, we will explain why. If you disagree, you may reply with additional information; we will reconsider in good faith.

We do not currently operate a paid bug-bounty program. Acceptance into this Policy does not constitute a contract for payment.

---

## 7. PUBLIC ACKNOWLEDGEMENT

With your permission, and only after the vulnerability has been remediated, we are happy to publicly acknowledge the researchers who responsibly report security issues to us. Indicate in your report whether you would like:

- **Full credit:** your name (or handle), affiliation if any, and a link.
- **Anonymous credit:** credited as "an independent researcher" with no further identifying detail.
- **No credit:** your report is acknowledged only privately to you.

We do not publish a hall of fame today; this section may be expanded in the future.

---

## 8. POLICY UPDATES

This Policy is a living document. Material changes will be reflected by updating the **Effective Date** at the top of this page. Researchers who are mid-engagement when a material change occurs may continue under the version of the Policy that was in effect when they began testing, provided they complete their disclosure within thirty (30) days of the change.

---

## 9. CONTACT

For all matters relating to this Policy, including but not limited to:

- New vulnerability reports.
- Status inquiries on existing reports.
- Questions about scope or rules of engagement.
- Requests for a coordinated disclosure timeline extension.

contact: **`support@benefeature.com`** (subject line: **"Security Report"**).

For non-security customer support, please use the same address with a different subject line, or refer to your subscription's support channel.


Contact Us

Info

Policies