Haveno Security Review: Proposed Installer and Monitoring Fixes

Haveno developers are reviewing how installers check download signatures and how a server script configures Java monitoring. The first concerns installation scripts for Tails and Whonix/Qubes. The second concerns a script used to configure monitoring on server deployments.

Both pull requests remained open when checked on November 9, 2026 UTC. Their descriptions credit a penetration test by turingpoint, reported by Jan Kahmen. The reports describe weaknesses found during testing, without evidence of a compromise of traders or theft of funds. Installer proposal #2841 and monitoring proposal #2842.

Status of the two proposals

Change	Scope	Verified status
PR #2841	Bind download verification to the expected signing key	Open, not merged, requested maintainer review still pending
PR #2842	Restore loopback binding when configuring Java monitoring	Open, not merged, requested maintainer review still pending

GitHub reported seven successful checks on each reviewed head commit, covering platform builds and code analysis. No reviewer had submitted a review, and the CI results do not establish independent reproduction of the security tests. The first check run and second check run belong to these proposals, not a released fix.

The latest upstream release listed during review was Haveno v1.12.0, published October 29. Its affected scripts still contain the old logic. We could not verify a stable upstream release containing these corrections. Independent trading networks distribute their own builds, so an upstream version number alone does not establish the state of every network's installer.

Installer verification: the right key must sign the file

A digital signature establishes that a file matches a signature made with a private key. You also need to establish that the corresponding public key belongs to the publisher you intended to trust. Merely possessing that publisher's key does not make another key's signature acceptable. Our PGP signature guide explains the two checks.

The affected scripts import a key, look for the expected fingerprint among the available keys, and run GnuPG to verify the download. In the v1.12.0 Tails installer, those checks are separate. Finding the expected fingerprint establishes that the key is present. The later verification can succeed with a different key in the same keyring.

An attacker would need both the expected key and an extra key in the verification keyring. They would also need to substitute a download and a valid signature from that extra key. A signature from a random unknown key is not enough. The normal full-fingerprint lookup leaves only the expected key in the ring, according to the author. How an outside attacker could introduce the extra key and substitute the download depends on the installation environment.

Binding the signature to the expected key

The installer diff keeps GnuPG's signature verification and adds a comparison against its machine-readable VALIDSIG result. The comparison uses the primary key fingerprint, including when a signing subkey made the signature. That prevents a legitimate publisher's signing subkey from failing merely because its own fingerprint differs from the primary key's. GnuPG documents these fields in its status-message specification.

The patch applies this binding to both installation paths and makes the Whonix script's verification result visible. The author reports testing an isolated keyring containing an expected key and another key, with the latter signing the file. The old check accepted it and the patched check rejected it. Reported controls accepted the expected primary-key and subkey signatures. We inspected the code and reported results, but did not run the installers or reproduce that keyring experiment.

Monitoring: a local setting did not keep the remote port local

Java Management Extensions, or JMX, lets tools inspect and manage a running Java application. A monitoring agent may use it for process metrics. Its security settings matter because the interface exposes management operations as well as observations. Oracle's JMX documentation describes authentication, transport security, and the distinction between local and remote management.

The v1.12.0 monitoring installer removes existing JMX flags from environment files, then writes a replacement set. The replacement omits the loopback binding while retaining port 6969 and disabling authentication and TLS. A remaining setting named jmxremote.local.only applies to the local connector. It does not restrict the remote connector created by the port setting.

For this concern to apply, the script must have modified an environment file that a running service uses. An attacker must then be able to reach the resulting management listener. Firewall rules and network placement affect that reachability. Running an ordinary desktop trading client does not, by itself, establish those conditions.

Listener binding and the returned address

The monitoring diff restores jmxremote.host=127.0.0.1 and sets java.rmi.server.hostname=127.0.0.1. The first controls the relevant listener. The second controls the address returned to the management client through Java's remote invocation mechanism. Restoring only the listener binding can leave a local monitoring client trying to connect to a different address.

The author's test reports an unauthenticated connection through the host's non-loopback address with the original flags. With both changes, the local monitoring connection worked and that non-loopback connection failed. The report also describes a separate local connector that the patch leaves unchanged. Those are author-reported tests, not measurements of public Haveno servers or tests performed for this article.

What users and operators can check

For a download, use your trading network's official distribution instructions and independently confirm the expected signing fingerprint. Check which key signed the actual file. A successful signature check without that identity comparison does not answer whether the intended publisher signed it. Do not install a PR branch solely because its description discusses security.

For a server, establish whether the monitoring installer ran, which environment file the service reads, and what its current process listens on. A file change does not prove the running process adopted it. Restrict unnecessary management access, then verify that legitimate local monitoring still works. Do not assume a successful desktop update changes a server's monitoring configuration.

Haveno is upstream software used by independently operated networks. Our RetoSwap guide explains that distinction. The Whonix and wallet update guide also separates operating-system packages from separately installed applications.

What remains unverified

The reviewed PR descriptions and public discussion contain no reports of exploitation. The release notes do not document an incident either. Affected hosts could still exist. The exact population of affected installations, downstream adoption, and any private incident investigations remain unknown. The verified findings here are the code differences, current proposal status, and the tests their author reports.