Summary
OpenRefine through 3.10.1 contains a cross-site request forgery vulnerability in the get-rows command that can cause a user's active session to process attacker-controlled Jython facet expressions. If a user with access to OpenRefine visits a malicious page, the cross-origin request may result in operating system commands executing with the OpenRefine user's privileges.
OpenRefine through 3.10.1 contains a cross-site request forgery vulnerability in the get-rows command that can cause a user's active session to process attacker-controlled Jython facet expressions. If a user with access to OpenRefine visits a malicious page, the cross-origin request may result in operating system commands executing with the OpenRefine user's privileges.
Affected context
The issue occurs in OpenRefine deployments where the get-rows command accepts cross-origin requests and processes an engine parameter capable of reaching Jython facet evaluation. Risk is higher when an authenticated or otherwise active OpenRefine user can be induced to browse to an attacker-controlled page while the OpenRefine service is accessible from that browser context.
The issue occurs in OpenRefine deployments where the get-rows command accepts cross-origin requests and processes an engine parameter capable of reaching Jython facet evaluation. Risk is higher when an authenticated or otherwise active OpenRefine user can be induced to browse to an attacker-controlled page while the OpenRefine service is accessible from that browser context.
Exploit preconditions
- Attack surface: OpenRefine's web interface and the get-rows command
- Required access: A victim must have an active or authenticated OpenRefine session, depending on deployment controls
- Trigger point: Processing of a cross-origin GET request containing attacker-controlled command parameters
- Why exploitation is possible: The request may be accepted without adequate cross-site request validation, allowing server-side evaluation of Jython facet expressions under the OpenRefine user's privileges
- Attack surface: OpenRefine's web interface and the get-rows command
- Required access: A victim must have an active or authenticated OpenRefine session, depending on deployment controls
- Trigger point: Processing of a cross-origin GET request containing attacker-controlled command parameters
- Why exploitation is possible: The request may be accepted without adequate cross-site request validation, allowing server-side evaluation of Jython facet expressions under the OpenRefine user's privileges
Why this happens
The vulnerability results from insufficient cross-site request forgery protection on a stateful or command-processing HTTP endpoint. When the application relies on browser credentials without requiring an unpredictable request token or equivalent origin validation, a different site may cause the browser to submit a request on the user's behalf. Because the endpoint can process Jython facet expressions, the CSRF flaw can extend beyond unauthorized request execution to operating system command execution. This behavior maps to CWE-352: Cross-Site Request Forgery (CSRF).
The vulnerability results from insufficient cross-site request forgery protection on a stateful or command-processing HTTP endpoint. When the application relies on browser credentials without requiring an unpredictable request token or equivalent origin validation, a different site may cause the browser to submit a request on the user's behalf. Because the endpoint can process Jython facet expressions, the CSRF flaw can extend beyond unauthorized request execution to operating system command execution. This behavior maps to CWE-352: Cross-Site Request Forgery (CSRF).
Potential impact
- An attacker may cause unauthorized OpenRefine actions through a victim's browser session
- Server-side Jython expressions could execute operating system commands
- The OpenRefine service account or host environment could be compromised
- Sensitive project data may be exposed, altered, or destroyed
- A compromised instance could be used for further network access or lateral movement
- An attacker may cause unauthorized OpenRefine actions through a victim's browser session
- Server-side Jython expressions could execute operating system commands
- The OpenRefine service account or host environment could be compromised
- Sensitive project data may be exposed, altered, or destroyed
- A compromised instance could be used for further network access or lateral movement
General mitigation guidance
Mitigation generally focuses on enforcing request authenticity and reducing the authority of command-processing endpoints.
Common defensive patterns include:
- Requiring robust, unpredictable CSRF tokens for browser-initiated requests that use session credentials
- Validating request origins or trusted hosts as a defense-in-depth control
- Avoiding state-changing or command-executing behavior on cross-origin GET requests
- Separating expression evaluation from browser-accessible endpoints where practical
- Running OpenRefine with a dedicated least-privilege operating system account
- Restricting network exposure and requiring an authenticated administrative boundary
- Applying secure cookie attributes and narrowly scoped session handling
These controls reduce the chance that a user session can be abused and limit damage if a request reaches the service.
Mitigation generally focuses on enforcing request authenticity and reducing the authority of command-processing endpoints.
Common defensive patterns include:
- Requiring robust, unpredictable CSRF tokens for browser-initiated requests that use session credentials
- Validating request origins or trusted hosts as a defense-in-depth control
- Avoiding state-changing or command-executing behavior on cross-origin GET requests
- Separating expression evaluation from browser-accessible endpoints where practical
- Running OpenRefine with a dedicated least-privilege operating system account
- Restricting network exposure and requiring an authenticated administrative boundary
- Applying secure cookie attributes and narrowly scoped session handling
These controls reduce the chance that a user session can be abused and limit damage if a request reaches the service.
How teams detect issues like this
Organizations commonly look for:
- Static analysis findings on endpoints that process session-authenticated requests without CSRF protections
- Code review signals such as command-capable GET handlers, missing token validation, and absent origin checks
- Web logs showing unusual cross-origin requests to the get-rows command or unexpected engine parameters
- Policy checks requiring CSRF defenses on state-changing or expression-evaluating routes
- Runtime monitoring for unexpected child processes or operating system commands launched by the OpenRefine service
Automated security scanning and code review tools may help identify missing request-validation controls, but findings should be verified against the application's authentication and browser-access model.
Organizations commonly look for:
- Static analysis findings on endpoints that process session-authenticated requests without CSRF protections
- Code review signals such as command-capable GET handlers, missing token validation, and absent origin checks
- Web logs showing unusual cross-origin requests to the get-rows command or unexpected engine parameters
- Policy checks requiring CSRF defenses on state-changing or expression-evaluating routes
- Runtime monitoring for unexpected child processes or operating system commands launched by the OpenRefine service
Automated security scanning and code review tools may help identify missing request-validation controls, but findings should be verified against the application's authentication and browser-access model.
