Kixie · Vulnerability Disclosure

Kixie Vulnerability Disclosure

Vulnerability disclosure

Kixie publishes a dedicated security page with a named security contact, explicit reporting instructions, and guidance on what not to include in a report. There is no bug bounty, no safe harbour statement, no published SLA for triage, and no machine-readable security.txt — but a real, human-reachable disclosure route exists and is documented.

Kixie publishes a vulnerability disclosure policy for reporting security issues. A dedicated security contact is published.

CompanySales EngagementVoiceTelephonySMSMessagingContact CenterPower DialerCRMWebhooksCommunicationsRevenue Operations
Program:

Disclosure Policy

Security Contact

Contact
emailsecurity@kixie.com
Contact
pagehttps://www.kixie.com/security/
Contact
probed{"fetched" => "2026-08-12", "http_status" => 200, "url" => "https://www.kixie.com/security/"}

Source

Vulnerability Disclosure

kixie-vulnerability-disclosure.yml Raw ↑
generated: '2026-08-12'
method: searched
probe: true
source: https://www.kixie.com/security/
docs: https://www.kixie.com/security/

name: Kixie vulnerability disclosure
description: >-
  Kixie publishes a dedicated security page with a named security contact, explicit reporting
  instructions, and guidance on what not to include in a report. There is no bug bounty, no safe
  harbour statement, no published SLA for triage, and no machine-readable security.txt — but a
  real, human-reachable disclosure route exists and is documented.

published: true
program_type: direct-contact disclosure page
bug_bounty: false
bug_bounty_platform: null
safe_harbour_published: false
response_sla_published: false
pgp_key: null

contact:
  email: security@kixie.com
  page: https://www.kixie.com/security/
  probed:
    url: https://www.kixie.com/security/
    http_status: 200
    fetched: '2026-08-12'

reporting_instructions:
  verbatim: >-
    "If you believe you have found a security issue involving Kixie, email security@kixie.com with
    a clear description, affected URL or product area, reproduction steps, and any supporting
    evidence. Do not include passwords, access tokens, customer records, or other sensitive data
    in an initial report."
  requested_fields:
  - clear description
  - affected URL or product area
  - reproduction steps
  - supporting evidence
  prohibited_in_report:
  - passwords
  - access tokens
  - customer records
  - other sensitive data

security_txt:
  served: false
  probed:
  - url: https://www.kixie.com/.well-known/security.txt
    http_status: 404
  - url: https://developer.kixie.com/.well-known/security.txt
    http_status: 404
  - url: https://app.kixie.com/.well-known/security.txt
    http_status: 404
  finding: >-
    The policy exists but is not machine-discoverable. A researcher's tooling, and any agent
    following RFC 9116, finds nothing.
  remedy: >-
    Serve /.well-known/security.txt containing at minimum:
    Contact: mailto:security@kixie.com, Policy: https://www.kixie.com/security/, Expires.

page_freshness:
  last_reviewed_stamp: '2026-08-03'
  note: >-
    The page carries its own "Last reviewed" date, which is a genuinely good practice and rarer
    than it should be — it lets a reader judge staleness without guessing.

posture_note: >-
  Kixie's security page is unusually candid: it states that it "intentionally does not claim a
  certification, audit result, hosting architecture, retention period, or control that has not
  been confirmed for publication." That is an explicit refusal to imply compliance it has not
  confirmed. It is worth reading as a deliberate honesty choice rather than as an omission — but
  it does mean an evaluator gets no certification evidence without a sales conversation.

gaps:
- No security.txt (RFC 9116).
- No bug bounty or coordinated-disclosure program.
- No safe harbour / legal protection statement for good-faith researchers.
- No published triage or remediation timeline.
- No PGP key or encrypted reporting channel, despite requesting reproduction evidence by email.