A Flutterwave secret key authenticates your server to the Flutterwave API. With it, someone can create payments, read transactions and customer details, and issue refunds, all under your merchant account. The secret key is meant to live only on your server, never in a browser or a mobile app, because it signs requests that move money. A leaked key is therefore a payments incident. Rotate it first, then review what it was used for.
Check your GitHub account for leaked secrets — free
- Provider
- Flutterwave
- Severity
- Critical
- Impact
- Payments and customer data
- Checked live by LeakWatch
- No
What a Flutterwave Secret Key looks like
The rule matches Flutterwave keys in their test form, which begin with FLWSECK_TEST-. Two forms are covered by the same pattern. The shorter form is the encryption key: the prefix followed by 12 letters or digits from the hexadecimal set. The longer form is the secret key itself: the same 12 characters, then 20 more, then a -X suffix. Masked, they look like this:
FLWSECK_TEST-…XXXX Flutterwave encryption key, short form (masked)
FLWSECK_TEST-…XXXX-X Flutterwave secret key, long form (masked)
The rule only matches the test-mode prefix. A live-mode key with a different prefix is not reported by this rule, so if you hold live keys, search for them separately as well. The rule’s severity is critical even for test keys, because the secret key signs payment API calls and its exposure gives access to transactions and refunds.
How Flutterwave secret keys get leaked
- Server code with keys inline. A payment handler or a webhook processor that calls the API with the key typed into the source file.
- Front-end builds. A web or mobile app that puts the secret key into its build configuration, so every visitor receives it. Only the public key belongs in the front end.
- Environment files. A
.envfile or a Docker Compose file committed withFLW_SECRET_KEYor a similar variable set to the real value. - Sample code. A tutorial project or a starter kit that was edited to use a real key and then published.
- Logs and tickets. A request dump or a support thread that shows the authorization header with the key in it.
What to do in the first hour
- Generate new keys. Sign in to the Flutterwave dashboard, open Settings, then the API keys section under Developers. Use the option to generate new keys. Flutterwave’s documentation says this replaces the existing keys. Save the new secret key at once, because it is shown only once.
- Update your servers with the new key in your secret manager or environment variables. Restart the services that use it, then run a test payment in test mode to confirm the new key works.
- Check that the old key is gone. Requests with the old value should now fail. Confirm this from your own logs, not only from the dashboard.
- Review transactions. Look at the charges, transfers and refunds since the exposure. Pay most attention to refunds, transfers to unfamiliar bank accounts and any payment links you did not create.
- Check webhooks. Make sure your webhook endpoints point to your own servers, and that the verification secret is still the one you expect.
- Check team access. Review the dashboard users who can see or manage API keys, and remove anyone who should not have access.
- Clean the repository. Remove the value from the code and rewrite history if needed. See I accidentally pushed an API key to GitHub, and use deep scanning of your whole git history to find older copies.
Not sure what else leaked? Run a free scan.
Revoke it at Flutterwave
Keys are managed in the dashboard. Open the API keys page under Settings, and use the option to generate new keys, which invalidates the existing set. Some regions and product versions describe an expiry period for the old keys instead, so read the wording on the page before you confirm. Whichever path the page offers, make sure your replacement is already deployed, because the old key will stop working.
How LeakWatch detects it
The rule is called Flutterwave Secret/Enc Key. It looks for a word boundary, then the literal test prefix FLWSECK_TEST-, then 12 characters from the set of letters a to h and digits, both upper and lower case. An optional tail of 20 more characters from the same set and the suffix -X makes it the long secret form. Lower-case prefixes and values with other letters are not reported. The severity is critical, with the impact class payment data. This type is not checked live: LeakWatch does not send any request to Flutterwave with the key it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone refund customers with this key?
Yes, if the key’s account can issue refunds. An attacker who holds the secret key can also read customer and transaction details. Look at refunds first, then transfers, because those are where money leaves the account.
Is the test key still a problem?
It can be. Test keys are not real money, but they are still secret credentials for your account, and they tell an attacker how your integration is built. Rotate the test key too if it was exposed next to a live one.
Do I need to change my public key?
No. The public key is meant for front-end code and is not a secret. Only the secret key and any encryption key that came with it need rotating.