A Drupal API-auth module that fails open: no key generated, no authentication
Most authentication bugs are a wrong check. The one that landed on Drupal.org on November 4 is a missing precondition: a module that gates your REST and JSON:API endpoints with an API key, and that quietly lets everyone in when no key exists yet. I run a lot of "enable the module, configure it later" installs, so this one made me stop and re-read my own checklist.
What the advisory says
SA-CONTRIB-2026-298 covers the contrib module rest_api_authentication (REST & JSON API Authentication for Drupal). It is rated Critical, 17/25, vulnerability type access bypass, and carries CVE-2026-122067. Every version earlier than 3.2.1 is affected.
The description is short: the module "doesn't reject requests when the application API key hasn't been generated." An unauthenticated attacker can bypass authentication and may read or modify protected resources. The advisory scopes the exposure precisely: you are affected when API authentication is enabled but no key exists. The risk vector reads AC:Basic/A:None/CI:Some/II:All/E:Theoretical/TD:Default, so no authentication, basic complexity, and full integrity impact, with no public exploit code at the time of writing.
Why a fail-open default is the interesting part
I haven't read the module's source line by line, so I won't pretend to describe the exact comparison. What the advisory describes is a classic shape, though: the code compares the key a client sends against the key the site has stored. If the stored key is empty, "nothing to compare against" is treated as "nothing to enforce". The safe behaviour is the opposite. An enabled gate with no credential configured should refuse every request until someone finishes setup.
That is a fail-open versus fail-closed choice, and it matters most in the window right after installation. Think about how people actually deploy: install the module through Composer, import configuration, turn authentication on, and generate the key in a later step, or on staging but not production. Between those steps your /jsonapi and REST resources are protected only in the UI's sense of the word.
The advisory's workaround is worth quoting in spirit because it shows how little the exposure needs: if you can't upgrade straight away, generate an API key, then check your logs for suspicious access by administrative users. That second half is the part I'd take seriously. Generating a key closes the hole going forward, but it tells you nothing about what happened while it was open.
What I'd do about it
First, find out whether you are even exposed. Run composer show drupal/rest_api_authentication (or check the module list) and compare against 3.2.1. If you are on an older release, upgrade, then confirm in the module's settings that a key actually exists rather than assuming it does.
Second, test the failure mode directly. Request a protected endpoint with no credentials and with a wrong key, and make sure both return 401 or 403. It takes a minute, and it is the check that would have caught this bug on your own site regardless of what the vendor shipped.
Third, the same advisory batch is a reminder of how much of Drupal's risk lives in contrib. The same day brought another Critical, SA-CONTRIB-2026-293 for Content Synchronizer (PHP object injection, fixed in 4.1.1), and a third, SA-CONTRIB-2026-305 for Reset Password Email/SMS OTP (fixed in 1.0.5). Core wasn't involved in any of them.
The practical lesson I'm taking away is small and unglamorous: every authentication layer I install gets a negative test in the deploy checklist, run with the credential deliberately absent. Configuration order is part of your attack surface, and a module that is "on but unconfigured" deserves the same suspicion as one that is off.