Drupal Quick Tabs: CVE-2026-73477 Exposes Unpublished Content

Published on 16 August 2026

An unpublished draft, a candidate dataset not yet cleared for release, an internal block containing contract details – content that really shouldn't be visible to anyone outside the editorial team. Under certain conditions, exactly this kind of content could become visible on Drupal websites without visitors having to log in. The cause is a security vulnerability in the popular Drupal module Quick Tabs, which the Drupal security team disclosed on 12 August 2026 in advisory SA-CONTRIB-2026-099 under the identifier CVE-2026-73477. All versions before 4.3.1 are affected. An update is already available – and you should install it promptly.

The good news first: this is not a vulnerability that would let attackers take over your website, alter data or inject malicious code. The bad news: confidential content you deliberately held back could have become publicly visible. And if it contains personal data, that can quickly turn into a GDPR issue.

What happened?

Quick Tabs is a widely used Drupal add-on module that creates tabbed content areas – the familiar "tabs" between which visitors click back and forth on a page. Each individual tab can display different content: so-called nodes (the typical Drupal content items such as articles or pages), blocks (reusable content components), views or further Quick Tabs instances.

The problem lay in the access control when displaying node and block tabs. Put simply: the module did not correctly check whether the visiting user was even allowed to see a piece of content. Instead of requiring an explicit grant, the faulty code treated an undecided ("neutral") access decision as permission. For reusable custom blocks, according to the advisory, there was in fact no access check at all.

The Drupal security team describes it this way in the advisory:

"The module did not correctly enforce access when rendering node and block tabs. It treated a neutral access result as a grant for node tabs and block plugins, and performed no access check for reusable custom blocks." (Drupal Security Team, SA-CONTRIB-2026-099)

The result: content that Drupal's normal access logic would actually deny – such as unpublished nodes or unpublished reusable blocks – could appear in the tab output.

The technical background – explained in plain terms

For its access decisions (technically: AccessResult, i.e. the outcome of a permission check), Drupal recognises three possible states: explicitly allowed, explicitly forbidden and neutral (neither one nor the other). This matters, because in Drupal "not forbidden" does not automatically mean "allowed".

This is exactly where the bug lay. Before version 4.3.1, Quick Tabs only checked for nodes and block plugins whether access was explicitly forbidden. If it wasn't – i.e. in the neutral state – the content was displayed anyway. The official Drupal core documentation explicitly warns against precisely this misconception and prescribes the isAllowed() method for the yes/no decision:

"Always use isAllowed() for this." (Drupal Core API documentation, AccessResultInterface)

The new version 4.3.1 switches the logic to a positive grant check: only an explicitly allowed result is rendered. In addition, it now also checks access to reusable block content and adds cache information for the access decision, so that a rendering intended for other users isn't accidentally reused.

Important for context: an attacker cannot choose which content is disclosed. Only what an editor with the administer quicktabs permission previously embedded in a tab becomes visible. The Drupal team offers this reassurance in the advisory itself:

"The access bypass is mitigated by the fact that affected content is selected by a user with the 'administer quicktabs' permission when the tab is configured, so an attacker cannot choose which content is exposed." (Drupal Security Team, SA-CONTRIB-2026-099)

Who is affected?

In principle, all Drupal websites running the Quick Tabs module in a version lower than 4.3.1 are affected. According to Drupal.org, 26,178 websites currently report using the module. That figure, however, says nothing about version levels or specific tab configurations – so it is by no means the number of confirmed vulnerable or compromised installations.

A case is only actually exposable if all three of the following conditions coincide:

• A Quick Tabs instance contains a node or block tab (pure view or sub-tab configurations are not affected, according to the advisory).
• A user with the administer quicktabs permission has selected an access-restricted or unpublished piece of content there.
• The page in question is reachable by visitors who ought not to be able to see this content.

It becomes particularly critical when these unpublished contents contain customer, candidate, employee or contract data.

Is it being actively exploited? At the time of research (15 August 2026) there are no public indications of active exploitation and no published proof of concept. Drupal explicitly classifies the exploit availability as "theoretical/white-hat". The machine-readable CISA KEV catalogue (version 2026.08.14) – a US directory of known actively exploited vulnerabilities – does not contain the CVE ID. That is an additional indicator, but not proof of the worldwide absence of exploitation.

A minor status note in passing: CVE.org currently still lists CVE-2026-73477 as "RESERVED", while Drupal and the vulnerability database OSV already reference the identifier in full. That is merely a difference in how up to date the databases are – not the all-clear.

How to check whether you are affected

1. Determine the installed version: In the project directory, check the actual version with composer show drupal/quicktabs. With lock files, additionally use composer show --locked drupal/quicktabs. If the version is lower than 4.3.1, you are affected according to the advisory.
2. Check module status: Determine whether the module is enabled on the production website, for example with drush pm:list --type=module --status=enabled --format=list | grep -x quicktabs. An installed but disabled module does not create the exposure described.
3. Review Quick Tabs instances: As an authorised administrator, open the route /admin/structure/quicktabs. Check each instance for the tab types Node and Block.
4. Record the selected content: For each node or block tab, document which specific node or block is selected and whether it was unpublished, access-restricted or sensitive. Particularly important: could anonymous or low-privileged users reach the page?
5. Test visibility for real: Access the pages in question in a clean anonymous session and – if available – with a low-privileged test role. Preserve any unexpectedly visible drafts or blocks as findings. In doing so, do not disseminate any real personal content further; keep only the minimum evidence necessary.
6. Check logs: Review web server, CDN and Drupal logs for the vulnerable period for accesses to affected pages and, where applicable, Quick Tabs AJAX paths. Note: there are no published indicators of compromise – log hits alone therefore do not yet prove that any content was actually viewed.

What you need to do now

1. Update to Quick Tabs 4.3.1 immediately. That is the official fix, released on 12 August 2026. Before rolling it out to production, create a backup and test in staging. For Composer installations – subject to your own dependency policy – use, for example, composer update drupal/quicktabs --with-all-dependencies, then run the usual steps drush updatedb and drush cache:rebuild. The release page lists composer require 'drupal/quicktabs:^4.3' as the package channel. Supported core versions are Drupal ^10.3, ^11 and ^12.
2. If patching is not immediately possible: temporarily disable all Quick Tabs instances with node or block tabs, remove them from the layout, or change the selected content so that no unpublished or access-restricted data is rendered. This is only a stopgap, not a substitute for the update.
3. Test again after the update: revisit each previously identified page anonymously and with the relevant roles, then clear caches. Goal: access only with an explicitly allowed result.
4. Clean up permissions: review the administer quicktabs permission under the least-privilege principle (only as many rights as necessary) and grant it exclusively to trustworthy editors.
5. Where content may be personal: stop the exposure immediately, determine scope and time frame, secure access logs, involve data protection officers or specialist advice, and document the risk and notification-obligation assessment.
6. Improve patch management: subscribe to Drupal security advisories, inventory Composer lock files, and after each update carry out a role-based visibility check for non-public content.

The vendor, incidentally, is unequivocal about the urgency:

"This is a security release of Quick Tabs. Sites using Quick Tabs are urged to upgrade to 4.3.1 immediately after reviewing the associated security advisories." (Quick Tabs Release Notes 4.3.1)

Assessment and GDPR

Drupal rates the vulnerability at 13 out of 25 points as "moderately critical" – authentication "None" (no login required), confidentiality impact "Some", integrity impact "None", exploit status "Theoretical". Technically, then, a vulnerability of medium severity. For an individual SME, however, the risk can turn out higher if Quick Tabs displays unpublished or access-restricted personal content.

And that brings us to data protection. Unpublished content is not automatically personal – a purely editorial draft with no personal data is not a data breach. But: under Art. 4(12) GDPR, a "personal data breach" also covers the unauthorised disclosure of, or unauthorised access to, personal data. So if an unpublished customer, contact, candidate, employee or contract item became visible via a faulty Quick Tabs tab, that can be a reportable data breach.

For controllers, the following then applies:

• Every personal data breach must be documented.
• A notification to the competent supervisory authority is required 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 the individuals concerned.
• Where a high risk is likely, the affected individuals must, as a rule, also be notified without undue delay.

The decision is a case-by-case risk assessment – not an automatic consequence of the CVE. The EDPB (European Data Protection Board) expressly recommends that SMEs set up procedures for containment, risk assessment, documentation and notification in advance.

On fines: these are not incurred automatically. Art. 83 GDPR requires a case-by-case sanction that is effective, proportionate and dissuasive. Breaches of technical and organisational obligations (such as Art. 32) can reach up to EUR 10 million or 2% of worldwide annual turnover, more serious cases up to EUR 20 million or 4%. For this specific case, however, no public fines, notifications or damages are known.

Conclusion

CVE-2026-73477 is not a catastrophe, but neither is it to be dismissed. The vulnerability permits neither data manipulation nor server takeover – it "only" breaches confidentiality and can reveal non-public content previously selected by the administrator. But that content is often precisely the sensitive kind: drafts, internal blocks, personal data.

Since a fix is available and no public active exploitation is currently documented, the right priority is clear: update to 4.3.1 in the short term and check specifically whether anything was disclosed in the past – rather than waiting. Check your Quick Tabs instances for node and block tabs, test visibility as an anonymous visitor, and, in case of doubt, clarify together with your data protection advisers whether personal data was affected. Anyone who sets up their patch management cleanly now and consistently assigns permissions on the least-privilege principle will be able to act considerably faster the next time an advisory comes along.