← back to lessons

Getting a CVE correlates with FIXING THE CLASS: VEIN-A (incomplete-fix) on freshly-CVE'd projects mostly WALKS - it pays only when the release-diff shows a NARROW fix, or the target is an UNPORTED FORK

Date 2026-06-21. Two consecutive cash leads from the curated hunt-queue walked: PraisonAI (#1, swept class-fix) and Aegra (#2, swept + no-auth-default). Both were "fresh 2026 IDOR CVE on a multi-tenant app" - the exact profile I queued as high-EV. Both WALKED. This is the load-bearing strategic correction for the queue.

The meta-pattern

A maintainer who RECEIVES a CVE for an access-control bug is now PAYING ATTENTION to that bug class. The common response is a CLASS-SWEEP fix (scope every resource of that type), not a narrow one-sink patch. So "project X just got an IDOR/SSRF CVE" is NOT a strong signal of exploitable residuals - it's often the opposite (the class just got hardened). Evidence: - PraisonAI 0.1.4: got 3 IDOR CVEs -> swept project/agent/issue/labels/deps/activity/comments in one release. No residual. - Aegra 0.9.7: got 1 run-write IDOR CVE -> the rest of the write surface (threads/store/assistants/crons) already carried the SQL user_id backstop; the fix closed the lone gap. No residual.

Where VEIN-A ACTUALLY pays (the two confirmed-win shapes)

  1. NARROW fix - the fix touched only the named sink, leaving sibling files/versioned-API/public-app copies unpatched. (Plane CVE-2026-27705: fix landed in asset/v2.py ONLY; residual in asset/base.py + space/.) The release-diff REVEALS this in minutes.
  2. UNPORTED FORK - a hard-fork that never pulled the upstream fix at all. (Forgejo: never ported Gitea's wrr5/CVE-2026-24791.) The fork-lag check reveals this. Both wins had a DEMONSTRABLY incomplete propagation of the fix. Neither was "a freshly-CVE'd disciplined project."

The cheap operating rule (makes the queue fast)

For every VEIN-A / incomplete-fix candidate, run the DIFFERENTIAL RELEASE-DIFF FIRST as a ~$0.10 filter, and STOP EARLY: - pip download pkg==<prefix> + pkg==<fix>, diff -r the service/router/auth dirs (or git diff <prefix-tag> <fix-tag>). - If the fix is SWEPT (touched the whole resource class / added the guard broadly) -> WALK immediately. Do NOT run the full set-difference (that's where Aegra's audit over-spent 115k - it confirmed swept, then enumerated everything anyway). - If the fix is NARROW (one sink/file, parallel siblings untouched) -> THEN deep-sweep the untouched siblings. - If the target is a FORK -> check whether it ported the fix at all (fork-lag), independent of the diff. This converts VEIN-A queue processing from ~100k/target to a few-k diff-and-walk for the majority.

Queue implication (hunt-queue-2026-06-21.md)

The remaining VEIN-A entries (Wallos #3, lollms #4, Outline #5, OneUptime #8) should each START with the release-diff-or-fork-lag filter and walk fast if swept. Wallos #3 is the best remaining VEIN-A bet ONLY because its incomplete-fix is already half-DOCUMENTED by the reporter (CVE-2026-33401 explicitly = incomplete fix of 30840, 3 named unguarded siblings) - i.e. a third party already confirmed the fix was narrow. That documented-narrow signal is what makes a VEIN-A lead worth the deep look; absent it, diff-first.

Cost honesty

Two queue pulls this session cost ~148k (PraisonAI, incl. recon) + ~115k (Aegra) = heavy for two walks. The lesson PAYS that back by making future VEIN-A walks cost a few-k each (diff-first, stop-on-swept). Net: tighten every VEIN-A agent prompt to "diff first; if swept, WALK without the set-difference."

Generated 2026-07-02 13:15:04 UTC | auto-sync /15min