If you stood up a Supabase or Zulip server using one of VPS.org's one-click deployment templates, there is a good chance your database is listening to the whole internet and will accept the password postgres. The CERT Coordination Center published the details on July 31 in vulnerability note VU#243636, and it comes with an unusually blunt caveat: there is no patch, and CERT/CC says it could not reach VPS.org to coordinate a fix.
What's affected
Two templates carry their own CVE. CVE-2026-16503 covers the Supabase template and CVE-2026-16504 covers the Zulip one. The important distinction, and one worth stating plainly, is that these are flaws in the deployment templates the hosting provider ships, not defects in Supabase or Zulip themselves. The upstream software is fine. What is broken is the packaging that decides how it gets configured the moment you click deploy.
CERT/CC rates the technical impact of both as Total, its top rating, meaning an attacker gains complete control of the affected system or full disclosure of everything on it.
How the attack works
The Supabase template stands up PostgreSQL bound to every network interface (0.0.0.0:5432) with the hard-coded database password postgres. A remote attacker who can reach that port simply connects and authenticates as the postgres superuser, which means reading and exfiltrating data, altering or deleting it, changing the database schema, or taking the instance down.
The detail that makes this worse than a routine default-password advisory is the firewall behaviour. Docker manages its own iptables rules, so the published port can bypass a standard host UFW configuration. An operator who set up UFW, checked it, and reasonably believes port 5432 is closed may still be answering the internet. That is the part worth acting on even if you are confident in your firewall, because confidence is exactly what the bug defeats.
The Zulip template is a different shape of the same problem. It ships with the hard-coded application signing key secret_key: changeme, a default database password of zulip, and DISABLE_HTTPS=True. Because the signing key is public, an attacker can forge or validate signed session material and bypass authentication outright, while the disabled HTTPS leaves credentials readable in transit.
Why this one spreads quietly
When the vulnerable artifact is a deployment template rather than a running binary, every instance ever created from it is already live and already configured this way. There is no update to wait for and no version number to check, and an operator who deployed months ago has no signal that anything changed. Internet-facing Postgres with a known default is precisely the sort of thing mass scanning finds within hours; we recently covered a botnet that hunts exposed servers to harvest cloud credentials, and the pattern of software shipping insecure out of the box turned up again this week in fuel terminal controllers with an open root debug port.
What you should do
With no vendor fix available, the burden sits entirely with operators. CERT/CC's guidance is to change every default password and secret key before a deployment goes near production, restrict access with firewall rules and network segmentation, and enable HTTPS where it is switched off. Given the Docker and UFW interaction, verify exposure from outside the host rather than trusting the firewall configuration: check what port 5432 actually answers to from an external address, rotate the Postgres password and the Zulip signing key, and treat any instance that has been internet-reachable with the stock credentials as potentially accessed rather than merely at risk.
The issues were reported by Simon Gajdosik and published through CERT/CC's coordinated disclosure process. VPS.org's status in the note remains Unknown.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.