CVE-2026-71863: SecureDrop: Onion Service client auth credentials copied to Monitor Server

Published Nov 6, 2026
·
Updated

SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from, and communicate with anonymous sources. From 2.13.0 until 2.16.1, running the securedrop-admin install Ansible playbook with journalist alerts disabled leaves the journalist alert key filename empty, causing the copy task to transfer every file in ~/.config/securedrop-admin/, including Onion Service client authentication credentials, to the Monitor Server. An attacker must first compromise the privileged Monitor Server to obtain the credentials, and the credentials remain an additional protection layer rather than sufficient access by themselves because the Journalist Interface still requires a username, passphrase, and MFA, while SSH access still requires SSH keys. This issue is fixed in version 2.16.1.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade SecureDrop to a version that resolves this vulnerability.

    Fixed in 2.16.1

Event History

Nov 6, 2026
CVE Published
via MITRE·08:58 PM
Data Sourced
via MITRE·08:58 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are affected?

Deployments running SecureDrop versions 2.13.0 through 2.16.1 are affected if the securedrop-admin install Ansible playbook was run with journalist alerts disabled.

2

What would an attacker need to exploit the exposed credentials?

An attacker must first compromise the privileged Monitor Server to retrieve the copied Onion Service client authentication credentials. Those credentials alone do not grant access to the Journalist Interface or SSH: the Journalist Interface also requires a username, passphrase, and MFA, and SSH requires SSH keys.

3

What should teams do to remediate the issue?

Upgrade SecureDrop to version 2.16.1, which fixes the copy behavior. Because credentials may already have been transferred to the Monitor Server in affected installations, teams should treat that server as holding those credentials until they have assessed and addressed the exposure.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203