CVE-2010-20103: Critical Backdoor in ProFTPD 1.3.3c Tarball

CVE-2010-20103 is a critical (CVSS 9.8) backdoor in the official ProFTPD 1.3.3c source tarball that was distributed between 28 November and 2 December 2010. A hidden FTP command lets an unauthenticated remote user run shell commands as root. Replace any server built from that tarball with a clean, signature-verified ProFTPD release.

What's affected

The record lists the product as ProFTPD and scopes the problem to one artifact, not to the whole 1.3.3c line: the official 1.3.3c source tarball distributed between 28 November and 2 December 2010. Anyone who compiled ProFTPD from that tarball in that window is in scope. Packages from a distribution, and tarballs downloaded outside the window, are not described by the record as affected.

The record does not name a fixed version. It is a tampered download rather than a coding bug, so the remedy is to rebuild from a clean source release and verify it. The project home page currently lists maintenance and candidate releases along with SHA256 and PGP signatures. Check the project's own notices for the exact guidance on the 2010 incident.

A few details help scope the problem. The tampering happened at distribution, so two machines with the same version string can differ. A host that built from the compromised tarball carries the backdoor in its compiled binary, and a later upgrade of the same package on the same machine replaces it only if the build is redone. Teams that cache source archives in an internal mirror should check the mirror too, since a poisoned archive keeps being served long after the public site is cleaned up.

The record is dated 2025 but describes a 2010 event. That gap is normal for this kind of entry. The CVE was assigned long after the incident, and an old FTP server that nobody has rebuilt since is exactly the kind of system that still carries it.

How to check if you're exposed

You cannot tell from the version string alone, because a clean and a tampered 1.3.3c report the same version. Work from provenance instead.

Find out how each ProFTPD binary was built:

proftpd -v
which proftpd

Then look at your build records. If you compiled from a tarball, find the tarball or the build log and compare its checksum with the checksums the project publishes. If you cannot show where the source came from, treat the binary as untrusted.

If ProFTPD came from an operating system package, check the package's source and changelog with your distribution's tools rather than assuming either way.

Also list every host that exposes FTP to find forgotten servers:

nmap -p 21 --open 10.0.0.0/24

Only scan networks you own or are authorised to test.

For a stronger answer, collect hashes. If you still hold the original tarball, compute its SHA256 and compare it with the checksum the project publishes for the release you believe you built:

sha256sum proftpd-1.3.3c.tar.gz

If the tarball is gone, use the build date. A build made during the 28 November to 2 December 2010 window from the official site is the case the record describes. A build outside that window, or from a distribution package, is not.

When in doubt, rebuilding from a verified release is cheaper than proving a negative.

What to do now

1. Inventory every ProFTPD server and record the version, the install method and the build date.
2. For any server built from a 1.3.3c tarball around late 2010, assume compromise is possible. Isolate it and plan a rebuild rather than an in-place patch.
3. Download a current release from the project site and verify it against the published SHA256 and PGP signatures before building.
4. Review the host for signs of unauthorised root activity. Because the backdoor runs commands as root, rotate credentials and keys that were stored on or reachable from the server.
5. Restrict FTP exposure to the networks that need it, and consider replacing plain FTP with an encrypted transfer option.
6. Keep a software inventory so the next tampered download is easy to trace. The free in-browser dependency scan covers dependency manifests, and the Gold directory shows what is known about a given component.

Why it matters

This is a supply chain compromise. The source code in the project's repository was not the problem. The tarball that people downloaded had extra code added. The record classifies it under CWE-912 (Hidden Functionality): functionality that is not documented or intended, here a trigger that gives remote root command execution without logging in.

The lesson outlives the date. A version number does not prove integrity, and an old build can sit unnoticed on a forgotten server. Checking hashes and signatures at download time, and keeping an inventory of what you built from where, are the controls that catch this class of problem. The record does not flag this as a CISA Known Exploited Vulnerability, and it contains no claim about exploitation in the wild.

Try it yourself

Knowing which components you run, and where they came from, is the first step. This demo walks through building that inventory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• ProFTPD project home page
• ProFTPD repository on GitHub
• Gold vulnerability page

Last reviewed: 19 October 2026.