Most Severe Flaws Sit Off the Advisory Map

When security teams plan their week around vendor patch releases, they may be working from an incomplete map. Attack data published by offensive security startup Armadin indicates that the large majority of critical and high-severity weaknesses found in live tests on enterprise systems this year fell outside anything a vendor advisory would have flagged.

The report, released on November 2 by the firm founded by Mandiant founder Kevin Mandia, draws on AI-driven attacks against clients' production environments. Its central finding: 88% of the critical and high-severity issues uncovered would not have been identified through vendor advisories or other outside sources.

Armadin did not say how many organizations or individual findings the dataset covers, though it described the clients as spanning nearly a dozen industries. That omission leaves the sample size unclear, and the figures should be read as the company's own characterization of its engagement work rather than an independently verified census.

Where the severe findings lived

The report breaks the uncovered weaknesses into categories. Flaws in software the clients had written themselves accounted for 67% of critical findings and 78% of high findings that advisories could not cover.

Vendor products deployed in ways no advisory describes — the example given is administrative consoles exposed directly to the internet — made up 24% of critical findings and 22% of high ones.

The remaining 9% of critical findings, and under 1% of high ones, were zero-days Armadin discovered itself. One of those was in an identity governance platform, and the vendor took almost four months to issue an advisory for it.

The unauthenticated surface dominates

Nearly 70% of critical and high findings sat on the unauthenticated attack surface — reachable without logging in. Among the documented attack chains, 82% began without credentials, and 56% of those proceeded without a password or key ever being presented.

In more than 70% of client environments, Armadin said it reached a critical outcome in three steps or fewer without valid credentials. That characterization frames the results around speed and the absence of authentication rather than around exotic exploitation technique.

Credentials left out in the open

Just under half of the chains that started without authentication leaned on an exposed credential. Of those credentials, 71% belonged to applications or service accounts rather than to people.

Nearly 90% were reachable without any extraction step, often sitting in repositories, configuration files, backups, logs or cloud settings. In other words, the credential did not need to be stolen from a protected store — it was already lying where the attacker could read it.

Armadin described one engagement in detail: starting from an unprivileged domain account, it used a flaw in backup software to read the credentials the software held. From there it reached a hypervisor management server and, via a domain controller backup, obtained domain administrator hashes.

What it took to fix

Remediation was not a single action in most cases. Shipping application code was required in 51% of fixes for severe findings, changing a setting, permission or policy in 43%, and rotating an exposed credential in 32%, with many findings needing more than one step.

Armadin's recommendations included policies for provisioning, storing and rotating service account credentials, and checks of pipelines and code repositories for exposed secrets.

The fixing stays in-house

By Armadin's count, 93% of severe findings required no third party to act — the remedy rested with the affected organization itself.

That figure reframes the familiar patching conversation. If the weakness is in code the client wrote, or in a deployment choice the client made, waiting on a vendor is not a plan. The report's own numbers point the same way: the largest share of uncovered critical findings were in custom software, and the second-largest in vendor products configured in ways no advisory anticipated.

What the numbers add up to

• 88% of critical and high-severity findings were missed by vendor advisories and outside sources.
• 67% of uncovered critical findings and 78% of high findings were in client-written software.
• 24% of critical and 22% of high findings involved vendor products deployed outside advisory guidance.
• 9% of critical findings and under 1% of high findings were zero-days found by Armadin.
• Nearly 70% of critical and high findings sat on the unauthenticated attack surface.
• 82% of documented attack chains began without credentials; 56% of those never presented a password or key.
• More than 70% of environments reached a critical outcome in three steps or fewer without valid credentials.
• 71% of exposed credentials used in unauthenticated chains belonged to applications or service accounts.
• Nearly 90% of those credentials were reachable without extraction.
• Fixes required code changes in 51% of cases, setting or policy changes in 43%, and credential rotation in 32%.
• 93% of severe findings needed no third party to act.

A gap advisories cannot close

The report does not argue that advisories are wrong, only that they are incomplete as a measure of exposure. A vendor advisory describes a flaw in the vendor's product as shipped. It does not describe a bespoke application, an internal API, a console left facing the internet, or a backup tool whose stored credentials are readable from a low-privileged account.

Armadin's data puts most of the severe findings in exactly those places. The 56% of unauthenticated chains that never presented a password or key also suggests that the initial foothold often does not require stealing anything in the conventional sense — the material was already exposed.

The four-month lag on the identity governance zero-day is the one case in the dataset where a vendor did eventually act, and it illustrates the timing problem from the other direction: even a disclosed flaw can sit unpatched for a quarter while defenders wait.

What it means for defenders

The practical implication, drawn from the report's own figures, is that advisory-driven patching addresses only part of the severe risk in a typical environment. With 93% of fixes requiring no third party, the leverage sits with the organization: reviewing its own code, its deployment choices, and where application and service account credentials are stored and how often they are rotated.

Armadin's recommendations follow that logic — credential lifecycle policies and secret scanning across pipelines and repositories. The report's finding that nearly 90% of exposed credentials were reachable without extraction suggests that scanning where secrets live, rather than only watching for their theft, could matter more than many teams assume.

The caveat remains the undisclosed sample size. The percentages are striking, but without a count of organizations or findings, they describe Armadin's client base rather than the industry as a whole. Still, the pattern the company describes — self-written code, misconfigured vendor products, and exposed service account credentials — is one that most enterprises can check against their own environments without waiting for an advisory to tell them to.