Summary
WeGIA contains broken object-level authorization in CRUD controllers exposed through its control dispatch endpoint, allowing an authenticated user to access or change records belonging to other users. In some affected workflows, missing CSRF protections may also allow a malicious website to trigger state-changing requests through an authenticated victim's browser.
WeGIA contains broken object-level authorization in CRUD controllers exposed through its control dispatch endpoint, allowing an authenticated user to access or change records belonging to other users. In some affected workflows, missing CSRF protections may also allow a malicious website to trigger state-changing requests through an authenticated victim's browser.
Affected context
The issue affects WeGIA deployments using the vulnerable control dispatch and CRUD flows for attended persons, internal users, employees, and volunteers. Risk increases when request parameters select controller classes, methods, or record identifiers without reliable server-side ownership checks, and when state-changing operations lack CSRF validation.
The issue affects WeGIA deployments using the vulnerable control dispatch and CRUD flows for attended persons, internal users, employees, and volunteers. Risk increases when request parameters select controller classes, methods, or record identifiers without reliable server-side ownership checks, and when state-changing operations lack CSRF validation.
Exploit preconditions
- Attack surface: The web-based
/controle/control.phpdispatch endpoint and associated CRUD methods - Required access: An authenticated WeGIA account; authorization scope may depend on the deployment's roles and permissions
- Trigger point: Requests containing controller, method, and record identifier parameters
- Additional condition: The selected operation must accept an object identifier without verifying that the requester owns or is authorized to access the object
- CSRF condition: For affected methods without CSRF validation, a victim may only need to visit a malicious page while authenticated
- Why exploitation is possible: Object-level authorization is missing or insufficient after attacker-controlled dispatch parameters are accepted
- Attack surface: The web-based
/controle/control.phpdispatch endpoint and associated CRUD methods - Required access: An authenticated WeGIA account; authorization scope may depend on the deployment's roles and permissions
- Trigger point: Requests containing controller, method, and record identifier parameters
- Additional condition: The selected operation must accept an object identifier without verifying that the requester owns or is authorized to access the object
- CSRF condition: For affected methods without CSRF validation, a victim may only need to visit a malicious page while authenticated
- Why exploitation is possible: Object-level authorization is missing or insufficient after attacker-controlled dispatch parameters are accepted
Why this happens
The underlying flaw is an authorization design failure in which the application trusts request-supplied record identifiers without enforcing ownership or permission checks at the object boundary. Using extract($_REQUEST) also increases the risk of unintended parameter control and broadens the dispatch surface by allowing request data to influence controller and method selection.
This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, because a user-controlled identifier can be used to reach another user's record. The missing request-origin validation in several state-changing methods also maps to CWE-352: Cross-Site Request Forgery.
The underlying flaw is an authorization design failure in which the application trusts request-supplied record identifiers without enforcing ownership or permission checks at the object boundary. Using extract($_REQUEST) also increases the risk of unintended parameter control and broadens the dispatch surface by allowing request data to influence controller and method selection.
This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, because a user-controlled identifier can be used to reach another user's record. The missing request-origin validation in several state-changing methods also maps to CWE-352: Cross-Site Request Forgery.
Potential impact
- Sensitive personal, medical, identity, address, financial, or employee data could be disclosed
- An authenticated user could modify records belonging to other users
- Records could be deleted or rendered unavailable
- Victims could have account or profile information altered without authorization
- CSRF-based requests could cause unauthorized state changes through an authenticated browser
- Data integrity, privacy, and operational workflows could be disrupted
- Sensitive personal, medical, identity, address, financial, or employee data could be disclosed
- An authenticated user could modify records belonging to other users
- Records could be deleted or rendered unavailable
- Victims could have account or profile information altered without authorization
- CSRF-based requests could cause unauthorized state changes through an authenticated browser
- Data integrity, privacy, and operational workflows could be disrupted
General mitigation guidance
Mitigation should center on centralized, server-side object authorization and narrowly defined request dispatching.
Common defensive patterns include:
- Enforcing ownership or role-based authorization for every read, create, update, and delete operation
- Deriving permitted object scope from the authenticated principal rather than trusting request identifiers
- Replacing dynamic request extraction and unrestricted method selection with explicit allowlists and typed request handling
- Applying CSRF protection to every state-changing browser operation, including methods that appear internal
- Using secure-by-default authorization middleware or policy checks at controller and service boundaries
- Limiting privileged operations through least-privilege roles and narrowly scoped permissions
- Returning consistent authorization failures without revealing whether another user's record exists
- Validating identifiers and enforcing schema constraints without treating validation as a substitute for authorization
Mitigation should center on centralized, server-side object authorization and narrowly defined request dispatching.
Common defensive patterns include:
- Enforcing ownership or role-based authorization for every read, create, update, and delete operation
- Deriving permitted object scope from the authenticated principal rather than trusting request identifiers
- Replacing dynamic request extraction and unrestricted method selection with explicit allowlists and typed request handling
- Applying CSRF protection to every state-changing browser operation, including methods that appear internal
- Using secure-by-default authorization middleware or policy checks at controller and service boundaries
- Limiting privileged operations through least-privilege roles and narrowly scoped permissions
- Returning consistent authorization failures without revealing whether another user's record exists
- Validating identifiers and enforcing schema constraints without treating validation as a substitute for authorization
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving
extract($_REQUEST), dynamic controller or method dispatch, and direct use of request identifiers in CRUD queries - Code review signals showing database operations that lack an authorization check tied to the authenticated principal
- Tests that access, modify, and delete objects across users, roles, and tenants
- Checks confirming CSRF tokens are required for every state-changing request and validated server-side
- Runtime monitoring for repeated cross-account identifier access, unusual CRUD activity, and authorization failures
- Policy enforcement requiring centralized authorization middleware and explicit dispatch allowlists
Automated security review tools may help identify dynamic request handling and missing authorization patterns, but application-specific access-control tests remain important.
Organizations can look for:
- Static analysis findings involving
extract($_REQUEST), dynamic controller or method dispatch, and direct use of request identifiers in CRUD queries - Code review signals showing database operations that lack an authorization check tied to the authenticated principal
- Tests that access, modify, and delete objects across users, roles, and tenants
- Checks confirming CSRF tokens are required for every state-changing request and validated server-side
- Runtime monitoring for repeated cross-account identifier access, unusual CRUD activity, and authorization failures
- Policy enforcement requiring centralized authorization middleware and explicit dispatch allowlists
Automated security review tools may help identify dynamic request handling and missing authorization patterns, but application-specific access-control tests remain important.
