Regex and Wildcard Misconfigurations in Role-Based Access Control Rules

Wildcard and regex misconfigurations in role-based access control begin with a reasonable shortcut and end with access nobody meant to grant. The rule looks bounded, but its real reach depends on the permission catalog or parser behind it. Finding that gap requires more than reading policy text. It requires enumerating effective permissions, narrowing the grants, and testing what an attacker could actually do.

Why wildcard and regex patterns in RBAC rules routinely grant more access than their authors intended

An engineer who writes a wildcard rule usually wants to keep least privilege without having to list hundreds of permissions. A pattern such as Microsoft.Compute/* makes a long role definition easier to write and keep up to date. But it hides the full permission set, leaving the author to check only a shorthand for the operations it allows. The engine can apply that shorthand exactly as designed and still grant more access than the engineer intended. Nothing has to break for the rule to overreach.

A valid rule can be unsafe because the author misunderstands its scope, because other bindings broaden its effect, or because the matched catalog later grows. The same gap appears across different systems. Azure action wildcards, Kubernetes resource wildcards, regex-based access gates, and CORS origin rules all depend on whether the engineer’s understanding matches what the system actually accepts.

How Azure's wildcard action syntax creates cross-provider privilege reach engineers cannot see

Azure action names use a hierarchy of dots and slashes, but a wildcard does not necessarily respect the boundary an engineer has in mind. Placed at a non-terminal segment, it can reach across an entire Resource Provider or across multiple providers. Custom Roles also permit infix placements such as Microsoft.*/read and */delete, giving customers more flexibility than Microsoft uses in its predefined roles. That flexibility makes authoring easier and inspection harder. So looking only at predefined roles cannot show everything that patterns written by customers can reach.

Christophe Parisel’s 2025 paper, Quantifying Azure RBAC Wildcard Overreach, treats this as a computable problem. Its Belshazaar framework defines Azure action syntax through a formal context-free grammar, then compiles wildcard expressions into explicit action sets. It also uses an ultrametric diameter metric to quantify how widely those grants spread. The math serves a practical purpose here.

A wildcard written today also matches future actions Microsoft adds under the same namespace, so platform growth can enlarge an existing grant without a configuration change by its owner. The portal does not make that expansion obvious. A review of the original role text therefore cannot establish what the role will permit after the catalog changes.

How the same expansion logic produces wildcard ClusterRoles that are functionally equivalent to cluster-admin

A ClusterRole with wildcard verbs, resources, and apiGroups grants every operation on every current and future API resource in the cluster. When bound across the cluster, it is functionally equivalent to cluster-admin, even if it has an ordinary application name. The name offers no protection against the grant. A check that only looks for explicit cluster-admin bindings can miss the same authority expressed through wildcards.

KENSAI’s analysis of 12,000 production Kubernetes clusters found that a majority contained RBAC misconfigurations severe enough to enable lateral movement and escalation to cluster-admin. It identified wildcard permissions among the five most dangerous patterns. Even wildcard read access can expose sensitive material across namespaces, including database credentials, API keys, TLS certificates, and cloud provider IAM tokens stored in Kubernetes secrets. Access to credentials can both expose application data and provide the next link in an attack.

The pods/exec create permission shows how that link can work. An attacker compromises a pod and obtains its service account token. If that account has the permission, the attacker can use it to make an API call that executes commands inside another pod running a high-privilege service account. The resulting reach depends on the target account’s privileges.

How third-party Helm charts and operators ship wildcard defaults that persist silently into production

Teams can enforce least privilege in their own workloads and still get broad grants from third-party software. Monitoring stacks, ingress controllers, CI/CD operators, and logging agents can ship Helm charts with wildcard or cluster-admin defaults. Those defaults become part of the cluster’s authorization model when installed. A team may scrutinize a role it wrote while accepting a dependency’s permissions as an installation requirement.

The UpgradeScope agent GitHub issue #16 documented that mismatch in an October 2026 audit. The agent’s default ClusterRole contained a full wildcard read rule, wider than its documentation said it needed. Documentation and enforcement had diverged in a consequential way. A team relying on the stated requirements rather than the manifest would not see the excess grant. The example shows why vendor descriptions cannot stand in for the policy that the API server applies.

An inherited wildcard also ages differently from an explicit permission list. Its reach can extend to future matching API resources as the cluster grows, even when nobody revisits the chart installation. Meanwhile, bindings accumulate as teams add access for debugging, pipelines, and monitoring, then rarely remove it. Time broadens the problem from both directions. The catalog gains resources while the cluster keeps grants that may no longer serve their original purpose.

How regex-based access gates fail by the same expansion logic — the pgAdmin CVE as a worked example

A regex access gate creates a similar gap when it models inputs differently from the application that consumes them. CVE-2025-13780 in pgAdmin 4, published 2025-12-11, affected the plain-text restore feature, which used a Python regex to block dangerous psql meta-commands in uploaded database dumps. The filter assumed that Python and psql treated whitespace and line boundaries alike. They did not interpret those boundaries the same way. Strategically placed whitespace bypassed the filter and enabled remote code execution on the pgAdmin host.

The regex described only part of psql’s grammar. As a result, an input could pass the gate while still becoming a dangerous command when psql interpreted it. This is not RBAC wildcard expansion in the literal sense, but the same mistaken boundary is at work. The author believes the pattern defines a safe set, while the system accepts something outside that understanding. The failure lies between the model and the interpreter.

Endor Labs’ research argues that regex-based patches are almost always the wrong abstraction for input validation because the regex must completely and correctly model the parser it guards. That is a demanding condition to verify. Spring Security’s mvcRequestMatcher vulnerability provides a parallel, where a mismatch with Spring MVC’s pattern matching allowed unauthenticated access to protected resources when a missing leading slash changed /** to ** and caused the access rule not to apply.

Why CORS wildcard misconfigurations belong in the same vulnerability class, and why conflating two different patterns causes teams to fix the wrong one

CORS belongs in this discussion because a simplified access rule can expose more than its author intended, but the dangerous configuration is not necessarily the one displaying an asterisk. An Access-Control-Allow-Origin value of * without credentials is a deliberate, spec-compliant choice for public APIs. The WHATWG Fetch specification prevents that wildcard arrangement from authorizing browser reads of authenticated responses. A broad-looking header’s effect on that risk depends on how the browser handles credentials and the origin response together.

Reflecting an arbitrary request Origin into Access-Control-Allow-Origin while setting Access-Control-Allow-Credentials to true is the dangerous alternative. With those settings, an origin controlled by an attacker can read authenticated responses through a small HTML page served from the attacker’s domain. It can look more specific than a wildcard. But copying whatever origin arrives lets origins through whether or not they are trusted.

CVE-2025-55462 affected Eramba v3.26.0, with a CVSS score of 6.5, because its /system-api/login and /system-api/user/me endpoints reflected attacker-controlled origins while allowing credentials. The flaw sat in governance, risk, and compliance software’s own authentication endpoints. Treating every CORS asterisk as critical can direct effort toward a public configuration while leaving the exploitable reflected-origin pattern untouched.

Why static scanning and compliance tooling structurally cannot catch wildcard expansion at runtime

The Belshazaar paper identifies limited visibility into wildcard expansion in Azure’s RBAC APIs and portal tools. Among the gaps it names are detecting when Microsoft’s service evolution expands existing wildcards and replacing wildcard expressions with explicit permissions while preserving intended functionality. A scanner that reads a policy without checking what it matches in the live catalog lacks the information needed to answer these questions about effective access. Running that same check all the time still leaves it without that model.

The Kubernetes equivalent is a check limited to the name cluster-admin. Such a check can catch an explicit binding but miss a wildcard role that has a different name and the same authority. Other checks may flag the wildcard itself without showing the attack path it opens up. Syntax inspection can identify a suspicious expression, but it cannot by itself describe the consequences of that expression in a particular cluster.

Bingyu Shen’s A Survey of Access Control Misconfiguration Detection Techniques describes the challenge as finding out whether a configuration meets the security goals set for it. Those goals cannot remain implicit in the author’s head if a verification tool is expected to check them. A policy with valid syntax does not prove that it does what its author intended. Inheritance, bindings that build up, and stale role membership can put more distance between the written rule and what it allows, so a policy that looks tidy in a review may give a poor picture of actual access.

What detection and remediation actually require — effective-permission enumeration, explicit scoping, and tested exploitation

Grants need to be evaluated against the system that enforces them. For Azure, that means using the direction demonstrated by Belshazaar, expanding wildcard expressions into explicit actions from the live permission catalog. For Kubernetes, it means enumerating what a ClusterRole permits against the current API server’s resource list. The catalog must be part of the review. Otherwise, the same text can receive the same approval after its effective reach has changed.

Only a very small set of principals, such as break-glass accounts and CD/CI pipelines, should use wildcards, while other principals should be given explicit actions. In Kubernetes, namespace-scoped Roles should replace ClusterRole bindings where they suffice, and pods that do not need API access should use automountServiceAccountToken set to false. Third-party Helm manifests need direct inspection even when vendor documentation supports approval. Quarterly RBAC audits should also identify stale bindings left by departed team members and decommissioned services.

Regex gates need a different replacement for the same reason. They should use the application’s parser rather than a secondary regex that attempts to reproduce its grammar. A matching rule is not a parser substitute. Using the same parser keeps security from depending on two separate ways of reading every relevant input agreeing with each other.

Testing should go beyond reporting a broad pattern and show an escalation path that works. A demonstrated chain from a compromised pod to cluster-admin distinguishes a proved outcome from a suspected one, because the reachable service accounts determine the actual blast radius. That work requires whitebox access to RBAC manifests, Helm defaults, and cloud IAM configurations. Blackbox testing cannot enumerate role definitions it cannot read, while partial greybox access can miss inherited defaults.