External Login CVE-2025-11177

Exploitation requires that the External Login plugin (≤1.11.2) be installed AND configured to use a PostgreSQL or MSSQL database as the external authentication backend - the default MySQL/MariaDB configuration is NOT affected, which sharply narrows the exploitable population. When that backend is configured, no further conditions apply: the attack is remote and unauthenticated (PR:N), needs no user interaction (UI:N), and targets the 'log' parameter of the login flow. The primary limiting factor is therefore the non-default database configuration; secondary limits include the confidentiality-only impact (data disclosure, not write or denial of service).

This is a moderate-priority vulnerability whose raw CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) overstates real-world risk because of a significant, often-overlooked precondition in the description. The CVSS vector correctly reflects an unauthenticated (PR:N), network-reachable, low-complexity SQL injection with high confidentiality impact only (C:H/I:N/A:N), which is internally consistent with the CWE-89 classification and the stated goal of extracting database data. However, exploitation is NOT possible against the default WordPress stack: the description explicitly states the flaw is only reachable 'when a PostgreSQL or MSSQL database is configured as the external authentication database.' WordPress core defaults to MySQL/MariaDB, so the vulnerable code path requires a deliberate, non-default External Login configuration - a material limiting factor that the AC:L metric does not capture (CVSS 4.0 would express this as AT:P). The supporting signals point to low urgency: EPSS is 0.40% (32nd percentile), there is no CISA KEV listing, and no public proof-of-concept is referenced. The reference set points only to the vulnerable source line (db.php#L153) and the Wordfence advisory, with no exploit code cited. Net: a legitimate, patch-worthy SQLi for the subset of sites running External Login against PostgreSQL/MSSQL, but low likelihood of mass exploitation and no evidence of active attacks - treat as routine-priority patching rather than emergency response, prioritizing only confirmed PostgreSQL/MSSQL deployments.

An unauthenticated attacker submits a crafted value in the 'log' (username) parameter to the External Login endpoint of a WordPress site that has been configured to authenticate against a PostgreSQL or MSSQL backend. Because the parameter is insufficiently escaped and the query is not properly prepared, the attacker appends additional SQL to the existing authentication query and reads sensitive data (e.g., credentials or user records) from the external database. No authentication or user interaction is required, but no public exploit code is referenced, so exploitation would currently require custom tooling.