freshdesk-cli holds a helpdesk API key and can send an irreversible public reply to a real customer. Reports about that write path, or about the credential it holds, get priority.

Report privately through GitHub's Private Vulnerability Reporting: go to the Security tab of this repository and open a draft advisory. Please do not open a public issue, a pull request, or a discussion thread for a suspected vulnerability, and please do not include real customer data, real ticket contents, or a live API key in the report — a redacted reproduction is enough.

A useful report includes the version (freshdesk version), the exact command line with secrets removed, what you expected, what happened, and the smallest reproduction you have. If the issue involves attachment fetching, the shape of the URL matters more than the URL itself.

What to expect:

Fixes ship in a normal release with a security advisory. Reporters are credited by name or handle unless they ask otherwise. We ask that you hold public disclosure until the advisory is published, and we will not take legal action against good-faith research that follows this policy.

The project is v0.x. Only the latest released minor version is supported. Fixes land on main and go out in a new release; there are no backports to earlier v0.x minors. If you are running an older version, upgrading is the fix.

The security-relevant properties of this tool are that there is exactly one write path, that it is fenced, and that credentials and signed URLs do not escape the process. Reports that break one of those are in scope.

• Any bypass of the send guardrails that leads to an unintended send. That includes: posting a reply without --yes; posting more than one reply from a single reply send invocation; a duplicate reply passing the timeline duplicate check; a reply going out against a ticket whose fingerprint no longer matches --baseline; or reply verify issuing any write at all.
• Credential exposure. FRESHDESK_AUTH_B64 appearing on stdout or stderr, in any envelope field, in a bundle artifact, or anywhere on disk. The CLI is supposed to pass it through into a single request header and nowhere else.
• Attachment host allowlist bypass. The allowlist — freshdesk.com, its subdomains, and s3.amazonaws.com — holds per hop, not just on the initial URL: every redirect hop is re-checked against the same predicate, and a hop that leaves the list aborts the fetch and is recorded as skipped_policy with third_party_host:<host>. Any fetch that reaches a host outside the list is in scope, whether it gets there by redirect, by URL parsing that disagrees with what the HTTP client ultimately requests, or by any other route.
• Presigned URLs or credentials appearing in manifest.json, or anywhere else in a bundle directory. A bundle is meant to be safe to hand to a model or attach to a case file.
• Path traversal or arbitrary file write through an attacker-controlled attachment filename, or any other write outside the --out directory.
• Denial of service that is cheap to trigger and not bounded by the tool's own request, attachment, size, and pagination caps.

These are real ways to get hurt, but they are the operator's configuration, not a flaw in the tool:

• Passing a wrong or stale --baseline. The baseline is the caller's assertion about which evidence the draft was written against; the tool checks the ticket against it, it cannot check it against the caller's intent.
• Exposing your own credential — echoing FRESHDESK_AUTH_B64 in a shell, committing it, or putting it into CI logs.
• A misconfigured directory file that maps an alias to the wrong group_id or status_id and therefore scans the wrong queue. The tool validates the file's structure; it cannot know which numbers are correct for your account.
• Anything that requires an attacker to already control the machine, the environment variables, or the --body-file contents.
• Vulnerabilities in Freshdesk itself, or in its API — report those to Freshdesk.
• Missing hardening with no demonstrated impact, and automated-scanner output without a working reproduction.

Worth stating, because reports sometimes arrive as "it doesn't do X":

• It does not encode, decode, validate, or inspect FRESHDESK_AUTH_B64. It sends the value verbatim. In sandboxed deployments the variable is a placeholder that an egress proxy replaces on the wire, so a CLI that "helpfully" re-encoded or sanity-checked it would break the deployment. A value that looks wrong is not treated as an error.
• It never retries a write. No write command issues a second request. For the idempotent ones (ticket tag, ticket update, ticket close) an unknown outcome is resolved by reading the ticket back, not by writing again.
• It never retries a reply. An unknown send outcome stays exit 8 and is resolved by a separate read-only reply verify. Automatic resend would be a bug, not a feature.
• Its write surface stops at four commands. reply send, ticket tag, ticket update and ticket close are all of it. Private notes, deletion, and writes to the requester, subject or description are absent by design, and ticket update refuses --status 5 so that closing has exactly one door. Requests to add any of these are product decisions rather than security reports.