Investigación de seguridadDivulgación responsableControl de accesoIDORRazonamiento whiteboxGHSA

Eight access-control flaws, disclosed in a day

Published on 2026-11-08 · Xiliux

In a single day in November 2026 I reported, through each project's official channel, eight access-control vulnerabilities in open-source software. Four received a GitHub GHSA advisory identifier —one rated critical—; the other four went to the maintainer by encrypted email. None was made public prematurely: technical details and names are withheld until a fix exists, as responsible disclosure requires.

This piece names no targets and ships no exploits. It explains the method, because that is what can be measured.

The method: reason about the code, don't scan it

A scanner matches known patterns and, against well-maintained software, comes up dry. Broken access control is not a pattern: it is an absence —a missing where, a check that lives one layer further out, two features their authors never saw together—. An absence has nothing to match.

The procedure was the same across all eight: model the system and its trust/tenancy/privilege boundaries; state the invariant in one sentence ("a user only reads resources of their own organization"); refute each hypothesis by looking in the source for the control that would make it safe; and confirm by execution, never by reading —standing the project up in a local lab and reproducing the flaw through the real path, with a positive control proving the test discriminates.

What separates signal from noise

The most honest part of the work was throwing away the false positives. A candidate that does not survive a reading of the source is not a finding: in one case, verifying the artifact reduced a list of "five vulnerable endpoints" to exactly one; in another, the project's own test proved the supposed second bug was deliberate design. Severity was reported without inflation.

What it demonstrates

Not a list of tools: measured depth. Eight broken invariants, found by reasoning about the code and confirmed by execution; four with a public advisory number; one critical, over health data. The same standard I apply to my own products —post-quantum cryptography, clinical records under Colombian data-protection law— is the one I apply when auditing someone else's: verification crosses the program boundary, or it does not count.

FAQ

Do you name the affected projects?

Not before a fix exists. Responsible disclosure delivers the detail privately to the maintainer and waits for the issue to be resolved; naming it earlier would put their users at risk. Once the advisories are public they can be linked.

Is this automated scanning?

No. A scanner matches patterns and comes up dry against maintained code. Broken access control is a missing piece of logic, found by reasoning about the source and confirmed by execution in a local lab.

← More articlesRequest a quote