Drupal Diff Module: CVE-2026-73478 Exposes Revision Data

Published on 16 August 2026

An editor is working on an article, correcting an internal contact person, deleting a sensitive note – and assumes that the old version is no longer accessible. This is exactly where a new vulnerability in the popular Drupal module Diff comes in: in certain versions, a person who was actually only permitted to view an entity could, under some circumstances, view earlier revision states via the comparison feature. In doing so, content that was long no longer intended for everyone may become visible.

The official Drupal advisory SA-CONTRIB-2026-096 describes the flaw under the identifier CVE-2026-73478. Drupal classifies it as moderately critical with 13 out of 25 points – so within the mid-range severity band. Important right up front: a fix already exists. The patch versions were released on 11 August 2026, while the advisory itself is dated 12 August 2026. Explicitly affected is not Drupal Core, but the additionally installable contrib module Diff.

What happened?

The Diff module displays differences between revisions (version states) of content. In the vulnerable versions, the diff route provided by the module did not check access rights sufficiently. Specifically, the Drupal Security Team describes the problem like this:

„The module doesn't sufficiently restrict access to non-node entity revision diffs.“ – Drupal Security Team, SA-CONTRIB-2026-096

Translated: the module did not sufficiently restrict access to revision comparisons of non-node entities. A “node” in Drupal is the classic content type (such as an article or a page). “Non-node entities” are all other structured data objects – for example certain standard or custom-built entities, provided they are revisionable, i.e. maintain a version history.

The risk lies solely with confidentiality: non-public content from earlier revisions could potentially be exposed. The integrity of the data remains untouched according to the advisory – so data cannot be altered or deleted, only viewed.

The technical core – explained clearly

A comparison of the official module archives shows the cause clearly: in the vulnerable states 2.0.0 and 2.1.0, the dynamically generated diff route only required the normal view permission for the entity – i.e. the right to view the entity at all. In the patched versions 2.0.1 and 2.1.1, the stricter permission is checked instead, namely being allowed to view all revisions.

In other words: previously, the weaker view right was enough to look into the history via the revision comparison. After the patch, that is no longer sufficient. Noteworthy is the historical context: it was only version 2.1.0 (released on 10 June 2026) that explicitly introduced support for all entity types – that is, precisely the extension in connection with which the insufficient check came to light.

Who is affected – and who is not?

According to the advisory, the following version states of the Diff module are affected:

• All versions lower than 2.0.1 are affected.
• Version 2.1.0 (the range from 2.1.0 up to but not including 2.1.1) is also affected.
• The problem is fixed in 2.0.1 and 2.1.1.

An important note on scope: the official Drupal project page reports 74,661 websites that use Diff. However, this is a pure usage figure – it already includes patched, non-exposed or possibly no longer active installations. It is not a figure of confirmed vulnerable or compromised websites. For CVE-2026-73478, Drupal publishes neither a number of affected companies nor exposed records nor confirmed incidents.

The crucial limitation

Whether the flaw is practically exploitable hinges on a specific precondition. The Drupal Security Team puts it this way:

„This vulnerability is mitigated by the fact that an attacker must have a role with the permission to view the entity.“ – Drupal Security Team, SA-CONTRIB-2026-096

So an attacker needs a role that is allowed to view the affected entity. At the same time, the advisory rates authentication as not required – access would therefore also be conceivable via an anonymous role, provided that role is allowed to see the entity. But this is not blanket, precondition-free access to any arbitrary website. Where public or broadly assigned roles cannot see relevant non-node entities, the real risk is correspondingly lower.

Drupal lists the exploit status as theoretical or white-hat. At the time of the advisory, no public exploit code was available. A targeted search also produced no solid evidence of active exploitation or a public proof-of-concept up to 15 August 2026. This statement is time-bound and does not prove that abuse never took place.

How to check whether you are affected

1. Is Diff installed and active at all? In Composer projects, composer show drupal/diff shows the installed package version. With composer outdated drupal/diff or composer outdated drupal/* you can see available updates. For the general security check, Drupal recommends composer audit.
2. Classify the version precisely. Every version lower than 2.0.1 is affected, as is 2.1.0. What matters is the state actually rolled out on the production system, along with the lock file – not a figure from a ticket or documentation.
3. No Composer? In the administration area, check the installed release version under “Reports” and “Available updates” as well as directly in the installed Diff module directory. Record on which system and when you checked.
4. Identify revisionable non-node entities. Determine which standard or custom entities of your installation are revisionable and offer a revision comparison via Diff. Not every entity type is automatically revisionable – hence a system-specific check is necessary.
5. Compare role permissions. Look under “Administration → People → Permissions” for view and revision permissions. Critical for the old check logic is a role that is allowed to view the entity but has no permission to view all revisions. Explicitly include anonymous and broadly assigned logged-in roles as well.
6. Secure and review logs. Retain web server, WAF and Drupal logs and, together with your service provider, review them for unusual accesses to revision views of affected non-node entities. A log review cannot reliably rule out actual access, but it is important for a later assessment and for providing evidence.

A note: there is no fixed, universally valid URL structure for testing, because the diff path is derived from the revisions-diff link template of the respective entity type. Therefore, do not rely solely on a blanket URL pattern.

What you need to do now, concretely

1. Apply the fix. Update the 2.0.x branch to at least 2.0.1 or the 2.1.x branch to at least 2.1.1. Diff 2.0.1 is compatible with Drupal ^10.5 or ^11, Diff 2.1.1 with Drupal ^10.5, ^11 or ^12. A pure permissions workaround does not replace the update.
2. Back up before the update. Create a tested database and file backup. For Composer, Drupal recommends first composer update drupal/diff --with-all-dependencies --dry-run and, after sign-off, composer update drupal/diff --with-all-dependencies; then drush updatedb and drush cache:rebuild.
3. Staging first. Roll out the update first in a test or staging environment, document the tests and the time.
4. Verify after the update. Test with an account that is allowed to see the entity but has no permission to view all revisions, to confirm that no revision diff is reachable any more. In parallel, check with an explicitly authorised role that your required workflows still function.
5. Temporarily reduce access. Until the update is applied, after a technical review you can restrict access to affected non-node entities and revision functions to the bare minimum. Because the flaw requires the view permission, this can limit the attack surface. However, do not disable production functions untested – the vendor does not name a full-fledged replacement workaround.
6. Establish an update process. Introduce a recurring update process for contrib modules with clear responsibility, an inventory and a test window, controlled via composer outdated and composer audit.

GDPR: When does the flaw become a notification obligation?

Clearly up front: a vulnerability alone is not yet a notifiable data breach. What is decisive is whether personal data was actually unlawfully disclosed or made accessible. Revision content can certainly be personal – such as names, contact details, internal free-text notes or earlier content states with identifying information. Whether this is the case for your website is something you have to determine specifically.

Legal framework: Art. 32 GDPR requires a level of security appropriate to the risk and explicitly names unauthorised disclosure and unauthorised access as risks. The Federal Commissioner for Data Protection formulates the obligation like this:

„Verantwortliche und Auftragsverarbeiter im Sinne der DSGVO müssen geeignete technische und organisatorische Maßnahmen treffen, um einen Schutz etwa vor unbefugter Kenntnisnahme, unrechtmäßiger Verarbeitung oder dem unbeabsichtigten Verlust der Daten zu gewährleisten.“ – BfDI

If a breach actually occurs, Art. 33 GDPR applies: 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. Every breach must be documented. In the case of a likely high risk, Art. 34 additionally requires the affected individuals to be notified without undue delay. The fine framework under Art. 83 is case-specific and takes into account, among other things, severity, duration, negligence, damage mitigation as well as existing technical and organisational measures.

By way of context, an – not directly comparable – German Art. 32 case: in 2018, the LfDI Baden-Württemberg imposed a fine of 20,000 euros following a hacker attack with around 330,000 affected user accounts, among other things because of passwords stored in plain text. The authority took cooperation and improvements into account in the assessment. The then State Commissioner Dr. Stefan Brink emphasised:

„Wer aus Schaden lernt und transparent an der Verbesserung des Datenschutzes mitwirkt, kann auch als Unternehmen aus einem Hackerangriff gestärkt hervorgehen.“ – Dr. Stefan Brink, LfDI Baden-Württemberg

This is explicitly not a prognosis for CVE-2026-73478 and not legal advice – but it shows that transparency and remediation can be assessed positively.

The Hessian supervisory authority shows that data protection violations remain a perennial issue: Art. 33 notifications rose by 28 percent in 2025 to 2,730 (2024: 2,141), and registered attacks on IT systems even by 30 percent, from 482 to 625. These figures are an overall Hessian view and not Drupal-specific, but they underline the trend.

Assessment and conclusion

At 13/25 points, CVE-2026-73478 is not a top-category emergency, but it is a case for a timely, controlled update. Several reasons speak for this: the patch is already available, the flaw affects confidentiality, and earlier revisions can contain unpublished information. The real risk rises when publicly or broadly authorised roles are allowed to see non-node entities, these entities are revisionable, and their history contains personal or commercially confidential content.

The all-clear applies where Diff is not installed at all or inactive, where no relevant non-node entities exist, or where version 2.0.1 or 2.1.1 is already running. There was no confirmed active exploitation or public proof-of-concept at the time of research.

A separate warning from the BSI or CERT-Bund about precisely this CVE could not be identified up to 15 August 2026 – which does not rule out a later report. Our advice remains pragmatic: check your version, clarify your role permissions, apply the fix and document your approach. In this way you close the gap before someone tries it out – and, in case of doubt, you also stand on safe ground in terms of data protection law.