Manipulating Email Trust: Invoice Import to GitHub and Slack Takeover

Some accounting platforms let you add expenses by email: you forward a receipt to an address like receipts@redacted.com, and the platform turns the email's HTML into a PDF and files it in your portal. To make that work, you first register a source email so the platform knows which incoming mail is yours. That one trust decision - who owns an incoming email - is where the whole thing comes apart.

The feature

On the target (call it redacted.com) the flow was:

1. Set a source email on your account, e.g. user@deepstrike.io.
2. Forward a receipt from that address to receipts@redacted.com.
3. The platform converts the email to a PDF and stores it in your portal.

The key detail: the platform decides which user an incoming email belongs to by matching the sender against each user's configured source email.

Taking over GitHub

The shared address receipts@redacted.com is a real, deliverable mailbox, so we pointed it at account signups instead of invoices.

• GitHub sends its verification codes from a fixed address, noreply@github.com.
• In our portal, we set our source email to noreply@github.com.
• We started a GitHub signup using receipts@redacted.com as the email.
• GitHub emailed the code to receipts@redacted.com, from noreply@github.com.
• The platform matched that sender to our source, converted the email to a PDF, and dropped it into our portal.
• We read the code from the PDF and finished the signup.

That handed us a GitHub account on the company's email, and with it, access to their workspace.

When the sender is random: Slack via Apple

GitHub was easy because its sender never changes. Slack is harder: it sends from no-reply-{random}@slack.com, so there is no fixed address to preset. We bridged through Apple's OAuth instead.

• Set the portal source email to appleid@id.apple.com.
• Create an Apple ID using receipts@redacted.com. Apple's confirmation lands in our portal, so we grab the code and finish the Apple account.
• Go to Slack and choose Sign up with Apple. OAuth asks Apple to vouch for the email - there is no email round-trip.
• Slack trusts Apple's assertion and lets us in.

The random-sender defense stopped mattering the moment a provider we could verify (Apple) would vouch for the address.

The single-source variant

Some platforms only accept mail from the exact address you signed up with. There you would need to register the account with noreply@github.com itself, and the whole thing hinges on whether the platform enforces email confirmation. Several did not, underestimating how much that one check is worth.

Fixing it

The clean fix is to stop sharing the corporate domain with these machine mailboxes. Give the feature its own domain or subdomain - receipts@redacted.co or receipts@mail.redacted.com - so an intercepted email can never masquerade as a login for the primary domain.

Finding more of these

We looked for the pattern: addresses like receipts@ and expenses@, plus docs or forum posts describing "forward your receipt to...". Search dorks around those phrases surfaced new targets, including lifestyle and productivity apps that ask you to forward mail to save@... style addresses.

By the numbers

Across 75+ platforms with email-based import:

• 25 were exploitable.
• 22 had basic protections (like 2FA) but still had gaps reachable with more work.
• 33 were solid - some used AI to pull invoice data without storing the email at all; others isolated the feature on a separate domain.

The through-line: an email address is not an identity. Any system that treats "who sent this" or "who can receive this" as proof of ownership can be bridged - directly, like GitHub, or through a provider that will vouch for it, like Apple.