THE RISK IN PLAIN SIGHT
A harmless spelling package—or a hidden backdoor?
In January 2026, security researchers identified two malicious Python packages on PyPI — spellcheckerpy and spellcheckpy — that pretended to be connected to the legitimate pyspellchecker project.
They looked credible enough to fool developers, but were designed to deliver a remote access trojan instead.
That may sound like a narrow developer problem. It isn’t.
Modern software teams increasingly rely on open-source packages they did not write, do not fully inspect and often install in seconds. One credible-looking package can become a direct route into systems, credentials and sensitive development environments.
WHAT HAPPENED
The package borrowed trust from a legitimate project.
The malicious packages copied a real identity, linked to the genuine repository and hid their payload where it was less likely to attract attention.
01
Looked authentic
The packages copied the legitimate author’s identity and linked to the real GitHub repository.
02
Hid the payload
Base64-encoded malicious logic was concealed inside a dictionary resource file.
03
Activated later
A later version added an obfuscated trigger which could execute when the spellchecker was used.
A developer thought they were installing a harmless spelling package.
What they may actually have installed was a hidden backdoor. The attack depended on getting someone to trust the wrong package name.
WHY THIS MATTERS
More than 1,000 downloads before removal.
The malware was not nuisance code. Aikido reported that it downloaded and launched a Python-based remote access trojan capable of fingerprinting the machine, contacting a command-and-control server every few seconds and executing attacker-supplied code remotely.
A small naming trick at the edge of the development process can become a much bigger business problem.
01
Developer workstation
Potential access to the machine where software is built.
02
Credentials and tokens
Potential exposure of valuable authentication data.
03
Code and pipelines
Potential compromise of internal code, environments or delivery pipelines.
04
The wider estate
Risk spreading from one mistaken installation into connected systems.
WHY THIS ATTACK DESERVES ATTENTION
Software risk is not always loud or obvious.
The payload was hidden in a place that looked legitimate for that kind of library: a language dictionary file. The attacker first published dormant versions containing the payload without activating it, and only later enabled execution in version 1.2.0.
Sometimes the danger is not a flashing alarm.
Sometimes it is a package that looks normal, behaves normally at first glance and only reveals its purpose later. That is why dependency risk is so difficult to manage by intuition alone.
THE BIGGER LEADERSHIP LESSON
Your business is exposed through the code your team imports, trusts and builds upon.
Many organisations understand “our application” but have far less visibility into the outside code entering their environment through normal development work.
01
Open-source packages
02
Indirect dependencies
03
Outdated components
04
Typosquatted packages
05
Install-time behaviour
06
Workstation exposure
If you cannot see what is flowing into your software estate, you cannot properly assess what you are trusting.
WHERE THE CODE REGISTRY FITS
Visibility must extend beyond the code you authored yourself.
Modern software is assembled from layers of internal code, open-source packages, frameworks, APIs and third-party components. If leadership understands only the top layer, it is making decisions with partial visibility. That is a governance problem.
EVIDENCE-BASED VISIBILITY
Know what is in your software—and
what you are trusting.
01
What exists
Understand the components and dependencies within the software estate.
02
Where it came from
Establish the provenance of the outside code the business relies on.
03
What risk it carries
See the risk sitting inside packages, frameworks and third-party components.
04
How to explain it
Communicate exposure clearly to technical and non-technical stakeholders.
TRUST IS NOT VERIFICATION
A package can look legitimate and still be malicious.
It can resemble a trusted name. It can even point to the real upstream project. That is why software trust now has to be backed by evidence.
Not paranoia. Not guesswork. Evidence.
For developers, that means better dependency controls and scrutiny. For leadership, it means recognising that software assurance now includes provenance, visibility and supply-chain awareness.
One wrong package name is sometimes all it takes to create a very real business risk.
Know Your Code.
Know What’s In It.
Know What You’re Trusting.
FROM COMPLEXITY TO CLARITY
Move from uncertainty to complete code confidence.
Get the independent intelligence you need to understand, verify and protect your software.
Book a demo