Summary
WookTeam v1.6.6 and earlier contain a code injection vulnerability in the project task export interface. A remote attacker who can submit data to the affected endpoint may cause attacker-controlled PHP code to execute through an unsafe eval operation.
WookTeam v1.6.6 and earlier contain a code injection vulnerability in the project task export interface. A remote attacker who can submit data to the affected endpoint may cause attacker-controlled PHP code to execute through an unsafe eval operation.
Affected context
The vulnerability occurs in the project task export functionality at /api/project/task/export. The endpoint base64-decodes a data parameter and passes the result to string2array() in app/Module/Base.php; when the decoded input matches the expected array condition, it is incorporated into dynamically evaluated PHP code. Deployments that expose this interface and process attacker-influenced input may be at risk.
The vulnerability occurs in the project task export functionality at /api/project/task/export. The endpoint base64-decodes a data parameter and passes the result to string2array() in app/Module/Base.php; when the decoded input matches the expected array condition, it is incorporated into dynamically evaluated PHP code. Deployments that expose this interface and process attacker-influenced input may be at risk.
Exploit preconditions
- Attack surface: The project task export HTTP endpoint
- Required access: Ability to submit requests to the affected interface; authentication requirements may depend on deployment configuration
- Trigger point: Processing of the endpoint's base64-encoded
dataparameter - Why exploitation is possible: Decoded input can flow into an
evalcall without adequate separation between data and executable PHP code
- Attack surface: The project task export HTTP endpoint
- Required access: Ability to submit requests to the affected interface; authentication requirements may depend on deployment configuration
- Trigger point: Processing of the endpoint's base64-encoded
dataparameter - Why exploitation is possible: Decoded input can flow into an
evalcall without adequate separation between data and executable PHP code
Why this happens
The underlying bug is dynamic execution of attacker-influenced input. The application decodes request data and constructs PHP source code that is then evaluated by eval, allowing input to alter program behavior beyond its intended array representation. This is consistent with CWE-94, Improper Control of Generation of Code, because external data is treated as executable logic rather than being parsed through a constrained data-only mechanism.
The underlying bug is dynamic execution of attacker-influenced input. The application decodes request data and constructs PHP source code that is then evaluated by eval, allowing input to alter program behavior beyond its intended array representation. This is consistent with CWE-94, Improper Control of Generation of Code, because external data is treated as executable logic rather than being parsed through a constrained data-only mechanism.
Potential impact
- An attacker may execute arbitrary PHP code in the application process.
- The compromise could expose, alter, or delete application data.
- The attacker could use the application context to access other internal services.
- Service availability could be disrupted through unauthorized commands or resource consumption.
- Credentials or configuration secrets available to the process could be disclosed.
- An attacker may execute arbitrary PHP code in the application process.
- The compromise could expose, alter, or delete application data.
- The attacker could use the application context to access other internal services.
- Service availability could be disrupted through unauthorized commands or resource consumption.
- Credentials or configuration secrets available to the process could be disclosed.
General mitigation guidance
Mitigation generally centers on removing dynamic code evaluation from request
processing and replacing it with data-only parsing.
Common defensive patterns include:
- Representing exported task data with a strict, documented serialization format.
- Parsing input with a safe data parser rather than constructing PHP source code.
- Enforcing a schema, type checks, size limits, and allowed-value constraints before processing.
- Treating base64 encoding as an encoding mechanism, not as a security boundary or trust signal.
- Restricting access to export functionality according to least privilege.
- Running the application with minimal filesystem, database, and operating-system permissions.
- Keeping secrets out of the application process where possible and isolating sensitive services.
Mitigation generally centers on removing dynamic code evaluation from request
processing and replacing it with data-only parsing.
Common defensive patterns include:
- Representing exported task data with a strict, documented serialization format.
- Parsing input with a safe data parser rather than constructing PHP source code.
- Enforcing a schema, type checks, size limits, and allowed-value constraints before processing.
- Treating base64 encoding as an encoding mechanism, not as a security boundary or trust signal.
- Restricting access to export functionality according to least privilege.
- Running the application with minimal filesystem, database, and operating-system permissions.
- Keeping secrets out of the application process where possible and isolating sensitive services.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules that flag
evaland other dynamic execution APIs. - Data-flow analysis tracing HTTP parameters, decoding functions, and request values into code-generation sinks.
- Code review checks for string concatenation or interpolation used to construct executable PHP.
- API tests that verify malformed, unexpected, and oversized export parameters are rejected as data.
- Runtime monitoring for unusual export requests, repeated failures, unexpected child processes, or anomalous outbound connections.
- Policy enforcement in CI pipelines that blocks dynamic evaluation of externally influenced input.
Organizations can look for this class of issue through:
- Static analysis rules that flag
evaland other dynamic execution APIs. - Data-flow analysis tracing HTTP parameters, decoding functions, and request values into code-generation sinks.
- Code review checks for string concatenation or interpolation used to construct executable PHP.
- API tests that verify malformed, unexpected, and oversized export parameters are rejected as data.
- Runtime monitoring for unusual export requests, repeated failures, unexpected child processes, or anomalous outbound connections.
- Policy enforcement in CI pipelines that blocks dynamic evaluation of externally influenced input.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
