CVE-2026-21892: Parsl SQL Injection Vulnerability

CVE-2026-21892 Overview

A SQL Injection vulnerability has been discovered in the parsl-visualize component of Parsl, a Python parallel scripting library. The vulnerability exists in versions prior to 2026.01.05 and allows an unauthenticated attacker with access to the visualization dashboard to inject arbitrary SQL commands through the workflow_id parameter in URL routes. The application constructs SQL queries using unsafe string formatting (Python % operator) with user-supplied input, potentially leading to data exfiltration or denial of service against the monitoring database.

Critical Impact

Unauthenticated attackers can inject arbitrary SQL commands through the visualization dashboard, potentially exfiltrating sensitive workflow data or causing denial of service against the monitoring database.

Affected Products

• Parsl parsl-visualize component versions prior to 2026.01.05
• Parsl monitoring visualization module (parsl/monitoring/visualization/views.py)
• Parsl visualization dashboard endpoints handling workflow_id parameters

Discovery Timeline

• 2026-01-08 - CVE CVE-2026-21892 published to NVD
• 2026-01-08 - Last updated in NVD database

Technical Details for CVE-2026-21892

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) exists within the Parsl visualization component's handling of the workflow_id parameter. The application uses Python's unsafe string formatting operator (%) to construct SQL queries directly from user-supplied URL route parameters without proper sanitization or parameterized queries. This architectural flaw allows attackers to manipulate SQL query logic by crafting malicious workflow_id values. The vulnerability is accessible through the network without requiring authentication, making it exploitable by any attacker who can reach the visualization dashboard endpoint.

Root Cause

The root cause of this vulnerability is the use of unsafe string formatting for SQL query construction in the visualization views. Instead of using parameterized queries or prepared statements, the application directly interpolates user-supplied workflow_id values from URL routes into SQL query strings using Python's % operator. This practice violates secure coding principles and allows specially crafted input to break out of the intended query context and execute arbitrary SQL commands.

Attack Vector

The attack vector is network-based, requiring no authentication or user interaction. An attacker can craft malicious workflow_id parameters in HTTP requests to the visualization dashboard endpoints. The vulnerable endpoints accept the workflow_id from URL routes and pass it directly into SQL queries without sanitization. This allows injection payloads such as ' OR '1'='1 or more complex statements that can extract data, modify records, or cause denial of service conditions against the backend monitoring database.

import pandas as pd
+import sqlalchemy
from flask import current_app as app
from flask import render_template

Source: GitHub Commit Details

The patch introduces SQLAlchemy for safer SQL parameter handling, replacing the unsafe string formatting with parameterized queries that properly escape user input.

Detection Methods for CVE-2026-21892

Indicators of Compromise

• Unusual or malformed workflow_id parameters in HTTP request logs containing SQL syntax characters such as single quotes, semicolons, or SQL keywords
• Database error messages or exceptions in application logs indicating malformed SQL queries
• Unexpected database queries or access patterns in monitoring database audit logs
• Anomalous response times or database performance degradation suggesting injection attempts

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block SQL injection patterns in URL parameters
• Monitor HTTP access logs for requests containing SQL metacharacters in the workflow_id field
• Deploy intrusion detection system (IDS) signatures for common SQL injection payloads targeting Flask applications
• Enable database query logging to identify anomalous or unauthorized SQL statement execution

Monitoring Recommendations

• Configure alerting on database query anomalies and syntax errors originating from the visualization component
• Monitor network traffic to the visualization dashboard for unusual request patterns or high volumes of malformed requests
• Implement application performance monitoring to detect latency spikes that may indicate SQL injection exploitation attempts
• Review access logs regularly for reconnaissance activity targeting visualization endpoints

How to Mitigate CVE-2026-21892

Immediate Actions Required

• Upgrade Parsl to version 2026.01.05 or later immediately to apply the security fix
• Restrict network access to the visualization dashboard to trusted networks or authenticated users only
• Implement input validation and WAF rules as defense-in-depth measures while scheduling the upgrade
• Review database audit logs for evidence of prior exploitation attempts

Patch Information

The vulnerability is fixed in Parsl version 2026.01.05. The patch modifies parsl/monitoring/visualization/views.py to use SQLAlchemy's parameterized query approach instead of unsafe Python string formatting. Organizations should upgrade to this version or later by updating their Parsl installation using pip: pip install parsl>=2026.01.05. For detailed information about the security fix, refer to the GitHub Security Advisory and the commit implementing the fix.

Workarounds

• Disable or restrict access to the parsl-visualize dashboard until the patch can be applied
• Place the visualization dashboard behind a reverse proxy with SQL injection filtering capabilities
• Implement network segmentation to limit access to the visualization component to trusted internal networks only
• Use firewall rules to restrict dashboard access to specific IP addresses or VPN connections

# Configuration example - Restrict access to visualization dashboard
# Add to nginx configuration if using reverse proxy
location /parsl-visualize {
    allow 10.0.0.0/8;      # Allow internal network
    allow 192.168.0.0/16;  # Allow private network
    deny all;               # Deny all other access
}