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

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

## Summary

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.

## 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

- https://cwe.mitre.org/data/definitions/295.html
- https://owasp.org/Top10/A02_2021-Cryptographic_Failures/
- https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
- https://attack.mitre.org/techniques/T1557/
- https://attack.mitre.org/techniques/T1190/

---
Source: https://www.netzilo.com/threats/1panel-cert-bypass-rce