Default self-registration creates unauthorized accounts in fuomag9 Caddy Proxy Manager

Caddy Proxy Manager is a web interface for managing Caddy Server reverse proxies and certificates. Prior to 1.5.1, Caddy Proxy Manager enables email and password self-registration by default at /api/auth/sign-up/email, allowing an unauthenticated remote actor to create an active account with the user role without administrator approval. The user role cannot view or modify proxy data, so the direct impact is limited to unauthorized creation of low-privilege accounts. The fixed configuration in src/lib/config.ts and src/lib/auth-server.ts requires AUTH_ALLOW_SELF_REGISTRATION=true before the authentication library's disableSignUp control permits sign-up. This issue is fixed in version 1.5.1.

• The normalized record identifies caddy-proxy-manager from fuomag9 as affected for versions < 1.5.1. • The vendor advisory lists affected versions as < 1.5 and the patched version as 1.5.1. • Release 1.5.1 is identified as fixing the issue. The difference between < 1.5.1 and < 1.5 is not resolved by the available evidence, so deployments at that boundary should not be assumed safe without checking the vendor's release branch and the local configuration. • The issue concerns email and password self-registration being enabled by default; the available evidence does not show that every other authentication configuration is affected.

This is an insecure default initialization flaw in Caddy Proxy Manager's authentication flow. Before the fix, email and password self-registration was enabled by default at /api/auth/sign-up/email, allowing an unauthenticated remote actor to submit registration and receive an active account with the user role. That role cannot view or modify proxy data, so the available evidence does not establish a direct path to administrator privileges or proxy data.

The fix adds config.auth.allowSelfRegistration, derived from AUTH_ALLOW_SELF_REGISTRATION === "true", and passes its inverse to disableSignUp in src/lib/auth-server.ts. When the control is disabled, the developer test confirms that the endpoint returns EMAIL_PASSWORD_SIGN_UP_DISABLED; when intentionally enabled, the test confirms that registration creates a user account. The underlying authentication-library behavior and any additional limits of the user role are not described in greater detail by the available sources.

The flaw is reachable over the network through /api/auth/sign-up/email and does not require prior authentication. The supplied record describes low attack complexity, no user interaction, and account creation by a remote actor without administrator approval.

The practical precondition is that the instance must allow untrusted actors to reach the registration endpoint. The vendor's stated workaround is not to expose that endpoint to unknown actors. The record marks public_exploit as false and does not mark the issue as known exploited; that status does not prove that exploitation has never occurred in deployed environments.

• The confirmed technical outcome is creation of an active user account without administrator approval. • The direct security impact is limited because the user role cannot view or modify proxy data, according to the vendor advisory. • No confirmed evidence establishes privilege escalation, Caddy configuration changes, proxy-data access, or service-availability impact. • Organisationally, the issue can create unauthorized identities and require account inventory, revocation, and legitimacy checks. This is a possible operational consequence, not evidence of a specific breach.

• An exposed instance can accumulate unapproved user identities, weakening account governance and creating cleanup, revocation, and review work. • The available evidence limits the user role and does not permit viewing or modifying proxy data. No confirmed evidence shows data access, proxy configuration changes, or service disruption. • The main operational risk is unauthorized account lifecycle activity and the resulting difficulty of distinguishing legitimate users from externally created accounts. • Actual exposure depends on whether the registration endpoint is reachable by untrusted networks or actors.

1. Upgrade to 1.5.1, which the normalized record and vendor advisory identify as the fixed version.
2. After upgrading, update the Docker Compose file to the one from the 1.5.1 release if Docker Compose is used, because the release notes specifically request that change.
3. Until the upgrade is complete, do not expose /api/auth/sign-up/email to unknown actors. This is the workaround stated by the vendor.
4. On the fixed code, keep AUTH_ALLOW_SELF_REGISTRATION false or unset unless public self-registration is an approved business requirement. Set AUTH_ALLOW_SELF_REGISTRATION=true only after the exposure and account-governance implications have been reviewed.
5. Review and handle user accounts created while the instance may have been exposed. The available evidence does not establish a requirement to rotate other credentials or secrets.

1. Inventory Caddy Proxy Manager deployments and reconcile both recorded version boundaries: the normalized record marks < 1.5.1 as affected, while the vendor advisory lists < 1.5 as affected.
2. On a fixed deployment, inspect Docker Compose or environment configuration for AUTH_ALLOW_SELF_REGISTRATION. The default should be false or unset; true indicates that self-registration has been intentionally enabled.
3. In a controlled test environment, verify that a request to /api/auth/sign-up/email is rejected when self-registration is disabled and returns EMAIL_PASSWORD_SIGN_UP_DISABLED.
4. Review account records and audit logs for active user accounts created without administrator approval. Requests to the registration endpoint can also be monitored as a precaution, but the available sources do not provide a specific IOC or log pattern.

The absence of a matching log event does not prove that an instance is safe, especially where registration or reverse-proxy logging is incomplete.