1Panel versions 1.10.33 - 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the Change Username functionality available from the settings panel (/settings/panel). The endpoint does not implement CSRF protections such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a username-change request; when a victim visits the page while authenticated, the browser includes valid session cookies and the request succeeds. This allows an attacker to change the victim’s 1Panel username without consent. After the change, the victim is logged out and unable to log in with the previous username, resulting in account lockout and denial of service.

1Panel versions 1.10.33 through 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the panel name management functionality. The affected endpoint does not implement CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a panel-name change request; if a victim visits the page while authenticated, the browser includes valid session cookies and the request succeeds. This allows a remote attacker to change the victim’s panel name to an arbitrary value without consent.

1Panel versions 1.10.33 - 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the web port configuration functionality. The port-change endpoint lacks CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a port-change request; when a victim visits it while authenticated, the browser includes valid session cookies and the request succeeds. This allows an attacker to change the port on which the 1Panel web service listens, causing loss of access on the original port and resulting in service disruption or denial of service, and may unintentionally expose the service on an attacker-chosen port.

Summary The https cookie that comes with the panel does not have the Secure keyword, which may cause the cookie to be sent in plain text when accessing http accidentally.

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie#secure

PoC Directly configure https for the panel, and then capture the packet when logging in again and find that the cookie does not have the Secure keyword

Impact Everyone who has configured the panel https

Summary An OS command injection vulnerability exists in 1Panel firewall functionality. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

Details 1Panel firewall functionality /hosts/firewall/ip endpoint read user input without validation, the attacker extends the default functionality of the application, which execute system commands.

PoC the payload ; sleep 3 # will lead server response in 3 seconds !image

the payload ; sleep 6 # will lead server response in 6 seconds !image

Impact An attacker can execute arbitrary code on the target system, which can lead to a complete compromise of the system.

Patches

The vulnerability has been fixed in v1.4.3.

Workarounds

It is recommended to upgrade the version to v1.4.3.

References

If you have any questions or comments about this advisory:

Open an issue in https://github.com/1Panel-dev/1Panel Email us at wanghe@fit2cloud.com

1Panel is an open source Linux server operation and maintenance management panel. Prior to version 1.3.6, an authenticated attacker can craft a malicious payloads to achieve command injection when entering the container terminal. The vulnerability has been fixed in v1.3.6.

1Panel is an open source Linux server operation and maintenance management panel. Prior to version 1.3.6, an authenticated attacker can craft a malicious payload to achieve command injection when adding container repositories. The vulnerability has been fixed in v1.3.6.

1Panel is an open-source, web-based control panel for Linux server management. A stored Cross-Site Scripting (XSS) vulnerability exists in the 1Panel App Store when viewing application details. Malicious scripts can execute in the context of the user’s browser, potentially compromising session data or sensitive system interfaces. All versions of 1Panel up to and including v1.10.33-lts and v2.0.16 are affected. An attacker could publish a malicious application that, when loaded by users (locally or remotely), can execute arbitrary scripts. This may result in theft of user cookies, unauthorized access to system functions, or other actions that compromise the confidentiality, integrity, and availability of the system. The vulnerability is caused by insufficient sanitization of content rendered by the MdEditor component with the previewOnly attribute enabled. Specifically, the App Store renders application README content without proper XSS protection, allowing script execution during content rendering; and similar issues exist in system upgrade-related components, which can be fixed by implementing proper XSS sanitization in the MdEditor component. These vulnerabilities can be mitigated by applying proper XSS protection and sanitization when rendering content in the MdEditor component. Safe versions with a patch incorporated are v1.10.34-lts and v2.0.17.

Summary

A CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO).

Details

The /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body:

"ignoreCaptcha": true

The backend implementation uses this value to determine whether CAPTCHA validation should be performed:

if !req.IgnoreCaptcha { if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != "" { helper.BadAuth(c, errMsg, nil) return } }

Because req.IgnoreCaptcha is taken directly from user input—with no server-side validation, no session binding, and no privilege checks—any unauthenticated attacker can force CAPTCHA validation to be skipped.

There are no additional conditions, such as:

no requirement for MFA

no trusted device

no IP reputation checks

no prior valid session

no rate limiting

This results in CAPTCHA being entirely client-controlled, which violates fundamental authentication and anti-automation security assumptions.

Summary The server trusts all reverse-proxy headers by default, so any remote client can spoof X-Forwarded-For to bypass IP-based protections (AllowIPs, API IP whitelist, “localhost-only” checks). All IP-based access control becomes ineffective.

Details - Gin is created with defaults (gin.Default()), which sets TrustedProxies = 0.0.0.0/0 and uses X-Forwarded-For/X-Real-IP to compute ClientIP().

- IP-based controls rely on ClientIP(): - AllowIPs / BindDomain (core/middleware/iplimit.go, core/utils/security/security.go). - API IP whitelist (core/middleware/apiauth.go). - "localhost-only" checks that depend on ClientIP().

- Because no trusted-proxy range is enforced, any client can send X-Forwarded-For: 127.0.0.1 (or a whitelisted IP) and be treated as coming from that address.

Impact All IP-based access control is rendered ineffective: remote clients can masquerade as localhost or any whitelisted IP, defeating AllowIPs, API IP whitelists, and “localhost-only” protections.