Summary
A cross-site request forgery vulnerability in REDAXO's backend user administration can cause an authenticated user to submit unintended account-management changes. If a logged-in backend user has access to the users administration function, a crafted request may grant administrator privileges, deactivate accounts, or lock out the sole administrator.
A cross-site request forgery vulnerability in REDAXO's backend user administration can cause an authenticated user to submit unintended account-management changes. If a logged-in backend user has access to the users administration function, a crafted request may grant administrator privileges, deactivate accounts, or lock out the sole administrator.
Affected context
The vulnerability occurs in REDAXO's backend user administration page at users/users when account updates can be triggered through the FUNC_UPDATE path without a required CSRF token. It is relevant where authenticated backend users have the users[] permission and their browsers can be induced to send requests to the administrative interface.
The vulnerability occurs in REDAXO's backend user administration page at users/users when account updates can be triggered through the FUNC_UPDATE path without a required CSRF token. It is relevant where authenticated backend users have the users[] permission and their browsers can be induced to send requests to the administrative interface.
Exploit preconditions
- Attack surface: REDAXO backend user administration functionality
- Required access: A logged-in backend user with the
users[]permission - Trigger point: An account update request processed through the
FUNC_UPDATEpath - Attacker interaction: The victim must be induced to visit or load a crafted link or request while authenticated
- Why exploitation is possible: CSRF validation is conditional on the
saveparameter, while the update path can proceed without requiring a valid anti-CSRF token
- Attack surface: REDAXO backend user administration functionality
- Required access: A logged-in backend user with the
users[]permission - Trigger point: An account update request processed through the
FUNC_UPDATEpath - Attacker interaction: The victim must be induced to visit or load a crafted link or request while authenticated
- Why exploitation is possible: CSRF validation is conditional on the
saveparameter, while the update path can proceed without requiring a valid anti-CSRF token
Why this happens
The underlying flaw is incomplete enforcement of request authenticity checks. The application validates a CSRF token only for requests containing a particular parameter, but an alternate update workflow can modify user accounts without passing the same validation.
This maps to CWE-352: Cross-Site Request Forgery, where state-changing actions rely on ambient browser authentication without consistently verifying that the request originated from the intended application interface.
The underlying flaw is incomplete enforcement of request authenticity checks. The application validates a CSRF token only for requests containing a particular parameter, but an alternate update workflow can modify user accounts without passing the same validation.
This maps to CWE-352: Cross-Site Request Forgery, where state-changing actions rely on ambient browser authentication without consistently verifying that the request originated from the intended application interface.
Potential impact
- An attacker may grant administrator privileges to an account
- Existing accounts could be deactivated
- The sole administrator could be locked out
- Unauthorized user and privilege changes could undermine backend access control
- Administrative changes may be performed without the victim intentionally submitting them
- An attacker may grant administrator privileges to an account
- Existing accounts could be deactivated
- The sole administrator could be locked out
- Unauthorized user and privilege changes could undermine backend access control
- Administrative changes may be performed without the victim intentionally submitting them
General mitigation guidance
Mitigation focuses on making request-origin validation mandatory for every state-changing administrative operation.
Common defensive patterns include:
- Enforcing CSRF tokens on all update and delete paths, regardless of optional parameters
- Rejecting state-changing requests when the token is absent, invalid, expired, or associated with the wrong session
- Using same-site cookie protections as a complementary control rather than the sole defense
- Applying origin or referer validation where appropriate for administrative requests
- Requiring explicit confirmation for high-impact privilege and account-lockout changes
- Limiting user-administration permissions according to least privilege
- Avoiding state changes through unauthenticated or link-triggered GET requests
Mitigation focuses on making request-origin validation mandatory for every state-changing administrative operation.
Common defensive patterns include:
- Enforcing CSRF tokens on all update and delete paths, regardless of optional parameters
- Rejecting state-changing requests when the token is absent, invalid, expired, or associated with the wrong session
- Using same-site cookie protections as a complementary control rather than the sole defense
- Applying origin or referer validation where appropriate for administrative requests
- Requiring explicit confirmation for high-impact privilege and account-lockout changes
- Limiting user-administration permissions according to least privilege
- Avoiding state changes through unauthenticated or link-triggered GET requests
How teams detect issues like this
Detection can include:
- Static analysis for state-changing handlers that do not invoke centralized CSRF validation
- Code review of alternate action branches, optional-parameter checks, and legacy update routes
- Tests that submit each administrative operation with missing, invalid, and mismatched CSRF tokens
- Dynamic testing to verify that cross-origin requests cannot modify user accounts
- Policy enforcement requiring anti-CSRF middleware or equivalent controls on all backend mutation endpoints
- Monitoring for unusual administrator creation, privilege changes, account deactivation, or repeated lockout events
Detection can include:
- Static analysis for state-changing handlers that do not invoke centralized CSRF validation
- Code review of alternate action branches, optional-parameter checks, and legacy update routes
- Tests that submit each administrative operation with missing, invalid, and mismatched CSRF tokens
- Dynamic testing to verify that cross-origin requests cannot modify user accounts
- Policy enforcement requiring anti-CSRF middleware or equivalent controls on all backend mutation endpoints
- Monitoring for unusual administrator creation, privilege changes, account deactivation, or repeated lockout events
