Updated 1/21/2026
Stewart Vulnerability Disclosure Policy (VDP) & Researcher Guidelines
Contact for all reports: secops@stewart.com
Purpose: enable responsible security research and fast, coordinated fixes that protect our customers, partners, and funds.
1) Commitment to good-faith research
If you make a good-faith effort to follow this policy while testing in scope, Stewart will consider your research authorized and will not pursue legal action (including CFAA/DMCA/anti-hacking claims). We ask that you avoid privacy harm and service disruption and coordinate disclosure with us.
2) Scope
In scope
- Domains we operate: https://stewart.com and subdomains (*.stewart.com).
- Public sites and authenticated portals linked from stewart.com that Stewart operates (e.g., customer/agent/partner portals).
- Public APIs owned by Stewart.
Out of scope
- Third-party services we don’t operate (e.g., cloud hosting, payment processors, mobile deposit/wire apps, county/recording systems). Please report those to the vendor; if risk to Stewart users exists, you may copy us.
- Social engineering (phishing/vishing/smishing), physical attacks, or account takeover of Stewart staff or customers.
- Denial of Service (DoS/DDoS), spam, resource exhaustion, or any activity that degrades service.
- Automated scanning at high rates or testing that uses real customer data.
Unsure if a target is in scope? Email secops@stewart.com before you test.
3) Testing ground rules
Do
- Use non-destructive techniques and the minimum data needed to demonstrate impact.
- Create and use your own test accounts.
- Respect privacy. If you encounter production data, stop; capture only what’s necessary to show impact (e.g., redacted screenshot) and report immediately.
- Rate-limit requests and avoid actions that could trigger outages.
- Clearly document steps to reproduce and provide a minimal PoC.
Don’t
- Access, modify, or exfiltrate data you don’t own (beyond what’s strictly necessary to show impact).
- Laterally move into third-party systems.
- Attempt ransom, extortion, or threats.
- Repeatedly trigger emails/SMS or financial transactions.
- Persistently run crashing/fuzzing payloads against production.
4) What to report (and what not)
High-value issues
- Authentication/authorization flaws (IDOR/BOLA, privilege escalation)
- Injection (SQL/command/template), RCE
- SSRF with internal impact; stored/reflected XSS with sensitive impact
- Logic flaws enabling fraud or funds movement
- Sensitive data exposure (NPI/PII, secrets/keys/tokens)
- Misconfigurations with exploit path (open admin, object storage exposure)
- Broken cryptography or transport security with practical exploitability
Generally not eligible for recognition
- Missing headers or version banners without exploitability
- Clickjacking on non-sensitive pages
- Rate-limit suggestions without the abuse path
- Self-XSS, mixed content on brochure pages
- Weak, expired, or self-signed certificates
5) How to report
Send to: secops@stewart.com
Subject line: Security report: <short title> — <host/app>
(Optional) If you prefer encryption, note this in your email; we can arrange PGP or secure transport.
Include:
- Summary (one sentence)
- Targets (URL, app/API version, environment)
- Steps to reproduce (numbered, reliable)
- Impact (who/what is affected; data/funds at risk)
- Minimal PoC (e.g., curl/HTTP transcript or redacted screenshots)
- Your contact and disclosure preference (credit or anonymous)
Please avoid large payloads, live data dumps, or repeated execution of PoCs.
6) Stewart’s response & timelines
We aim to:
- Acknowledge within 3 business days
- Triage & severity within 7 business days
- Provide status updates at least every 14 days until resolution
Target fix timelines (guidance; may vary with complexity)
- Critical: 30 days
- High: 60 days
- Medium: 90 days
- Low: 120 days
If your report is a duplicate, we’ll let you know and may credit significant new context.
7) Coordinated disclosure
Please do not publicly disclose details or PoCs until we’ve validated the issue and released a fix/mitigation, or 90 days have passed—whichever is first. If a critical fix needs more time, we’ll discuss an extension and a mutually agreeable disclosure plan.
8) Legal safe harbor
- Testing of in-scope systems under this policy is authorized by Stewart.
- We won’t initiate legal action for good-faith research that follows these rules.
- If you inadvertently access personal or proprietary data, stop immediately, minimize exposure, and notify us.
- This policy does not authorize actions that cause harm, breach privacy, or violate laws. Stewart may update this policy over time.
9) Recognition & rewards
We operate on an honor system, meaning we do not provide a monetary bug bounty to researchers who responsibly disclose a potential vulnerability, and we do not agree to any demand to provide a monetary bug bounty in compensation for disclosing a potential vulnerability. Depending on the materiality of the vulnerability you report, and in our sole discretion, we may offer a monetary or non-monetary reward in appreciation for responsibly disclosing the vulnerability once the issue is fixed.
10) Privacy & data handling
- Redact names, account numbers, routing/wire details, tokens, and keys in artifacts.
- Do not retain, share, or transfer any data obtained during testing.
- On request, securely delete any data you collected and confirm deletion.
11) Safe testing support
Where feasible, we can provide test accounts or sandbox endpoints with demo data. Request access at secops@stewart.com before you begin.
12) Sample template (for researchers)
Subject: Security report: [short title] — [host/app]
Targets
- URL / App or API version / Endpoint:
- Environment: (prod / staging / mobile vX.Y)
Summary
One-sentence description of the issue and impact.
Steps to reproduce
- …
- …
- …
Impact
Who/what is affected; data/funds at risk; business action enabled.
Evidence
- Redacted screenshots or short video
- Minimal PoC (curl/HTTP transcript)
Suggested fix (optional)
Your remediation idea or relevant docs.
Researcher
Name/Handle, public key (optional), disclosure preference (credit/anonymous).