SSRF in Drupal Entity Share Websub: CVE-2026-73474 Endangers Servers

Published on 16 August 2026

If your Drupal website automatically synchronises content with other Drupal sites, you should take a look at a particular module right now. On 12 August 2026, the Drupal Security Team published a security vulnerability in the contrib module Entity Share Websub under the identifier SA-CONTRIB-2026-097. The flaw carries the identifier CVE-2026-73474 and enables what is known as Server-Side Request Forgery (SSRF) – that is, an attack in which the web server is tricked into carrying out network requests dictated by the attacker. Every version of the module below 1.1.2 is affected. The vendor has already made a patch available.

The good news first: at the time of research there is no known public exploit, no confirmed attacks and no reported data leaks. The less good news: the flaw is reachable without authentication, is technically simple to exploit and, according to Drupal, affects all module configurations. Anyone running the module in an outdated version should therefore act promptly – not in panic, but without unnecessary delay.

What happened?

The Drupal Security Team classified CVE-2026-73474 as “Moderately critical”, with a risk score of 13 out of 25 points. The advisory describes the cause briefly but unambiguously:

“Certain inputs were not sufficiently validated, allowing an attacker to achieve server-side request forgery attacks.” – Drupal Security Team, SA-CONTRIB-2026-097

In other words: certain inputs were not adequately validated, which allows an attacker to carry out SSRF attacks. On target distribution, the advisory states plainly:

“TD – Target distribution: All module configurations are exploitable.” – Drupal Security Team, SA-CONTRIB-2026-097

So it is not enough to rely on the fact that you only run one particular role (hub or subscriber). The only thing that matters is the installed version.

The timeline is straightforward: on 11 August 2026, Drupal released version 1.1.2 as a security release (created at 18:43 UTC). One day later, on 12 August 2026, the official advisory followed. According to Drupal, the vulnerability was reported by Marcus Johansson. The vendor does not give a discovery or reporting date.

Technical background: what is SSRF – and why is it relevant here?

The Entity Share Websub module is used to synchronise content between multiple Drupal sites. It works in what is known as the hub-subscriber model: when content changes on a source site (the hub), the subscribing site (the subscriber) receives a notification and then retrieves the updated content entity. For this retrieval to work, the server itself must actively carry out network requests – and this is exactly where the problem lies.

Server-Side Request Forgery means that an attacker abuses an application to make requests on its behalf. The OWASP project, a recognised authority on web security, describes it as follows:

“SSRF is an attack vector that abuses an application to interact with the internal/external network or the machine itself.” – OWASP Cheat Sheet Series

The actual damage depends heavily on which systems are reachable from the web server. In many corporate networks, a server can address internal services that are deliberately not accessible from outside – such as management interfaces, databases or cloud metadata services. If a server is tricked via SSRF into querying such internal targets, an attacker may under certain circumstances obtain information it could never have reached directly.

Important for context: Drupal names neither the specific faulty parameter nor an attack scenario, no target URL, no request method and no proof of concept. Only the attack class is documented. The risk fields of the advisory read in detail:

• AC: Basic – low attack complexity
• A: None – no authentication required
• CI: Some – possible loss of certain non-public information
• II: None – no specified integrity impact
• E: Theoretical – theoretical exploitability, no known public exploit
• TD: All – all module configurations affected

Who is affected?

Only Drupal websites (versions 9.x and 10.x) on which the Entity Share Websub module is installed in a version lower than 1.1.2 are affected. Anyone who does not use the module at all, or has already updated to 1.1.2, is not affected by this particular vulnerability according to the vendor.

On distribution: when queried on 15 August 2026, Drupal.org listed a total of 422 sites using the module. This is a usage indicator – not a figure for demonstrably vulnerable, let alone compromised, installations. This figure does not imply that all of these sites are still unpatched, nor that there are compromised companies, exposed data sets or confirmed damage.

Active exploitation is not confirmed as of the research cut-off date. The advisory records exploitability as “theoretical”, and a check of the official CISA KEV catalogue (the US agency’s list of known, actively exploited vulnerabilities) returned no hit for CVE-2026-73474. However, neither of these rules out later or non-publicly documented exploitation.

How to check whether you are affected

1. Determine module and version. In the project directory of your Drupal site, run:
   composer show drupal/entity_share_websub
   If no package is found, the module is not present in your Composer installation. For sites that are not managed with Composer, check the release status via your deployment or hosting archive, or the installed module copy.
2. Compare the version. Any identified version lower than 1.1.2 is affected according to the advisory. Do not rely solely on the hub or subscriber role here – Drupal rates all configurations as exploitable.
3. Check operating status. Additionally, you can check the enabled status:
   drush pm:list --type=module --status=enabled | grep entity_share_websub
   The package version, however, remains the decisive criterion.
4. Document. Record the time of the check, the identified version and the result internally. If your website is maintained externally, explicitly task your hosting or Drupal service provider with CVE-2026-73474 and the mandatory target version 1.1.2 – and demand proof that the patch has been rolled out.

What you need to do now

The vendor patch takes clear priority. Proceed in a structured way:

1. Create a backup. Back up the website and database before any change. Drupal explicitly recommends a database backup before module updates.
2. Apply the patch. Update the package specifically:
   composer update drupal/entity_share_websub --with-all-dependencies
   In a controlled deployment environment, first test the update in a staging environment and roll out the composer.lock in a controlled manner.
3. Perform post-update tasks. After the code update, run the prescribed Drupal steps:
   drush updatedb, drush cache:rebuild and, if applicable, drush config:export --diff. Then functionally test the hub/subscriber synchronisation.
4. Do not assume a supposed workaround. Drupal names no configuration workaround and rates all configurations as exploitable. If patching at short notice is exceptionally not possible, only temporarily disable the affected Entity Share Websub function or its synchronisation after a documented impact assessment. This reduces the attack surface but does not replace the update.
5. Limit outbound connections (defence in depth). Restrict the web server’s outbound network connections to known targets that are actually required for synchronisation, and do not permit freely chosen target URLs. For SSRF, OWASP explicitly recommends allowlisting trusted IP addresses or domains and warns:

   “Do not accept complete URLs from the user because URL are difficult to validate and the parser can be abused.” – OWASP Cheat Sheet Series

6. Check logs. After the update, review your security and web server logs for unusual outbound connections or unexpected synchronisation events. Since Drupal publishes neither a parameter nor indicators of compromise (IoCs), no CVE-specific log signatures can be reliably specified.

Context and GDPR relevance

An unpatched SSRF vulnerability is not automatically a data breach. Such an incident only becomes relevant in the sense of the GDPR when a security event actually leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or unauthorised access to, personal data.

Article 32 GDPR requires a level of protection appropriate to the risk through technical and organisational measures – the timely application of security updates clearly being one of them. If a forensic examination reveals that a risk to the rights and freedoms of natural persons is likely, the controller must, pursuant to Art. 33 GDPR, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Where a high risk is likely, the data subjects must be informed without undue delay pursuant to Art. 34 GDPR. The European Data Protection Board (EDPB) recommends documenting in a traceable manner the point at which awareness arose, the risk assessment and the decisions taken.

The financial framework should be taken seriously: for breaches of the obligations under Articles 25 to 39 GDPR – and therefore also under Art. 32 to 34 – Art. 83(4) GDPR provides for an upper limit of up to EUR 10 million or up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher. The specific sanction always depends on the individual case. In addition, Art. 82 GDPR may give rise to claims for compensation where material or non-material damage is proven.

That supervisory authorities do in fact enforce Art. 32 in Germany is shown by a practical example: in 2019, the BfDI imposed a fine of EUR 9.55 million on 1&1 Telecom GmbH for inadequate technical and organisational measures in telephone-based customer authentication. The then Federal Commissioner Ulrich Kelber said of this:

“Data protection is the protection of fundamental rights. The fines imposed are a clear signal that we will enforce this protection of fundamental rights.” – Ulrich Kelber, then BfDI

For context: this case involved neither SSRF nor Drupal and is no precedent for the CVE discussed here. It does, however, demonstrate that deficient technical and organisational measures can lead to tangible consequences in Germany.

Figures and comparison

For orientation, a few solid facts from the material:

• 422 sites used the module according to Drupal.org on 15/08/2026 – a usage indicator, not a figure for vulnerable or compromised installations.
• The risk rating is 13/25 (“Moderately critical”).
• Drupal publishes no figures on affected companies, personal data sets, successful attacks or data leaks.
• A comparable Drupal contrib SSRF case is SA-CONTRIB-2026-053 (CVE-2026-13233) of 24/06/2026 in the OpenAI Provider module, rated 10/25 and likewise as theoretically exploitable. The cause and prerequisites were, however, different.

Conclusion

CVE-2026-73474 is no cause for panic, but a clear call to action. The combination of no required authentication, low attack complexity and the finding that all module configurations are affected makes the flaw time-critical for anyone running Entity Share Websub in a version below 1.1.2. The fact that Drupal currently rates exploitation only as “theoretical” and that no public exploit is known merely describes the situation at the time of publication – it does not reduce the need to apply the patch promptly.

The three most important steps in brief: first, check whether the module is installed and which version is running. Second, after a prior backup, update to 1.1.2 and carry out the usual Drupal post-update tasks. Third, as additional protection, limit the web server’s outbound connections to known, necessary targets. Anyone who works through these points and documents the process is on the safe side with regard to this specific vulnerability – and can, in an emergency, also demonstrate to a supervisory authority that they acted appropriately.