High

1Panel Core-Agent TLS Verification Bypass to Privileged Command API

This detects a two-part pattern seen when someone exploits a certificate verification weakness in 1Panel (versions 2.0.5 and earlier) between its Core and Agent components. It fires only when a client that has explicitly turned off TLS certificate checking also sends a command to one of 1Panel's high-privilege endpoints carrying an actual attack payload like a reverse shell or download-and-execute string.

How the attack works

1Panel's Core and Agent components are supposed to verify each other's TLS certificates, but versions up to 2.0.5 do this incompletely, letting a forged or substituted certificate sit unnoticed on that channel. The rule cannot see the TLS handshake itself, so it instead looks for two things that leave visible traces: first, a client explicitly disabling certificate checks (flags like curl -k, wget --no-check-certificate, or code setting InsecureSkipVerify/verify=False) while talking to a 1Panel Core or Agent address; second, a call to a privileged 1Panel API - command execution, terminal, cron jobs, container exec, or file exec/chmod - whose payload contains a concrete exploitation primitive such as a reverse shell, base64-decoded pipe to a shell, or an SSH key drop. Only when both halves appear together does the rule fire; either alone is too common to be meaningful. This combination is treated as the client-side signature of the same trust failure the underlying vulnerability describes.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
7c3f9a41-5e2b-4d18-9f6a-2b8c1d40e7a3
Severity
High

Why it matters

An attacker exploiting this can run arbitrary commands on the host through 1Panel's own management API, potentially gaining full control of the server 1Panel manages.

What you can do

  • →Upgrade 1Panel past version 2.0.5 and confirm Core-to-Agent TLS verification is enforced, not just enabled.
  • →Replace self-signed or bootstrap certificates on Core/Agent channels with properly validated ones, and avoid routine use of -k/--insecure flags against 1Panel endpoints even during setup.
  • →Restrict network access to 1Panel's command, terminal, cronjob, and file-exec APIs to trusted management networks only.
  • →Review any hits where a TLS-verification-disabled client also invoked these privileged endpoints with shell, download, or SSH-key-modifying payloads, since legitimate maintenance scripts can also match this pattern.

Known benign look-alikes

  • Ops/platform agents bootstrapping a self-hosted 1Panel install that still presents a self-signed Core/Agent certificate, using `curl -k https://host:9999/api/v1/...` during first-run setup. This is the single largest FP source and is exactly why the rule is report-only - it is also, genuinely, the insecure posture this CVE punishes.
  • Legitimate use of the 1Panel cronjob API to schedule a maintenance shell script that downloads an artefact (matches the endpoint plus a download primitive in the body).
  • Authorised penetration tests or internal vulnerability validation against a company 1Panel deployment.
  • Runbooks, IaC snippets or shell history pasted into agent context that contain `--insecure` examples for 1Panel administration.
  • Security tooling traffic (Sigma/nuclei rule bodies, advisory text, scanner output) that quotes these patterns verbatim - suppressed by filter_security_content and filter_advisory.
  • curl/wget man pages or `--help` output rendered into a tool result - suppressed by filter_helptext.

References