tinyauth CVE-2026-97736

Requires a tinyauth deployment (before 5.1.3) that enforces path/route-based access rules via regular expressions, where at least one 'allowed' route string exists that an attacker can append to a restricted path. Because the vulnerable regex is unanchored, appending the permitted substring makes the rule match and the auth decision pass. Limiting factors: the attacker must know or infer the allowed route patterns and how rules are structured (reflected in AC:H); deployments that do not use regex allow-rules, or that fully anchor their patterns, are not exploitable. No authentication and no user interaction are needed (PR:N/UI:N), and the flaw is remotely reachable over the network wherever tinyauth fronts an application.

This is a moderate-severity access-control weakness, not a top-tier emergency. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N = 5.4) indicates a network-reachable, unauthenticated (PR:N) bypass but with high attack complexity (AC:H) because success depends on the specific regex-based access rules configured in a given tinyauth deployment, and only limited confidentiality/integrity impact (C:L/I:L) on the protected upstream. Scope is changed (S:C), consistent with tinyauth being a forward-auth gatekeeper whose failure exposes a separate backend application. No EPSS score, no CISA KEV listing, and no explicit POC are present in the provided intelligence, so exploitation is not confirmed to be occurring - the only source is the vendor's own GitHub security advisory (GHSA-r27r-rr9v-vv37) via MITRE. There is no conflict between the description and the CVSS vector: an unanchored regex genuinely permits an unauthenticated remote request to slip past rule matching, matching AV:N/PR:N/AC:H. Overall this is a real but conditional bug - priority scales with whether a deployment actually relies on tinyauth path rules to protect sensitive routes; it is not a high-real-risk drop-everything issue absent evidence of exploitation.

An attacker crafts a request to a protected/forbidden path and appends a string matching an allowed route so that tinyauth's unanchored regular expression still matches the allow rule, causing the forward-auth check to pass and the reverse proxy to serve the protected upstream resource. No credentials are required (PR:N), but the attacker must know or guess the allowed route patterns and the deployment's rule structure (AC:H). No public exploit code is identified in the provided data, though the vendor advisory describes the bypass technique.