dbcve.org
SQL InjectionWeakness · CWE-89

CVE-2025-9943

CRITICAL · 9.1 CVSS v3.1 Published 2025-09-10
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
An SQL injection vulnerability has been identified in the "ID" attribute of the SAML response when the replay cache of the Shibboleth Service Provider (SP) is configured to use an SQL database as storage service. An unauthenticated attacker can exploit this issue via blind SQL injection, allowing for the extraction of arbitrary data from the database, if the database connection is configured to use the ODBC plugin. The vulnerability arises from insufficient escaping of single quotes in the class SQLString (file odbc-store.cpp, lines 253-271). This issue affects Shibboleth Service Provider through 3.5.0.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A blind SQL injection vulnerability exists in the SAML replay cache of Shibboleth SP when using ODBC database storage. The vulnerability stems from insufficient escaping of single quotes in the SQLString class (odbc-store.cpp lines 253-271), allowing unauthenticated attackers to inject malicious SQL through the 'ID' attribute of SAML responses.

MitigationUpgrade Shibboleth SP beyond version 3.5.0 or apply the vendor patch to properly escape single quotes in the ODBC SQLString class. If immediate patching is unavailable, disable ODBC-based replay cache storage and use an alternative storage backend.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Shibboleth SP version
    Run 'shibd -v' or check the installed package version via your system's package manager (e.g., rpm -q shibboleth, dpkg -l shibboleth, or yum list shibboleth)
    Affected if The installed version is 3.5.0 or earlier (any version up to and including 3.5.0)
  2. Locate the SAML replay cache configuration
    Search the Shibboleth SP configuration file (commonly shibboleth2.xml or similar) for '<ReplayCache>' or 'ReplayCache' elements
    Affected if A <ReplayCache> element exists and specifies ODBC storage (look for 'odbc' or ODBC-related data source references)
  3. Verify ODBC is the active replay cache storage backend
    In theReplayCache configuration, check the 'type' or data source definition - look for ODBC connection strings, ODBC provider classes, or references to odbc-store in the configuration
    Affected if The replay cache storage is explicitly configured to use ODBC (e.g., type='ODBC', connection strings with 'Driver=', or similar ODBC data source configuration)
  4. Confirm the vulnerability path exists
    Verify that SAML responses with an 'ID' attribute are being processed by the ODBC-based replay cache - this is implicit if steps 1-3 confirm a vulnerable version with ODBC replay cache enabled
    Affected if Shibboleth SP version is 3.5.0 or earlier AND ODBC-based replay cache is configured and active

You are affected if running Shibboleth SP version 3.5.0 or earlier with the SAML replay cache configured to use ODBC database storage.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade Shibboleth SP beyond version 3.5.0 or apply the vendor patch to properly escape single quotes in the ODBC SQLString class. If immediate patching is unavailable, disable ODBC-based replay cache storage and use an alternative storage backend.

Recommended fix Moderate confidence

Latest Shibboleth SP release (check shibboleth.net for 3.5.1 or subsequent security release)

  1. 1. Identify the current Shibboleth SP version installed using package manager or binary version check
  2. 2. Review the replay cache configuration in shibboleth2.xml to confirm if ODBC database storage is in use
  3. 3. If ODBC is configured, immediately consider disabling the replay cache or switching to an alternative storage backend as a temporary mitigation
  4. 4. Check Shibboleth project's official security advisories at shibboleth.net for the fixed release version
  5. 5. Upgrade Shibboleth SP to the latest stable release that addresses CVE-2025-9943
  6. 6. After upgrade, verify the odbc-store.cpp file contains the corrected SQLString escaping logic
  7. 7. Test the SAML response processing to ensure normal functionality
  8. 8. Monitor logs for any SQL injection attempts targeting the ID attribute
Caveat Upgrading Shibboleth SP may require configuration adjustments; test in staging first

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing6.0 h
  • Review / QA3.0 h
15.0 hours of engineering $2,560
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,096.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-9943 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-9943 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data