The Perils of test.php: How a Simple File Led to a Spam Nightmare

The Perils of test.php

In the world of web development, we've all deployed throwaway files for debugging—often with innocent names like test.php. But sometimes, these small conveniences can snowball into major security breaches.

One such case involved a test.php file containing a single, seemingly harmless line of code:

<?php phpinfo(); ?>

What’s the Harm in phpinfo()?
At first glance, phpinfo() is a useful tool. It provides detailed information about your PHP configuration, environment variables, installed modules, and more. But that’s also exactly why it’s dangerous.

When test.php was deployed and left publicly accessible, it revealed sensitive environment variables to anyone who visited the URL. Among those were AWS SES credentials—tokens that granted programmatic access to Amazon’s Simple Email Service.

The Consequence? Weaponized Infrastructure
An attacker discovered the file, harvested the credentials, and used them to integrate AWS SES into a mailer service. From there, they sent out a tidal wave of spam emails—all under the banner of the legitimate SES account. That not only led to a compromised sender reputation, but could have triggered account suspension, blacklisting, or even regulatory action depending on the volume and content of those messages.

Key Takeaways for Developers and Ops Teams:

  • Never expose phpinfo() or debugging tools in production. Use secure environments and authentication barriers for diagnostics.
  • Audit all public files before deployment. Even a single overlooked file can undo years of careful engineering.
  • Use scoped IAM roles and do not store credentials in environment variables that are accessible by the web server.
  • Set up alerts and rotate credentials regularly—a single leak shouldn’t mean total compromise.

🕵️ Other Files Scammers Commonly Hunt For

Bad actors often use automated scanners to sweep the internet for exposed files that can leak credentials, configurations, or system insights:

File/Endpoint

Risk Description

/phpinfo.php or /info.php

Same as test.php, exposes server configs and env variables

.env

Contains environment variables like database credentials, API keys

.git/config or .git/HEAD

Exposes Git repo internals, possibly allowing full source code download

config.php, db.php

Often contain DB login credentials hardcoded for convenience

backup.zip, site.tar.gz, db.sql

Accidental backups of full systems or databases

composer.json / composer.lock

Can reveal package dependencies with known vulnerabilities

/admin/ directories

Common brute-force targets for admin panel access

.DS_Store, Thumbs.db

Leak directory structure and sometimes sensitive filenames

/server-status (Apache)

Provides live metrics about server load and connections (if enabled)

Some scanners even look for misconfigured CI/CD pipelines, logs, or temporary test scripts named debug.php, temp.php, or sandbox.php.

Debugging should never come at the expense of security. In this case, one line of PHP script created a gateway for exploitation. The next time you’re tempted to drop a test.php onto the server for a quick check—pause and think of the spam tsunami that might be lurking behind it.

Daniel Mitchell

Daniel Mitchell