Gotowebinar Vulnerability Disclosure

generated: '2026-08-13'
method: searched
probe: true
policy: []
contact:
- security@goto.com
channel_url: https://www.goto.com/company/trust/security-measures
evidence:
- source: https://www.goto.com/company/trust/security-measures
  status: 200
  kind: security-page
  quote: 'Looking to submit a security request? Contact security@goto.com.'
security_txt:
  served: false
  probed:
  - {url: 'https://www.goto.com/.well-known/security.txt', status: 404}
  - {url: 'https://api.getgo.com/.well-known/security.txt', status: 404}
  - {url: 'https://developer.goto.com/.well-known/security.txt', status: 404}
  - {url: 'https://identity.goto.com/.well-known/security.txt', status: 404}
bug_bounty:
  program: none-found
  note: >-
    No HackerOne, Bugcrowd or Intigriti program was found for GoTo / goto.com,
    and no page under goto.com/company/trust names a bug bounty or a
    responsible-disclosure policy.
grade: contact-only
note: >-
  GoTo publishes a named security contact (security@goto.com) on its Trust
  Center security page, which is a real, anonymous, provider-served channel for
  reporting a vulnerability. It is NOT a formal disclosure program: there is no
  published policy document, no safe-harbour language, no scope statement, no
  response-time commitment, and no RFC 9116 security.txt on any GoTo host. The
  gap here is cheap for GoTo to close — a security.txt at
  https://www.goto.com/.well-known/security.txt naming this same address and a
  policy URL would make the channel machine-discoverable.