The Coding Test That Was a Payload: Attacking Developers Through Trust
This piece is my read on research published by David Dodda. The findings are theirs; the argument about what they mean is mine. Their original write-up is worth reading in full.
I am reading David Dodda’s story about how he was almost caught out by a fake job interview – and it is precisely the example of what makes the period we are living in so dangerous for developers.
An experienced guy, eight years in the field, received a “legitimate” approach on LinkedIn. A real profile, a real company, a website, a logo, even posts about blockchain innovation. Everything looked perfect.
He gets a short “coding test” on Bitbucket, sees clean code, tidy documentation, and it all looks like another ordinary technical exercise.
And then, thirty seconds before running the application, he decides to ask his AI to check whether there is anything suspicious in the code. The bot finds, inside one small controller, a fragment of obfuscated code that downloads a payload remotely and runs it with full server privileges.
In plain terms: code that would have stolen his entire digital life. Wallets, files, passwords, clients. And the best part? The server serving the payload disappeared after 24 hours. Knock knock – evidence? None.
Why this matters
Because this is an attacker who understands people, not just code. They build legitimacy: real profiles, a real company website, even a Calendly to schedule a call. They create a sense of urgency – “do the task before the meeting” – and construct a perfect story that makes you drop your defences at exactly the moment you must not.
And that is what is frightening. There was no sophisticated exploit here. No buffer overflow, no sandbox escape. This was a social engineering attack against developers, with code as the vector.
And no, it is not an isolated case. We are seeing more and more attacks that exploit developers’ trust:
- npm packages impersonating well-known libraries
- fake repositories on GitHub
- coding tests with a hidden payload
- VS Code extensions carrying malicious code
They have worked out that we, the developers, have become the most worthwhile target. We do not just hold data – we write the code that runs it.
One iron rule
Never run code you did not write yourself outside a clean, isolated environment. A VM, Docker, a container – it does not matter which, as long as it is not your personal machine. And if you use AI, use it properly: ask it to check suspicious code before you run it, exactly as David did.
This story ended well, but only thanks to healthy suspicion and one moment of pausing. So this post is not only a warning – it is a call to rethink the trust model of the development community.
We are used to downloading, running, checking quickly. But today, every npm install, every “technical test” and every small clone can be a back door.
I first shared a version of this as a LinkedIn post on 2025-10-30. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula
