Aunova Reproducible Evidence and Disclosure

Cowork:Alice RED

A public log of the open source security audits we run, including the ones that found nothing.

What this is

RED stands for Reproducible Evidence and Disclosure. It is a promise about the run and about the route it takes. It is not a badge and it is not a certification.

Reproducible
Every entry names the exact commit that was read and the run that produced the candidates, so the same run can be repeated by someone who does not trust us.
Evidence
Every entry links to the artefact behind it. Severity is our own assessment, never a tool's, and we say per entry what was checked by hand and what was not.
Disclosure
Findings go to the maintainer before they go anywhere else. Nothing that is still unpatched is published here.

Runs that turned up nothing are listed alongside the rest. A log that shows only wins is a brochure, not a record.

Timeline

Oldest on the left. Scroll the rail sideways, or give an entry focus and use the left and right arrow keys. Open an entry to read the detail.

The record is short, and stating that is the point. Four engagements against code or services we do not own have been run to date, and three of them are below. One went privately to a maintainer whose project carries no open source licence, and it will not be listed at all. The newest is not open source either: it is a hosted API reviewed from the outside, listed because the vendor answered every point and welcomed further testing. Read the outcome field on each entry rather than the count: one is fixed upstream and anybody can check that from outside, one is disclosed and its re-verification by us was not run, an owner decision the entry states plainly, and one is partly fixed with a finding held back until its fix ships. A red team that publishes only what flatters it is not worth reading.

Oldest Time runs left to right Newest
  1. 2026-08-13 disclosed FIPS Nine findings in a Rust mesh network, disclosed privately before anything was said in public
    Target
    https://github.com/jmcorgan/fips
    What we found
    An agentic SAST pass over the project at a pinned commit produced 54 raw candidates. We adjudicated every one by reading the source ourselves and reported 9, of which 7 held up under that review. They sat in three areas: a node's sessions being taken down by a party that could merely reach it, traffic being attributed to the wrong node, and a node's path MTU being steered. We also downgraded the tool's own CRITICAL rating ourselves, because its preconditions required a position on the network the rating did not assume. Severities on this page are ours, never a scanner's.
    Patch status
    Reported privately to the maintainer, who replied within a week and shipped fixes across v0.4.2 and v0.5.0, and who has since stated that the security review cycle behind those releases is closed. Two things we still will not say: we did not re-read the fixed code against our own 9 findings, so calling them verified would be our word rather than a measurement, and the release notes credit unsolicited reviews without naming anyone, so we do not claim those commits as ours. The disclosure route is what this entry evidences: the maintainer had the findings, and had shipped, before any of it was described in public.
    Evidence
    Write-up
    Read the write-up
  2. 2026-08-30 merged floci KMS mints a NIST P-521 key and reports it as Ed25519
    Target
    https://github.com/floci-io/floci
    What we found
    CreateKey with KeySpec ECC_NIST_EDWARDS25519 returned HTTP 200 and a NIST P-521 keypair while still reporting the key as Ed25519, so a caller received the wrong algorithm with no error. Signing then failed as a retryable HTTP 500 rather than a client error, which made the AWS SDK retry an operation that could never succeed. Root cause was a four character copy-paste in the KeySpec enum. Found by manual source review at a pinned commit, no scanner involved, and reproduced against the shipped container image before it was reported.
    Patch status
    Fixed upstream. Pull request 3004, authored by a project contributor, was merged into main on 4 September 2026 and closed the issue. Verified by reading the merged pull request, not on our own say-so.
    Evidence
    Write-up
    Read the report
  3. 2026-10-23 partly fixed NanoGPT API Five notes on a hosted AI API from the outside: three fixed in two days, one withdrawn, one still open
    Target
    https://nano-gpt.com/api/v1
    What we found
    A manual, low-volume review of the public API and its agent sign-in metadata from the outside, with our own key: about a dozen requests, no scanner, no fuzzing. This is a commercial hosted service, not open source, so there is no commit to pin; the run is the requests, and every check below can be repeated by anyone. None of the notes is an exploit. OAuth scopes were advertised but not enforced, and the docs did not say so, so a client asking for read-only access could expect a narrower key than it would get. There was no machine-readable way for an app to revoke its own key. HSTS lacked includeSubDomains. A ?key= parameter on the model list looked like query-string authentication. A fifth note is not yet fixed and is not described here. What held up when we tried to break it: redirect_uri validation refused seven bypass payloads with no redirect and nothing reflected, an invalid team ID fails closed instead of billing the personal balance, and errors leak no stack traces, paths or versions. We also suspected two provider-override headers of SSRF and were wrong: both were ignored.
    Patch status
    Re-checked from the outside on 25 October 2026. Revocation: an RFC 7009 endpoint is live at /oauth/revoke, listed as revocation_endpoint in the authorization server metadata, and it answers a made-up token with HTTP 200 and an empty body. HSTS: now max-age=63072000; includeSubDomains. Scopes: still informational by design, and auth.md section 3 now says so and states that a request for models.read alone is rejected. The ?key= note was ours and it was wrong: the model list is public, the parameter is ignored, and the response with a made-up key is byte-identical to the one with none, so we withdraw it. The fifth note: the vendor acknowledged it and describes a fix in progress. That rests on a private reply, not on anything a reader can check, so it stays off this page until it can be.
    Evidence
    Write-up
    No write-up published.

Field notes

Things we came across while doing other work, written up so others can check their own systems. No target is named.

Availability

This work is done in the open.

Enquiries about these open-source audits go to c@mailstr.app.