Rings of Risk

Even when an application’s outer perimeter is secured, weaknesses deeper in its code may combine to reach critical outcomes. A file, session or identifier accepted by one feature can cross into another that grants greater authority.

Vulnerability counts and individual severity scores do not show whether such routes exist. The Common Vulnerability Scoring System (CVSS) also distinguishes severity from risk. Rings of Risk (RoR) traces these routes and profiles each protected outcome by consequence, entry conditions, distinct supported routes and the controls that could interrupt them. Each finding is represented once in the route map and may contribute to multiple chains that reach different outcomes.

We examine 15 public open-source applications, selectively hardening exposed direct routes in six local forks. Source analysis follows code flaws together with artifacts, victim actions and ordinary processing steps. The remaining source contains potential paths to serious outcomes, including multi-flaw chains. Securing an entry point therefore cannot substitute for independent controls deeper in the application code.

Securing an application’s outer perimeter closes its most visible direct routes to critical harm. Yet lower-trust input may still cross several code boundaries and reach a privileged operation. One flaw can supply an identifier, session or file that another flaw wrongly trusts. The application therefore needs independent controls at each handoff: that is the code-level defence-in-depth problem this paper examines.

By outer perimeter we mean exposed application entry points and their prominent direct routes to critical outcomes. Addressing those routes is a specified defensive step, not a claim that every external flaw is gone. Our selective fixes create a specified before-and-after version of that scenario in open-source software (OSS) code pinned to fixed revisions. We then examine routes through the controls that remain.

Defence in depth here means independent controls within application code: authentication at entry, authorisation at the sensitive operation, tenant separation, safe file processing and checks before privileged execution. A profile-picture upload becomes consequential when attacker-controlled content reaches a vulnerable parser or worker. The upload, handoff and later operation must form a traceable path; accepting a file alone does not establish one.

Security attention may concentrate on conspicuous functions such as login, payments and customer data, while an ordinary feature supplies the first step of a serious chain. This is a motivation to trace cross-feature paths, not an observed pattern of developer or penetration-test behaviour in our sample.

Agentic tooling makes cross-feature search increasingly practical. Work on exploitation of published vulnerabilities and multi-stage activity reinforces the need to examine paths across application features. A one-finding-at-a-time report can obscure the consequential route those features form together.

This paper contributes an outcome- and capability-based risk model; a method for tracing code flaws together with ordinary or external prerequisites; and a 15-application OSS study that contrasts isolated scores with route inventories and examines routes remaining after selective hardening, including paths that the fixes break. It also visualizes how one finding can feed more than one route and how each route ends at a distinct outcome.

2.1What existing measures actually measure

Security teams need different answers from a vulnerability assessment: how severe a flaw is, whether attackers exploit it, whether the affected system matters, and what an attacker can reach through it. These are related but different questions. A single finding can disclose a token that enables a second flaw; conversely, a high-severity finding may need an identity or configuration absent from the application being assessed. A score attached to either finding does not, by itself, describe that route.

CVSS v4 classifies and rates individual vulnerabilities. Its Base score expresses technical severity, while Threat and Environmental metrics let a consumer add threat and deployment context. FIRST, which maintains CVSS, explicitly warns against using Base alone as risk. The same user guide does explain how an analyst may score a known vulnerability chain by combining exploitability and impact metrics. RoR does not claim that CVSS ignores chains. The difference is that a chained CVSS score starts with an identified chain; it does not discover the application’s routes, enumerate alternative routes to distinct outcomes or determine which code fixes interrupt them. Adding individual CVSS numbers is not the CVSS method and does not produce an application-risk score. A CVSS Base score is an ordinal severity ranking, so differences between scores are not measured differences in harm or exploitation probability.

The Common Vulnerabilities and Exposures (CVE) Program gives published vulnerabilities common identifiers; the National Vulnerability Database (NVD) enriches CVE records with CVSS, weakness and affected-product information. These are essential reference data for disclosed vulnerabilities, not a score for unpublished first-party findings or a map of an application’s code handoffs.

Exploit Prediction Scoring System (EPSS) estimates the probability that exploitation of a published CVE will be observed in the wild over the next 30 days. FIRST says EPSS is not a complete risk score: it does not include the impact or the particular deployment. It updates daily for published vulnerabilities with CVE identifiers. FIRST also cautions against multiplying EPSS by a CVSS Base score: a calibrated probability times an ordinal severity ranking has no clear interpretation. The US Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities (KEV) catalogue of CVEs with evidence of exploitation. It is an important remediation signal, not a probability. Neither can directly score an unpublished flaw in first-party code, and neither establishes whether two local findings compose. They can still inform a route’s urgency when its steps have CVE identifiers.

Combining these signals can make a published-CVE remediation queue more manageable. In a study of 28,377 vulnerabilities, Shimizu and Hashimoto report roughly 95% less urgent remediation work while retaining 85.6% coverage of their exploitation reference set. That is a result for their filtering policy and data, not an estimate of how much application risk was removed. It does not reveal routes through unpublished findings in first-party code.

CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) uses a stakeholder-specific decision tree to prioritise vulnerability response, incorporating exploitation and organisational impact. It makes a different decision from CVSS or EPSS: what action to take on a known vulnerability. A source-level route and the protected outcome it reaches could supply evidence to such a decision; RoR is not a replacement for that response policy.

2.2Application and business context

The Open Worldwide Application Security Project’s OWASP Risk Rating Methodology combines estimated likelihood and technical or business impact for a particular risk scenario. It can assess an application-specific chain when an analyst has identified one. RoR contributes a repeatable way to describe which code steps and ancillary handoffs reach each outcome before that scenario is rated. OWASP’s Top 10 is an awareness list of risk categories, not a score for one application; Application Security Verification Standard (ASVS) specifies verifiable security controls. Both help identify controls to inspect at a chain handoff, but neither is a route inventory. MITRE’s Common Weakness Enumeration (CWE) provides a vocabulary for weakness types, while ATT&CK organises observed adversary behaviour. They help name a flaw or step without assigning this application’s protected outcome or calculating a route.

The National Institute of Standards and Technology (NIST) describes risk in SP 800-30 through a contextual assessment of threats, vulnerabilities, likelihood and consequences for an organisation. Factor Analysis of Information Risk (FAIR) models the probable frequency and magnitude of loss. These broader frameworks are appropriate when there is evidence to estimate organisational impact and event frequency. This source-only study lacks deployment and loss data. Its reachability profile should therefore be an input to a risk assessment, not a numerical probability or expected-loss claim.

The NIST Cybersecurity Framework (CSF) 2.0 and OWASP Software Assurance Maturity Model (SAMM) address how organisations manage security work and improve application security practices. RoR can supply evidence about specific code paths to those programmes; this study does not assess programme maturity or whether an organisation implements their controls.

2.3Operational prioritisation and attack paths

Commercial prioritisation goes beyond CVSS Base. Tenable’s Vulnerability Priority Rating (VPR) combines technical impact and threat intelligence; Rapid7 Active Risk adds exploit and threat signals to CVSS; Qualys TruRisk aggregates findings with asset criticality and exposure. Developer-facing Snyk prioritises by severity, exploit maturity, fixability and project importance. Its reachable-vulnerability analysis can build a call graph for dependencies. These products can use deployed asset data, threat signals or dependency reachability to prioritise a finding. Our study has no deployed asset inventory or live threat telemetry; its contribution is tracing how findings and ordinary code steps connect to protected application outcomes.

Dependency call reachability can show that an application invokes a vulnerable library. RoR asks a different question: whether first-party code flaws and ordinary steps connect a stated starting actor to a protected outcome. A vendor’s priority score and that route profile can be used together.

Attack paths are also established practice. MulVAL derives attacker capabilities from facts and prerequisite rules in a network model. Topological Vulnerability Analysis represents dependencies among exploits and the paths to a network attack goal without listing every path separately. The k-zero-day safety literature asks how many unknown flaws a network path would require; its general network formulation is NP-hard. These works establish why combinations and alternative routes matter. They take host, network and configuration facts as inputs rather than deriving application-code handoffs from source. That complexity result does not describe the cost of RoR’s bounded review of known code findings.

Microsoft Security Exposure Management and Tenable Attack Path show routes among assets, identities and exposures and identify choke points for remediation. Wiz’s Security Graph similarly connects cloud and AI assets to surface consequential combinations. RoR uses the same prerequisite-to-capability idea to examine handoffs within first-party application code and its ordinary consumers: sessions, files, workflows, parsers, logs and jobs. It does not infer a network or cloud path that the source and stated deployment do not establish.

Industry analyses also use paths to narrow remediation. In a reported customer analysis, Praetorian reduced roughly 500,000 vulnerability findings to 14 endpoints exposed to complete browser exploit and sandbox-escape combinations. This is a vendor case, not a prevalence estimate for application-code chains. Cycode describes lower-severity application findings that can contribute to serious outcomes through intermediate steps. RoR takes the complete route as the unit to review, including the code handoff, starting conditions and protected outcome. Vendor examples cannot validate a proposed route in our corpus; that requires review of the pinned application source.

2.4Program analysis and agent benchmarks

Code property graphs combine syntax, control flow and data dependencies so queries can locate vulnerable code patterns. IRIS combines a large language model with static analysis to infer taint specifications and detect vulnerabilities across Java repositories. Both help discover flaws; RoR starts with findings and follows the capabilities they grant through other code and ordinary processing. VEX-Bench tests whether agents can assess the exploitability of known vulnerable dependencies in downstream projects. That is a different reachability question from composition among first-party application findings.

Agent exploitation benchmarks show why capability and outcome should be kept distinct. CVE-Bench evaluates agents against known web-application CVEs and reports that its strongest framework resolved up to 13% in that test. ExploitBench grades 16 successive capabilities on 41 bugs in the V8 JavaScript engine, from reaching vulnerable code to arbitrary code execution. AgentCyberRange tests web footholds and subsequent movement in ranges with 156 internal hosts; its best reported system solved 16.1% of web-exploitation tasks and 31.7% of post-exploitation tasks under that evaluation. These figures describe particular agents, tasks and budgets, not the likelihood of any RoR route. RoR characterises source-supported routes from a stated start, including unpublished flaws and non-code handoffs; it does not infer actual agent success from those routes. An exploit benchmark tests whether an agent achieves a specified task.

2.5Why aggregation needs routes

One reachable critical outcome is already critical. A second route to the same outcome does not double the harm, but it can increase the opportunity to reach that harm and require another fix. Route count alone is not a probability: routes may share a step or prerequisite. Administrator control and mass customer-data disclosure are also distinct outcomes despite both being critical. RoR therefore keeps consequence, entry difficulty, independent supported routes and the fixes needed to interrupt them for each protected outcome. This is the gap an isolated severity score, a threat-intelligence signal or a finding total cannot fill by simple addition.

If routes had known, independent success probabilities, we could subtract the product of their failure probabilities from one. But application routes often share a credential, vulnerable operation, victim action or deployment condition, so independence rarely holds. This study has no measured p_i values and does not turn route counts into a probability. It instead reports which outcomes each route reaches, what its entry conditions demand, and which fixes interrupt shared or separate paths. Possible route combinations can multiply while the harm of one compromised outcome remains bounded.

3.1Outcome, capability and transition

For each application, a context card identifies important functions and assets before findings are graded. Each protected outcome names the resource, operation, affected population and consequence: for example, reading customer records across tenants or executing code in the application-server process. The execution environment matters; the label “remote code execution” alone does not identify what was compromised.

A capability is something an actor can do or know, such as reading a file, supplying a workflow property, holding a role or knowing an object identifier. A transition uses stated prerequisites and a mechanism to produce another capability. The mechanism may be a code flaw or ordinary application behaviour; a victim action may also be required. Code claims cite source, while external conditions remain explicit assumptions. This prerequisite-to-capability representation draws on attack-graph reasoning such as MulVAL.

A large language model (LLM) proposes capabilities and transitions; source review tests whether each handoff works under the stated identity, permissions and configuration. A route is source-supported when those reviewed transitions connect the stated starting actor to a protected outcome. Only reviewed transitions enter the graph. Deterministic code then derives the outcomes reachable from a declared starting position. Citation existence is checked mechanically, while the source review establishes what the cited code actually does.

3.2Consequence bands and aggregation

Each band grades a specified outcome, not an application. RoR keeps distinct critical outcomes separate and does not add their bands or count additional routes as additional harm. A highest-band headline can point to the full profile, but cannot replace it.

3.3Chains and prerequisites

An attack route connects a starting actor to a protected outcome. A chain has at least two distinct security-relevant transitions: one step supplies an artifact or capability that a separate step uses to cross another trust or authority boundary. At least one step involves a code flaw. A multi-vulnerability chain contains two or more distinct code flaws. A mixed chain includes a separate, capability-changing handoff through a credential, victim action, document, browser, log, workflow or other ordinary behaviour. We record the full route and the number of code flaws separately. A prerequisite does not automatically become a chain link: SQL injection used to dump a database is one flaw’s direct route, even if it takes multiple queries. Uploading a file to trigger a vulnerable parser is likewise not a chain merely because storage and processing are separate operations. Phishing can bridge steps, but must be stated as a condition unless its role and outcome are independently supported.

A consequential chain matters even when a shorter route also exists, and it need not reproduce the outcome of a flaw chosen for repair. After hardening, we ask whether its own steps still connect to its own outcome; a route that requires patched code no longer survives. Each handoff must preserve the actor’s capability across environments: browser execution, server execution, continuous-integration (CI) execution and PDF creation are different outcomes unless code connects them.

Code-adjacent handoffs provide the search map for those connections. A file, message, credential or URL may carry attacker influence without itself being a vulnerability. The important event is its later consumption by a different principal or more privileged component. We search for the producer, carrier, consumer, trigger and resulting capability, then test that handoff against source and stated deployment conditions.

This is a catalogue of possible bridges, not a list of observed attacks. File-upload processing, log consumption, CI script evaluation and agent use of untrusted text illustrate distinct consumer boundaries. Browser content does not inherit a browser extension’s permissions; PDF scripting depends on the viewer’s controls. Crossing from a browser, viewer, runner or guest into the application server or host requires another supported transition.

3.4Access ring, reach ring and effort

The Access Ring (AR) places an attacker, or a protected asset, by the privilege tier it holds or requires. Rings are numbered from the core, as the consequence bands are, so AR1 is the innermost.

A vulnerability finding is an arrow. Its tail is the ring the attacker occupies when exploiting it, and its head is the ring the attacker holds afterwards, so its length is the number of rings it crosses: what the finding gives. A finding that discloses an identifier but confers no authority leaves the attacker in AR5 and enables a later arrow instead of moving the attacker inward. Every arrow ends in a circle. A final outcome is a circle inside the ring whose privilege the outcome puts under attacker control. An intermediate outcome is the position or capability a finding gives on the way, such as an administrator session or a leaked secret, and the next finding starts from that circle, which makes the chain and its hand-offs visible. A finding used by several routes is drawn once.

The ring and the consequence band are different measures. The band grades the harm of an outcome; the ring says where the attacker stands. A B1 Critical account takeover can end in AR3, whereas server-process execution ends in AR1. Rings are assigned from the reviewed capability and outcome of each step under a stated rule, not from CVSS: an outcome takes the ring of the privilege needed to perform that function legitimately, and a capability takes the ring of the authority it confers. Judgement calls are marked in the classification table. An enabling step that puts an account, credential or a victim’s session within the attacker’s reach, such as open self-registration, a phished password or a lure that makes a privileged user open attacker content, is drawn as a dashed arrow into the ring it reaches (AR4 for an ordinary account, AR3 for a privileged victim), and the first code arrow starts from that ring. A configuration, file or missing control gives the attacker no position of its own, so such a route starts in AR5. A first code flaw whose starting position the ledger does not record is drawn entering from outside the rings, and no starting ring is assumed.

The Reach Ring (RR) classifies a finding by what it can reach from a declared starting position. The consequence band grades an outcome; RR grades a finding’s role in reaching it. In ring terms, an RR1 or RR2 finding is a single arrow from the declared start to a B1 Critical or B2 Major outcome, whereas an RR3 finding is an arrow that ends short of the outcome and contributes only as an earlier segment of a longer path. RR4 Bounded reach describes a finding; B1 Critical describes an outcome.

Victim actions, credentials and configuration are recorded alongside each RR assignment. A route involving one code flaw and a victim action can still be RR1 Critical reach or RR2 Major reach; the action affects entry difficulty, not the code-flaw count. A finding at either level can also carry a chain flag. RR5 No established reach means that reach was not established from this starting position.

Figure 1 introduces the visual notation. The rings are drawn uncurled, as consecutive columns from AR5 at the left to AR1 at the right, so that the distance an arrow travels reads as the number of columns it crosses. Vulnerability findings are arrows that cross rings, protected outcomes are circles, and a shared finding is drawn once with later arrows starting where it ends. Dashed links mark supporting conditions such as credentials, victim actions or configuration.

For each outcome, RoR records the demands of every supported route: starting access, victim action, configuration, code-flaw count and evidence state. It then identifies the least demanding routes. When one needs a victim click and another needs an extra code flaw, neither is automatically easier; both remain visible.

An Exposure Ring can separately describe where a component sits in a deployment. This source-only study has no consistent entry-point or network policy data, so it records application entry conditions without assigning deployment exposure levels.

3.5Outcome profiles and known-route closure

RoR reports a structured profile for each protected outcome:

For each outcome, the profile contains its consequence band, the entry requirements and least demanding routes, the number of distinct supported routes, and the minimum number of fixes needed to interrupt known routes. The profile keeps different kinds of evidence visible instead of adding them into an opaque score. Outcomes at the same band can have different entry conditions and remediation work. Route count and entry difficulty indicate attack opportunity; they are not a calibrated probability of exploitation.

Closure depends on shared mechanisms. Twenty variants through one vulnerable operation that consumes attacker input may require one fix; three independent routes may require three. The field covers known supported routes. A compact profile might read:

“Critical customer-data disclosure; ordinary-account entry; three supported routes; two fixes to close the known routes.”

The underlying paths and fixes remain available for review. The current OSS ledger is an input to this profile, not a completed outcome profile. Its records include overlapping variants and unreviewed handoffs. Distinct supported-route and closure counts require those records to be adjudicated against specified outcomes.

3.6Found and residual risk

Here, ground truth means the study’s reference inventory of findings used to evaluate scanner alerts. Found risk describes outcomes reachable through findings reported by a scan and can guide remediation without ground truth. Scanner residual risk is a benchmark quantity: after treating matched ground-truth findings as fixed, it asks which outcomes remain reachable through missed findings. Post-hardening residual reach, used in this study, instead inspects routes remaining after documented fixes to pinned source. A live system’s unknown misses cannot be measured directly, so these quantities answer different questions.

4.1Corpus and route inventory

We compare the available CVSS scores for ground-truth findings with candidate route records across all 15 pinned applications. Their simple score sums are shown only to test what an additive finding-level summary conveys; they are not CVSS risk scores. The six locally changed forks provide the narrower before/after comparison. The nine unchanged repositories supply baseline source data, not observed results of a fix budget.

The chain ledgers contain 801 proposed pairs of steps for all 15 applications. A pair is a route proposal, not necessarily a complete chain to an outcome. We retain non-rejected routes labelled B2 Major or B1 Critical, remove routes requiring a patched flaw in the relevant modified fork, and collapse identical ordered first-step/second-step/outcome records. We assess whether each handoff exists regardless of any shorter route.

The result is 246 route records carrying source references: 123 beginning with a code flaw, 123 with an ancillary step, and 178 labelled with a B1 Critical outcome. An ancillary step is a condition such as a credential, victim action or ordinary application operation, rather than another code flaw. Nineteen records have a stale or imprecise source reference. These counts describe the review inventory, not 246 distinct established chains.

We inspect source, fixes and configuration without running applications. A route is source-supported under conditions when the code establishes its steps and handoffs, and any victim or deployment conditions are stated. A record with citations but an unverified capability transfer remains a candidate; contradicted or patched paths are removed. This source standard does not claim that an exploit was executed.

To identify longer paths, we also join a route’s resulting finding to another route that begins with that finding, then check whether the first step supplies the second step’s required capability, role or token. This exact-ID pass produced 54 joined path records across Budibase, Ghost, Keycloak and Open WebUI. They are overlapping graph paths, not 54 distinct chains: source review rejects the two Open WebUI empty-password LDAP joins, and some apparent Keycloak starts do not provide the DCR token required by the next step. The retained longer paths and their conditions are described in §5.2; the composed-path register records every generated path.

4.2Selective interventions

In six local forks, we fix selected direct routes from exposed application entry points to serious outcomes, then examine the routes still present in the code. Each intervention names the flaw and fix, making the before/after comparison reproducible. This models outer-perimeter hardening at the named routes without claiming that every exposed flaw was closed.

The six modified forks retain 67 route records, 39 involving two code flaws. Several share steps or outcomes, so the count is not an aggregate harm score. The fixes also eliminate some proposed chains: Gradio’s file-read patch breaks seven recorded pairs that depended on that code, including four proposals labelled B1 Critical. The intervention therefore reveals both surviving routes and routes a shared fix closes.

4.3Route assessment

For each route, we identify the lower-trust producer and carrier, the exact consumer, the trigger that brings them together, and the capability gained at that boundary. We then record the starting actor, cited code steps, credential or configuration conditions, protected outcome and execution environment. The source review checks that the produced artifact, identity or value can actually reach the named consumer with the claimed authority. We distinguish a separate capability-changing handoff from the ordinary delivery, trigger or consequence of one flaw. We also check whether a selected fix removes a required step. The question is whether this route’s steps compose to reach this outcome, regardless of another available route.

5.1The full 15-application view

All 15 applications enter the cross-sectional comparison below. Six local forks have documented changes, permitting a before/after route check; the other nine remain pinned baselines. Every application has route records labelled B2 Major or B1 Critical, but those records are not distinct harms or a completed RoR score. The CVSS column deliberately shows what simple addition yields; it is not a CVSS-sanctioned measure of application risk. Its sums describe the pinned ground-truth inventories, while the route columns use modified forks in six cases and pinned baselines in nine. The figures are descriptive inputs, not a ranking of these applications.

*Three ground-truth findings lack a numeric CVSS score (two in Budibase, one in MLflow). The sum uses the other 876 scores. Route records vary in review depth and may share steps or outcomes, so their count is not an alternative risk score. Only the six changed forks support an observed before/after comparison; placing hypothetical fixes in the nine baselines would require a separate intervention and route review.

MLflow’s ledger contains 13 conditional victim- or untrusted-artifact routes. Eleven are provisionally labelled B1 Critical and enter the table; two browser-card routes are B3 Moderate and do not. Nine routes labelled B1 Critical have source-supported processing handoffs under stated artifact or victim conditions. The MLproject-parameter and card-template routes remain candidates because attacker control of the later input is unconfirmed. No MLflow route in this ledger links two code flaws, and its pinned fork has not been selectively hardened. The ledger is a scoped source review of victim/artifact handoffs, not an exhaustive enumeration of possible pairs.

Route records cannot be read as independent risks. XWiki’s 63 include victim/configuration variants and repeated sinks; Keycloak’s 49 include specific identities and integrations. Their eventual outcome profiles must group shared routes, retain distinct outcomes and state each route’s entry conditions. A shorter route changes immediate fix priority without erasing a deeper path.

5.2Source-supported chain patterns

Artifact to processing. MLflow’s pinned fork provides a clear reason to include code-adjacent steps: an untrusted model or recipe artifact must be selected and later loaded or rendered by a user or worker. The ledger records eleven artifact- or parameter-to-processing routes labelled B1 Critical, nine with source-supported handoffs under that condition. Two more need confirmation that attacker input reaches the later command or template. These paths end in the loading or rendering process; they do not show that the public tracking server automatically executes an uploaded file.

Lower-trust content to privileged processing. In pyLoad’s credential-hardened fork, an account with the ADD permission can place content in a Downloads view. When an administrator opens it, the cited rendering flaw can run script in that administrator’s browser. A separate session-store/upload weakness is proposed as a later step toward server execution; that browser-to-server handoff still needs source confirmation. The password change leaves the cited code steps in place. The route illustrates why the browser and server capabilities must be traced separately.

Identity and permission handoff. Weblate, an unchanged baseline, shows how a low-rated permission defect could open a deeper operation. In the pinned source, ordinary permission collection skips a team that enforces two-factor authentication (weblate/auth/models.py:791–799), while global permission collection uses that team’s roles (:874–880). Project creation checks project.add (weblate/trans/views/create.py:112–115). A separate backup-restore flaw can write version-control content (weblate/trans/backups.py:918–935); later processing of that content is the proposed server-execution step. This conditional route requires a privileged password, the specified team policy and that later processing trigger. It is not an anonymous-entry route.

Privileged browser to server. Ghost’s local fix closes the selected anonymous Content API route. Remaining records propose a different path: attacker-influenced Portal content reaches an administrator’s browser, then a browser/session capability is used toward a theme-helper path to server execution. The relevant code-step files remain after the fix. An obsolete fixture citation and an incomplete permission handoff prevent those records from establishing the full server outcome yet; they identify a concrete cross-boundary path for adjudication.

Routes a fix actually breaks. Four proposed Gradio file-read chains labelled B1 Critical used CVE-2023-51449 as their second step. The local fix removes that step, so those chains do not survive in the modified fork. Other Gradio records involve a victim browser reaching localhost or share=True tunnel behaviour. The browser, tunnel and CI runner remain distinct environments; the source does not connect them into one server-execution chain.

Other proposed routes use an identifier disclosed before a gated Flowise or Langflow operation, an Airflow log or import error as an information carrier, an n8n OpenID Connect flow requiring a real identity-provider account, or Open WebUI content rendered in a browser before PDF creation. The catalogue directs attention to the next consumer in each case. Reading a log does not execute it; exporting a PDF does not run embedded code. None of the reviewed source routes establishes a malicious browser extension or virtual-machine escape.

Longer compositions and shared findings. Joining source-reviewed route segments shows why a finding list alone hides route structure. In Budibase, CVE-2026-73406 exposes identity information that can feed the SSO account takeover in CVE-2026-73302; the resulting global account session can reach a separate license-control flaw (GHSA-4wr8-5c3p-rjcr). This is a conditional three-flaw path to account and license control. In Ghost, a staff password hash exposure can feed a device-verification bypass; the resulting staff session can then reach separate administrator or staff operations. Four recorded hash-source findings and three downstream outcomes produce 12 ledger combinations, but they share mechanisms and are not 12 independent chain types. In Keycloak, a valid initial-access token can open a DCR client management flaw, a victim administrator’s visit can create an admin session, and separate realm-permission and component/LDAP flaws can extend that session to server execution. The route depends on the token, victim action, role and component configuration.

Long end-to-end paths also include non-code stages. In Weblate, a compromised privileged password, a team 2FA/global-permission flaw, project creation and backup/VCS processing form a conditional path involving two code flaws and a later worker operation. In pyLoad, low-privilege content reaches an administrator’s browser, then a separate server-side flaw; the victim’s view is the bridge. These paths have more attack stages than code flaws. A finding shared by several paths is counted once in the map and appears in every route that uses it.

The 54 joined records are a mechanical search result, not the study’s chain count. Exact finding-ID joins find only links represented in the ledgers; capability-based joins can also connect a credential, role, artifact or ordinary operation to another vulnerable feature. The composed-path register lists all 54 generated paths, including rejected joins, and the full route register lists all 246 underlying route records. The present review supports longer candidate families; it does not claim to have enumerated every possible capability-based composition in all 15 repositories.

5.3Repository route maps

Figures 2–16 in the paper show one Access Ring map for each pinned application, with the rings drawn uncurled from AR5 (left) to AR1 (right). Vulnerabilities are labelled V1, V2, … and each map’s legend gives the audit identifier for every code. Each map includes every source-anchored route record in the current audit. A finding used by several routes is drawn once. Dashed amber steps are supporting conditions (credentials, victim actions, configuration, files) and are not counted as vulnerabilities.

Rings are assigned from the reviewed capability and outcome of each step under the rule in §3.4; judgement calls are marked in the classification table. Where the ledger does not record a starting position for a first code flaw, its arrow enters from outside the rings and no starting ring is assumed. Exposure Rings are omitted because the snapshots carry no deployment position. Full source gates and conditional assumptions remain in the route register and the route audit.

Final outcomes listed with the Access Ring they sit in and their consequence band (B1 Critical, B2 Major). All are conditional candidate routes, not observed attacks.

6.1What selective hardening changes, and what it does not

Securing an exposed direct route changes what an attacker can reach most easily, but leaves the rest of the application’s code to assess. The six changed forks retain route records through other weaknesses and ordinary conditions, some labelled B1 Critical. Gradio also shows that one fix can remove several proposed chains sharing a vulnerable step. The relevant result is therefore the path left after each named fix: which handoffs still connect to which protected outcome, and under what conditions?

The 1,000-to-ten example illustrates why a small backlog does not establish low risk; it is not a reduction measured here. Our intervention targeted ten finding IDs across five forks and an administrative credential condition in a sixth. It tests how named fixes affect recorded routes, rather than how often such chains occur across production software.

6.2Implications for remediation and scanners

Remediation should follow outcomes and routes. A flaw with a bounded effect alone may become urgent if it supplies the identifier or authority needed by a critical path. A proposal labelled B1 Critical with an impossible handoff should be rejected. Teams can then see whether one fix interrupts several routes or whether independent routes to the same outcome need separate controls.

Two scanners with equal finding recall can leave different protected outcomes reachable through their misses. RoR’s benchmark residual-risk measure makes that difference visible. The six modified OSS forks address a related question: which routes remain after documented fixes? Both views move evaluation from finding totals toward consequences.

6.3Agent-assisted search

Agent-assisted search can explore cross-file and cross-feature paths that single-finding triage misses. Its value here is to propose consequential handoffs for source review, not to assume every proposed path works. Defence in depth means tracing and breaking those paths in code so that one failed control does not grant the next protected capability.

6.4From a list of findings to a map of chokepoints

A list of vulnerabilities ranks each finding alone. It cannot show which findings hand an attacker the same position, or which single finding stands between that position and the crown jewels. The Access Ring maps add both. Each circle is a position that several findings can reach, and each arrow is a finding that moves the attacker from one position to the next. Counting the routes that share a circle or a finding turns the same inventory into a statement about where a fix removes the most paths. Three patterns appear across the fifteen maps.

Dispersed chains. Airflow and Budibase are ordinary applications whose routes do not share a centre. No circle carries more than two route records (Airflow: five records over eight findings, each circle on one record; Budibase: eleven records over fifteen findings, the busiest circle on two). Reaching AR1 takes a separate chain each time: one route in Airflow and two, through different findings, in Budibase. Here the map confirms that no single fix removes the exposure, so findings are best treated one by one, and the ring view shows which of them completes a route into AR1.

A convergent chokepoint. Ghost has twenty-one route records, and twelve of them end in AR1 through one finding, CVE-2026-29053 (server-process execution). Twelve different findings lead into that finding through seven circles at AR3, all of which are administrator or owner positions. The busiest, i4 (an administrator session reached through a victim), is entered by six findings alone. A list presents these thirteen findings as separate items. The map shows that one of them guards the route to AR1 for the other twelve, so correcting the step between the AR3 circles and AR1 removes every AR1 route in the ledger, while correcting any one entry finding removes only its own route. A second, smaller chokepoint sits one ring out: CVE-2026-22594 carries the four routes that start from a cracked staff password.

Interlocking chains. Keycloak has forty-nine route records over twenty-two findings and twenty intermediate circles, and its chains cross. Three structures stand out. First, one finding, CVE-2025-13467, ends all thirteen AR1 routes. Second, the circle for a delegated administrator session (i13) carries twenty of the forty-nine records, entered by ten findings and left through two. Third, the standard-user circle (i17) is entered only through supporting steps (seven credentials, registration tokens and issued accounts), never through a code flaw, and eight findings leave it towards seven different outcomes. Because the routes leaving i17 end at AR2 or AR3, reaching AR1 from there depends on joining them with the realm-administrator routes, which the composed-path register treats as candidate joins still subject to token and role review. The practical reading is that the controls behind those seven steps (how initial access tokens are issued, who may register, how credentials are handled) deserve review to the same standard as the code, since a failure in any one of them opens several routes at once.

This selected corpus cannot estimate chain prevalence across production software or establish how organisations prioritise review. Advisory/version matches and merged finding rows may be imperfect. The ledgers contain route variants, free-text outcomes and conditional assumptions; their B2 Major or B1 Critical labels need confirmation against exact resources and affected populations. We reviewed selected code handoffs and 54 exact-ID path joins, not every possible capability-based composition, and did not run the applications. A source citation locates evidence; it does not by itself establish a capability transfer.

Securing an application’s outer entry points does not settle the risk deeper in its code.

Weaknesses can compose across ordinary features, identity checks and privileged operations; independent controls at those handoffs are the code-level defence in depth that matters. Rings of Risk expresses this risk per protected outcome, showing consequence, entry conditions, distinct routes and the fixes needed to interrupt known paths. Across 15 OSS applications, selective hardening in six local forks leaves a substantial route inventory while also breaking chains that share patched code. The remaining source paths need outcome-level adjudication, but they already show why counting fixed findings alone cannot answer what remains reachable.

Evidence record

Supporting files are in the project repository: github.com/kolega-ai/rings-of-risk.

• Fork manifest: pinned revisions, selective fixes and resulting local heads.
• Static route audit and count notes: 15-repository table, 246-route inventory and source-reference gaps.
• Attack-vector chain review, full route register and 54-path exact-ID register: longer path families, shared finding reuse and rejected joins.
• Full chain map and non-code surface catalogue: conditional handoffs and environment distinctions.
• Ground-truth audit: 879 finding rows.
• All-15 CVSS comparison and six-fork fix-budget pilot: descriptive score inputs and the limits of current route-priority claims.

References

1. [1]FIRST. CVSS v4.0 User Guide.
2. [2]FIRST. EPSS FAQ.
3. [3]CISA. Known Exploited Vulnerabilities Catalog and SSVC Guide.
4. [4]OWASP. Risk Rating Methodology, Top 10 and ASVS.
5. [5]NIST. SP 800-30 Rev. 1: Guide for Conducting Risk Assessments.
6. [6]FAIR Institute. FAIR Standard v3.0.
7. [7]Tenable. Vulnerability Priority Rating and Attack Path.
8. [8]Rapid7. Active Risk strategy.
9. [9]Qualys. Understanding TruRisk Score.
10. [10]Microsoft. Security Exposure Management attack paths.
11. [11]Ou et al. MulVAL: A Logic-based Network Security Analyzer. USENIX Security, 2005.
12. [12]IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities. 2024.
13. [13]CVE-Bench: A Benchmark for AI Agents’ Ability to Exploit Real-World Web Application Vulnerabilities. 2025.
14. [14]AgentCyberRange: Benchmarking Frontier AI Systems in Realistic Cyber Ranges. 2026.
15. [15]MITRE. Common Weakness Enumeration and ATT&CK.
16. [16]CVE Program. Overview; NIST. NVD CVE FAQ.
17. [17]Snyk. Create a fix strategy and reachable-vulnerability analysis.
18. [18]Wiz. Cloud and AI Security Platform.
19. [19]NIST. Cybersecurity Framework; OWASP. SAMM.
20. [20]Shimizu and Hashimoto. Vulnerability Management Chaining. IEEE Access, 2026.
21. [21]Jajodia, Noel and O’Berry. Topological Analysis of Network Attack Vulnerability. 2005.
22. [22]Wang et al. k-Zero Day Safety: A Network Security Metric for Measuring the Risk of Unknown Vulnerabilities. IEEE TDSC, 2014.
23. [23]Yamaguchi et al. Modeling and Discovering Vulnerabilities with Code Property Graphs. IEEE S&P, 2014.
24. [24]Lee and Brumley. ExploitBench: A Capability Ladder Benchmark for LLM Cybersecurity Agents. 2026; Shi et al. VEX-Bench. 2026.
25. [25]Praetorian. Exploit Chain Analysis. 2026; Cycode. Attack Chaining. 2026. Both are vendor accounts.