I wanted to share a cautionary story about Amazon SES sandbox restrictions and the security mistake that led to abuse of my account.
I run a few WordPress sites and also use SES in my home lab through an internal relay. I've worked with enterprise SES deployments before, but while migrating several sites to ECS, I copied the existing directories—including backup configuration files containing AWS access keys. One backup file had an .old extension, which meant it bypassed PHP processing and could be downloaded publicly. An attacker found it and obtained a key.
At first, I assumed a flood of mailer-daemon messages and automatic replies was just backscatter. The next day, I checked the account and discovered that more than 10,000 emails had been sent in 24 hours. CloudTrail showed the activity came from one access key associated with a WordPress site. I immediately deactivated the keys and investigated the incident.
The key was restricted to SES, which limited the potential damage, but its permissions were still broader than they should have been. I had tried to use an IAM role, but I couldn't find a WordPress plugin that supported the role available through ECS or EC2. I've since changed plugins and built a more secure setup using Secrets Manager, ECS environment variables, scheduled key rotation, and alerts for unexpected sending volume. I'm also rotating other sensitive credentials and considering automatic kill switches for quota spikes.
This incident cost me time rather than money, but it reminded me why SES production access is tightly controlled. Even people who understand email security can make one poor deployment decision. If you're requesting production access, make sure your account details and sending practices are clearly documented, and have bounce handling, least-privilege permissions, monitoring, credential rotation, and threshold alerts in place before sending at scale.
4 Answers
The leaked backup configuration file was the real root cause. A file containing credentials should never be left in a web-accessible directory, regardless of its extension. Use Secrets Manager or another secret store, keep credentials out of copied site directories, and audit the container image and deployment artifacts for old configuration files. The access policy should also allow only the exact SES actions and resources the site needs.
The useful lesson here is to monitor sending behavior instead of relying only on service limits. Set CloudWatch alarms or application-level limits for volume, watch CloudTrail for unfamiliar activity, rotate credentials regularly, and have an automated response that disables sending when usage exceeds the expected range. Attackers checking the remaining quota is a good reminder that staying below a hard limit does not make the traffic legitimate.
For ECS workloads, an IAM task role is preferable to embedding long-lived access keys in WordPress. If the application or plugin cannot use the task role, that is a reason to replace or modify the integration—not to leave permanent credentials in the application. Also scan every backup, temporary, and renamed file before exposing a directory through a web server.
That was my conclusion too. I initially struggled to find a compatible plugin, but I’ve moved away from the one that required excessive permissions and am treating role support as a requirement.
SES production approval is usually easier when the account information is complete and the request explains exactly what mail will be sent, expected volumes, bounce handling, and abuse controls. Production access is restricted because a compromised credential can damage both the account owner and the reputation of shared sending infrastructure. A transactional email provider may also be a simpler choice for a small site.
Agreed. I’ve changed plugins and rebuilt the deployment so secrets come from a managed store instead of sitting in the site files. The migration shortcut is what created the exposure.