The week security controls defaulted to allow, not deny

We picture a breach as a strong lock beaten by a stronger attacker: a clever exploit, a memory-corruption chain, a password finally guessed. This week the locks did something simpler, and worse. Asked a question they could not answer, they answered yes.

Of the 8,370 events our desk reached a logged decision on in the past week, we judged seven worth publishing. Four of them were not an attacker overpowering a control. They were a control that, faced with an error, a race, a missing check, or a request it could not place, defaulted to letting it through. A fifth, a web firewall, went a step past standing aside and ran the attacker's command itself. The useful story of the week is not a bug class. It is a direction. When these controls gave way, they gave way open.

Fail open is a decision, not an accident

Apache Camel's OAuth component is a gate. Its job is to verify a caller before a request reaches a protected route. CVE-2026-80312 is what happened when it could not verify one. Rather than stop the request, the processor handed control to the route anyway, so an unauthenticated caller arrived as if signed in. The project maintainer published a defensive reproducer that shows the tell plainly: a request carrying no valid credential comes back 200 where it should come back 401. The fix is in the current release lines. (our write-up.)

In safety engineering this is the line between fail-open and fail-closed, and it is a choice made in advance, not a surprise sprung at runtime. A turnstile that unlocks when the power dies fails open; one that stays locked fails closed. Software makes the same choice every time it meets a state its author did not plan for. The secure default is almost always to deny, because the price of wrongly refusing a legitimate user is an error message, while the price of wrongly admitting an attacker is everything behind the gate. A control that leans the other way is not slightly weaker. It is inverted: it works hardest to let people in at the exact moment it has lost the ability to tell who they are.

Three more of the week's flaws, same choice

The LatePoint booking plugin locks an account after ten wrong one-time-code attempts. CVE-2026-110653 is what the lock does under pressure. The code that tallies bad guesses reads the running total, adds one, and saves it with no lock wrapped around that sequence, so a flood of requests fired at once all see the same low total before any of them records its own. The ten-try cap never trips, and a six-digit code, one chance in a million, becomes something a machine can grind through. The control that existed specifically to make guessing pointless simply stopped counting when it mattered.

FunnelKit, a funnel builder for WooCommerce, had no missing count to lose. CVE-2026-107746 is a missing authorization check: the endpoint that hands back order data never asked who was asking. An unauthenticated visitor could pull the billing name, postal address, contact email, and phone number tied to any order in the store. The default behaviour of an unguarded endpoint is to answer, and so it answered. Absence of a check is the purest fail-open of all, because nothing failed. The deny was never written.

BeyondTrust Remote Support is the one of the four that attackers were already using. CVE-2026-102764 lives in an internal messaging component that never checked which sender a message actually came from. A remote caller holding no privileges could use that gap to run file operations against the appliance and then lift itself to root. Mandiant reports a China-nexus group exploited it as a zero-day since late August, and CISA added it to its Known Exploited Vulnerabilities catalogue on October 16. CISA listed it the same week as an authentication bypass in Ivanti Connect Secure, and the agency named the common root cause itself: a device trusting a request whose origin it never properly checked.

A month ago in this column we wrote that the week's exploited flaws were in the identity appliances themselves, the gatekeepers rather than the applications behind them (the gatekeeper was the target). The BeyondTrust and Ivanti listings are that story one rung deeper. It is not that attackers keep deciding to go after gates. It is that gates keep being built to trust by default, and trust-by-default is fail-open wearing a lanyard.

The sharpest version: a control that runs the attack

One flaw this week did not merely step aside. SiteGuard is a web application firewall, the component whose whole purpose is to read incoming requests and block the dangerous ones. CVE-2026-106931, which the vendor advisory and researchers report is being exploited in the wild, is a command injection in its statistics feature that runs commands as root on Linux or SYSTEM on Windows. The security product did not fail open and pass the request to something else; it executed the attacker's command itself, with the highest privilege on the box. A control that can be turned into the attack is the worst case of the week's lesson. The thing you install to lower risk is still software, and it is usually privileged software, which makes its own failure modes the ones that cost the most.

What this means for the servers you run

Every one of these runs on infrastructure that someone operates themselves: a WordPress host, a Java integration layer, a self-hosted support appliance, a firewall in front of an application. So the failure direction is not only the vendor's problem. It is a property you can test on your own estate, this week, without waiting for the next advisory.

Start by establishing what each control you depend on does on the unhappy path. Feed it the input it was not built for: an expired or malformed token, an identity provider it cannot reach, a burst of requests fired at once, a request with no credential at all. Note whether the answer is a refusal or a success. A control whose default is to allow when it is confused is a liability no matter how well it scores on the happy path, and that behaviour is observable in a controlled test long before an attacker finds it.

Then watch for the allow you did not expect, not only the attack you did. Most monitoring is built to catch attacker behaviour: signatures, anomalies, known-bad payloads. A control that fails open produces none of that. It produces a success. The signals are inverted, which is why the last column of the table above is written as a thing that worked when it should have refused: a protected route returning 200 to a request that carried no credential, a lockout that never fires during a burst from one address, a security component spawning a shell. Those are not anomalies in the usual sense. They are your own controls reporting that they did their job, at the moment they did the opposite.

Finally, patch the ones named here if you run them, and treat the patch as the floor rather than the finish. Camel, LatePoint, FunnelKit, and SiteGuard all have fixed releases; BeyondTrust does too, but because it was exploited for roughly six weeks before the fix, the honest move is to hunt that window rather than assume the upgrade closed it.

We reached a logged decision on about 8,370 events this week and flagged around 39 as showing signs of active exploitation to arrive at these seven. The pattern worth keeping was not in the severity scores or the bug classes, where command injection and remote code execution topped the pile as they usually do, well ahead of cross-site scripting and the authentication flaws behind it. It was in a question those counts never ask. When the control gave way, which way did it fall? This week, too often, it fell open. The work for defenders is to make sure the controls they can still change fall the other way.