CVE-2025-9943 Overview
An SQL injection vulnerability has been identified in the Shibboleth Service Provider (SP) affecting the handling of the "ID" attribute in SAML responses. This vulnerability is exploitable when the replay cache is configured to use an SQL database as a storage service with the ODBC plugin. An unauthenticated attacker can leverage blind SQL injection to extract arbitrary data from the database, potentially compromising sensitive authentication and session information.
The vulnerability stems from insufficient escaping of single quotes in the SQLString class within the odbc-store.cpp file (lines 253-271). This flaw allows malicious actors to inject SQL commands through crafted SAML response ID attributes, bypassing input validation mechanisms entirely.
Critical Impact
Unauthenticated attackers can extract arbitrary database contents through blind SQL injection, potentially compromising all user credentials and session data stored in the SP's database.
Affected Products
- Shibboleth Service Provider through version 3.5.0
- Systems using ODBC plugin for SQL database storage
- Configurations with SQL-based replay cache enabled
Discovery Timeline
- September 3, 2025 - Shibboleth releases security advisory
- September 10, 2025 - CVE-2025-9943 published to NVD
- November 4, 2025 - Last updated in NVD database
Technical Details for CVE-2025-9943
Vulnerability Analysis
This SQL injection vulnerability (CWE-89) exists in the Shibboleth Service Provider's ODBC storage implementation. The flaw is triggered when processing SAML response ID attributes that are stored in the replay cache database. The vulnerable code path only activates when administrators have configured the SP to use an SQL database through the ODBC plugin for replay cache storage.
The attack is network-accessible and requires no authentication or user interaction. Successful exploitation allows attackers to read sensitive data including user credentials, session tokens, and other information stored in the database. While confidentiality and integrity are severely impacted, availability is not directly affected by this vulnerability.
Root Cause
The root cause lies in the SQLString class implementation in odbc-store.cpp (lines 253-271). The code fails to properly escape single quote characters in user-controlled input before incorporating them into SQL queries. When a SAML response with a maliciously crafted ID attribute is processed, the unescaped single quotes allow an attacker to break out of the intended SQL string context and inject arbitrary SQL commands.
This is a classic example of improper input sanitization where the trust boundary between external SAML data and internal database queries is not properly enforced.
Attack Vector
The attack is executed by sending a specially crafted SAML response to the Shibboleth Service Provider. The attacker manipulates the ID attribute within the SAML response to include SQL injection payloads. Since the replay cache stores these IDs in the database to prevent replay attacks, the malicious SQL is executed when the ID is processed.
The blind SQL injection technique allows attackers to extract data through boolean-based or time-based inference, even when direct query results are not visible. This makes the vulnerability particularly dangerous as attackers can systematically enumerate and extract database contents without triggering obvious errors.
The vulnerability mechanism involves the following process: When a SAML response arrives at the Service Provider, the ID attribute is extracted and passed to the ODBC storage layer. In vulnerable versions, the SQLString class constructs SQL queries by concatenating the ID value without adequate escaping. An attacker can include payloads such as single quotes followed by SQL commands within the ID attribute, which then execute against the database. For detailed technical analysis, refer to the SEC Consult Security Advisory.
Detection Methods for CVE-2025-9943
Indicators of Compromise
- Unusual SAML response patterns containing single quotes or SQL syntax in ID attributes
- Database query errors or anomalies in Shibboleth SP logs
- Unexpected database access patterns or data retrieval from authentication tables
- SAML requests with abnormally long or malformed ID attribute values
Detection Strategies
- Deploy Web Application Firewall (WAF) rules to detect SQL injection patterns in SAML traffic
- Monitor Shibboleth SP logs for malformed SAML response processing errors
- Implement database audit logging to detect unauthorized SELECT queries
- Review network traffic for anomalous SAML response sizes or structures
Monitoring Recommendations
- Enable verbose logging on the Shibboleth Service Provider to capture SAML attribute details
- Configure database monitoring to alert on queries returning large result sets
- Set up intrusion detection rules for common blind SQL injection timing patterns
- Monitor for repeated authentication attempts with varying SAML response IDs
How to Mitigate CVE-2025-9943
Immediate Actions Required
- Upgrade Shibboleth Service Provider to version 3.5.1 or later immediately
- If immediate patching is not possible, temporarily switch to file-based replay cache storage
- Review database logs for signs of prior exploitation attempts
- Rotate any credentials that may have been stored in the SP database
Patch Information
Shibboleth has released Service Provider version 3.5.1 to address this vulnerability. The patch implements proper input escaping in the SQLString class to prevent SQL injection through SAML response ID attributes. Organizations should download the updated version from the Shibboleth Service Provider Downloads page. Debian users should apply the security update as detailed in the Debian LTS Security Announcement.
Workarounds
- Disable ODBC-based replay cache and switch to file-based or in-memory storage
- Implement network segmentation to limit direct access to Shibboleth SP endpoints
- Deploy application-layer filtering to inspect and sanitize SAML response ID attributes
- Consider using a reverse proxy with SQL injection detection capabilities in front of the SP
# Configuration example - Switch to file-based replay cache
# In shibboleth2.xml, replace ODBC ReplayCache with:
<ReplayCache type="StorageService" StorageService="file"/>
# Ensure file storage service is configured:
<StorageService type="File" id="file" prefix="shibd"/>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
