Your finding list has no criticals. That is not the same as no critical risk.

A post published on dev.to under the title "The Endpoint Wasn't Vulnerable. The Attack Chain Was." opens with an assessment whose first finding was not critical, not interesting, and involved no SQL injection, no remote code execution and no authentication bypass, just an API endpoint that should not have been exposed ^[1]. It matters because the standard security deliverable, a list of findings each stamped with a severity, cannot represent the thing the author is actually describing: a forgotten endpoint that exposes functionality, functionality that reveals an authorization weakness, a weakness that provides access to another service, and a service that trusts information it should not, which together become a serious attack path ^[2].

Look at the arithmetic of the example report the post uses: Finding #1 Low, Finding #2 Medium, Finding #3 Medium, Finding #4 Informational ^[3]. Nothing in that list is rated above medium ^[5]. The same post then draws what an attacker sees instead: A leading to B leading to C leading to D leading to impact ^[4], four stages for the four findings ^[6]. Same evidence, two incompatible summaries. One of them gets triaged into next quarter.

The mechanism of the undercount is compositional, and the post is precise about it. A scanner asks whether a component is vulnerable; the tester should also ask what happens when this is combined with something else, which the author frames as a core difference between vulnerability scanning and offensive security ^[7]. In the worked example, an endpoint list containing /api/v1/profile, /api/v1/orders and /api/v1/payments also contains /api/v1/internal/status, undocumented, absent from the primary workflow, and apparently exposing information meant for internal systems ^[8]. Written up alone it reads as undocumented functionality exposed to an untrusted client, not necessarily critical, but an entry point ^[9].

The next question is not whether the endpoint breaks but what it trusts: a header assumed to come from an internal proxy, a parameter assumed to be generated by a trusted service, an identifier assumed to belong to the authenticated user, a role value assumed to have been validated elsewhere ^[10]. Those assumptions are the trust boundaries, and the post argues that is where interesting vulnerabilities appear ^[11]. In its sketched architecture of gateway, application, user service, payment service and internal service, every arrow is a trust relationship, and an attacker may not need to compromise every component, only the relationship between them ^[12]. Authentication is not authorization: proving who you are does not prove you may read order 1042, which is the broken access control class ^[13]. So the tester follows the value after it leaves the public API and asks whether the second service performs its own authorization check, on the principle that the further data travels the more assumptions accumulate ^[14]. The internal service is not internet-facing, which is good, but the application can reach it, and it assumes requests arriving from the application are what they claim to be ^[15].

Two honest caveats. This is an illustrative walkthrough built on an invented application, not a named client incident with dates or counts ^[16]. And the published text stops mid-sentence at the internal service's trust assumption, which is the exact point where the chain would have paid off ^[15].

The practical consequence for anyone commissioning testing is a contract question, not a technical one: does the report include the path graph and the cheapest single link to cut, or only the inventory. If your remediation queue is sorted by severity, a chain of mediums never reaches the top of it.