Every developer who publishes somewhere depends on a few accounts: the game portals, the package registry, the add-on store, the code host, the payment provider. Losing one of them means losing the ability to ship, and in the worst case someone else ships in your name. That is why the most common scam aimed at developers is not an offer at all. It is a notice that looks like it comes from one of those platforms and asks you to act now. This part of our series shows what these notices look like, the cases we received, how to tell a real one from a fake one and what to do if you already clicked.
The first part of the series describes the fee-first partner offers and keeps the list of every scam message we received. This part is about the messages that want a login rather than a payment.
#What we received
The most direct case came as a public comment under one of our games on a game portal. An account named like platform staff wrote that our builds had been hidden by moderation and that we had to "complete creator verification" through a shortened link within 48 hours, quoting a ticket number that looked official. Real moderation never happens in public comments: platforms tell developers through the dashboard and through mail from their own domain. We did not open the link, removed the comment and reported the account from the dashboard.
By mail we received "action required: update business information to avoid disruption" in the name of a payment provider and "please review your account verification" in the name of a bank. The display names were right. The sender domains belonged to unrelated parties. Neither mail would have survived a look at the headers.
The useful counterexample was a data breach notice from an invoicing service we really use. It looked alarming, so we checked it with the same routine: SPF, DKIM and DMARC passed for the service's own domain, the mail contained no login link and it told us to type the address ourselves. The breach had also been reported independently. It was genuine. The routine does not treat everything as a scam; it tells the two apart.
#The patterns aimed at developers
Package registries and add-on stores
Registries are a prize because one stolen account can push a malicious version to everyone who depends on it. In July 2025 PyPI warned about mail from a domain that differed from the real one by one letter, with the subject "[PyPI] Email verification", which led to a copy of the login page. In August 2025 Mozilla warned add-on developers about mail saying their account "requires an update to continue accessing developer features". Mozilla's advice is a good general rule: genuine mail comes only from the company's own domains, it passes SPF, DKIM and DMARC, and you go to the site directly instead of following the link.
Code hosts and OAuth consent
The cleverest variant does not ask for a password at all. In March 2025 attackers opened fake "security alert" issues on nearly 12,000 GitHub repositories, so GitHub's own notification mail delivered them. The link led to a real GitHub authorisation page for an app called "gitsecurityapp" that asked for full access to repositories, workflows and the right to delete repositories. Approving it hands over a token without any password being typed. No platform asks you to authorise a third-party app to secure your account.
Copyright and policy notices
"We received a DMCA notice regarding your account", "your listing may violate community standards", "respond within 24 hours". Malwarebytes described one such campaign in November 2025 that led to a fake login page. A real notice under the US copyright law has six elements, set out in 17 U.S.C. 512(c)(3): a signature, the work claimed to be infringed, the material and where it is, contact details of the complainant, a good-faith statement and a statement, under penalty of perjury, that the complainant is authorised to act. A mail that has a button instead of those elements is not a notice. Platforms also show their actions in the dashboard.
Payment providers
"Payment on hold", "verify your identity", "your payouts are suspended". Payoneer states on its phishing page that it never asks for card numbers or passwords by mail or text, and the same is true of every serious payment provider. These mails often come with an attachment, which is a second reason not to open them.
#How to verify a notice
- Open the original message and read the authentication results. The
Authentication-Resultsheader shows whether SPF, DKIM and DMARC passed, and for which domain. The domain must be the platform's own. - Compare the domain character by character. One letter, a hyphen, an extra word such as "support" or "verify", or a different ending is enough to make it someone else's.
- Open the platform yourself. Type the address or use a bookmark, sign in and look at the dashboard, the notifications and the account's security page. A real problem is there.
- Read the permissions on any authorisation page. If a "security" step asks you to grant repository, workflow or delete rights to an app, close it.
- Look at where a link points without opening it. Hover over it or copy it as text. A shortener hides the destination by design.
From: "Add-ons Team" <noreply@addons-support.example>
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=addons-support.example;
dkim=pass header.d=addons-support.example;
dmarc=pass header.from=addons-support.exampleEverything passes in the example above, and it is still a fake: the domain is not the platform's. Authentication proves where a mail came from, not who is behind it.
#If you already clicked
- Change the password of that account from the real site and sign out every other session.
- Revoke unknown OAuth apps and personal access tokens, and create new tokens where you need them.
- Check the security history, recently published versions, new workflows in your repositories and new gists.
- If you entered card details, call the bank and block the card.
- Tell the platform through its official support or report form, and keep the message for them.
Passkeys and hardware keys help a great deal here, because they only work on the real domain: a copy of the login page cannot use them. We describe the full routine, including filters, in the last part of the series. For the website side of the same problem, our article on web application security basics is a good companion.
#Checklist
- Does the mail or comment ask me to act through its own link?
- Is there a deadline of 24 or 48 hours?
- Is the sender domain exactly the platform's own, with SPF, DKIM and DMARC passing for it?
- Do I see the same notice in the dashboard when I open the site myself?
- Does an authorisation page ask for more rights than the task needs?
- Does a copyright notice contain the six elements the law requires?
#Frequently asked questions
Can a scam come through the platform's own notification mail?
Yes. If someone opens an issue, comments or sends a message on the platform, its genuine notification mail will deliver the text. The mail is real; the content is not from the platform. Judge the link and the request, not the envelope.
What should I do with a fake comment under my game or project?
Do not open the link. Remove or hide the comment if you can, report the account through the platform's report function and, if the platform has a support contact, tell them about the impersonation.
Is a DMCA notice without a dashboard entry always fake?
Not always: some notices are sent straight to the developer. A real one still names the work, the material and a reachable complainant, and contains the required statements. It never needs your password.
Comments
Comments
No comments yet. Ask a question or share what worked for you.
Leave a comment