Efak
Monthly
EFAK 5.0.0 through 5.1.0 exposes stored LLM provider API keys to any authenticated user holding the lowest-privilege ROLE_USER account, because the /api/model-config/page and /api/model-config/{id} REST endpoints are not covered by the admin authorization gate implemented in WebSecurityConfig. A successful query returns the provider keys unmasked, letting a low-privilege account reuse those credentials against external LLM providers, run up charges on the victim's account, or pivot into provider-side resources. Exploitation requires a valid non-anonymous account (PR:L per the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N vector) and a deployment that actually stores LLM provider keys, so multi-user or multi-tenant installations with self-provisioned accounts carry the highest risk while single-admin deployments without configured keys are effectively unexposed; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation.
Privilege escalation in EFAK (Eagle for Apache Kafka) through 5.1.0 lets any authenticated low-privilege user grant themselves ROLE_ADMIN, create new administrator accounts, or delete existing users by sending POST, PUT, or DELETE requests to the /api/users endpoints, which are handled by UserController but never restricted to administrators by WebSecurityConfig. Exploitation is not pre-authentication and requires a valid low-privilege EFAK account (CVSS PR:L), but there is no user-interaction requirement and standard configurations are affected; no public exploit identified at time of analysis. Success yields full administrative control over the Kafka clusters that EFAK manages, with high confidentiality, integrity, and availability impact, and urgency rises sharply in deployments allowing self-registration or shared low-privilege logins.
EFAK 5.0.0 through 5.1.0 exposes stored LLM provider API keys to any authenticated user holding the lowest-privilege ROLE_USER account, because the /api/model-config/page and /api/model-config/{id} REST endpoints are not covered by the admin authorization gate implemented in WebSecurityConfig. A successful query returns the provider keys unmasked, letting a low-privilege account reuse those credentials against external LLM providers, run up charges on the victim's account, or pivot into provider-side resources. Exploitation requires a valid non-anonymous account (PR:L per the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N vector) and a deployment that actually stores LLM provider keys, so multi-user or multi-tenant installations with self-provisioned accounts carry the highest risk while single-admin deployments without configured keys are effectively unexposed; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation.
Privilege escalation in EFAK (Eagle for Apache Kafka) through 5.1.0 lets any authenticated low-privilege user grant themselves ROLE_ADMIN, create new administrator accounts, or delete existing users by sending POST, PUT, or DELETE requests to the /api/users endpoints, which are handled by UserController but never restricted to administrators by WebSecurityConfig. Exploitation is not pre-authentication and requires a valid low-privilege EFAK account (CVSS PR:L), but there is no user-interaction requirement and standard configurations are affected; no public exploit identified at time of analysis. Success yields full administrative control over the Kafka clusters that EFAK manages, with high confidentiality, integrity, and availability impact, and urgency rises sharply in deployments allowing self-registration or shared low-privilege logins.