> ## Documentation Index
> Fetch the complete documentation index at: https://developers.fastdrop.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Advisories

> Security issues found in the FastDrop API, what they exposed, and what to do about them

Security issues that affected the API are published here once fixed, whether or
not anyone reported them and whether or not we believe they were exploited. Each
advisory states what was exposed, who could reach it, how long it was reachable,
and what — if anything — you need to do.

Changes that alter how the API behaves for callers live in the
[changelog](/changelog). This page is only for issues with a security
consequence.

***

## FD-2026-001 — `GET /v1/webhooks` returned the full signing secret

| | |
| - | - |
| **Status** | Resolved in the 2026-08-15 release |
| **Exposure window** | 2026-03-05 — 2026-08-15 |
| **Affected** | `GET /v1/webhooks` |
| **Reachable by** | The authenticated owner of the API key, own endpoints only |
| **Action required** | Conditional — see [What you should do](#what-you-should-do) |

### What was exposed

`GET /v1/webhooks` returned the full 64-character signing secret for every
registered endpoint, on every call. The
[registration docs](/api-reference/register-webhook) stated the secret was
returned once, at registration, and not afterwards. That was not true of this
endpoint for the period above.

### Who could reach it

The endpoint requires a valid API key and returns only the endpoints belonging to
that key. A caller received their own secrets, over TLS, and never anyone else's.
There was no unauthenticated path to the data and no path for one account to read
another account's secret.

### Why it still required a fix

A signing secret is the only thing that distinguishes a genuine FastDrop webhook
from a forged one. Placing it in a routine list response put it everywhere such
responses go: proxy and gateway logs, HTTP client caches, application debug
output, terminal scrollback, screen shares, and support tickets. Any of those
copies is a working key. Whoever holds one can sign a request your handler will
verify and accept as ours.

The scope above bounds who could read the response. It does not bound where the
response was subsequently written.

### What changed

The endpoint now returns `secret_prefix` — the first 8 characters, enough to tell
two endpoints apart and useless for signing. The full secret is returned only by
[Register Webhook](/api-reference/register-webhook) and
[Rotate Secret](/api-reference/rotate-webhook-secret), each of which returns it
exactly once.

### What you should do

Rotate the signing secret for any endpoint registered before 2026-08-15 **if a
response from `GET /v1/webhooks` was written anywhere durable** — a log
aggregator, an error tracker, a CI transcript, a saved HTTP session, a ticket, a
recording.

```bash theme={null}
curl -X POST https://api.fastdrop.io/api/v1/webhooks/WEBHOOK_ID/rotate-secret \
  -H "X-API-Key: fd_live_your_key_here"
```

The old secret stops working the moment you rotate, so deploy the new one to your
handler before rotating rather than after. See
[Rotating a secret](/guides/webhooks#rotating-a-secret) for the full sequence.

If you never called `GET /v1/webhooks`, or only ever called it interactively
without persisting the output, the secret was not written anywhere it had not
already been by registration, and there is nothing to do.

***

## Reporting a vulnerability

Email [support@fastdrop.io](mailto:support@fastdrop.io) with enough detail to
reproduce. We will confirm receipt, tell you what we found, and publish an
advisory here once a fix ships. Please do not open a public issue for a security
report.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.