VPS.org One-Click Template: Public PostgreSQL Fixed Password and Zulip Session Forgery

1. Basic Information

• 
  Article Title: JVNVU#91736352 Multiple Vulnerabilities in VPS.org One-Click Deployment Templates


• 
  Published By: JVN


• 
  Publication Date: August 3, 2026 (CERT/CC primary info on July 31, 2026)


• 
  Severity: High


• 
  Original Source: https://jvn.jp/vu/JVNVU91736352/index.html
  


• 
  Primary Source: https://kb.cert.org/vuls/id/243636
  


• 
  Related Entities: VPS.org, Supabase template, Zulip template, PostgreSQL, CVE-2026-16503, CVE-2026-16504


• 
  Patch Status: No vendor contact was established, and no patches are available as of publication.

2. Executive Summary

One-click templates fail to generate deployment-specific secrets. They expose the Supabase database at 0.0.0.0:5432/postgres:postgres, and deploy Zulip with secret_key: changeme, a DB password of zulip, and plain HTTP. This allows remote takeover immediately after deployment.

3. Attack Flow

Supabase/PostgreSQL

1. A user deploys the VPS.org Supabase template using one-click deployment.


2. PostgreSQL binds to all interfaces (0.0.0.0:5432) and uses the hardcoded superuser password postgres.


3. Docker-specific iptables rules may bypass the host UFW settings and expose the service to the Internet.


4. An attacker scans port 5432 and authenticates using postgres/postgres.


5. The attacker performs data reading/exfiltration, modification/deletion, schema/role changes, establishes DB object persistence, or causes a Denial of Service (DoS) via a drop command.

Zulip

1. The template is deployed with secret_key: changeme, a DB password of zulip, and DISABLE_HTTPS=True.


2. An attacker forges and validates signed session material using the known secret, achieving authentication bypass and account/instance takeover.


3. The attacker connects to the database using the default password or intercepts credentials and sessions via plain HTTP paths.

4. Attacker Position and Execution Location

• Remote connection from the Internet to port 5432 or Zulip HTTP on the public VPS.


• Database commands run with PostgreSQL superuser privileges; session forgery runs within the Zulip application context.


• A network-path attacker can intercept HTTP credentials and sessions.

5. Victim and Administrator Perspective

• Users mistakenly believe the one-click deployment is complete and that unique secrets were generated.


• Even if UFW shows a deny rule in the cloud/firewall console, Docker NAT may still expose the port.


• Security Operations Centers (SOCs) may observe successful database logins following massive scans, unknown sessions, role/schema changes, and HTTP credential usage.

6. Success and Failure Conditions

Success Conditions

• Deployment uses a vulnerable template without changing default secrets/passwords.


• Port 5432 or Zulip HTTP is reachable from the Internet or the attacker's network.


• Operators do not understand the difference between Docker exposure and the host firewall.

Failure Conditions

• Changing all passwords and secret keys to random, unique values before deployment.


• Binding the database to localhost or a private interface, and restricting access using cloud firewalls, security groups, or network segmentation.


• Enforcing HTTPS, invalidating existing sessions, rotating secrets, and rebuilding without using templates.

7. What Happens on Success

• Reading/exfiltration, tampering, or deletion of all PostgreSQL data; role/schema changes; DB persistence; and DoS.


• Account/instance takeover via Zulip session forgery.


• Interception of credentials and sessions over HTTP.


• Due to the static template, the same credential attack can be repeated against other instances.

8. Observable Logs

• 
  Email: Zulip account notifications, unexpected password or session activity.


• 
  Proxy/SWG/DNS: Zulip HTTP access, unknown sources, credential transport without TLS. (The database may bypass the proxy.)


• 
  Endpoint/EDR: postgres, zulip, or changeme strings in Docker compose/env/config files, container processes/networks, and database child processes or extensions.


• 
  Identity/IdP: Missing MFA/login events due to forged sessions, unexpected account actions, and events around session key rotation.


• 
  SaaS/Cloud: VPS provisioning, template versions, security groups, flow logs, snapshots, and console access.


• 
  Network: Inbound traffic from the Internet to port 5432, Docker DNAT/iptables activity, PostgreSQL connections, unencrypted HTTP traffic, and large egress data volumes.

9. Attack Success Determination

• 
  Contact Only: Port scans, HTTP GET requests.


• 
  User Action: Deployment of a vulnerable template (no user action required during the attack).


• 
  Initial Execution: DB login with default credentials or acceptance of a forged Zulip session.


• 
  Malware or Successful Authentication: PostgreSQL superuser session or Zulip takeover.


• 
  Data Theft / Session Compromise: Query/data egress, forged sessions, HTTP interception.


• 
  Subsequent Compromise Confirmation: Role, schema, or DB object modifications; new accounts; data destruction or persistence.

10. Investigation Playbook

• 
  Trigger: Use of a VPS.org template, public port 5432, detection of default secrets, or sessions without login events.


• 
  Initial Verification: Preserve provisioning time/template, container configuration, actual listening ports/DNAT, cloud flow logs, and DB/Zulip logs.


• 
  Endpoint: Check compose/env files, Docker iptables, container images, DB extensions/objects/roles, and web configurations.


• 
  Authentication & Cloud: Rotate database, application, and admin passwords, secret keys, sessions, and API tokens. Invalidate all sessions.


• 
  Subsequent Operations: Investigate query history, dumps/archives, large data egress, schemas, roles, jobs, triggers, and credentials for other services.


• 
  Containment: Block public ports, stop containers, rebuild using clean templates, verify data integrity, and enforce HTTPS.


• 
  Judgment Categories: Vulnerable Deployment, Internet Exposure, Default Auth Success, Session Forgery, Data Access, Persistent DB Compromise.

11. Defense and Detection Ideas

• 
  Single Event: Successful connection to port 5432 from the Internet, postgres default password usage, secret_key: changeme, DISABLE_HTTPS=True.


• 
  Chronological Correlation: One-click deployment → Docker port publication → Scan → Superuser login → Dump/role/schema changes.


• 
  Hunting: Inventory VPS.org templates, check for public ports, scan for default secrets, check differences between UFW and Docker NAT, and identify instances with TLS disabled.


• 
  Log Gaps: Missing provisioning template versions, cloud flow logs, PostgreSQL audit logs, Zulip session audit logs, and container configuration history.


• 
  Priority Countermeasures: Automatic unique secret generation, private binding, cloud firewalls, Docker exposure testing, HTTPS enforcement, and post-deployment security gates.

12. Facts / Inference / Hypothesis

Facts

• The Supabase template uses 0.0.0.0:5432 and the postgres password, and Docker rules can bypass UFW.


• The Zulip template uses secret_key: changeme, a DB password of zulip, and DISABLE_HTTPS=True.


• CERT/CC evaluated the technical impact as high and noted that no patches are available because the vendor could not be reached.

Inference

• Instances created from templates are easily targeted for mass exploitation using identical credentials, and breaches can occur via scans immediately after deployment.


• Even if application secrets are rotated, the risk of re-entry remains unless existing sessions and database modifications are investigated.

Hypothesis

• If automated bots combine public instance searches with default credentials, they can compromise instances before the user's initial login.

13. MITRE ATT&CK Mapping

• 
  T1190 Exploit Public-Facing Application (Medium; primary cause is unsafe defaults)


• 
  T1078 Valid Accounts (High; default DB credentials)


• 
  T1539 Steal Web Session Cookie / T1550.004 Web Session Cookie (Medium; session forgery/interception)


• 
  T1213 Data from Information Repositories (High)


• 
  T1098 Account Manipulation (Medium)


• 
  T1505 Server Software Component (Medium; when using DB objects/extensions for persistence)


• 
  T1485 Data Destruction / T1499 DoS (Medium)

14. Unknowns and Additional Investigation

• The duration for which vulnerable templates were distributed and the total number of deployments.


• Whether current templates have received silent fixes.


• The existence of actual exploitation and victimized instances.


• The session format and required fields that can be forged using the secret key.


• Whether templates other than Supabase and Zulip share the same static secret root cause.

15. Impact on SOCs and General Organizations

Organizations that spin up test environments or small SaaS applications using affordable VPS and one-click templates face similar risks. CMDBs should record not only cloud accounts, but also templates, sources, generated secrets, and container published ports. Confirming that the host firewall is enabled is not enough to rule out Docker exposure; external reachability tests should be used as a deployment gate.

16. Summary by Target Audience

• 
  For SOCs: Hunt for template-deployed instances, public port 5432, default secrets, sessions without login events, and database changes.


• 
  For Administrators: Immediately block ports and rotate all secrets and sessions. Perform clean rebuilds and check data integrity.


• 
  For Users: One-click deployment does not mean secure settings are complete. Do not input data until you change default passwords and verify that HTTPS and private access are enabled.