Somebody on your staff asks whether the member-only research library is actually locked. You check. It is. The pages require a login, the permissions are set the way they were set three years ago, and nothing in the admin interface suggests otherwise.
What you checked was the configuration. What decides who can read that library is a contributed module, and on September 2 the Drupal security team published ten advisories in one day.
Where this comes from. All of the advisory detail below is from Drupal's own security advisory pages, read individually rather than from a roundup. Where we characterize what a flaw does, we are quoting the advisory rather than the coverage, because on this one the coverage and the advisory do not say the same thing.
What Shipped on September 2
Ten contributed project advisories in a single day is a heavy batch by any standard. The composition is the part worth looking at:
- Eight of ten. Eight of the ten are access bypass. One is cross-site scripting, and one of the criticals is a second cross-site scripting issue in the same project family.
- Four are rated Critical. Unpublished Node Permissions, Jsonapi Role Access, and two separate advisories against Email Verification, SMS Verification and OTP Verification.
- None of the ten marks its project unsupported. Every one of them has a fixed release. This is a patching week, not a rip-and-replace week, which is the better of the two outcomes.
Now the pattern. Three of the four critical advisories are in modules whose entire purpose is deciding who may see what. A module that grants permissions, a module that gates an API by role, and a module that verifies identity. The thing that failed is the thing you installed to do the gating.
The Two That Matter Most for an Association
The API one is the one to check first. Jsonapi Role Access, SA-CONTRIB-2026-127, is rated critical at 16 out of 25 and tracked as CVE-2026-84917. The advisory says the module does not sufficiently enforce access controls where a request mimics an XMLHttpRequest. Authentication required: none. Anything earlier than 2.0.2 is affected, and 2.0.2 is the fix. If you expose JSON:API to a front end, a mobile app or an integration, this is role-based restriction that can be walked around without logging in.
The second one is being widely described incorrectly, including in material we read this week. Unpublished Node Permissions, SA-CONTRIB-2026-132, is critical at 15 out of 25 and tracked as CVE-2026-84920. Versions below 1.8.0 are affected; 8.x-1.8.0 is the fix.
Read what it actually says. The advisory says the module allowed view access for published content, overriding other access mechanisms that might have been in place. Published, not unpublished. So the risk is not that your embargoed drafts became readable. It is that content you did publish, and then deliberately restricted by some other means, stopped being restricted, because this module's grant overrode the thing that was holding the door.
Which is worse for most associations, not better. That distinction changes what you go and look at. Drafts are not the exposure. Your members-only published library is.
Why This Shape Is Hard to Notice
An access bypass in an access-control module is close to invisible from the inside, and that is what separates it from an outage.
There is no error. Nothing breaks. The page loads for the person who should not be seeing it exactly as it loads for the person who should, which means no one reports it. Your own staff, who are logged in, see the correct behavior every time they check. And a request that succeeds does not look like anything in a log, because as far as the server is concerned it was allowed.
For a membership organization the failure is quiet in a specific and expensive way. The practical consequence is that you will not discover this by watching. You discover it by knowing which modules you run and reading the advisories against them, which is a maintenance function rather than a monitoring one.
What to Do This Week
The work splits cleanly into a same-day task and a normal maintenance window:
- Today, find out whether you run Jsonapi Role Access, Unpublished Node Permissions, or the Email, SMS and OTP Verification family. If any of them are installed, patch to the fixed release now rather than at the next window. All three are access bypass and all three sit in front of content you have decided not to give away.
- Then take the remaining six in the ordinary window. Webform Submissions Delete, Media Library Importer, Mailer Plus Log, Islandora, Monobank payment API and PhotoSwipe. Moderately critical is still critical enough to schedule.
- Separately, and regardless of which modules you run, verify the gate from outside. Log out, or open a private window, and try to reach the member-only pages, the gated documents and any JSON:API endpoint. This is the check that answers the question your staff actually asked.
- Then fix the thing underneath. If you cannot produce a current list of the contributed modules on your site and their versions, you cannot act on an advisory day like this one at all, and there will be another.
Core Is Not the Problem. Contrib Is the Job.
Associations that chose Drupal for its permissions model sometimes assume the security burden sits in core. It does not, and the September 2 batch is the illustration: ten advisories, not one of them against core.
Drupal core is maintained by a large security team on a published schedule, and it is genuinely good at this. A contributed module is maintained by whoever wrote it, for as long as they stay interested in maintaining it. That is not a complaint about contrib, which is the reason Drupal can do what it does for organizations with complicated membership rules. It is a description of where the risk actually sits, and it is not where most boards look when they ask whether the platform is safe.
The practical version of that. Every contributed module is a small ongoing subscription to somebody else's attention. The question worth asking before you install one is not whether it does the job. It is who maintains it, how recently they touched it, and whether anyone at your organization would notice if they stopped.
The Governance Point
Ten advisories in a day is not unusual for Drupal contrib and it is not a sign that Drupal is unsafe. It is a sign that the security team is doing its job in public, which is the behavior you want from a platform. WordPress publishes at a similar rate and gets less credit for it.
The thing that determines whether a day like this costs you anything is not the platform. It is whether somebody at your organization, or at your agency, reads the advisories against the specific modules you run, on the day they come out. That is an ongoing function with a name and an owner, or it is nobody's job and you find out later.
We Will Tell You What You Are Running
Start with the question at the end of the last section: can you produce a current list of the contributed modules on this site and their versions? If the answer is no, that list is the deliverable, and read-only access is enough to build it. You get every contributed module and its installed version, which of them have open advisories against them right now, which of those are access bypass sitting in front of member-only content, and the fixed release for each. The September 2 batch is checked as part of it. If nothing on your site is affected, that is what the letter will say.