Summary
Malcolm's kiosk Flask application exposes a script-management endpoint without authentication and permits requests from arbitrary origins. A remote attacker may use cross-site request forgery to make an operator's browser submit management commands, potentially deleting forensic data or disabling monitoring when the kiosk is reachable and the operator interacts with a malicious page.
Malcolm's kiosk Flask application exposes a script-management endpoint without authentication and permits requests from arbitrary origins. A remote attacker may use cross-site request forgery to make an operator's browser submit management commands, potentially deleting forensic data or disabling monitoring when the kiosk is reachable and the operator interacts with a malicious page.
Affected context
The issue occurs in Malcolm deployments where the kiosk Flask application exposes the POST /script_call/<script> endpoint with no authentication and uses permissive wildcard CORS configuration. It becomes risky when an operator's browser can reach the kiosk and process attacker-controlled cross-origin requests, allowing management actions to be triggered through the operator's browser context.
The issue occurs in Malcolm deployments where the kiosk Flask application exposes the POST /script_call/<script> endpoint with no authentication and uses permissive wildcard CORS configuration. It becomes risky when an operator's browser can reach the kiosk and process attacker-controlled cross-origin requests, allowing management actions to be triggered through the operator's browser context.
Exploit preconditions
- Attack surface: Network-accessible Malcolm kiosk Flask application
- Required access: No direct authentication to the script endpoint; the attacker needs to cause an operator's browser to send a request
- Trigger point: A cross-site POST request to
/script_call/<script> - Why exploitation is possible: The endpoint lacks request-origin and anti-CSRF protections, while wildcard CORS broadens the set of origins able to interact with it
- Attack surface: Network-accessible Malcolm kiosk Flask application
- Required access: No direct authentication to the script endpoint; the attacker needs to cause an operator's browser to send a request
- Trigger point: A cross-site POST request to
/script_call/<script> - Why exploitation is possible: The endpoint lacks request-origin and anti-CSRF protections, while wildcard CORS broadens the set of origins able to interact with it
Why this happens
The underlying bug is a missing cross-site request forgery defense on a state-changing management endpoint. The application accepts browser-originated commands without requiring a user-specific anti-CSRF token, trusted origin validation, or equivalent authorization control. This maps to CWE-352: Cross-Site Request Forgery, where an attacker causes a user's browser to submit an unintended request using the user's available browser context.
The underlying bug is a missing cross-site request forgery defense on a state-changing management endpoint. The application accepts browser-originated commands without requiring a user-specific anti-CSRF token, trusted origin validation, or equivalent authorization control. This maps to CWE-352: Cross-Site Request Forgery, where an attacker causes a user's browser to submit an unintended request using the user's available browser context.
Potential impact
- Captured network traffic and forensic logs may be permanently deleted
- Security monitoring may be stopped or disabled
- Investigation history and evidence availability could be impaired
- The kiosk's management functions may be invoked without intended operator approval
- Incident response and detection coverage could be disrupted
- Captured network traffic and forensic logs may be permanently deleted
- Security monitoring may be stopped or disabled
- Investigation history and evidence availability could be impaired
- The kiosk's management functions may be invoked without intended operator approval
- Incident response and detection coverage could be disrupted
General mitigation guidance
Mitigation generally focuses on protecting every state-changing management action with explicit authorization and cross-site request defenses.
Common defensive patterns include:
- Requiring authenticated, least-privilege access for script-management endpoints
- Enforcing anti-CSRF tokens for browser-based state-changing requests
- Validating trusted origins and avoiding wildcard CORS for privileged operations
- Restricting allowed HTTP methods and rejecting unexpected content types
- Separating destructive administrative actions from operator-facing browser routes
- Requiring explicit confirmation and additional authorization for data deletion or monitoring changes
- Applying network segmentation and least-privilege service permissions
Mitigation generally focuses on protecting every state-changing management action with explicit authorization and cross-site request defenses.
Common defensive patterns include:
- Requiring authenticated, least-privilege access for script-management endpoints
- Enforcing anti-CSRF tokens for browser-based state-changing requests
- Validating trusted origins and avoiding wildcard CORS for privileged operations
- Restricting allowed HTTP methods and rejecting unexpected content types
- Separating destructive administrative actions from operator-facing browser routes
- Requiring explicit confirmation and additional authorization for data deletion or monitoring changes
- Applying network segmentation and least-privilege service permissions
How teams detect issues like this
Organizations can identify related weaknesses through:
- Static analysis for state-changing routes without CSRF middleware or authorization checks
- Code review of CORS configuration, especially wildcard origins on privileged endpoints
- Testing whether cross-origin forms or requests can invoke administrative actions
- Policy enforcement requiring authentication and anti-CSRF controls for destructive operations
- Monitoring logs for unexpected script invocations, origin values, request patterns, and operator-session activity
- Automated application-security testing that checks browser-based cross-origin request behavior
Organizations can identify related weaknesses through:
- Static analysis for state-changing routes without CSRF middleware or authorization checks
- Code review of CORS configuration, especially wildcard origins on privileged endpoints
- Testing whether cross-origin forms or requests can invoke administrative actions
- Policy enforcement requiring authentication and anti-CSRF controls for destructive operations
- Monitoring logs for unexpected script invocations, origin values, request patterns, and operator-session activity
- Automated application-security testing that checks browser-based cross-origin request behavior
