Ten Drupal security advisories for contributed modules published on August 26, 2026, running from SA-CONTRIB-2026-108 to SA-CONTRIB-2026-117, every one rated moderately critical. Read as a list it is unremarkable maintenance. Read together it is close to a single defect appearing ten times, because six of the ten are the same mistake: a module hands data out through a route, a JSON endpoint or a JavaScript settings blob, and never re-checks whether the person asking is allowed to have it. This piece covers what actually shipped, the one advisory that is a different animal, why the read path is where contributed modules keep failing, what the risk scores are and are not telling you, and what to check on your own site.
The batch, and what is in it
Nothing here is core. All ten are contributed projects, which matters because Drupal core and contrib have very different review pipelines and very different upgrade urgency in most shops.
The XSS pair are the conventional entries. Slick Carousel (CVE-2026-81160) did not sufficiently validate input in the option sets that hold HTML for carousel buttons, and the advisory notes the fix actually shipped in 8.x-2.1 without being marked as a security release at the time. Monster Menus (CVE-2026-81201) does not sanitize HTML in page names when they render in its tree browser, mitigated by requiring an attacker who can already create pages with HTML titles.
The remaining eight are about access, and that is where the pattern lives.
Six advisories, one mistake
Line them up and the repetition is hard to miss.
Entity API (CVE-2026-81158) "doesn’t correctly apply access controls for JSON:API entity collection endpoints," mitigated by requiring JSON:API to be enabled alongside it. Data Field (CVE-2026-81269) "doesn’t sufficiently check access when returning Data Field values through its JSON endpoint," which the advisory says may expose field values from entities a user cannot view, "including unpublished content." Entity PDF (CVE-2026-81164) "does not check entity view access when fetching a PDF route," so a user can pull a PDF rendering of something they cannot read.
Digital Signage Framework (CVE-2026-81166) is the clearest statement of the shape. Its refresh route "did not check whether the requester was a signage device, nor whether the requested block was one that the module delivers to displays," so an anonymous visitor could read rendered blocks not meant for them. It is mitigated, usefully, by the fact that many block plugins run their own access checks.
DXPR Builder (CVE-2026-81162) leaks a credential rather than content, covered below. And LDAP / Active Directory Integration (CVE-2026-81205) does not sanitize input before building an LDAP search filter, letting an attacker discover information they should not see.
Six modules, six different authors, one defect: the data leaves by a path the module built itself, and the access check that guards the normal path was never repeated on it.
The DXPR Builder one is worth a second look
This is the advisory that deserves attention beyond patching, because of what triggers it.
DXPR Builder is a visual page builder for Drupal, and per its own advisory it "uses a JSON Web Token for licensing, user license management, AI services, and subscription metadata." The 2.x versions "do not sufficiently restrict access to API credentials in JavaScript settings." Then the condition: "When AI agent features are enabled, the token is exposed to all page visitors (including anonymous users) via drupalSettings."
Switching on the AI feature is what publishes the credential. A site running the module with those features off is not exposed by this. Turn them on and a token covering licensing and AI services is readable by anyone who views source on any page.
That is a specific instance of a general problem we have been circling for weeks. CMS and MCP agent permissions argued that agent features need to inherit the permission model rather than bring their own, and the CMS agent governance standard looked at the same question from the standards side. Here is what it looks like when it goes wrong in a shipped module: the AI capability needed a credential in the browser, and the credential went into the one place every visitor can read.
If you run DXPR Builder with AI features enabled, patching is not the end of it. The token was public for as long as the feature was on, so it should be treated as disclosed and rotated, not merely fixed.
What the risk scores are actually saying
Every advisory in this batch is "moderately critical," which flattens some real differences. The numeric scores and vectors separate them.
Two sit at 14 out of 25: LDAP / Active Directory Integration and DXPR Builder. The rest cluster at 12 and 13.
More useful than the number is the exploit-maturity field. Most of the batch is marked E:Theoretical. Two are E:Proof, meaning a proof of concept exists: the LDAP filter injection and one of the two Disable Login Page issues. If you are triaging by what is likeliest to be attacked rather than by headline severity, those move first, and the LDAP one combines proof-level maturity with A:None, meaning no account is required.
One small data oddity worth noting rather than resolving: CVE-2026-81269 appears on two separate advisories in this batch, Data Field and one of the Disable Login Page entries. That looks like a cataloging error rather than a shared root cause, and it is a reminder to track these by SA number, which is unambiguous, rather than by CVE.
Disable Login Page got two, which is its own lesson
The module restricts /user/login behind a secret key, and it drew two advisories on the same day for two unrelated failures.
The first (CVE-2026-18260) is that it does not limit repeated attempts to guess the key, so the restriction can be brute forced. The second (CVE-2026-81269) is that enabling the restriction does not invalidate the relevant caches, so previously cached login page responses stay reachable until caches are cleared.
The second is the interesting one, because the module works exactly as designed and the protection still fails. Anything that makes a page conditionally private has to reckon with every layer that already made a copy of it while it was public. That is a Drupal-shaped problem, and it generalizes to any CMS with a page cache in front of it.
Where Drupal security advisories actually reach you
Worth saying plainly, because it is the operational gap behind batches like this one: core and contrib advisories do not arrive with the same force.
Core advisories get attention because everyone running Drupal is running core. Contrib advisories land in a separate stream, and whether one reaches you depends on whether anyone is watching the projects your particular site happens to have installed. A ten-advisory day for contributed projects can pass unnoticed at an organization that patches core promptly, because none of the ten are on anything they think of as Drupal.
The practical control is a current module inventory checked against the advisory feed, which is a maintenance habit rather than a tool. The Slick Carousel entry in this batch is the argument for it: the fix shipped in 8.x-2.1 and was not marked as a security release at the time, so a site tracking only flagged releases would have taken the patch without knowing it mattered, or skipped it without knowing it did. Sites treating their module list as a managed inventory, in the way Drupal’s context control center approaches configuration state, are the ones that catch this.
What to check on your site
Inventory before you patch, because the exposure question differs by module. For DXPR Builder, determine whether AI agent features were ever enabled, and treat the token as burned if they were. For Entity API, the exposure requires JSON:API to be on. For Digital Signage Framework, what leaked depends on whether your block plugins do their own access checks.
Then look past this batch. The pattern is that custom routes and JSON endpoints skip the access check that the standard render path applies for free. That is worth auditing in your own custom modules, where nobody publishes an advisory when you get it wrong. Anything that serves entity data outside the normal view pipeline is a candidate, and "it is only reachable if you know the URL" is not an access check.
None of this touches core, and the security team’s broader work continues on the track we covered in Drupal’s security engineers AI initiative. This batch is a contributed-module story, which is where most Drupal risk has always lived, because it is where most Drupal code has always lived.
Frequently Asked Questions
How many Drupal security advisories were published on August 26?
Ten, covering contributed projects, numbered SA-CONTRIB-2026-108 through SA-CONTRIB-2026-117. All are rated moderately critical. Some coverage has counted nine, which misses that Disable Login Page received two separate advisories for two unrelated defects.
Is Drupal core affected?
No. Every advisory in this batch covers a contributed module. Core has its own advisory stream, and contrib and core differ in review process and in how quickly most organizations apply updates.
What is the DXPR Builder issue exactly?
The module uses a JSON Web Token for licensing, user license management, AI services and subscription metadata. In 2.x, access to API credentials in JavaScript settings is not sufficiently restricted, and when AI agent features are enabled the token is exposed to all page visitors, including anonymous ones, through drupalSettings. The exposure is conditional on those AI features being switched on.
If I patched DXPR Builder, am I done?
Not if AI agent features were enabled at any point on a public site. The token was readable by any visitor for that entire period, so it should be treated as disclosed and rotated. Patching stops future exposure; it does not un-publish a credential that was already served in page output.
Which of these should I fix first?
Sort by exploit maturity rather than by the shared “moderately critical” label. Two carry `E:Proof`, meaning a proof of concept exists: the LDAP / Active Directory Integration filter injection and one of the Disable Login Page issues. The LDAP one also requires no account, which makes it the most accessible in the batch.
Why do the same CVE numbers appear twice?
CVE-2026-81269 is listed on both the Data Field advisory and one of the Disable Login Page advisories. That appears to be a cataloging error rather than a shared root cause. Track this batch by SA-CONTRIB number, which is unique per advisory, rather than by CVE.
What connects six of the ten?
They all expose data through a path the module added, without repeating the access check that guards the standard path: a JSON:API collection endpoint, a JSON endpoint, a PDF route, a block refresh route, a JavaScript settings blob, and an LDAP search filter. Different modules, different authors, the same omission.
What should I audit in my own custom modules?
Any route, REST resource or JSON endpoint that returns entity data outside the normal render pipeline, and anything that writes values into drupalSettings. Those are the two places this batch failed repeatedly. Obscurity of a URL is not an access control, and unpublished content is the usual thing that surfaces first when the check is missing.
