Published on 16 August 2026
A login module that is actually supposed to increase security can, under certain database settings, achieve exactly the opposite: it allows two different identities to pass as the same one – and thereby opens the door to someone else's user account. This is precisely what the security advisory SA-CONTRIB-2026-098 describes, which the Drupal security team published on 12 August 2026 for the External Authentication module. The vulnerability carries the identifier CVE-2026-73476, is rated "moderately critical" (13 out of 25 points) and affects all versions before 2.0.13.
If your website uses Drupal and users log in via an external service – for example via LDAP (a directory service for user accounts), CAS or SAML (standards for single sign-on), SimpleSAMLphp, certificates or BankID – then this module may be in use in the background without you seeing it directly. This article explains what happened, how to reliably check whether you are affected, and what you should do now, in concrete terms.
The Drupal module External Authentication manages the mapping between an external identity – that is, an identifier supplied by an external login service – and a Drupal account. This mapping is stored in a database table called authmap. Essentially three things are stored there: the external identifier (authname), the name of the login service (provider) and the internal user ID of the Drupal account.
The problem: before version 2.0.13, the module did not compare the externally supplied identity values byte-for-byte, that is, not exactly character by character. Instead it relied on the comparison performed by the database itself. And this database comparison depends on the so-called collation – these are the rules by which a database decides whether two strings are considered equal.
The Drupal security team puts it this way:
"The module does not sufficiently ensure exact matching of externally supplied identity values when storing and looking up authentication mappings under certain database collation configurations." (Drupal Security Team, SA-CONTRIB-2026-098)
In other words: under certain collations, the module does not ensure that externally supplied values match exactly. And – this is the crucial point for practice – the security team explicitly warns:
"Affected collations are quite common so all sites are encouraged to upgrade." (Drupal Security Team, SA-CONTRIB-2026-098)
The affected collations are therefore "quite common", which is why all users of the module are advised to upgrade – regardless of whether they know their exact database configuration.
Many databases are configured by default to be tolerant when comparing text. For example, they treat upper and lower case as equal (case-insensitive) or ignore accents and diacritical marks (accent-insensitive). This is often convenient in everyday use – for a search, for instance. For security decisions, however, it is dangerous.
The official patch itself provides an illustrative example: it tests the identifiers user1 and üser1. Under collations such as utf8mb4_unicode_ci or utf8mb4_general_ci (the "ci" stands for "case-insensitive"), the "ü" can be reduced to a "u" – the database then considers both identifiers to be identical. In the same way, different capitalisations can pass as equal.
In concrete terms this means: before 2.0.13, a database hit was sufficient during lookup, without subsequently verifying whether the stored values actually matched the supplied values character for character. In this way an external identity can hit an incorrect mapping in authmap – and thereby someone else's Drupal account. If this misassignment succeeds, the access protection can be bypassed. How great the damage then is depends on which privileges the erroneously matched account holds.
Important: the collation names mentioned in the example are an illustration of the comparison logic. Drupal has not published a complete list of the affected collations, no attack steps and no cases of real compromise.
The fix in 2.0.13 works on two levels. Maintainer Sven Decabooter describes the database change in the official patch commit as follows:
"Converts both columns from their previous case/accent-insensitive collations to binary-safe equivalents so that byte-distinct authnames and provider values are matched exactly by the database." (Sven Decabooter, fixer and maintainer)
First, the columns authname and provider are converted to a binary-safe format – so that byte-distinct values are no longer treated as equal by the database. Existing installations run the update hook externalauth_update_8104() for this purpose, which migrates the columns and re-creates the combined unique key. Second, the runtime code additionally compares once more byte-for-byte via PHP (using the strict operator ===) before returning a user ID.
To put it in context: this is not a bug in the Drupal core and not remote code execution – that is, not a hole through which attackers can execute arbitrary program code. It is an access-protection bypass in a contrib helper module (an add-on module provided by the community).
According to the Drupal project page, at the time of retrieval on 15 August 2026, 100,455 websites use the External Authentication module. This is a pure usage figure – not an indication of the number of actually vulnerable or even compromised installations.
For you as an SME, what counts is not the total number of all Drupal instances, but your own configuration. There is an increased risk if all of the following points apply:
drupal/externalauth is installed and active.authmap table actually contains mappings.At the time of checking there is no public exploit code (Drupal rates the exploit availability as "Theoretical"), and CVE-2026-73476 is also not listed in the official CISA KEV catalogue (version 2026.08.14) – the US register of known actively exploited vulnerabilities. This does not prove general non-exploitation, but there is currently no documented evidence of active attacks. That is not an all-clear, however: the vendor recommendation is clearly "upgrade for everyone".
composer outdated "drupal/*" and search composer.lock for drupal/externalauth. If the package is not installed, this CVE does not affect you.externalauth and check which SSO, directory or login modules use it as a dependency. Note: the module itself offers no visible site-builder interface – so merely looking at login forms is not sufficient.SELECT COUNT(*) AS authmap_rows FROM authmap; (use the actual name if there is a table prefix). A result greater than zero indicates existing external mappings. A result of zero does not, however, replace the upgrade.SELECT VERSION(); shows the database server. You can determine the collation of the security-relevant columns with: SELECT COLUMN_NAME, COLLATION_NAME, COLUMN_TYPE FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'authmap' AND COLUMN_NAME IN ('authname','provider'); Since Drupal does not publish a complete list of names, checking the version and upgrading is more reliable than deriving an all-clear from a collation name.SELECT provider, authname, COUNT(*) AS n FROM authmap GROUP BY provider, authname HAVING COUNT(*) > 1; Do not delete automatically – reconcile the mapping with the respective identity provider.drush updatedb runs through without errors, that drush cache:rebuild completes and that the external login paths work in a test environment.drupal/externalauth before 2.0.13 as requiring a patch. Because of the widespread collations, the vendor explicitly recommends the upgrade to all sites.composer update drupal/externalauth --with-all-dependencies, then drush updatedb and drush cache:rebuild. The database update is essential here because 2.0.13 ships a schema update for authmap.The BSI sums up the basic rule: "Install updates as soon as possible after they are released."
Note: the following context is general information, not legal advice. An unpatched vulnerability is not automatically a reportable data breach. Under Art. 4(12) GDPR, a personal data breach only exists once a security breach leads, among other things, to unauthorised access to or unauthorised disclosure of personal data. If someone else's Drupal account is actually reached via CVE-2026-73476 and personal data is accessible through it, this definition may be met.
In such a case, the controller must robustly investigate and document the facts – affected data and accounts, time period, possible access and remedies taken. Art. 33 GDPR then requires a notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where a high risk is likely, the affected persons must in principle be notified without undue delay under Art. 34.
For prevention, Art. 32 requires a level of protection appropriate to the risk and procedures for regularly reviewing the measures. A prompt security update, documented update processes and checking the accounts actually mapped are therefore relevant technical and organisational measures. Breaches of Art. 32 fall under the fine framework of Art. 83(4): up to EUR 10 million or, in the case of undertakings, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher. However, no automatic fine follows from CVE-2026-73476 or a mere delay in patching.
CVE-2026-73476 is not a spectacular remote takeover, but an inconspicuous yet insidious access flaw: a database setting that seems useful in everyday use can lead to two different identities being wrongly treated as the same. Because the affected collations are, according to Drupal, "quite common", the recommendation applies explicitly to all users of the module – not just those with exotic configurations.
Against acute mass attacks, the current arguments are the missing public exploit and the missing CISA KEV entry. But that is a reason for diligence, not for complacency. For German SMEs the practical priority is therefore clear: promptly update to External Authentication 2.0.13, run the database update, check the external identity mappings and logs – and document the whole process properly. Anyone who does not use External Authentication at all is not affected by this advisory. Anyone who does use it should firmly plan the patch into the next maintenance window.