Builtwith Vulnerability Disclosure

generated: '2026-08-14'
method: probed
probe: true
source: https://builtwith.com/.well-known/security.txt
policy: []
contact:
- mailto:support@builtwith.com
encryption:
- https://builtwith.com/.well-known/publickey.txt
expires: '2035-08-26T00:00:00.000Z'
evidence:
- source: https://builtwith.com/.well-known/security.txt
  kind: security.txt
  spec: RFC 9116
  http_status: 200
  fields: [Contact, Encryption, Expires]
  file: ../well-known/builtwith-security.txt
- source: https://api.builtwith.com/.well-known/security.txt
  kind: security.txt
  spec: RFC 9116
  http_status: 200
  note: identical document served from the API host
- source: https://api.builtwith.com/.well-known/api-catalog
  kind: api-catalog linkset
  http_status: 200
  note: >-
    The provider's own RFC 9727 catalog links security.txt and the PGP public key as the
    security contact surface, which corroborates that this is the intended disclosure channel.
bug_bounty: null
gaps:
- >-
    The security.txt carries no "Policy:" field, so there is no published disclosure policy
    page and no bug-bounty program (HackerOne / Bugcrowd / Intigriti all absent).
corrections:
- date: '2026-08-14'
  removed_evidence: https://builtwith.com/vulnerability-disclosure
  reason: >-
    The prior round recorded that URL as a disclosure page on an HTTP 200. builtwith.com serves
    a site-wide "Search results for <path>" template with HTTP 200 for every unknown path, so
    that 200 was a soft 404 and the "vulnerability" keyword match came from the echoed search
    term, not from a disclosure policy. Verified by probing
    https://builtwith.com/thispagedoesnotexist12345, which returns the same 200 template.