Leaked SMTP Credentials? Change Them Now

An SMTP login lets whoever holds it send email through a mail server or mail provider, as the account it belongs to. The messages leave from your real domain and pass the checks that recipients rely on, so phishing or spam sent this way looks genuine. It also damages the sending reputation that keeps your legitimate mail out of spam folders. This is one of the most serious leaks in the messaging category, because the credentials are often a plain username and password with no separate scope to limit them. Change the password first, then find out what was sent.

Check your GitHub account for leaked secrets — free

Provider: Other
Severity: Critical
Impact: SaaS account access and billing
Checked live by LeakWatch: No

What SMTP credentials look like

SMTP credentials come in two common forms. The first is a connection URL, written with a scheme that is smtp or smtps, optionally followed by +ssl or +tls as some mail libraries write it. The URL carries a username, a password, the host name of the mail server, and sometimes a port. The second form is a set of separate settings, such as a host variable, a port variable, and a user and password pair, which is what most frameworks use in their configuration files.

Only the URL form carries everything in one string, so it is the one that appears most often in a single leaked line. Whichever form you find, the username is usually an email address or a service account name, and the password is a random string that is generated by the provider or chosen by whoever set up the account. Nothing in the password’s shape tells you which provider issued it, so the context matters: the scheme, the host name and the name of the setting or library are the clues you need to find the owner.

How SMTP credentials get leaked

Mail helpers with the connection URL in them. A small utility that sends alerts or receipts, committed with the URL written directly into the code.
Framework mail configuration. Rails, Django, Laravel, PHPMailer and Node.js mail setups that hold the username and password in a committed file, instead of reading them from environment variables.
Environment and compose files. A .env file or a Docker Compose file that lists the mail settings next to other secrets, and was never excluded from version control.
Test fixtures and CI pipelines. A test that uses a real mail account, or a pipeline that prints its environment on failure and so shows the password in the build log.
Support tickets and screenshots. A configuration page captured with the password visible, or a stack trace from a mail error that includes the connection string.

What to do in the first hour

Identify the account. Work out which mail provider or mailbox the username belongs to. The host name in the leaked settings is the quickest clue, and the username often tells you the account. If you cannot tell, search your own accounts and your team’s password manager for that username.
Change the password or replace the SMTP key. Do this at the provider, following the steps in the revocation section below. Prepare the new value in your secret store before you change it, so that the application is not left without working credentials for longer than necessary.
Deploy the new credentials. Update the application, restart it, and send one test message to an address you control. Confirm that the message arrives and that its sender address and headers look right.
Check what was sent. Open the sent mail, activity or log view of the provider for the period since the exposure. Look for messages you did not write, unfamiliar recipients, a sudden jump in volume, and odd subject lines or links. If the provider shows bounce and spam complaint figures, check them too, because they rise quickly when someone abuses a sender.
Check forwarding rules and filters. If the account is a hosted mailbox, look for automatic forwarding, filters that hide replies, and sender addresses that you did not add. Attackers often set these up so that they can keep receiving messages after the password has changed.
Review other access to the same account. Look at app passwords, API keys and connected applications. Remove those that you cannot name an owner for, and rotate any other secret that was in the same file.
Clean the repository. Remove the value from the code and, if you want the old copy gone from history, rewrite it. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Revoke it at your SMTP provider

There is no single console for SMTP credentials, because the login belongs to whichever service issued it. It might be a transactional email provider, a hosted mailbox, or a mail server that your own team runs. Open that provider’s account and find its SMTP settings or application password section. Some providers have a separate SMTP key that you can delete and replace, and others let you change the account password, which also changes the password used for SMTP logins.

Be careful with the second case. Changing a mailbox password does not always end app-specific passwords or separate SMTP keys, which usually have to be deleted one by one. Check the list of those credentials after the main password change. If your own mail server holds the credentials, change the password in its user database and restart any service that caches the old value. The SMTP settings page of your provider is the place to start, and the provider’s own documentation is the reference for the exact menu names, which vary by service.

How LeakWatch detects it

The rule is called “SMTP Credentials”. It looks for the schemes smtp and smtps, with an optional +ssl or +tls suffix, in any letter case. After the scheme it expects a username made of letters, digits, dots, hyphens, underscores or percent signs, then a colon, then a password that runs up to the first at sign or whitespace, then an at sign and a host name. A host with no credentials is not reported, and neither is a username with no password. The rule matches only the URL form, so separate settings for a user and a password in environment variables are not detected. The severity is critical. This type is not checked live: LeakWatch does not try to log in to the mail server with the credentials it finds.

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 read my email with SMTP credentials?

Usually not. SMTP is for sending messages, so the credentials let someone send mail, not open a mailbox. Some providers accept the same password for IMAP or for the web interface, though, so check whether the same login works there, and change it everywhere it is used.

Is the password in the leaked text the real password?

Not necessarily. A password in a URL is often percent-encoded, so some characters appear as codes such as a percent sign followed by two digits. Take the value from your secret store or from the provider when you check the new setup, not from the leaked text.

Do I need to tell my recipients?

Tell them only if you can see messages sent from your domain that nobody on your team wrote. Phishing that uses your real sender address is the risk that matters most. A short notice with the sender address and a request to ignore unexpected messages from it is enough.