Wyatt Vulnerability Disclosure

generated: '2026-09-04'
method: probed
source: https://wyattcorp.com/vulnerability-disclosure
published: false
program: none
note: >-
  NO vulnerability disclosure program was found. probe-security-programs.py initially recorded a
  hit here; it is a false positive and has been overwritten by hand. wyattcorp.com sits behind a
  slowAES JavaScript cookie challenge (cupid.js) that answers HTTP 200 for EVERY path with a
  ~785-byte challenge page, and that page embeds the requested URL verbatim in its
  location.href redirect. The scanner's keyword match on "vulnerability" was matching the path it
  had just asked for, not any content the company published. A control fetch of
  https://wyattcorp.com/this-page-cannot-exist-9x2 returned the same 200 and the same page shape,
  which is what disqualifies the hit.
controls:
- url: https://wyattcorp.com/vulnerability-disclosure
  status: 200
  bytes: 785
  verdict: bot-challenge page, path echoed into the body — not a disclosure page
- url: https://wyattcorp.com/this-page-cannot-exist-9x2
  status: 200
  bytes: 787
  verdict: negative control returns the same page — host is a catch-all for our crawler
- url: https://drforhair.co.kr/.well-known/security.txt
  status: 404
  verdict: no RFC 9116 security.txt
- url: https://drforhair2024.cafe24api.com/.well-known/security.txt
  status: 404
  verdict: no RFC 9116 security.txt on the tenant API host either
bug_bounty: none-found
searched:
- hackerone
- bugcrowd
- intigriti
push_to_provider: >-
  Wyatt publishes no security contact of any kind on either brand domain. An RFC 9116
  /.well-known/security.txt on drforhair.co.kr naming the df@wyattcorp.com address it already
  publishes in its storefront footer would close this at near-zero cost.