CVE-2026-16504: Zulip VPS Template Auth Bypass Flaw

CVE-2026-16504 Overview

CVE-2026-16504 affects the VPS.org one-click Zulip deployment template. The template provisions Zulip instances using a hardcoded application signing key, a default database password of zulip, and DISABLE_HTTPS=True. Every deployment inherits identical secrets, so any attacker who obtains the key material can forge session tokens, decrypt traffic, or access the database on any instance built from the template. The vulnerability maps to CWE-321: Use of Hard-coded Cryptographic Key. The issue is tracked by CERT/CC in VU#243636.

Critical Impact
Attackers can forge authenticated sessions and access sensitive Zulip data on any instance deployed with the VPS.org one-click template.

Affected Products

VPS.org one-click Zulip deployment template
Zulip instances provisioned from that template retaining default settings
Downstream forks that reuse the same signing key or database password

Discovery Timeline

2026-07-31 - CVE-2026-16504 published to NVD
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-16504

Vulnerability Analysis

The VPS.org one-click Zulip image bakes secrets into the base template rather than generating them at first boot. Each new deployment reuses the same Django application signing key, so session cookies and password reset tokens produced on one server validate on any other server built from the same template. The database role uses the literal password zulip, which grants full read and write access to Postgres if the port is reachable. The template also sets DISABLE_HTTPS=True, causing the server to accept plaintext HTTP and to send authentication cookies without the Secure flag. An on-path attacker can intercept credentials, and a remote attacker can replay forged tokens without ever touching the network segment.

Root Cause

The root cause is static provisioning. Secrets that must be unique per deployment (SECRET_KEY, zulip_org_key, database passwords) are shipped inside the image instead of being regenerated by a first-run script. The DISABLE_HTTPS=True default compounds the problem by removing transport protections that would otherwise limit exposure of the reused key material.

Attack Vector

An unauthenticated remote attacker retrieves the template, extracts the embedded signing key, and crafts a valid Zulip session cookie or CSRF token for any deployed instance. The attacker connects over HTTP because the template disables TLS, submits the forged cookie, and authenticates as an arbitrary user. If Postgres is exposed, the attacker connects with user zulip and password zulip to read message history and user records directly. See the CERT/CC advisory for the vendor coordination record.

Detection Methods for CVE-2026-16504

Indicators of Compromise

Postgres authentication events for user zulip from external IP addresses
Zulip web sessions originating from IPs that never completed a login flow
Inbound HTTP traffic on port 80 to a Zulip host with no redirect to HTTPS
Unexpected API tokens or bot accounts created outside change windows

Detection Strategies

Compare the deployed SECRET_KEY and zulip_org_key values against the known template defaults and alert on matches
Inspect /etc/zulip/settings.py and /etc/zulip/zulip-secrets.conf for the string DISABLE_HTTPS = True
Query Postgres pg_shadow or role configuration for accounts using the password zulip

Monitoring Recommendations

Forward Zulip application logs and nginx access logs to a central SIEM and alert on plaintext HTTP logins
Monitor for outbound connections from the Zulip host to unexpected destinations, which may indicate data exfiltration
Track privilege changes and new administrator accounts inside the Zulip realm

How to Mitigate CVE-2026-16504

Immediate Actions Required

Rotate SECRET_KEY, zulip_org_key, and any per-realm API keys on every instance built from the VPS.org template
Reset the Postgres zulip role to a strong, unique password and restrict pg_hba.conf to localhost
Set DISABLE_HTTPS=False, install a valid TLS certificate, and force HTTP-to-HTTPS redirects
Invalidate all active sessions and require users to re-authenticate

Patch Information

No vendor patch reference is listed in the NVD entry at the time of publication. Follow guidance in the CERT/CC advisory VU#243636 and monitor VPS.org and Zulip project channels for an updated template that generates secrets at first boot.

Workarounds

Rebuild affected instances from the official Zulip installer instead of the VPS.org one-click template
Place the Zulip host behind a reverse proxy that enforces TLS and blocks direct access to port 80 and Postgres
Restrict management interfaces to a VPN or bastion host until secrets have been rotated

bash

# Regenerate Zulip secrets and disable plaintext HTTP
sudo /home/zulip/deployments/current/scripts/setup/generate_secrets.py --production
sudo sed -i 's/DISABLE_HTTPS = True/DISABLE_HTTPS = False/' /etc/zulip/settings.py
sudo -u postgres psql -c "ALTER USER zulip WITH PASSWORD '$(openssl rand -base64 32)';"
sudo systemctl restart memcached postgresql supervisor