Summary
Agnai through version 1.0.555 includes fixed administrative credentials and a publicly exposed JWT signing secret in its Docker Compose configuration. An unauthenticated attacker who can reach the affected service may authenticate as an administrator or forge privileged tokens, potentially taking control of accounts and server settings.
Agnai through version 1.0.555 includes fixed administrative credentials and a publicly exposed JWT signing secret in its Docker Compose configuration. An unauthenticated attacker who can reach the affected service may authenticate as an administrator or forge privileged tokens, potentially taking control of accounts and server settings.
Affected context
The vulnerability occurs in deployments that use the affected self-host.docker-compose.yml configuration with its default fixed admin password and public JWT secret. Risk is greatest when the service is network-accessible and these values have not been replaced with unique, securely managed secrets before deployment.
The vulnerability occurs in deployments that use the affected self-host.docker-compose.yml configuration with its default fixed admin password and public JWT secret. Risk is greatest when the service is network-accessible and these values have not been replaced with unique, securely managed secrets before deployment.
Exploit preconditions
- Attack surface: The Agnai authentication and application service exposed through its deployment - Required access: Network access to the service; no valid account may be required when default credentials or token signing secrets remain active - Trigger point: Authentication or JWT validation using values embedded in the deployment configuration - Why exploitation is possible: Static secrets are shared, predictable, or publicly available, allowing administrative authentication or acceptance of attacker-generated privileged tokens
- Attack surface: The Agnai authentication and application service exposed through its deployment - Required access: Network access to the service; no valid account may be required when default credentials or token signing secrets remain active - Trigger point: Authentication or JWT validation using values embedded in the deployment configuration - Why exploitation is possible: Static secrets are shared, predictable, or publicly available, allowing administrative authentication or acceptance of attacker-generated privileged tokens
Why this happens
The deployment configuration embeds credentials and a JWT signing key directly in a distributed, reusable file. This violates the principle that authentication secrets should be unique, confidential, and externally managed. Because the application trusts these fixed values for administrator authentication and token verification, disclosure or reuse can enable impersonation and privilege escalation. This behavior maps to CWE-798, Use of Hard-coded Credentials.
The deployment configuration embeds credentials and a JWT signing key directly in a distributed, reusable file. This violates the principle that authentication secrets should be unique, confidential, and externally managed. Because the application trusts these fixed values for administrator authentication and token verification, disclosure or reuse can enable impersonation and privilege escalation. This behavior maps to CWE-798, Use of Hard-coded Credentials.
Potential impact
- An attacker could authenticate as an administrator.
- An attacker could impersonate users by presenting forged privileged tokens.
- Account passwords could be reset without authorization.
- Server configuration could be changed or weakened.
- Sensitive application data could be accessed, modified, or deleted.
- Compromised credentials could support persistence or further attacks.
- An attacker could authenticate as an administrator.
- An attacker could impersonate users by presenting forged privileged tokens.
- Account passwords could be reset without authorization.
- Server configuration could be changed or weakened.
- Sensitive application data could be accessed, modified, or deleted.
- Compromised credentials could support persistence or further attacks.
General mitigation guidance
Mitigation generally centers on removing credentials and signing keys from source-controlled or publicly distributed deployment templates. Deployments should use unique, high-entropy secrets supplied through a protected secret management mechanism, rotate any exposed values, and avoid shared defaults. JWT signing material should be isolated, access-controlled, and replaced without relying on public configuration files. Administrative interfaces should use least privilege, strong authentication, and restricted network exposure. Secure-by-default deployment templates should require explicit secret provisioning rather than silently enabling fixed credentials.
Mitigation generally centers on removing credentials and signing keys from source-controlled or publicly distributed deployment templates. Deployments should use unique, high-entropy secrets supplied through a protected secret management mechanism, rotate any exposed values, and avoid shared defaults. JWT signing material should be isolated, access-controlled, and replaced without relying on public configuration files. Administrative interfaces should use least privilege, strong authentication, and restricted network exposure. Secure-by-default deployment templates should require explicit secret provisioning rather than silently enabling fixed credentials.
How teams detect issues like this
Detection can include static analysis and secret-scanning rules for passwords, JWT secrets, signing keys, and authentication tokens in Compose files and deployment manifests. Code review should flag literal credential assignments, default administrator passwords, public signing material, and templates that enable privileged access without secret injection. Runtime monitoring can look for unexpected administrator logins, unusual token claims, password resets, and configuration changes. CI and deployment policies can block known secret patterns and require approved secret-management integrations.
Detection can include static analysis and secret-scanning rules for passwords, JWT secrets, signing keys, and authentication tokens in Compose files and deployment manifests. Code review should flag literal credential assignments, default administrator passwords, public signing material, and templates that enable privileged access without secret injection. Runtime monitoring can look for unexpected administrator logins, unusual token claims, password resets, and configuration changes. CI and deployment policies can block known secret patterns and require approved secret-management integrations.
